For the first time in its history Ruby en Rails was a multiple day event. The first day, October 31, was packed with interesting presentations on various Ruby and Rails related topics, by great speakers including renowned community idols like Yehuda Katz, Jeremy Kemper, Jonathan Weiss and many more. The second day (the ‘geek-day’) focused on more practical sessions and lightning talks. On this day another event was held: The RubyEnRails Rumble (RERR), a competition where teams of two had to complete an assignment within a certain time.

Since we from Kabisa consider ourselves to be Ruby programmers we wanted to take the challenge and see how we would do in this competition. Michel de Graaf and Ludo van den Boom were given the honor to rumble for Kabisa. This post will describe how we prepared for the RubyEnRails Rumble and how we have experienced it.

Rumble Preparations

After deciding that we would partake in the Rumble we knew that we would have to prepare ourselves as good as possible so that we could utilize our time at the Rumble as efficiently as possible. Neither of us had ever participated in an event like this, so we started of with a session in which we tried to decide what we could do to help us prepare for the Rumble. Together with our Kabisa colleagues we made a list of items and topics that could prove to be handy during the Rumble.

The hard part was that we had no experience and that we did not know what the assignment would be, so we dove into a broad range of subjects. With help from our colleagues we were able to refresh our knowledge of Ruby and Rails related technologies and built up a collection of snippets/links to quickly be able to perform standard tasks like retrieving tweets from Twitter and adding jQuery UI sugar to an application. In the end we prepared a Rails application template so that we would be able to quickly set-up a Rails skeleton application including basic functionality like authentication and authorization. Besides this template we also prepared a user interface template builder that could help us to quickly apply a ‘theme/skin’ to an application (interfaceLift).

For scaffolding we used dry_scaffold: This gem contains a rails generator that will replace the default rails scaffolding with more up to date DRY controllers and views. Controllers are implemented using inherited_resources. And the views are generated in haml that make use of Formtastic Forms to generate nice looking forms. The fork we where using also generated a search form that was implemented using searchlogic.

Another challenge was that we had not worked together before. So, apart from the technical toolkit that we set-up, we also had to find a way to get more acquainted with each others good and bad sides. We decided that the best way to do this would be to simulate a Rumble, and that’s what we did. Our colleague Ralph came up with an assignment that we worked on for about six hours. In these six hours we managed to crank out some decent results and learned how we could best divide the development tasks to our individual skill sets. This simulation prepared us for lots of things but it did not really simulate the most vital element of a competition: stress.

Rumble Ramblings

Some hints on what the assignment would be were dropped during the presentations on the first day. Still, we could only guess what exactly to expect. At the start of the Rumble the assignment was introduced and explained, the assignment was titled ‘Community Love’. It turned out that we had to create a system that would keep users of Ruby libraries up-to-date with updates about these libraries. The assignment was kept vague on purpose so that the teams had the ability to put their creative minds to work with finding a solution to the problems laid out in the assignment description.

So, now we had a little under eight hours left to design and build something that would convince the jury of our programming skills. After a short stand-up meeting we came up with a rough idea for what we would create.

The Plan…

As a Ruby/Rails developer you will probably make use of lots of gems in your application. You can specify these gem dependencies in your Rails configuration. Or make use of the awesome gem bundler. This will help you manage gem dependencies but they will not inform you when there are updates to the gems you are using. We figured that, as a developer who uses gems in a Ruby project you should be able to send a list of gem dependencies you use in a specific application to a service that will inform you when there are updates to the gems that you are using. An update could, for example, be a new version, a reported security vulnerability or a blog post. Since we had only one day to build something, we decided to focus on Rubygems exclusively. Mostly because there are already good centralized repositories where we would be able to easily find information about gems (gemcutter).

… And the Solution …

Our solution consists of three parts: (1) a gem that you use locally to update the list of gems you use in particular applications, (2) an online service (Rails application) where you can see the gems you use and (3) notification channels (i.e. email and twitter) through which news about gems is pushed to you. We named our solution ‘gemstreamer’, for it would stream information about gems to you as a user of these gems. For those of you who are interested to see what we actually made: you can see the ‘online service’ Rails application that is used as the central ‘information hub’ where information is gathered and distributed at http://github.com/ludo/rerr2009. For the gem that you would use locally to push the gems you use to the central hub see http://github.com/michel/gemstreamer. We deliberately kept the code as simple as possible and leveraged as many existing tools as possible to be able to quickly get things done. The end result is pretty simple, but the ideas behind it might actually be useful when extended and polished for real-life usage. This was also one of the comments from the jury, where they believed that something like this could make a great extension to http://gemcutter.org.

… At a Price

Did we mention the stress? Apparently we were both not very satisfied with how we made progress. There was so much that we wanted to do, and so little time to do it all. This is probably the biggest flaw in how we approached the Rumble. Before the Rumble we had already discussed that it would be best to make something small that works instead of something big that does not work. This reasoning sounded really good before the Rumble and after the Rumble, but we actually forgot it during the Rumble… Still, we managed to get our main ideas implemented which we were able to present at the end of the day.

Rumble Opponents

With five pretty strong teams the competition was fierce. It was interesting to see that every team approached the assignment from a different angle. Where our end result can be seen as an interesting prototype, others had created something that could be of use to developers right away. Here is a short summary of what the other teams created:

• The Fingertips team created Apprise for which they patched Bundler. This patch to was applied to Bundler By Yehuda the very next day.
• Iain Hecker and Marcel de Graaf built an extension to Webistrano that shows outdated gems, named ‘deproll‘.
• The i76 team (Tom-Eric Gerritsen and Rik Tonnard) built a Rails plugin that you can hook-up in your application so that you can see the dependencies that your app uses through a web interface (http://github.com/i76/rrrer2009).
• Leon Berenschot and Klaas-Jan Wierenga gave a cool presentation and won the Twitter vote (http://github.com/LeipeLeon/Dev-Enter).

Rumble Results

Victory! Completely unexpected we were awarded the first prize: two tickets to RailsConf 2010 in Baltimore, MD. The winner was selected by a jury and through public voting via Twitter. In the Twitter vote we ended as third, which we thought was already a great achievement. But the professional jury had unanimously picked us! These two votes combined made us the overall winners of the Ruby en Rails Rumble 2009: awesome!

In hindsight we can conclude that our plan was a little too ambitious as it turned out that eight hours is really not that much. Nonetheless, the rumble turned out to be a great experience that was really fun doing. It was a crazy day with a lot of stress, but it was also an interesting experiment to see how we would do against some other very good teams. The end result turned out to be even better than what we’ve hoped for. We want to thank the jury for choosing us as well as the people who voted for us on Twitter. Last but not least many thanks to the people who made Ruby en Rails possible this year, we had a great time!