Building Qoffee in 48-hours for Rails Rumble

For the 2014 Edition of the Rails Rumble competition, we built Qoffee - an app to help avoid wasting time during meetings. Qoffee came 3rd out of over 300 teams, an achievement we're very proud of. In this post, I'm just going to write a few words on how we prepared & how the team worked together during the weekend.

Image

Before the competition

Planning before the weekend starts is the key to success. In the time limited environment, there's not a huge amount of time to plan and think through the ins and outs of how your application is going to work. Fortunately, planning ahead of time is perfectly acceptable.

  • Outline exactly what your application will do. We wrote down our core goal ("save time in meetings by time-boxing talking points") and then made a list of features. We then broke features down into groups for required and if time. This allowed us to prioritise which items needed to be completed first and what things can be added on at the end if there was time available on Sunday afternoon/evening.

Image

  • Prepare your wireframes/mockups. We created mockups for every page of our application. Rob (our frontend guru) would then be able to take these during the weekend and create the markup & CSS needed for the application.

  • Think about your models & relationships. Before the competition started, we prepared a list of models, attributes & relationships which we would need in the app. The first thing I did on Saturday morning was to take these plans and create the models & migrations needed. This ensured that everyone else could immediately begin working.

  • Familiarize yourself with Heroku. If you haven't used Heroku much, it's worth deploying an application before the weekend. We deployed a very simple Rails app so we could understand exactly how to deploy, run migrations, access the console, set environment variables and work with add-ons.

During the competition

Once the competition has started, it's important not to panic and rush. You'll probably write your best code during the first 8 hours of the competition when you're feeling fresh.

  • Try and work in the same room as your team. We all came into the aTech Media office. We've always enjoyed working together and keeping the channels of communication as open as possible.

  • Ensure everyone knows exactly what their role is. We assigned roles to each person. I - Adam - was mostly responsible for the UI design & the Rails application, Dan W handled all javascript, Rob built all the HTML & CSS and Dan Q dealt with the integrations with third parties (Slack, Twilio, Hipchat etc...).

  • Don't try and work the full 48 hours. None of us are as young as we used to be (except Rob) and staying up for the full weekend wasn't really something we wanted (or needed) to do. Before I got out of bed on Saturday morning, I initialized our Rails application, added some dependencies and built most of our planned models. I then headed to the office and everyone could get started on a working app.

  • Drink & eat well. Make sure you get the developer food in in advance - whatever your team enjoy. I went to the supermarket on Friday evening and bought the usual things like soft drinks, crisps, ice creams and biscuits.

Image

  • Test everything. If you don't have time to write a test suite - that's OK but do make sure you test everything throughouly. The last thing you want is a show-stopping bug during the judging periood. Nothing seals your fate quite like a "Something has gone wrong" error! (Top Tip: go into privacy mode, use your app like a user from beginning to end throughout the weekend).

  • Make a video. If you have time, make a quick screencast or video which outlines what your application does. We had a bit of time spare on Sunday evening so we filmed a short video to explain the concept of our application. The link from our homepage to watch the video was the most clicked item on our homepage.

Image

After the competition

Phew! It's all done. You can mostly just sit back and relax now. You can't touch your application but there are a few things you can do...

  • Keep an eye on exceptions/errors. During the competition, add some sort of exception reporting. Of course you can't actually fix anything but you can know what issues users are experiencing.

  • Watch your traffic. Install some analytics in your app so you can see who's using it and when. It's quite fun to see how people are using the app and what they're clicking on.

Image

  • Get on social media. Get your application out there and get the public to come along and vote for your application.

  • Take a look at your competitors. Go and have a look at everyone elses apps and see what everyone has been up to. This year, the competitors were also the judges so this was rather important!

From a judging point of view

This year, as competitors were the judges I got an insight into how daunting it is go through so many entries to determine your favourites. These are a few things which came to mind which would have made it easier to judge.

  • Make your app easy to use. When you're building your app, make it easy to get started with your app. We used my fake-person gem to automatically generate personalities at the click of a button who could then use the appplication as a normal user.

Screenshot

  • It should be obvious what your app does, from your app! This year, I found loads of applications but I had absolutely no idea what they did unless I read their Rails Rumble profile. We knocked up a quick homepage which was meant to outline what we did in a couple of sentences.

  • Don't over request permissions! This is an important one. If you're asking people to login using Github or Twitter (or anything else), don't ask for any permissions you don't need. Some apps this year asked for a GitHub login (fine) but then requested access to all private repositories (not fine). Unfortunately, this meant I wasn't able to use their application to fully test it.

Conclusion

It was great to compete this year and we had a lot of fun working on Qoffee. We now plan to move this off Heroku and over to our own platform, Viaduct and run it as a service in its own right.