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."

Bundler: How You Can Start Using It Today

I took some time before I could understand and use Bundler in my Ruby projects. There was something about it that just didn't click with me.

In hindsight, I should have learned Bundler earlier. Once you "get" the workflow, Bundler is very simple and very powerful at the same time. It's one of those well-made tools that makes it dead easy to do simple stuff, and entirely possible to do complex stuff when the time comes.

I wrote a Bundler primer for the latest PragPub, the Pragmatic Programmer's monthly magazine. If you're not using Bundler yet, I hope that this article will turn you into a Bundler user before dinner.

(Even if you don't care about Bundler, the rest of the magazine is likely to have something for you. PragPub is my favourite programming mag ever, and I'm proud to write for them when it happens.)

The method_missing() Chainsaw

I have a guest post about method_missing() on RubyLearning. It's intended for Ruby beginners, but it's attracting interesting discussions in the comments and on Hacker News - mainly from people dissing Dynamic Methods in favor of Ghost Methods.

The Ruby Metaprogramming Spell Book

Here are all the spells from Metaprogramming Ruby, as link-friendly Gists.

March 2014 update: I updated this list to match the second edition of the book. I added three spells that are new to Ruby 2.x: Refinement, Refinement Wrapper and Prepended Wrapper. I also dropped a few spells that don't seem to be as relevant today as they used to be, at least in the context of this book: Argument Array, Named Arguments, Pattern Dispatch and Class Extension Mixin.

RubyKaigi 2010

The scarily efficient organizers of RubyKaigi 2010 only took a few hours to publish the video of my talk on metaprogramming and the Ruby object model (slides and audio only).

Yesterday I also lived the Andy Warhol moment of my life when I signed the first hundred or so copies of Metaprogramming Ruby Japanese Edition together with translator Kado Masanori and Matz. I looked at the long line of people happily waiting half an hour to have their copy signed, and suddenly spending three years to write a book seemed like a perfectly rational thing to do.