Michael Bleigh

In the Battle of the Ecosystems, No One Wins

Wed, 27 Jun 2012 20:13:00 -0400

While I was excited today at some of the announcements Google made at I/O, I was also troubled: there was an awful lot of Google Play, which is fine, but the Nexus Q announcement just left a bad taste in my mouth. It’s a product that has cool use, but the only demonstrated use of that product is in Google’s closed Play ecosystem, a tactic that smells entirely too much like Apple.

The traditionally held dynamic is that in a competitive market, the consumer wins. Competitors force each other to innovate and also force prices low. The problem is when the competition is between large, closed ecosystems involving multimedia content, the consumer will always lose. Google may make more of an effort to make their content available cross-platform than Apple does, but at the end of the day Play is just another iTunes store. I want to see better from Google.

Closed ecosystems gain enormous inertia as consumers begin to “buy in” to them. The more purchased media I have on (iTunes/Google Play) the less appealing and more cumbersome a switch to another ecosystem becomes. This inertia counterbalances normal competitive forces allowing for effective lock-in of customers without the need to continually court and re-convince customers to stick around. This is basically Apple’s whole business model, but it isn’t sustainable forever.

Apple’s domination of the digital content space is going to come to an end, and it isn’t going to be ended by a competitor that, for all intents and purposes, is identical. It’s going to be ended by Spotify, Netflix, Hulu, and other subscription services that challenge the very nature of traditional content distribution. Simply put, I don’t ever want to buy another movie, song, or book. I want access to everything, all the time, legally and with enough flexibility to do so when and how I wish. We have the technology, we just lack the right set of licensing agreements.

If Google wants to eat Apple’s lunch it shouldn’t be announcing the fact that you can now buy DRM'ed movies in Google’s store just like you can in Apple’s. It should announce a partnership with Netflix and Spotify that lets you subscribe to both services with a single bill. It should make its Nexus Q so seamlessly compatible with popular subscription services that Apple TV seems like a joke.

I’m sick of walled-off ecosystems. I will never, ever “purchase” content that I can’t freely reformat and redistribute in whatever way I see fit. Subscriptions at least offer me a middle ground: in exchange for giving up complete freedom over my viewing experience, I pay a small amount for access to huge libraries of content. That’s the future, and that’s where I will be from now until everyone else agrees with me. In the battle of the ecosystems, the first one that draws a line in the sand and says “no” to traditional distributions will be the real winner.

The Why of Zero Tolerance

Thu, 22 Mar 2012 11:36:33 -0400

In the past couple of days the developer sphere has been ablaze with fury over sexism. Two days ago, startup Sqoot made a carelessly sexist statement in an event description. As a result, a number of high-profile sponsors including Heroku immediately pulled out of the event and a minitornado of fury was directed at the fledgling company.

Today, ire is building over the actions of the founders of Geeklist after someone pointed out the sexist nature of a video that was posted with their branding. I’ve yet to see how this one is going to turn out, but I’ll tell you what I did personally: I tweeted at them to disable my private beta account and let them know that it was because of the emerging story.

It wasn’t until yesterday that I realized just how much of an opportunity the development community has. We have long suffered from a terrible lack of gender diversity. This lack of diversity is an incredibly complex subject and I can’t begin to understand all of the contributing factors; however, the casually sexist and man-culture attitude assumed by developers certainly isn’t helping things. This issue has been slowly heating up in the past months (even years) and I think it’s finally at a boiling-over point. The furor in the past few days paints a picture of a developer community with an emerging zero tolerance policy for sexism.

But, you might say, aren’t we getting a bit extreme here? Sure Sqoot did something careless, but wasn’t the response a bit disproportional? Yes, and that’s exactly the point. A zero tolerance policy is not about the specific cases, it’s about changing the behavior of a group as a whole. If we as a community make the punishment for even casual sexism swift and incredibly harsh, we will change behavior. A simple complaint is likely to make a specific person or company think twice about behavior (although it seems less clear that this is the case with Geeklist), but an internet firestorm that results in a measurable impact (lost sponsors, lost users)? That has the power to affect the whole community. People who see these acts even from the sidelines will think about how little they want to be in the shoes of Geeklist and Sqoot and, as they interact with the community, they will be a little more mindful not to make the same mistakes.

I’m not advocating political correctness, and I think that women are (chauvinistically) painted as being oversensitive and needing to be treated with kid gloves. I love that we can say fuck in our talks when we feel like it and I don’t want to see that change. Far more harmful is language that, without ever swearing, simply assumes that women aren’t a part of this community. Until we can purge that completely from our behavior we can’t honestly say that we are doing all that we can to encourage women to join us. I’m committed to that outcome, and I think that more and more we all are.

LocalStorage? IndexedDB? What we need is Redis for the browser.

Wed, 14 Mar 2012 14:42:12 -0400

After Mozilla’s hacks blog posted an article about how localStorage is too slow and someone else said localStorage is just fine it reminded me of how frustrated I’ve been at the various proposed “solutions” for an in-browser persistence engine. It is completely ridiculous to think it reasonable to have a schema-driven store in the browser. Schema-driven stores work on the server side because engineers can run data migrations and control the flow of data. Browsers are distributed and stateless, there’s no “migration” pattern except one that is roughly lashed on using ugly Javascript conditionals.

At the same time, localStorage simply isn’t enough (though it’s better than schema stores). A pure key value store works for lots of cases but is going to slow down and cause problems with any kind of complex structuring. So what is the solution? I think a document store could make sense: it’s schemaless, simple, and you could write simple querying semantics for it. Maybe a subset of MongoDB’s functionality. But you know what would be perfect? Having Redis in the browser.

Redis gives you a simple key value store with some simple but powerful data structures on top. The interface is dead simple, the values stored are just strings (like localStorage) but with sets, ordered sets, and lists you can implement powerful (and fast) complex logic for an application.

I’m not saying that Redis should literally be ported to the browser as an engine, but I do think that the ideal in-browser store would look almost exactly like Redis. It would be able to set values on keys, have them expire, add values to lists and sets and generally be a “key value store and a little bit more.” Implementation-wise I would imagine that this would be an in-memory store that had the ability (but not the necessity) of flushing to the disk.

Here’s the reasons it would work:

Straightforward API: No complex schema migrations, just a simple API that can be used to accomplish powerful things.
Small Footprint: Redis, for all its awesomeness, has a very small footprint in terms of complexity of implementation. I believe that something akin to Redis could be taken down the standards path because, unlike WebSQL, it is simple enough for each browser vendor to implement independently.
Just Enough Power: SQL is overkill for an in-browser storage layer. Similarly, a document store would be nice to have but would also be overkill for the 95% use case. Redis gives you a simple key value store that can do just enough to cover almost everyone almost all the time.

So Mozilla, Google, Opera (heck, even Microsoft) if you’re looking for an example of a storage API that would match the web browser perfectly, look no further than Redis.

So Fantastic It's Double Fine

Thu, 09 Feb 2012 09:34:59 -0500

Today is the day that I stand in awe of the internet and the wonderful things it can do. My particular amazement is directed at the fact that yesterday Tim Schafer (a famous adventure game designer and creator of amazing things like Psychonauts and Day of the Tentacle) created a Kickstarter project to fund a new adventure game with an ambitious funding level of $400,000. Eight hours later, he met his goal. As of the time I’m writing this, the project is at $554,000.

Think about that. In eight hours the internet came together to contribute more than half a million dollars to create an original video game. Whether or not you believe that video games are a worthwhile expenditure of money the ramifications of what just happened are staggering. As a technologist fed up with the status quo of the content industry, this is a shining beacon of where things are going.

In the future it won’t be record labels and media conglomerates deciding what is worth our time and money. It will be the creators themselves convincing us directly that they are worthwhile, that they deserve a shot. I’m a proud supporter of Tim Schafer’s game and I intend to do a lot more investing in Kickstarter projects moving forward. It’s the most honest and amazing way of raising capital that I can imagine.

On the same note, everyone should contact their Senators to support H.R. 2930, the crowdfunding bill that would allow ordinary people to invest money into startup businesses for real equity. It’s currently stalled in the Senate and getting bogged down with needless extra regulation, so some action is needed to get this thing into law!

The Innovator and the Inhibitor

Wed, 01 Feb 2012 11:11:28 -0500

Two little girls, Holly and Ivy, start lemonade stands in their neighborhoods one summer. Each has about the same foot traffic and each begins by selling lemonade at 25 cents. They do this for several days and, to their surprise they’re making more than $20 a day with their lemonade enterprise. Wow!

Other kids in the neighborhood hear about how much money Holly and Ivy have been making and decide to open their own lemonade stands…and this is where things start to diverge. Holly and Ivy’s next door neighbors both open their own lemonade stands and sell lemonade for the same price as Holly and Ivy. With the new competition, that day Holly and Ivy each only make $10.

Ivy spends the evening thinking about the new competition, and resolves that she will just have to make her lemonade stand the best one it can be. The next day she offers pink lemonade and real lemon wedges to her customers. This, along with the fact that her neighbors have been buying from her for days already and she makes $18 that day. As it turns out, she’s particularly adept at making pink lemonade (even better than classic) and it’s a huge hit. The next day she finds herself swamped with business because her neighbors all told each other how delicious the pink lemonade Ivy makes is. She makes $30 in one day, a new record!

Holly spends the evening talking to her mother, who is very well connected in the neighborhood. She tells her mother that it’s not fair that Billy next door opened a lemonade stand because she had the idea first. Holly’s mom calls Billy’s mom and asks her to tell Billy not to sell lemonade anymore. Billy’s mom, a bit confused, agrees because she doesn’t really want to have to buy lemons anyway. The next day Holly is once again the only lemonade stand in the neighborhood and is back to making $20 a day. Life is good.

Ivy is so successful with her pink lemonade that her neighbor copies her recipe and, in addition, three more people open lemonade stands in the same neighborhood. “Wow,” she thinks, “I’m going to have to really do a good job to keep all of my customers with all this competition.” So she tries lots of ideas: she starts selling cookies along with the lemonade, she hand-draws little cards that give someone a free lemonade for buying five and uses her mom’s hole-punch to keep track. She’s a friendly little girl and while the other kids in the neighborhood are making a little bit of money selling lemonade (and copying her every move), Ivy’s house has become something of a neighborhood gathering point. People come just to stand and talk about the day, all the while buying cookies and lemonade. It gets so popular that Ivy has to enlist some of the other neighborhood children to help her make enough lemonade and cookies to satisfy demand. Ivy is now making more than $100 a day, and three other kids in the neighborhood are making $30 a day helping her.

Other kids keep opening lemonade stands in Holly’s neighborhood too, but each time she tells her mother that it isn’t fair and her well-connected but a bit overprotective mother dutifully calls and asks the parents of the other children not to sell lemonade: that’s Holly’s thing. The other parents are starting to grumble a bit…Holly’s mom has been a good friend but isn’t it a little ridiculous that their children can’t sell lemonade just because Holly is stamping her feet and throwing a tantrum? Holly’s sales begin to dip as the parents (who are also Holly’s customers) get fed up with this entitled little girl.

As the weather cools from the hottest part of summer, the demand for lemonade starts dropping. Ivy has proven herself a consummate innovator and begins offering coffee and hot chocolate in addition to her cold beverages. Holly gets angrier and angrier that her profits are dipping and now her mother is calling in favors with neighbors to get them to come buy Holly’s lemonade. This can only go so far, and Holly’s sales dwindle down to almost nothing. Now she just asks her mother to pay her $20 a day directly to buy lemonade because it’s not fair that people don’t want to buy it anymore. Her mother, finally fed up, says “Holly it’s November, no one wants to buy lemonade. Go find another game to play.” Holly is shocked at the audacity of her mother’s statement and stamps off to her room, throwing herself on her bed and locking the door. Holly’s mother feels a fleeting moment of guilt for being hard on her daughter, but is more relieved just to have some peace and quiet around the house for once.

Which little girl would you rather be friends with?

If Government Embraced Technology...

Mon, 30 Jan 2012 14:33:52 -0500

As an entrepreneurial software developer, I don’t usually look to the government to solve problems for me. Instead I usually try to think of ways to solve the problem (or start a business to solve the problem) myself. Sometimes, though, I stop to think about what it would be like if the government truly embraced and understood technology the way I do. Here are three big changes that might come about from such a government.

Digital Currency

Physical currency’s days are numbered. It may be some time yet before we truly replace it, but the time has come to build the systems that will eventually supplant it. The government should create a system of digital currency that would include at least these features:

Peer-to-Peer Transfer: Any digital currency must obviously be as transferrable as real currency is now, both between individuals and from an individual to a business.
Not Device-Locked: Digital currency should not be tied to some specific “card” or device except as a convenience of transfer (such as a gift). I should be able to lose my wallet without losing my digital cash.
Anonymous Transactions: Digital currency should retain the same level of anonymity as physical currency. I should be able to buy something without it being tied to an account or the destination of my funds recorded. Any kind of “tracking” of specific digital currency must only happen after court order (if at all).
Online and Offline: Digital currency should be simple to use both in person and online.

The impact of digital currency would mean an immediate boost for peer-to-peer economies that are already developing online. If everything from Etsy to eBay could be paid for in cash instead of through an intermediary the growth of individual power in the marketplace would be greatly increased, something that I think is vital to our economic future. I’m guessing that many of the ideas surrounding Bitcoin could be used for “official” digital currency.

This would also negatively affect a number of large companies. Visa, Mastercard, Paypal, and a number of players small and large would have to drastically alter their business models to cope with a convenient, universal digital currency. Since digital currency is (in my opinion) inevitable, this is not reason enough to abandon the concept but instead a warning that there will likely be lobbying interests trying to stop such a move.

Phase Out Physical Addresses

The Post Office is struggling, and plenty of people say it shouldn’t exist at all any more. I’ll avoid weighing in on that, but one thing that should exist is a central registry that maps people and businesses to physical locations without the need for physical addresses. I would propose that the identifier should be an email and the system could work like so:

The system should be entirely opt-in and completed via some kind of online form.
I should be able to map multiple email addresses to my account and specify privacy options for each. This could include the ability to reject mail from unapproved senders or get emails to approve/deny the delivery of mail.
When I mail something, all I have to do is write the email address and affix a stamp. I can just write my own email address for the return address, or I can buy verified stamps associated to my own email address. This way someone can know that the message is actually from me.
There should be publicly available APIs to allow businesses to check if an email address is associated to a physical one and what the privacy policy is for that email. This way Amazon.com can check if my email is associated to an address and, if it’s not, have me do so.
There should be special APIs that can be accessed only by delivery companies such as UPS and Fedex that actually allow dereferencing an email address to a physical address. Usage of these APIs should be tightly restricted and regulated to prevent abuse.

The impact of this would be to drastically increase the ease and convenience of sending physical packages and mail. It would also encourage a whole new industry of startups based around the ease with which delivering physical mail would be handled. It would also ease the frustration of changing address, since people are now mailing things to you, not you at some specific address.

Negative impacts mostly center around the privacy dangers of having identity-based physical mail, but these are mostly addressed by the opt-in nature of the system. I would absolutely love to see this work.

The reason the government can do the above while it would be difficult for a business is because both of these problems have solutions that only work at massive scale. If there isn’t a single digital currency that everyone can depend on using it won’t take off. If there isn’t a single accepted repository for physical address mappings they won’t be used. What other infrastructure

Automatic Tax Preparation

It’s always seemed slightly insane to me that the calculation of taxes is a burden for the citizenry and not the government. It’s seems akin to hiring a plumber who hands you a complex rate sheet and a calculator instead of a bill when the work is done.

For the millions of individuals with relatively simple taxes (the kind that are mostly just filling in numbers from W-2s and other documents into TurboTax), why can’t the government simple accept the documents themselves and send a bill or a refund? Why do we have to purchase software or hire a professional to do something that could obviously be automated if the right systems were in place?

If implemented, this would greatly disrupt the accounting industry, of course, but given the productivity gains of millions of Americans not spending hours worrying about preparing taxes each year, the benefits would far outweigh.

Technology and Politics

I’m often only thinking about politics when they start mucking about in my own technological backyard (e.g. SOPA/PIPA), but the truth is that a government that truly embraced technology could do some pretty amazing things. What grand ideas do you have that could be a reality if the government had the same know-how as a startup?

Forward: Let's Start a Political Party

Mon, 30 Jan 2012 11:40:30 -0500

I’ve never really been very interested in politics. At least, I wasn’t until SOPA/PIPA came along. The issue demonstrated for me two very important facts:

Technologists are severely under-represented in our current political system.
Technologists are capable of causing political change.

The first I’d known for ages, the second came as a surprise. I honestly never expected that my outrage and participation in activism regarding SOPA/PIPA would actually succeed. So what now? Well, we can start with crowdfunding for startups, but why not aim a bit higher?

I think it’s time for technologists to organize and get some real change happening. The Test PAC is a great start, and I think any action should recognize that we may (for now) have more success influencing current political stakeholders than becoming them, but I believe that to truly move things forward we need actual people in office. Oh yeah, and I propose we call the party Forward. Simple, to the point, and not confusing for ordinary people like Sweden’s Pirate Party. I also have a few ideas for ways to make the party successful in ways other third parties aren’t:

Large Active Member Base. It is simply amazing how many technologists joined together to fight SOPA/PIPA. I truly believe that we can have a larger base of active party members (people who actually contribute in a meaningful way) than many other third parties.
Online Organization. We already know how to organize. We can use Reddit, Hacker News, Twitter, and networks we create to build consensus and tackle specific issues in a way no other group can.
Position of Power. We are the people building and shaping the most important industry in the world, the one that continues to grow despite the global economic setback. We can use this power for demonstration like with SOPA/PIPA and we can use it for education, too.

If we can get one person into Congress it can be the same as if every member of the party was elected. Why can’t we have an elected representative who puts a piece of proposed legislation on GitHub, accepts pull requests, and then submits the collaborative bill to Congress? From there we can collectively gather support from our representatives using phone campaigns, emails, etc. It’s time to change politics, and we have the power. Who’s with me?

P.S. I created a Forward Party Reddit and would love to see discussion, links, and more there to evolve this idea and really make a difference.

This is How I Want Social to Work

Wed, 11 Jan 2012 15:27:41 -0500

I think that solving the dual problems of privacy and noise in social networking applications are very difficult. Personally I don’t think any of the major players (Facebook, Twitter, Google+) have tackled these problems entirely successfully. I did a little thinking and if I built a social network today, here’s how I would tackle the graph.

Let’s say that I just signed up for the network. As part of the sign up process I would be asked to create Topics that I might post about. By default there would be two topics pre-populated: Personal and Work. In addition, the app would suggest that I add other topics that I might be interested and give examples such as Technology or Fashion. It would also say “hey don’t worry, you can always create topics while you post”.

So far so good. Now, whenever I share something I’m encouraged to select topics from those I have already posted about. I can also create a new topic on the fly just by typing its name. “Golly gee, this sounds an awful lot like Google’s Circles” you might be thinking if you were a 1950s era television character. Wait for it, here comes the payoff.

Now I want to connect to people on the network. When I click “Follow” I’m greeted with a dialog box that says “For which topics do you want to follow X?” and presents me with a list of all of the topics that X has posted about (or I can say “all”). For my close family members I follow all topics, for friends I follow their “Personal” topic, for coworkers I follow their “Work” topic and for everyone else I follow the topics that I think I’ll enjoy reading from them, maybe “Funny” or “Ruby” or any number of other things.

This is the best solution I’ve thought of to the “noise” problem with social networks. Right now I pretty much use Twitter for work and, well, I don’t really use Facebook much but if I did it would be for personal stuff. I don’t want to bore my friends with programming observations and I don’t want to bore my coworkers with personal observations. This system makes me certain that anyone looking at my posts has pro-actively decided that they are interested in hearing from me about that.

The final piece of this puzzle is privacy. I would also have the ability to create private topics that require my approval before someone can follow me on. When someone subscribes to “all” of my topics they can check a box to request permission for private topics as well, which I can approve or deny on an individual basis. Private topics are not explicitly listed out nor are they revealed when I post to them (in this way private topics are much like Circles).

There it is, my best attempt to describe a system that maximizes privacy control, minimizes noise, and creates as small a burden as possible. The only time that this requires “work” is that I need to tag each post I make with topics, and when I follow someone I have to decide which topics I want to follow them about.

Pros/Cons

Here are some of the advantages that I see to a system like the one described above:

I believe that this solves the noise problem better than any existing system. Being able to subscribe to a subset of a user’s posts allows for specialized content without alienating followers who are interested in something else.
Brands would be able to leverage this to their advantage as well. I could follow my favorite brands, blogs, etc. but only on the types of stories that would interest me.
Gets us a little closer to “one network to rule them all” instead of needing to create a dichotomy between our personal and public lives.
Since I’m encouraged to tag every post I make, lots of semantic data can be gathered about posts and used to make content discovery and other serendipity work on the system.

Of course, there are drawbacks as well, some surmountable some less so:

The biggest problem is that people have to tag their posts accurately or none of this matters. It requires more work when I share and friction there is definitely a problem.
What happens when people create new topics? I would imagine something like the Twitter interactions pane that would say “X posted about new topic Y, do you want to follow it?”, but this would have to be tuned to be user friendly.
Users may feel tempted to follow all topics just out of fear of “missing something.”

I’m putting this out there because I’m both wondering if anything like it exists and if there are huge glaring problems with it that I’m not considering. If this isn’t the right model for social, what is?

Free-to-Play Could Crash the Gaming Industry

Mon, 09 Jan 2012 11:48:19 -0500

This post is part of my Where Games Are Going series in which I talk about the future of one of my favorite industries: video gaming.

At the same time that digital distribution is poised to level the playing field more than ever before for independent developers, another trend has the potential to cause a crash the likes of which hasn’t been seen since 1983. And it’s all Zynga’s fault.

These days you can’t throw a rock in the gaming community without hitting someone who is talking about the brave new world of Free To Play. Everyone is taking a look at the hand-over-fist cash generated by the addiction engines pumped out by Zynga (no, I won’t call them games) and wants their piece of the pie. From the expected ranks of big publishers like EA to some of gaming’s most respected brands like Blizzard and Valve, everyone is exploring “alternative monetization” for games.

But, you might say, won’t these alternative monetization strategies just lead to more people playing games and more games being made? If games are cheaper (or even free) isn’t that better for everyone? The answer is no.

Free-to-play and in-game purchase models break the incentives associated with game development. Sure, it can be done in a tactful manner and, in some cases, may even lead to a bigger audience for a great game. I haven’t played it, but I hear that League of Legends handles free vs. paid players in a very fair way. The problem is that once your money comes not from an up-front or monthly fee but from in-game purchases, you are no longer incentivized as a developer to make the game as fun as possible. Instead, you are incentivized to make players make as many in-game purchases as possible.

We don’t have to make up a worst case scenario for how this could end up, it already exists. Games like FarmVille are, quite literally, addiction engines. They are fine-tuned to draw a player in and build an obligation to continue playing and then an obligation to continue purchasing. The problem is that there isn’t really a game underneath all the addiction; it’s just a psychologically tuned profit machine.

In-game purchases might actually be more profitable in the short term. If you can convince people that they aren’t spending as much when they actually end up spending more, you’re going to make money. The problem is that in the long term people will come to realize that they are “playing” these games but not actually having, you know, fun. If the industry focuses on this model as much as I fear it is gearing up to do, the realization that games aren’t fun anymore could have sweepingly negative impact on the industry as a whole.

The video game crash of 1982 was precipitated by a glut of mediocre-to-bad titles and little information to know which ones were good and which were bad. The gaming crash of 2015 might happen after developers have stopped making games fun in the quest to make them microtransactionally profitable. Casual and hardcore gamers alike could end up feeling jaded and alienated by an industry that treats them like marks instead of players, and if that happens gaming as a whole will suffer greatly.

Personally I loathe the idea of in-game purchases. I don’t want my experience playing a game to be marred by thinking about the price of my fun. “Gee, would I have $2.99 more fun if I bought this Vorpal Sword right now?” It’s not that I’m price-sensitive, it’s that I explicitly play games to escape the pocket-conscious decision-making of the rest of my daily life and now I’m being slapped in the face with it every five minutes.

I care deeply about the gaming industry. I believe that video games helped to shape my logical thinking and problem-solving, and I know that my interest in them precipitated my interest in computers and technology as a whole which has become a passionate and fulfilling career for me. So when I talk about this problem, it’s not because I think that there is something seriously wrong with games now. I just think that many in the industry are being fooled by this mirage of a free-to-play future, and I implore these people to think twice before signing up to willfully misalign their incentive to simply make a great game.

Calling Infringement Theft is Dangerous

Fri, 06 Jan 2012 10:08:05 -0500

Note: I actually submitted this as an op-ed piece to the New York Times which is why it’s far less technically voiced than my normal work. Unfortunately looks like I’m not getting picked up there, so I’ll just have to stand on my own soap box.

One day, Terry walked into a popular record store, slid a CD into his back pocket, and left the store without paying. The same day, Ian visited his favorite file sharing website and downloaded an album (as it happens, the same one that Terry shoplifted) without purchasing it or obtaining permission from the artist. If you think that these two cases sound almost identical, then you have likely fallen prey to a spreading and dangerous misnomer that has become nearly pervasive: conflating theft and copyright infringement.

In the story above, Terry has committed theft, a criminal offense under state laws. In legal terms, theft is taking the property of someone else without consent and with the intent to permanently deprive them of the property. Ian, however, is not guilty of theft but rather copyright infringement: he has created an unlicensed copy of a copyrighted work. By downloading an album from a file sharing service he has not taken it from anywhere but rather duplicated it. While each person is entitled to his or her own opinion as to the difference in morality or ethics between the two, one thing is clear: from a legal perspective these are very different illegal actions.

Theft is a criminal offense and is punishable by a wide array of remedies including jail time. Copyright infringement, on the other hand, is a civil infraction and can incur a lawsuit but cannot be prosecuted as a criminal offense (some instances of copyright infringement do warrant criminal punishment, but not as theft). The difference between criminal and civil infractions in our legal system is great: criminal infractions must be tried with the famous burden of proof of “beyond a reasonable doubt” while civil infractions are tried in court with a burden of “a preponderance of the evidence” (that the party is more likely guilty than not). The difference in burden is attributable to the weight of punishment: one cannot be jailed for a civil infraction, only fined.

Copyrighted works such as books, movies, songs, and even software are all protected by federal law for the purpose of encouraging their creation. “Intellectual Property” is the term given to these types of works and, in the United States, we have three means of protecting intellectual property: copyrights, trademarks, and patents. Intellectual property is something that cannot be stolen because it is, by definition, intangible. You might say that someone “stole your idea” but what you really mean is that someone copied your idea. How can someone have stolen your idea if it’s still in your head? I can understand how this confusion comes about, but while it may feel like a technicality it is actually a very important distinction.

I’m not surprised when representatives of copyright holders call infringement theft; it is to their direct benefit to create a direct equivalency between intellectual property rights and real property rights. What continues to shock me is seeing this confusion trickle its way into the vocabulary of everyone from Harvard law professors to members of Congress. It is frightening to think that this misnomer is being used by the very people who are currently debating laws regarding copyright infringement with sweeping ramifications.

My plea is simply this: stop thinking that these two terms are interchangeable and using them as such. Sure, “stealing” and “theft” are shorter and sound a lot more sensationalistic and juicy when one is talking about the issue of copyright infringement. But please at least use a term like “piracy” if you want a one-word term for the behavior. It may not be any more accurate but it doesn’t share the same effect of confusing everyday people about our legal system. Until there is a law decreeing that copyright infringement is a criminal offense punishable in the same manner as theft, one thing is certain: theft and copyright infringement are NOT the same thing.

P.S. I started a Tumblr to record these misnomers, feel free to submit one if you see it.

Should we eliminate gendered pronouns?

Thu, 05 Jan 2012 16:22:38 -0500

Today I was typing up another blog post and had to use him/her as a gender neutral pronoun reference. This is something that’s always bugged me as it’s awkward to write and awkward to read. “They” is not a suitable alternative because it’s plural and therefore grammatically incorrect in a singular context.

That got me thinking: why do we have gendered pronouns at all? After reading the recent post “It’s OK to be Neither” I’m wondering if there could be a positive cultural impact from completely eliminating gendered pronouns from language. I’m not proposing what we should standardize on, but if the English language didn’t have gendered pronouns, it would:

Solve the annoying he/she him/her pronoun problem.
Make the language non-deterministic for those who believe that gender is a spectrum.
Remove a subtle but foundational part of our language that encourages gender as a vitally important differentiator.

I’m not generally an alarmist when it comes to vocabulary. I think that words only have power when we allow them to. That being said, it would be interesting to see the landscape of our society if this change were implemented.

Would it make the issue of the marriage of same-sex couples seem less “different” from the norm?
Would workplace and friend networks be more likely to cross gender lines?
Would children raised without gendered pronouns be more likely not to discriminate based on gender?

I don’t have answers to any of these questions, I just think it’s an interesting topic to ponder. All of this being said, gender differences are a part of our lives and in many ways can and should be celebrated. But referential tags can be troublesome and this is one that’s literally baked into the language. Maybe it shoudn’t be…what do you think?

Where Games Are Going: Consoles as App Platforms

Tue, 03 Jan 2012 15:01:07 -0500

I’ve been an avid gamer since, well, ever. Like many developers, an interest in video games (and creating them) is what first lured me to the world of programming. While I’m not a part of the game industry I follow it closely and have greatly enjoyed discovering such online video series as All Your History Are Belong To Us and Extra Credits this year. “Where Games Are Going” posts simply represent my observations and predictions about gaming and its future. This time, we’re going to talk about the next generation of consoles.

The current generation of consoles (Xbox 360, PS3, Wii) is going to be the last generation in which physical media (discs, carts, what-have-you) are the primary way in which new games are acquired. This is a large trend that can be seen especially in Microsoft’s full downloadable games which include AAA titles from this year, not just the older/smaller titles to which downloadable games have traditionally been relegated.

The company that wins the next generation console war will be the one who most wholeheartedly adopts the App Store model, specifically meaning a simple distribution system open to any and all developers with a constant revenue share model. I believe that Microsoft is currently best positioned to make this happen: Xbox Live is still far and away the most comprehensive console gaming community, they’ve shown that they’re willing to pull in this model with Xbox Live Indie Games, and they have Windows Phone 7 and Windows App Stores either here or on the way. That’s not to say that there aren’t a few kinks left to figure out:

Big Publishers Will Resist. The next generation of consoles is going to see content created by a single guy pitted directly against content created by a seasoned team of 100. Big established publishers will fight hard to keep themselves separate to avoid competition from smaller developers but, ultimately, they will lose. They’ve already had to accept this on iOS and Android devices, they will eventually accept it on consoles as well.
Price Will Be A Problem. A recent post on Signal vs. Noise called the physical disc/digital content price gap the Lazy Tax, but in reality the problem is monolithic price control. Microsoft and publishers alike are going to have to radically alter the game price structure to work in the new market. Games will either have to drastically lower in price at the outset or aggressively discount after the first few months. Otherwise, there will be a big swell of frustration from the gamers who are accustomed to the used and on-sale markets for getting their games. One way to get around this (but it isn’t pretty) would be to have unique unlock codes that can be purchased for games and sold by retailers. This would allow Amazon et al to discount games more like they do currently.
Non-Games Will Be Huge. The next generation of gaming consoles aren’t just going to be for games. This is already obvious with the huge push for video that Microsoft has done on the Xbox 360 but it will become even more so as the consoles from all major players will open their doors to non-game content. Even Nintendo, traditionally focused exclusively on gaming, is rumored to be jumping on the app train.
Google and Apple Will Enter the Fray. The interesting side effect of consoles becoming app platforms is that they will suddenly face competition from the existing app platforms of Apple and Google. Each platform will have to work hard to differentiate itself from the pack.

I think the next generation of consoles will be very interesting and there’s a lot that remains to be seen. Perhaps even more interesting, I think the next next gen will come from disruptive game streaming services like OnLive. As actually fast connectivity gets cheaper and more available it will make a lot more sense to stream games from big gaming rigs in the sky than to outlay a pile of cash on a home console. Once this happens, game platforms will go ubiquitous, no longer tied to any one device. Expect to be able to play full Xbox 1080 games on your Windows Phone and (maybe) even your iOS or Android device.

Why I Rarely Read Books

Fri, 30 Dec 2011 15:11:41 -0500

I don’t really read books these days. I read plenty of blogs and web development related things via Google Reader, but I almost never just sit down and read something in my free time. Sometimes I’m filled with guilt about it: surely I should be reading more, enriching my life and whatnot. But then I realized that it’s not because I hate reading that I don’t do it often, it’s because reading is anti-social.

I spend a large portion of my life reading and writing text from and to a computer screen. When I’m ready to put down the computer I’m also ready to have some actual face-to-face interaction with people. Reading is just about the only form of common leisure activity that can’t be enjoyed simultaneously by more than one person (unless one is reading aloud or being read aloud to).

Video games, board games, concerts, and even to a lesser extent movies and television are all social experiences. When I’m playing video games with my family and friends we also chat about this and that in gameplay lulls. Board games have always been social and my collection continues to grow. Movies and TV aren’t quite as social but during commercial breaks (Hulu, of course, not actual television which I abandoned years ago) or afterwards there is a new shared experience to talk about. Most forms of entertainment are about creating that shared experience. Reading is not.

Reading is an isolating experience: you have to concentrate on the story and separate yourself from the rest of the world. So I still read when I’m on a plane or alone on a business trip, when I find myself both without company and uninspired to be hacking on open source or another side project. Sometimes my wife and I even read aloud to each other when we’re both really interested in a book (or manga series). But I rarely read books these days, and I’m starting to feel ok about that.

Announcing OmniAuth BrowserID

Wed, 21 Dec 2011 00:00:00 -0500

I’ve been following the progress of Mozilla’s BrowserID for some time now, and I’m a big fan. Having dove much deeper than most into the quagmire of fragmented authentication I’ve reached the same conclusion that Mozilla has: ultimately, authentication is a function that should belong to the user agent.

What is BrowserID?

BrowserID is a Single Sign-on service for the web, much like you can implement using OpenID or even Facebook or Twitter. However, BrowserID is fantastic for its simplicity: as an implementation of a simple “verified email” protocol, it is simply a way to be able to obtain the email of a user (and know that it’s verified).

For now, this works via a Javascript authentication flow on a website that Mozilla is maintaining. However, the future of this technology is that you would verify your email directly within your browser and would then be able to sign in to supported websites using your browser itself.

But, you ask, why do we want authentication in the browser? Browsers are called User Agents for a reason: they are simply tools that help connect you to the content of the internet that interests you. And a lot of that content right now requires you to manage dozens of different passwords and store sensitive login information with a third party. BrowserID doesn’t entirely solve this problem in its nascent web-based form, but once it is integrated into the browser itself BrowserID becomes a single, secure way to access content on the internet.

BrowserID + OmniAuth

I want BrowserID to succeed, and it will only succeed if people start using it. To that end, I’ve created OmniAuth BrowserID, a simple OmniAuth strategy that works with the BrowserID protocol. You can use it in your application like this:

# in Gemfile
gem 'omniauth-browserid'

# in application
use OmniAuth::Builder do
  provider :browser_id
end

That’s it! Now send your users to /auth/browser_id and they will be able to sign in using the BrowserID service. Of course you may prefer to implement your own Javascript flow. That’s fine, too, just take a look at the project README for more information about customizing the flow.

BrowserID is an important idea and whether Mozilla’s implementation is ultimately the one that gets adopted it’s high time we started moving authentication to where it belongs: in the user agent.

Implementing DRY Magic Methods in Ruby

Wed, 16 Nov 2011 00:00:00 -0500

As a new developer to Ruby you might wonder how certain methods seem to be magically available without being strictly defined. Rails’s dynamic finders (e.g. find_by_name) are one example of this kind of magic. It’s very simple to implement magic such as this in Ruby, but it’s also easy to implement things in a way that doesn’t entirely mesh with standard Ruby object expectations.

Your Friend `method_missing`

The way that many magic methods are implemented is by overriding method_missing. This special method in Ruby is automatically called by the interpreter whenever a method is called that cannot be found. The default behavior of method_missing is to raise a NoMethodError letting the user know that the method that was called does not exist. However, by overriding this behavior we can allow the user to call methods that aren’t strictly defined but rather programatically determined at runtime. Let’s look at a simple example:

class Nullifier
  def method_missing(*args)
    nil
  end
end

nullifier = Nullifier.new
nullifier.some_method     # => nil
nullifier.foo(:bar, :baz) # => nil

Here we simply told method_missing to immediately return nil, regardless of the method name or arguments passed. This essentially means that, for this class, any method call that is not defined on Object (the default superclass for new classes) will return nil.

While this example is certainly interesting, it doesn’t necessarily give us more use in the real world. Let’s take another example that actually does something useful. Let’s make a hash that allows us to access its keys by making method calls:

class SuperHash < Hash
  def method_missing(method_name, *args)
    if key?(method_name.to_s)
      self[method_name].to_s
    else
      super
    end
  end
end

h = SuperHash.new
h['abc'] = 'def'
h.abc            # => 'def'
h.something_else # => NoMethodError

This behavior gives us something pretty simple yet powerful: we have manipulated the foundation of the class to give us runtime methods. There’s a problem, though: using method_missing alone is only half the story.

Quack Check With `respond_to?`

In Ruby, you can call respond_to? with a symbol method name on any object and it should tell you whether or not that method exists on the object in question. This is part of what makes Ruby’s duck-typing work so well. So in our example, we also want to be able to know if a method is there using respond_to?. So let’s add a new override for the respond_to? method of our example above:

class SuperHash < Hash
  def respond_to?(symbol, include_private=false)
    return true if key?(symbol.to_s)
    super
  end
end

Well, that was easy enough. Now our SuperHash will return hash keys based on method_missing and even tell you if the method is there with respond_to?. But there’s still one more thing we can do to clean things up a bit: notice how we have repeated functionality in that we check key? in both methods? Now that we have a respond_to? we can use that as a guard for method_missing to make it more confident:

class SuperHash < Hash
  def method_missing(method_name, *args)
    return super unless respond_to?(method_name)
    self[method_name].to_s
  end
end

Wait, that can’t be right, can it? Can we just assume that we can call the key like that? Of course! We already know that no existing method was called if method_missing is activated. That means that if respond_to? is true but no existing method was called, there must be a key in our hash that caused respond_to? to return true. Therefore we can confidently assume that the key exists and simply return it, removing the conditional and cleaning up the method_missing substantially.

Now that you know how method_missing and respond_to? can work together to add functionality to an object at runtime, you have a powerful new tool in your metaprogramming arsenal. Enjoy it!

OmniAuth 1.0: Auth for All

Wed, 02 Nov 2011 00:00:00 -0400

Today I’m happy to announce that OmniAuth version 1.0.0 has been released into the wild. The result of more than a month of heavy development, the newest version of OmniAuth brings along with it a slate of new features, a whole new structure, and the tools to let OmniAuth be your only authentication library. The one thing that hasn’t changed is OmniAuth’s mission: to assume nothing about how your app works and what you want to do with authentication.

Breaking up the Band

OmniAuth was first written to abstract the common parts of authentication to external service providers like Twitter and Facebook. It launched as a small collection of gems that each contained many strategies (for instance, the oa-oauth gem contained Twitter and LinkedIn strategies). As OmniAuth’s popularity grew five strategies became fifty-five. Releases became fewer and further between because of the overhead of managing pull requests and issues for dozens of strategies.

No more. Starting with OmniAuth 1.0, each and every OmniAuth strategy will live in its own gem. The downside of this for end users is that you will have a few more lines to declare in your Gemfiles. The upsides, however, are numerous:

There is no longer a gatekeeper to releasing an OmniAuth strategy. Just build a gem, release it, and link it from the new strategy list wiki page.
Individual strategies are free to make releases as often as they’d like. Users don’t have to wait for a massive OmniAuth patch or minor release to pick up fixes for changing APIs or other improvements.
With a lean, focused core OmniAuth itself will be able to release more frequently and adapt itself to the needs of strategy authors.

As a final note about structural gem changes, OmniAuth 1.0 marks the beginning of strict semantic versioning for the project. For end users, this doesn’t mean much. For strategy authors, that means that you can safely declare your dependency on ~> 1.0.

Identity for OmniAuth

As I began using OmniAuth in my day-to-day coding, I began to crave the flexibility of OmniAuth in even traditional authentication scenarios. I wanted a way to leverage the same unassuming, simple authentication structure even when my users logged in via username and password. Today, I’m happy to announce the first official release of omniauth-identity, an OmniAuth strategy that bridges the gap between traditional auth and OmniAuth.

With omniauth-identity you can quickly and easily set up internal identity management for your app that behaves exactly like other OmniAuth strategies. The library is simple but its implications are powerful: you can now treat internal and external authentication exactly the same in your application.

OmniAuth now ships with a Developer strategy that is essentially “fake authentication” you can use as a placeholder until you determine your app’s real authentication strategies. Combined with the potential of Identity, authentication no longer has to be that annoying “first thing” you have to do before you can get down to the real business of building your app. Just drop in OmniAuth, use the Developer strategy, and implement other strategies down the road when it works for the timeline of your app. This is how I’ll be building all my apps from now on, and since OmniAuth is just Rack middleware even Sinatra and other non-Rails apps can use the same techniques.

For more information on how to use omniauth-identity, see the README on GitHub.

Strategy Builders: Better Docs, Better Tools

For the 1.0 release in addition to all of the new features and structure I also tried to significantly improve the documentation for the project, especially for those who are interested in building a strategy. You can see the results of those efforts on the OmniAuth wiki which is the official repository of all documentation for OmniAuth.

Along with better documentation for developers OmniAuth 1.0 also brings along a more declarative DSL for building strategies. The new strategy API gives developers clear ways to implement consistent functionality and makes everything cleaner across the board. For more information on the tools available for strategy developers, take a look at the Strategy Contribution Guide.

App Developers: Consistency, Dynamic Strategies

While many of the improvements in OmniAuth are structural and made for strategy developers, there’s also some great stuff available for everyday users of OmniAuth! Here’s some highlights of new features that work across all strategies:

Auth Hash. Some small tweaks have been made to the omniauth.auth hash that is returned after authentication completes. For one, you can now access keys using method accessors (e.g. env['omniauth.auth'].info.name. The user_info key has also been renamed simply to info. The schema can be considered a stable part of the public API and any breaking changes will trigger a major version release (you can rely on OmniAuth 1.9 to support the same schema as 1.0).

Options Everywhere. As of OmniAuth 1.0, strategy authors are encouraged to make all strategy configuration happen through the options hash that is passed in on initialization. You will still have strategies that have additional arguments (such as consumer keys and secrets) for convenience, but even those can be configured instead by passing in a single options hash. This means that every configurable aspect of the strategy is handled at runtime, which brings us to the next improvement.

Better Dynamic Strategies. OmniAuth 1.0 makes it easy to dynamically alter strategies for each request using the new, universally available setup phase. Simply set the :setup option to a Rack endpoint and you can modify the strategy or anything else about the environment before passing it along to OmniAuth for normal operation.

Skip Info. Some strategies will be able to determine the UID without making additional API calls. You can pass true, false, or a lambda that takes a UID and returns true or false as to whether additional info is required. This gives you the ability to make fewer API calls for cases where you already have a user in your system, for instance.

Custom Forms. If you are utilizing an OmniAuth strategy that displays the standard OmniAuth form, you can now pass in :form => (true || false || lambda) to the strategy to instead render a custom form that conforms better to your application. This replaces the previous poorly conceived method of requiring /auth/:provider to return a 404 in order for OmniAuth to trigger.

Calling All Companies

Now that each strategy for OmniAuth is its own gem, I’m putting a public call out to any and all companies with APIs, but especially companies that are already on a Ruby stack. I would like to get companies on board for maintaining their own “official” OmniAuth strategies. This gives developers using your API the simplest possible means of authenticating to your service and will only help you get more developer traction and experimentation.

I’m also happy to announce that our first “official” strategy maintainers are none other than GitHub! You can say hello to the official GitHub OmniAuth strategy and be sure that any changes to the GitHub API will be safely transitioned into the gem immediately. My hope is that going forward many more companies will join the official strategy ranks. If you’re interested in maintaining an official strategy, you don’t need my permission but I’d love to hear about it so shoot me a message on GitHub.

Where’s That Strategy?

Because of the structural changes to OmniAuth not all existing strategies are available at launch. I fully expect that in the coming weeks the strategy count will regain lost ground and even surpass the count as of the last 0.x release, but if your favorite strategy is missing from the official list here’s what you can do about it:

Find the source code for your strategy in the 0-3-stable branch
Clone omniauth-contrib and add the strategy there
Follow the strategy adaption guide to update the strategy for 1.0
Submit a pull request!

The omniauth-contrib repository is a temporary repository for strategies that have been written but aren’t robust and supported enough to have their own gem yet. This repository is not going to be maintained as an actual RubyGem and the strategies contained inside are meant to eventually be adopted by developers to become their own gems.

One More Thing

One last thing that I wanted to do for 1.0 is create a kind of living example that the community could update to have a simple example of as many strategies as possible. You can now visit omniauth.org and try out a number of authentication strategies that OmniAuth has to offer. The code is all open so you can see how simple it is to add and use OmniAuth in your applications today!

Welcome to 1.0

OmniAuth 1.0 marks an important milestone for the project and I’m looking forward to a new, leaner trajectory that lets us make changes more nimbly (and keeps the outstanding issue count low to zero). While the changes for 1.0 were mostly written by me, OmniAuth has been an outstanding community effort and it couldn’t have gotten to where it is today without the efforts of @sferik and countless other contributors. I hope you enjoy the new release and look forward to hearing your feedback!

Hire a Guard for Your Project

Thu, 25 Aug 2011 00:00:00 -0400

Of all of the new tools that I’ve picked up using for development in the past six months, there is one that has come to stand above the others for its nearly universal utility. That tool is Guard.

Guard is a RubyGem but don’t let that fool you into thinking it’s only useful for Ruby projects. Guard is essentially an autotest for everything. It provides a general purpose set of tools for watching when files are changed in your project and taking action based on it. You can use it to do just about anything, but common uses will include:

Re-running automated tests after a file changes.
Automatically compiling scripts or assets for a project (e.g. minification).
Installing new dependencies that may be added to the project.

With a little creativity and a slight bit of Ruby coding, though, you can make your entire project’s workflow run smoother and faster. It’s like having a telepathic robot buddy who just goes around doing whatever you were about to do next without having to be told (except the first time).

Getting Started With Guard

Guard requires a basic Ruby setup. Once you have Ruby and RubyGems installed, simply run:

gem install guard

This will get you started. If you want to make it easier for others to run your guards as well, you should also install Bundler to encapsulate the different guard gems you’ll be using:

gem install bundler

Once you have these installed, in the root of your project run:

guard init

This will initialize a Guardfile in the project root that will be telling Guard what to do going forward. From here, you will want to install some of the Guard extension gems that let you quickly create automation for your project. Some of my favorites:

guard-rspec: Automatically run RSpec tests based on easy-to-customize patterns. I use this on almost every Ruby project these days.
guard-coffeescript: Compile Coffeescript into Javascript lickety-split. Even though Coffeescript has its own automatic build command with the -w option, I prefer Guard because it lets you define the configuration once and, in addition, run a single process for all of your project’s automation.
guard-process: This is the guard for anything they haven’t made a guard for yet. Using this you can quickly and easily run shell commands as soon as files change, giving you the ability to do almost anything.
guard-sass: Never write vanilla CSS again. Using Guard SASS you can automatically compile SASS giving you the full power of mixins, variables, and more for all your styles.

There’s a full list of guards that include all kinds of magic (there’s even guard-livereload that can automatically refresh your browser whenever you make a change to a project), and it’s dead simple to create new Guard libraries if what you want isn’t available (or you can just use guard-process).

Standing Guard

For any of the Guard gems you install, you can add them to your Guardfile by running:

guard init guardname

Where guardname might be rspec or coffeescript, etc. That will fill your Guardfile with a basic implementation of the given guard and is usually enough for you to tweak the settings to your liking without further documentation.

There’s a great example of using Guard for a big Rails project, but I’m not just using it for Ruby. I’ve used Guard on jQuery plugins, Node.js projects, even static websites that I’ve been building (more on that a little later).

To make it easier for others to jump into your project with Guard, it also helps to use Bundler to maintain a Gemfile that points to the various guards you’re using for the specific project. Just run bundle init to get Bundler up and running then edit the file to look something like this:

source 'http://rubygems.org'

gem 'guard'
gem 'guard-coffeescript'
gem 'guard-process'

Then run bundle install. Once your gems are installed and you’ve set up your Guardfile, just run:

bundle exec guard

Guard will start up right away and your project now has some smooth automation action. Guard will even reload itself if you modify the Guardfile, so feel free to tweak as you go!

Guard in the Real World

I’m going to post just a couple examples of Guardfiles I’ve been using in my projects recently to give you an idea of its versatility.

Guarding a jQuery Plugin

Here’s the Guardfile for Sketch.js, a jQuery plugin that I just released:

# Automatically build the source Coffeescript into the lib directory
guard 'coffeescript', :input => 'src', :output => 'lib', :bare => true
# Also automatically build the test Coffeescripts
guard 'coffeescript', :input => 'test', :output => 'test', :bare => true

# Run Docco 
guard 'process', :name => 'Docco', :command => 'docco src/sketch.coffee' do
  watch %r{src/.+\.coffee}
end

# Copy the newly created lib file for minification.
guard 'process', :name => 'Copy to min', :command => 'cp lib/sketch.js lib/sketch.min.js' do
  watch %r{lib/sketch.js}
end

# Use uglify.js to minify the Javascript for maximum smallness
guard 'uglify', :destination_file => "lib/sketch.min.js" do
  watch (%r{lib/sketch.min.js})
end

This enabled my workflow to be instantaneous: I could immediately look at my work whether it was in my examples, my tests, or my documentation. Everything was immediately built and I never had to slow myself down with run and refresh cycles.

Guarding a Node.js Project

I’ve probably only scratched the surface here, but a simple Node.js project that I’m currently working on has this for a Guardfile:

guard 'coffeescript', :input => 'src', :output => '.', :bare => true

guard 'process', :name => 'NPM', :command => 'npm install' do
  watch %r{package.json}
end

Notice that using guard-process I’m automatically installing new dependencies that may arise when the package.json file is altered.

Guarding a Static Website

I’ve come to really appreciate both Coffeescript and SASS as worthwhile abstractions, so even if I’m building something that’s vanilla HTML I might have a Guardfile like this:

guard 'sass', :input => 'sass', :output => 'css'
guard 'coffeescript', :input => 'coffeescripts', :output => 'javascripts'

These are all basic examples, but that (to me) is the point: Guard is so simple to use and basic that you can drop it in every project you build. I’ve yet to run into something that I don’t want to use Guard on.

Tip of the Iceberg

I’ve been expanding my usage of Guard into, well, everything that I’m working on. Thus far it’s included Ruby, Javascript, and static HTML projects, but if I move on to other things Guard will be coming with me. For instance, I’d love to build a Guard to automatically recompile and run an Android application whenever the XML views change. The possibilities are limitless.

If you’re not using Guard, give it a try on one of your current projects. I think you’ll quickly find immense satisfaction in being able to simply cd into the project directory, run guard, and know that you are completely ready to roll. I’d like to see a Guardfile in every open source project I fork, every client project I clone…Guard is so useful that I simply want to be using it all the time. And that is the mark of a great tool.

Sketch.js: HTML5 Canvas Sketchpads for Whyday

Mon, 22 Aug 2011 00:00:00 -0400

Last Friday I decided to celebrate _whyday by taking a departure from my normal open source path and writing some Javascript (well, technically Coffeescript). So today we’re announcing Sketch.js, a simple jQuery library to enable HTML5 Canvas “sketchpads” for any web application.

Quick and Easy Doodling

Sketch.js allows you to initialize a canvas element as a sketchpad as well as draw with different colors, stroke sizes, and tools (currently only a marker and an eraser). These tools can be accessed programatically or using special links with data attributes. Here’s a basic example:

<canvas id='mysketch' width='400' height='300'></canvas>

<script type='text/javascript'>
  $('#mysketch').sketch();
</script>

That’s all there is to it! The canvas will now be drawable by your users and, thanks to a relatively straightforward API, you can customize it to your heart’s content.

The HTML5 Canvas element is extremely powerful but it can be a bit daunting to get started. I took this as an opportuntiy both to learn it some myself and to provide a drop-in tool for others. Hopefully you find it useful!

Learning on Whyday

I set out on Whyday with the intent of learning a few new tricks. Here’s some new things I tried out:

Sketch.js is coded in Coffeescript. I had used Coffeescript before but never its class system or more advanced features. I like it!
It’s documented using Docco which has been one of the most straightforward and pleasant documentation experiences I’ve ever had. It also, as an annotated source engine, encourages clean source code.
I set up an awesome instant build environment that uses Guard to compile Coffeescript, generate docs with Docco, and minify the JS into a build directory. The workflow worked really well.
I tried to do a very little bit of unit testing using QUnit, which was my first major foray into Javascript testing. Unfortunately, with how much I was learning about Canvas at the same time, I didn’t keep at the testing as much as I would have liked.

All in all it was a great chance to sharpen my skills on something that I hadn’t had a ton of experience with. You can see the docs (and live examples) on its GitHub pages or visit the code on GitHub. Enjoy!

What's Wrong With Patents? It's Obvious.

Thu, 18 Aug 2011 00:00:00 -0400

Patents are in the news in the tech circle more and more these days. As trolls lurk under bridges and the portfolio cold war gets hotter and hotter, everyone is talking about the fact that something is wrong. What exactly that something is, however, is up for debate. Should the patent system be abolished? What about just software patents? Is the term too long? I don’t know, maybe. But one of the primary issues, from my view as a web startup developer, is that what’s obvious isn’t really so obvious anymore.

Patents were established as part of a way to codify the Constitution’s Copyright Clause attempting to promote science and the “useful arts.” They grant a limited term of exclusivity for inventors in exchange for publishing the means to reproduce the invention. In theory, this is a win-win: the inventor gets to make money off of their invention and the public gets to know how it’s made. Other individuals or companies can even license the right to reproduce the invention before the patent has expired so it may reach even more people than it would otherwise.

I’m not going to get into arguments about whether or not the patent system as a whole encourages innovation in modern times. However, one of the requirements of getting a patent is that it not be obvious to “a person having ordinary skill in the art.” I believe that this requirement is no longer adequately strict for patent issuance due to three fundamental differences between the establishment of the system and today’s field of “inventors”: population, communication, and specialization.

Matters of Population

There are more than 300 million people in America, more than 100 times as many as when the country was founded. That means that for any given “art” there’s a great number more people in any particular field than there used to be. So how does this affect obviousness?

If eight people out of ten couldn’t figure out how to do something, maybe it’s reasonable to let the one out of two that figured it out first get a patent on it. That incentivizes the two that can figure it out to figure it out because there’s a real chance that they’ll break ground first and make some money off of it.

So let’s increase the field’s population a bit. Now let’s apply the same ratio to an invention but there’s 1,000 people in the field. That means that 800 out of 1000 would find it non-obvious, but 200 out of 1000 would. A person of “ordinary skill in the art” still would allow the patent to be issued, but now we’re talking about 200 separate people who would find it obvious. This isn’t inherently a problem if all inventions existed in a vacuum, but most often patented ideas (especially in software) represent only part of a larger vision or system. That means that because one out of 200 people happened to register for a patent first, their larger system is in the clear while 199 others that could be solving totally different problems but using the same invention as a part of their larger vision are now in jeopardy of owing licensing fees or being barred from pursuing matters entirely.

In modern America any given field will have tens of thousands of people all working, collaborating, and inventing. To posit that the standard by which exclusive, multi-year rights to something should be given to something that’s non-obvious to the average person doesn’t ring true. It should be something unique and groundbreaking enough to be non-obvious to the vast majority of people in the field. To merit exclusivity, it should be something so beneficial that the inventor would fight tooth and nail to keep it secret were the advantages of patents unavailable. Instead, hundreds of patents are issued for mundane, completely foreseeable advancements in the art. Just because something is non-obvious to most people doesn’t make it a breakthrough invention.

Proliferances of Communication

Can you even imagine how things must have worked back in the late 18th century? What would it have been like to be a scientist, a researcher, an inventor? Compared to the always-on global communications networks that researchers, engineers and inventors have today it’s an entirely different world. Lots has been written about how the world is “shrinking” as both travel and communication between disparate places becomes easier and easier, and the same goes for the inventive communities who are churning out patents.

This readily available communication has the effect of making all participants in a field effectively smarter than they would be otherwise: if I don’t know how to do something, I can just Google it and now I do. This has implications again for the consideration of the “obviousness” of patents. Are many of the things patented today non-obvious to a person of average skill in the art with access to the internet? I’m not so sure.

Especially Specialized

Over the course of our society’s development we have gone from an agrarian society to an industrial one and now to an informational one. The level of specialization found in the modern creative force makes it pretty difficult to tell exactly who should be considered a person with “average skill in the art.” As a disclaimer, I’m not actually sure how the courts currently make such decisions, but it surely is a more complicated question than it used to be. Where do we draw lines of separation for the “arts”?

Is the peer group for a new mobile device patent other mobile device engineers? Is it other device engineers? All electrical engineers? I’m not honestly sure how you would draw that distinction and where you draw the line will drastically effect the determination of average skill in the art.

Abandoning IP

So what is to be done about the patent problem? Well, my guess is that the growing tsunami of patent litigation is going to lead to some kind of change in the law. The current situation is pretty untenable, and I think it’s only going to become more so. Something big will break loose in the next few years and I think the landscape is going to change dramatically.

There are multiple fronts on which the current patent system seems to be at odds with proper innovation, and one of the biggest problems in my eyes is that it is only larger, heavily established and heavily funded companies that are even trying to get patents. You don’t see garage startups wasting their time trying to eke out software patents: they’re too busy building. It’s not until a company is big enough that it can afford to split its focus and hire patent attorneys and do what is necessary to start “protecting” its IP. That bothers me, because it’s propping up a system of innovation where only the big established players have a chance to exclusivity on their “inventions,” and in my mind those are the people who need protection the least.

Technology moves orders of magnitude faster than it did in “the old days” and I’m not even sure where patents fit anymore. 18 years is several lifetimes by current standards of advancement, and to lock up a technology for that long is equivalent to locking it up for the entire span of its usefulness.

Coming from an open source software advocacy background, patents seem like a greedy, antiquated version of what thousands do every day for free: sharing their technology with the world for the benefit of everyone (the creator included). In a world where everything can change in a matter of months, I think it’s time to stop worrying about protecting IP and time to focus solely on creating things of lasting value. Don’t keep your competitors from using your innovations, just make newer and better innovations that outpace them.

Ruby Thankful

Mon, 15 Aug 2011 00:00:00 -0400

A lot has been made in the talkosphere recently about the brewing “multi-Ruby version manager” war, namely RVM vs newcomer rbenv. I’m not here to discuss the relative merits of either software solution, mostly because I take things pretty simple and straightforward in command-line world and I’ve never run into problems with RVM. What I do think this little fracas displays, though, is a common thread in the Ruby community of having big, blown-up controversies when new things come along. In some ways, I think that such drama is one of the unique features of the Ruby community that make it so vibrant. It’s also a feature of the community that can lead to community casualties.

RVM vs. rbenv, Test::Unit vs. RSpec, HAML vs. ERB, Rails vs. Merb, Coffeescript vs. Javascript, Mongrel vs. Thin vs. Passenger vs. Unicorn, Cucumber vs. Steak, and the list goes on. It seems like the Ruby community has a habit of drawing battle lines every month or so. Why do these “fights” come up so frequently in our community? More importantly, what do they mean for the overall health of the community?

Today we’re launching a little site called RubyThankful. It’s barebones at the moment and open source, but what it represents is hopefully a way to find some positivity in the Ruby community.

Background: Passionate Programmers

I would argue that controversy breaks out on a regular basis in the Ruby community because, more than any other community in which I’ve participated, Rubyists are singularly driven to use not just good-enough tools but ideal tools. Ruby is a community of chaotic reinvention, a community that will jump off a cliff just to try out a new brand of parachute. It’s that passion that draws me to the community, that makes me feel like the things that I do matter. It’s also that passion that can cut to the bone.

People are inevitably going to form opinions about what they think is the best in a field of competing libraries/tools/products. This competition in the commercial marketplace is what drives high quality and low prices, and in the open source world it’s what drives reinvention and continual progress. If a library isn’t pushing its users forward, those users can and will seek out a different library that better meets their needs. This is natural and generally beneficial.

What isn’t maybe so beneficial is the “what have you done for me lately” attitude that can come with our pursuit of the perfect development process. It’s altogether too easy to write about reasons why “Y is better than X” while forgetting about the fact that before that, X was so much better than nothing at all.

Casualties of Harsh Reality

As I began to write this post I saw Steve Klabnik’s We Forget That Open Source is Made of People. It’ll be hard not to re-iterate many of his well-reasoned thoughts here, so I want to give him credit for making a point that needs to be made. I was also amazed to come against this controversy just one day after I wrote a post that included the sentence “Harsh words can sometimes be enough to completely dissolve the creator’s interest in continuing the project.” We’ve lost amazing members of this community because rather than respecting their contributions we tear them down when something marginally better comes along. This is the dark side of passion.

I like some tools better than others. I’ve even written blog posts debating the merits of one approach over another and declaring one superior for my purposes. I’ve been guilty of jumping onto new technologies and giving nary a thought to the old way of doing things. I don’t think it’s possible to stop this community from being obsessed with the new and different, and I don’t think that’s what needs to happen. What needs to happen is that our community needs to get better at raising our voice in something other than protest. We need to temper our enthusiasm for the new enough to at least be civil to the hard-working people who created the tools we used until oh-so-recently.

I’m as guilty as anyone of this. Short of trying to say “thanks” in person to the creators and maintainers of the tools I use every day when I see them at conferences, I don’t take much time to thank people for the amazing things they’ve done to make this community what it is. This all sounds sappy and somewhat inefficient, but I think it’s a vital piece of maintaining a healthy community.

Ruby Thankful

I almost wrote this just as a blog post to say “hey, let’s be more positive and thankful.” I was just about to post it when I realized I could do at least a little bit more than that. So I built an almost-nothing-to-it site that can serve as a public forum for the Ruby community’s gratitude for those who work hard to make it what it is. Just tweet something with the #rubythankful hashtag and it’ll get picked up. Maybe it’s someone you’re thanking for a library, or their blog post or tutorial that helped you out, maybe it’s something else. If you’re thankful for the Ruby community and the members of it, let’s put some voice out there!

This community has given me a lot in the last four years, and I’ve done my best to give back. But I haven’t always been thankful enough to the individuals who create the things that I use every day. Hopefully RubyThankful is a small way to encourage that to change.

Michael Bleigh

In the Battle of the Ecosystems, No One Wins

The Why of Zero Tolerance

LocalStorage? IndexedDB? What we need is Redis for the browser.

So Fantastic It's Double Fine

The Innovator and the Inhibitor

If Government Embraced Technology...

Digital Currency

Phase Out Physical Addresses

Automatic Tax Preparation

Technology and Politics

Forward: Let's Start a Political Party

This is How I Want Social to Work

Pros/Cons

Free-to-Play Could Crash the Gaming Industry

Calling Infringement Theft is Dangerous

Should we eliminate gendered pronouns?

Where Games Are Going: Consoles as App Platforms

Why I Rarely Read Books

Announcing OmniAuth BrowserID

What is BrowserID?

BrowserID + OmniAuth

Implementing DRY Magic Methods in Ruby

Your Friend method_missing

Quack Check With respond_to?

OmniAuth 1.0: Auth for All

Breaking up the Band

Identity for OmniAuth

Strategy Builders: Better Docs, Better Tools

App Developers: Consistency, Dynamic Strategies

Calling All Companies

Where’s That Strategy?

One More Thing

Welcome to 1.0

Hire a Guard for Your Project

Getting Started With Guard

Standing Guard

Guard in the Real World

Guarding a jQuery Plugin

Guarding a Node.js Project

Guarding a Static Website

Tip of the Iceberg

Sketch.js: HTML5 Canvas Sketchpads for Whyday

Quick and Easy Doodling

Learning on Whyday

What's Wrong With Patents? It's Obvious.

Matters of Population

Proliferances of Communication

Especially Specialized

Abandoning IP

Ruby Thankful

Background: Passionate Programmers

Casualties of Harsh Reality

Ruby Thankful

Your Friend `method_missing`

Quack Check With `respond_to?`