Tips for Participating in the Rails Rumble

The Rails Rumble is the biggest international Rails hackathon and it’s organized once a year – over 500 teams distributed across the globe, each with 4 members fabricating an awesome Rails app in 48 hours. The best part is that everyone can join, everybody’s in it for the fun. The next one is on the 7th and 8th of November!

Last year, the three of us from Infinum entered the Rails Rumble for the first time. We had no troubles coming up with the idea of what to create – at that time we were in between switching our apps from MySQL to Postgres and were having problems finding a slick desktop client for Postgres. We got spoiled by using SequelPro for MySQL and the Postgres alternatives weren’t as nearly as nice.

Since this was a Rails hackathon, we decided to create a Postgres manipulation client built as a Rails engine. We called it Pancakes. Since we’ve managed to learn a lot from the whole experience, here are some protips to help you perform best on the big day.

One of the few things you are allowed to do before the hackathon is to agree on an idea. The four of us had met at a bar 2 days before the hackathon to decide what we would do. However, we hadn’t completely ironed-out the implementation and we felt this during the hackathon.

Try to do the architecture of the whole system before the beginning; write user scenarios, draw up a class diagram or an ER diagram of your database – the only rule is that you don’t write any code before Saturday!

Once you start rumbling, it’s easy to take a whiteboard to list and assign all tasks:

The Rails Rumble starts on Saturday at 00:00 UTC and finishes exactly 48 hours later. We live in Zagreb (UTC+2), so that means we could’ve started on Saturday at 2 am, but we decided to start with the hackathon 4 hours later – somewhere around 6 am. Even though that made the hackathon 4 hours shorter for us from the beginning, at least we got a good night’s sleep and kicked the first day off quite fresh. I think I’ll let myself sleep until 8 am for the next one and be even fresher.

We decided to meet at our office and hack our way through 48 hours from there. It’s really better for everyone to be in one place to share ideas and have fun together.

Another recommendation would be to dress like you’re at home – bring your sweats and some comfy shirts – no one wants to wear jeans for 48 hours.

One other thing we did that helped minimize time wasting and keep the team morale high was sleeping at our office. If we had went home, we would have lost at least 4 hours more to regroup back at the office and risked more outside distractions.

Thinking back, it’s a good idea to make your sleep as comfy as possible. If you have couches in your office – bring your own pillow and blanket. If not, maybe bring/borrow a sleeping bag and a sleeping pad (the thingie you put under the bag to put something between the bag and the floor). Did someone mention camping?

Before entering the Rumble, agree with the rest of your teammates on the versions of Ruby and Rails you’re going to use. In reality it doesn’t matter which versions you use, just pick some and send an email saying: `We’re going to use Ruby 2.2.3 and Rails 4.2.3, please install it’. We had some short debugging sessions while using different minor versions of Ruby inside the team. If you could skip that, it would be awesome.

Also, agree on which database you’re going to use, and make sure everybody has it installed. Same goes for extra services such as Elasticsearch, Redis or whatever. You don’t want somebody wasting time during the hackathon.

Try to create a minimalistic app with only a few basic features and do them really well – it’s better to create an app with one or two impressive features than have 10 sloppy features.

Participants are also the jury and every participant needs to go through all the applications and judge them – no one has the time to check out dozens of features. If you finish before the deadline, it’s better to polish your UX than to add extra functions.

Also, try to make your app understandable to everyone. If you can’t pitch it in a sentence or two on your homepage, it’s probably too complicated and no one will have the time to try to figure out what it does.

To be honest, no one wants to see an app that’s designed by a Rails developer, and you’re more likely to create a better app with a really good designer. Although the hackathon is called the Rails Rumble, you’ll probably be better off with a good design than with a clean codebase. Check out the awesome design from last year’s winners:

Besides designing the system’s architecture, you can have your design finished before the hackathon begins. That will also force you to keep track of all of your goals.

Once again, despite the event name, you’ll probably be better off with a good front-end developer than a back-end developer hacking through your CSS. In most cases, the first will be faster and better.

Since we did an app with a heavy back end, we thought it would be okay for all of us to be Rails developers. In the end, we would’ve been faster if we had had a front-end developer.

Two rules:

We created a slack organization (it’s free) and it was really useful:

The three of us remember this as an excellent experience and still tell stories from those two days – tired dementia conversations, weird stuff going on when hyped on Red Bulls and what not. We’ve bonded more than before and just had pure, clean fun.

Lastly, take a day off on Monday – you’re gonna need it ?