Happy 4th of July!
Hope everyone is having a fantastic 4th of July. Make sure to drink some brews and eat some BBQ!
Hope everyone is having a fantastic 4th of July. Make sure to drink some brews and eat some BBQ!
We’ve been using CSS preprocessors for some time now but it wasn’t until recently that the reasons for using them really started coalescing for me. CSS preprocessors, like LESS or Sass, basically allow you to write CSS in a more powerful intermediate language which is then compiled down to normal CSS. Like a lot of developers, when I first started using LESS I had some reservations about introducing another layer of abstraction to our development stack. However, after developing a few reasonably sized projects with LESS I’m convinced that using a preprocessor is probably a great idea for many types of projects.
Avoiding the LESS vs. Sass discussion and looking at preprocessors as a class of tools, the clearest benefits are more expressiveness and better reusability.
As a language, CSS is amazingly straightforward, it basically consists of selectors and rules which are written in flat, plain text files and then combine to style your HTML. Since there are no constructs for variables, conditionals, or functions writing CSS is simple - just fire up and editor and start making changes. The ease of writing and understanding CSS is certainly a benefit but it comes at the price of sacrificing how expressive the language can be.
Using selector specificity as an example, the benefits of the preprocessed files are clear.
Using regular CSS you might end up having rules that look like:
/* From http://lesscss.org/#-nested-rules */
#header { color: black; }
#header .navigation {
font-size: 12px;
}
#header .logo {
width: 300px;
}
#header .logo:hover {
text-decoration: none;
}Versus the corresponding LESS:
/* http://lesscss.org/#-nested-rules */
#header {
color: black;
.navigation {
font-size: 12px;
}
.logo {
width: 300px;
&:hover { text-decoration: none }
}
}Looking at the two examples, the LESS uses its structure to express how the nesting rules work and because of this has a higher information density than the regular CSS.
Another common issue where increased expressiveness is helpful is in writing semantically meaningful CSS class names. With regular CSS, the tendency was to normally end up with CSS rules that end up looking like:
.btn-blue {
color: #fafafa;
background-color: linear-gradient(top, #1e5799 0%, #2989d8 50%, #207cca 51%, #7db9e8 100%);
border: 1px solid #2F3DA8;
padding: 5px;
}
.btn-red {
color: #000;
background-color: linear-gradient(top, #a90329 0%, #8f0222 44%, #6d0019 100%);
border: 1px solid #2F3DA8;
padding: 5px;
}The trouble of course being that the CSS class names are tied to their physical appearance as opposed to what they actually mean in your app. Although its possible to write semantic class names in vanilla CSS, the difficulty arises when you’re trying to uniformly apply things like colors, padding, and borders across a range of elements. Without variables and mixins it becomes significantly harder to manage or change these semantically named classes. Looking at how Twitter Bootstrap defines buttons, its clear how much more expressive the declarations are by keeping the colors in easily changed variables:
/* https://github.com/twitter/bootstrap/blob/master/less/buttons.less */
.btn-primary {
.buttonBackground(@btnPrimaryBackground, @btnPrimaryBackgroundHighlight);
}
// Warning appears are orange
.btn-warning {
.buttonBackground(@btnWarningBackground, @btnWarningBackgroundHighlight);
}
// Danger and error appear as red
.btn-danger {
.buttonBackground(@btnDangerBackground, @btnDangerBackgroundHighlight);
}Another benefit which preprocessors introduce is better code reusability. Although CSS has imports, the amount of code which you can functionally reuse is pretty limited since existing rules can’t be included into new ones. The best you can really hope for is being able to reuse a common stylesheet across projects. Comparatively, preprocessed CSS offers mixins and functions both of which foster more reuse.
Some of the best real world examples of this are in the Twitter Bootstrap mixins.less file which includes mixins used throughout the framework. Additionally, projects that build upon the Bootstrap framework would also be able to leverage any functions or mixins Bootstrap defines further increasing reuse.
Anyway, looking at the benefits compared to the overhead of involving a preprocessor I think for any reasonably sized project you’d almost always be better of developing with one. It’s obviously going to come down to the specific project but I’d be interested in hearing everyone else’s opinion.
I was hanging out with a friend of mine a couple of days and we started chatting about the online dating space. As we were talking, we both started nodding our heads in agreement that as an outsider, the space seems relatively interesting for a couple of reasons:
Obviously, life isn’t all rosy starting or running an online dating site since there’s an obvious “chicken/egg” problem, a significant user churn rate, and of course strong competition. Anyway, since Spark Networks (owns JDate and Christian Mingle among others) is a publicly traded company I decided to skim through their annual report in search of interesting tidbits. Here’s a couple of the most interesting things:
Some interesting stuff there. Looking at their revenue number, a little back of the envelope math would suggest they’re averaging around $20/mon for subscription revenue since 260k users x $20/mon x 12 months is roughly $62 million.
Ok great, but where are the opportunities? Looking at AngelList the majority of startups seem to be focussing on building traditional dating websites with a unique hook like “date friends of friends”, “ivy league dating”, “gamified dating”. Unfortunately, given the intense competition, chicken/egg problem, and capital that companies like Spark and IAC are spending on marketing I don’t think starting a new dating site is currently the best play. I think focussing on “selling the tools to the miners” is the best bet right now, potentially around a couple of themes.
Think a virtual assistant like FancyHands but specifically aimed at online dating. Need a couple of great date ideas? The concierge has you covered. Need some help writing or polishing up your profile? Covered. As a business perspective, you’d generate monthly subscription revenue with the opportunity to generate additional revenue via referrals while costs generally increased linearly. There are a couple of companies doing this already but no one has serious traction.
It’s 2013 and users are still effectively stuck searching one dating website at a time looking for “mr right”. You would fix this by building a “meta search engine” to allow users to search all the sites they’re a member of at the same time from a single interface. There are obviously technological as well as legal constraints to this but I think the potential value add is huge. Running this as a business would be tough since you’d always be at the mercy of the individual sites who would be well within their rights to shut you down like Craigslist and PadMapper. But who knows, maybe you could negotiate favorable terms in exchange for pushing users to register for new sites.
The goal would to build a handful of “power tools” to improve the overall experience of online dating. Example tools might be a Bayesian spam filter to learn what users flag as “spammy” and automatically block similar messages. Or maybe an “expert advisor” that analyzes messages you send and recommends changes in order to improve your response rate. The business model would be simple, sell the extension in the Chrome Webstore and charge a monthly subscription fee.
Anyway, just some off the cuff ideas - would love to hear any feedback or other ideas.
A couple of days ago, a friend of mine looking to engage in the community asked me which experienced PHP developers he should follow on Twitter. An interesting question, and as I started looking through the @setfive follower list I realized we really don’t follow very many. Anyway, not wanting to leave him hanging, I put together a list of 5 developers that I thought were a good start.
This is obviously just a start, but I’d love everyone’s help to build out a list of solid PHP developers to follower on Twitter. If you leave them in the comments, we’ll pull together a single list and update this post once we have it!
Co-founder and CEO for @SensioLabs, founder and project lead for @Symfony. Tweeting from @fabpot and on the web at http://fabien.potencier.org
Husband to @meganswage and director of technology @OpenSky. @ServerGrove @Symfony @DoctrineORM Tweeting from @jwage and on the web at http://jwage.com/
Lead architect & symfony guru at @opensky. lead dev on assetic, buzz, spork. father of 3, widower of 1. Tweeting from @kriswallsmith and on the web at http://kriswallsmith.net/
Nerd, englishman, chatterbox, cake-a-holic, celery hater, Italophile, nu-melbournite, SitePoint/Flippa code monkey. I’m also @cosadici. Tweeting from @d11wtq and on the web at http://chriscorbyn.co.uk
Technologist, Architect, Open Source Advocate Tweeting from @dustinwhittle and on the web at http://dustinwhittle.com/
Creator of Drupal, Drupal project lead, co-founder and CTO of Acquia, and Mollom spam fighter. Tweeting from @Dries and on the web at http://buytaert.net/
My twitter alter-ego is all about PHP and databases. My coding addiction is financed by @liip. Tweeting from @liip and on the web at http://www.liip.ch/en
Software Developer - #Symfony2 #PHP Polish Twitter Translator Tweeting from @stloyd and on the web at https://github.com/stloyd
Board member, eZ Publish Community Project Board : Open Source Advocate : Community Management : Social Media : Civil Servant : Information / Data Engineer Tweeting from @i_robin and on the web at http://www.linkedin.com/in/robinmuilwijk
Anything Regarding Software Security, Performance, Quality and Architecture… Tweeting from @ircmaxell and on the web at http://blog.ircmaxell.com/
18 year old student enjoying programming :) Tweeting from @nikita_ppv and on the web at http://nikic.github.io/
Philosopher. Tweeting from @igorwesome and on the web at https://igor.io/
PHP and ZF Developer; crazed father of two. Tweeting from @mwop and on the web at http://www.mwop.net/
Student by day, full stack developer by night. Open-Source evangelist all the time. Tweeting from @couac and on the web at http://careers.stackoverflow.com/williamdurand
Passionate web developer, specialized in web performance and php, #Composer lead, #Symfony2 developer. Partner at @nelmio, information junkie and speaker. Tweeting from @seldaek and on the web at http://seld.be/
Developer at @Onebip. I search for the harmony between form and context. Software, science, economics. Tweeting from @giorgiosironi and on the web at http://www.giorgiosironi.com/
Last week, at Google I/O Google announced a set of sweeping changes to their Wallet product. CNet has a decent run down of what they announced but basically it boils down to the ability to “send money with GMail”, Wallet integration into Chrome to decrease payment friction, and “instant buy” with Google+. All in all, the announcements are interesting but I think what’s more exciting is the potential for Google to truly innovate in the payments space.
In the last few years, companies like Square, Dwolla, and Stripe have been innovating in the payments space but they’ve all been reliant on existing credit card infastructure. With the exception of using Dwolla as a replacement for a check, each of the companies still relies on charging a user’s credit card to complete the transaction. I think this infrastructure piece is the key pinchin for Google Wallet. If Google can sidestep the existing payments infrastructure for Wallet, like they did with the telcos for Fiber, they’ll end up redefining how digital payments work.
Ok, so they own the infrastructure now what can they do?
As far as processing payments go, cost is ultimately one of the most important factors used in picking a processor. The pricing is so opaque that FeeFighters basically built and sold a business simply by explaining in straightforward terms which processor was the best for your business. If Google had the freedom of controlling the pipes, they’d be able to lower their pricing below everyone else by introducing better risk analysis tools into their payment solutions.
Looking at how the APIs from companies like Authorize.net work, they basically only accept the minimum information required to charge a credit card and nothing more. Google would be able to modernize this by incorporating additional “verifying details” about a user to reduce the risk on a transaction. For example, a charge originating from a 2-factor authenticated Google Wallet user that is at their “home” computer is obviously much less of a risk than an anonymous user using a credit card for the first time. By segmenting risk by user, device, as well as transaction type Google would be able to offer the best rates for “normal” transactions and also accept “high risk” transactions.
Google has tried to push out the NFC powered version of Google Wallet in 2011/12 but it was immediately blocked by major American carriers because it competed directly with their ISIS solution. It shouldn’t come as a surprise that the telcos didn’t want to get relegated to “dumb pipes” for payments as well but it’s also not like ISIS has garnered any real traction either.
If Google controlled the entire stack and could successfully convert Android users to Wallet users, they’d be able to essentially pay the carriers “blood money” to lift the Wallet ban to drive adoption and then hopefully reach a more permanent deal.
Ultimately, true mobile payments need to be freed from the existing credit card restrictions and Google could be poised to deliver just that.
People have been talking about “easy” micropayments on the Internet for several years but they haven’t really shaken out. Even today, charging someone $1 for something is a huge PITA and it really isn’t even practical. Between fees and long payment forms, the micropayments still aren’t economically feasible.
With Wallet integrated into Chrome and the infrastructure under their control, Google would be able to tackle this head on by reducing the friction to completing a payment and offering different pricing models for micropayments. Think 2 click checkouts for transactions under $5 and a monthly fee of $5 for merchant accounts in good standing instead of transaction fees.
Despite some reservations, I’m excited to see what Google ends up doing with Wallet and how it ultimately influence the payments space. Another big question is what’s Facebook going to do? Revamp Facebook Credits? Start offering co-branded Facebook credit cards?
Anyway, thoughts or comments welcome.