Rails Rumble '09

24 August 2009

We once again participated in Rails Rumble, the annual 48-hour Ruby on Rails development contest. The fruits of our near-sleepless labor is Operator, a multi-user phone forwarding and voicemail service.

Cake

The idea grew from our personal need for one phone number to route to both of our phones. We wanted to be able to schedule times when calls would be routed to either phone. On top of that we thought it was necessary to have a central voicemail box. If no one answers a phone call or no one is scheduled to be on call, the call is directed to voicemail.

Calls needed to be able to have comments, so we could keep track of what we had followed up on or any other information associated with them.

Icing

The voicemail messages are sent to Operator and transcribed to readable, editable, searchable text. Inline audio players allow you to listen to the message, or you can listen to all visible messages via the answering machine at the top of each page.

We also included drag-and-drop tagging and responsibility assignment. The search feature allows for some handy sorting, and you can save a search as a filter for one-click access to it later.

Due to the nature of the contest, we had to present Operator in a limited way. Visitors have anonymous guest access to post comments, make tags, assign responsibilities, and edit transcriptions. Since the on-call scheduler actually works, guests can view the schedule page but not actually save the changes. We’d rather not receive a bunch of test calls this week. We also thought it was important to mask the incoming phone numbers in order to respect the privacy of anyone wanting to test calls out.

In the future, we plan to implement a sign up process, adding team members, acquiring a phone number, and all that important mumbo jumbo. For now you can consider it the internet’s finest prank message repository, or a chance to anonymously spill the beans.

Post-mortem

This is our second year participating in the Rails Rumble. We learned some lessons last year that made our experience much better. There were some other things that we stumbled upon this year that also helped out.

Plan up front

During last year’s competition, we had to take some time to go over our vision for the app because we were both envisioning different things. This year, we spent some time the week before drawing out wireframes and planning features. Our weekend went much more smoothly since we knew what needed to be done.

Clear out your schedule

Last year, both of us had commitments over the weekend. This took time away from building our application. This year we could spend as much time as necessary to make it as perfect as possible.

Finish early

Plan to have your application finished two hours in advance. Then you can spend the rest of the time looking for bugs. We had a few big bugs left in last years application; we caught several before our final submission this year.

Work with others

All of the Kansas City teams (at least all that we knew about) worked out of ECJC over the weekend. This provided several benefits: fewer distractions (everyone present is working on something), motivation, and the ability to bounce problems off of each other.