Windows 8: solving the wrong problem

In the 80s and the 90s, we had a Holy Grail: cross-platform compatibility. We wanted to write our software once, and then run it on different platforms. It felt like a good dream to share: it wasn't pretty to rewrite the same stuff over and over. If your company wanted to support Windows and Apple, then you needed two separate teams writing the same application for two separate OSs. That felt like a huge waste.

We tried hard. We looked at every C compiler flaunting cross-compilation, every database driver promising vendor independency, every high-level approach touting push-button code generation. The more these solutions became sophisticated, the less they seemed to work.

We blamed Microsoft, Oracle and other corporate lockers-in for that sorry state of affairs. We were wrong. As it turned out, we were just trying to solve the wrong problem.

The real problem was not a technological issue: it was a usability issue, a culture issue, and a marketing issue. Different platforms approach the same domains differently, and their relative value lies in those differences, not in the common denominator. At one point, Java managed to solve the technological problem for good, and that was the point where we realized the awful truth: cross-platform compatibility was not important. It never had been.

So we quit trying to solve that problem. Instead, we left it behind by moving up a level and inventing a new, shared platform on the Web. (I still see companies pursuing push-button tools that generate or translate code for the CLR and JVM alike. That saddens me: somebody is still working on the wrong problem.)

Now, as it happens in IT, we're running another iteration of facing the same issues and making the same mistakes. We have multiple devices (PCs, smartphones, tablets), so we'd like to use the same software all over the spectrum. That's where Windows 8 seems to be going: you have the same OS on your tablet and your PC, so you can leverage the same technologies on both. And once again, this isn't going to work, because a tablet and a PC are different, and all those subtle and not-so-subtle differences pile up to require different approaches. Convergence is not important, interoperability is. Broad commonalities are not important, tiny details are. And please, Microsoft, get over it: the OS is not important, the user experience is.

That's why I think that Windows' current approach to tablets and smartphones is fundamentally, tragically, so-fucking-broken-it-cannot-be-fixed wrong.

Get Your Ruby Project on Travis and Have a Martini in 15 Minutes

Almost overnight, every Ruby project out there seem to be moving to Travis. Travis is a dead-simple, community-owned build system. I'm usually too lazy to put all my projects on automated build. Travis took away my excuses by getting me from zero to the first build in a matter of minutes.

Here are step-by-step instructions to get your project on Travis and have a delicious Martini Cocktail in about 15 minutes. Please note that preparing the Martini will take about 5 minutes, so the Travis part should take just 10 minutes of your life.

Check That Your Project Has What It Takes (2 minutes)

Your project needs three prerequisites to get on Travis:

1. It's a Ruby project on GitHub.
2. It uses Bundler to manage its gems. (Actually, that’s not strictly necessary, but it will make it easier to set up Travis.)
3. You can run the project's tests with a single command. A Rake task is typical, but other commands (like, say, bundle exec rspec spec) are also fine.

Ultimately, you should be able to test your project on a new machine by just doing a bundle install followed by the test command. If your setup is more complicated, then you'll need extra work to put the project on Travis. It's probably a good idea to make your project very easy to setup, whether or not you want to use Travis.

I’ll assume that your project meets the three prerequisites, and that you can run your test with bundle exec rake test.

Create a Travis Configuration File (3 minutes)

Commit a new file named .travis.yml in your project root. Here is what mine looks like:


All the entries have sensible defaults, so your configuration could be even simpler. For example, if you skip the script property, then Travis will try bundle exec rake, or just rake if you're not using Bundler. You can find more details on the Travis configuration page.

Activate Your Project on Travis (2 minutes)

Go to http://travis-ci.org and sign in with your GitHub account. Grant Travis read/write access to your GitHub. You should see your private Travis build token on your profile page:

You don't really need to care about the token now - but while you’re on the profile page, flip the switch for the project that you want to build with Travis.

Run Your First Build (3 minutes)

Push to your git repository (make sure that you committed the .travis.yml file), then go to the Travis home page and sit back as Travis adds your project to its build queue, installs the bundle and runs the tests. When the build is done, check your email to find a little love message from Travis - and congratulations for getting it green (or red)!

If You're Curious...

Why did Travis require write access to your GitHub account? That's because Travis automagically configures GitHub to be notified when you push to the project. Go check it if you like: on your project's admin page on GitHub, follow Service Hooks, and click on the Travis hook. The configuration should look like this:

If you click Test Hook, Travis should schedule a build right now.

Prepare the Martini (5 minutes)

Fill a frozen cocktail glass with cold gin, add a touch of vermouth and stir. Garnish with an olive.

(If you’re in a hurry, you can merge this step with the previous one, thus sparing 3 minutes and keeping yourself busy as Travis is building your project.)

Drink the Martini (extra quality time)

I don’t think you need my help here. Just find good company and enjoy. Drink responsibly!

Euruko 2011 Thoughts

Back from the European Ruby Conference. Great people, good talks overall. Here are my quick thoughts on what was good, and what could be improved.

(But first, a message to the people who praised my speech: I'd have to spam Twitter to thank each one of you, so please accept one big collective "thank you". I was stoked by your feedback.)

Why Euruko Was Brilliant

Flawless organization. I don't mean to reinforce cultural stereotypes ("The Germans are well-organized"), but this was one of the smoothest conference experiences I've ever been through. The volunteer organizers did a better job than most people who do this for a living. I heard there were a few people lost in the bushes or eaten by wild animals while hunting for the Saturday night party, but you can argue that was part of the fun. ;)

In particular, the location was great. Berlin is already one of my favourite cities, but this topped my best expectations: Karl-Marx Allee, near Alexanderplatz, one of the most reachable landmarks in town. That, and the most impressive conference screen I've seen so far.

Internet connection is usually a sore spot at conferences, but these guys astounded everyone by installing a parabolic dish on a nearby building just to provide us with perfect wireless connections. There were a few minor hiccups on the fist day, but they were quickly fixed. I was as impressed as everyone else. Standing ovation!

Oh, and most conferences should get a clue from these people when it comes to classy, non-dorky-looking t-shirts.

Why Euruko Should Get Bigger

I've read comments that the conference was too big, and previous Eurukos felt cozier. I do agree that small conferences make it easier to socialize. Nonetheless, I think that Euruko should be bigger, not smaller.

Matter of fact, only a selected lucky few made it to the conference. I'm talking out of experience here: if I hadn't been a speaker, I would also have been left out. Getting a ticket proved impossible. Like so many other people, I was hitting "Refresh" constantly, and tickets went straight from "Not yet available" to "Sold out" in the space of one HTTP call. Some of the people who were left out organized their own parallel conference. Most likely, hundreds more people just gave up and stayed home.

The organizers told me that they were taken by storm by the number of requests, and I understand that. Still, it's frustrating to think that next year I might have to either submit a speech or snipe the tickets if I hope to enter the conference (especially since next year's Euruko will be in Amsterdam, my other favourite northern city).

Apparently, only a small fraction of the submitted speeches made the cut. I gather that the organizers intentionally kept the conference single-track, to keep people closer together - but I think the idea backfired. I'm more likely to socialize if I have multiple tracks, smaller rooms, and plenty of corridors to hang around. Many talks received lukewarm feedback, and I think that was because most talks were very specific, so they couldn't possibly appeal to everyone. I'd rather let people select the talks that they find interesting across multiple separate tracks, than have the organizers do the selection for them.

One of the organizers told me that he thinks the European conference should strive to stay small and single-track. Apparently there is this meme that small conferences are more about people, and big conferences are more about money and business. I guess this fits with Berlin's young-and-smart, community-oriented, mildly anarchist mindset. Again, I sympathize with those feelings, but I disagree with the conclusions. Small conferences may be more about the people, but matter of fact, most of that people are being left out in the cold now. If it's small conferences we want, we already get plenty. Ruby is growing big in Europe, and the main European conference should be as big as the number of attendees - not the other way round.

So, to the folks organizing next year's Euruko: maybe it's time to go bigger?

GitHub is a game changer

Update: here is another recent blog post with excellent detailed instructions on forking and contributing to a GitHub project.

I used GitHub for a while before I could really appreciate what this site is doing to our culture as software developers. GitHub isn't just a neat tool: it's a revolution in the making.

GitHub is a social platform for developing software, built around git. The use cases for git have always been interesting, but not necessarily compelling. GitHub builds on the strenghts of git, and the result is a brand new approach to writing and sharing code. While git takes care of the technical issues like forks and merges, GitHub takes care of the social issues like pull requests and tracking forks.

Just think of a typical development problem: patches. Your project uses a third-party library, and that library has a bug. Here is how you usually deal with the problem if the library is proprietary:

1. You contact the producer's customer service and report the problem.
2. You sit on your hands until the company fixes the problem. If ever.

Here is what you tipically do with an open source library:

1. You go to the library project's forum and report the problem.
2. You sit on your hands until the authors fix the problem. Eventually.

As an alternative, you could fix the problem yourself. To do that, you have to download the library's code, set it up, make sense of it, patch it, build it and test it. It could take you weeks. Then you submit a patch, and you hope that your patch will end up in the original codebase. Until then, you have to merge subsequent changes from the original codebase into your patched local codebase. Merges are usually painful enough that you'll probably stick with steps 1 and 2 in most cases. Bottom line, you'll probably end up doing like you would for a proprietary project: you find a workaround, and keep hoping.

Now, here is what you do with GitHub:

1. You fork the library.
2. You fix the problem.
3. You use your own forked library in your project.
4. You send a pull request to the original library.
   

GitHub makes step 1 as easy as you could reasonably hope. If you use good tools like Bundler, step 3 becomes a one-liner as well. And step 4 is both trivial and not necessarily critical. You still have to merge future changes from the project into your fork, but git makes it easy for you to merge, and for the original library to incorporate your patch. All in all, GitHub turns patching from a bottomless pit of pain into a geeky form of pleasure.

Now look at step 2, the remaining difficult step. To make it worth the trouble, you need a project that is easy to setup, easy to understand, and well covered by tests. So GitHub is a perfect fit for languages that promote clear, concise code and for communities who take pride in unit testing and easy project setup.

Suddenly, complicated open source projects feel so last century. By removing all accidental difficulties of patching, GitHub tips the balance towards projects that are trivial to set up and test, and languages that promote easy change. If I need to pick between two projects, I'll probably pick the one that's easier to patch over the one that has the most bells and whistles. Month by month, GitHub is shifting our collective coders' hivemind towards simplicity.

After all, wasn't this one of the original promises of open source? "It's your code. You'll never be stuck."