This past weekend was the sixth annual Rails Rumble, where teams of up to four people competed to build the best Ruby on Rails web application in just 48 hours. New Relic was a corporate sponsor of the event and a couple of our engineers spent their weekend taking part in the challenge. This is their story:
Hi, I’m Nic Benders and I work on the Site Engineering team here at New Relic. For the Rumble, I teamed up with David Morrow from our Core App team, and our friends Matt Clark and Rob Kaufman from Notch8. The app we built is called Who You Know. It’s a job searching tool that cross references public job listings against your LinkedIn network, to see who you know at companies that are hiring. We thought it would be useful to share some of the tricks we relied on to build and ship our app in just two days. Read on for the details, and don’t forget to checkout out our (and other) apps in the Rumble so that you can cast your vote!
Something That Does Nothing
The contest started off at 5pm PT on Friday. But we’ve got families, so things didn’t get rolling until after dinner. Every project at New Relic starts the same way, so we knew that the first step was to ship “something that does nothing”. This would make sure that we could move on to building the product on Saturday and not waste time figuring out how to deploy.
Of course we had some help getting off the ground:
* The RailsApps project, Rails Composer, got things running right away with Twitter Bootstrap, OmniAuth, HAML and everything else we needed to get started
* The excellent Linode StackScript, provided by the Rails Rumble organizers, made getting up and running on a VPN painless
So we took our generated app, configured the sample Capistrano configuration, pushed the code to GitHub, and did our first deploy. The StackScript had already pre-configured Phusion Passenger and MySQL, so we were off to the races.
Authentication Is a Solved Problem
Our app uses LinkedIn’s contact data, so we knew that every user would need to have a LinkedIn account. Using their OAuth system as our primary login meant that we didn’t need to spend time on the standard login, password, email workflow as the omniauth-linkedin handled all of this for us.
Always Be Deploying
Code on the shelf is wasted inventory. And delivering a polished app in 48 hours meant there was no room for waste. We needed to be deploying all the time. The StackScript provided already worked well with Capistrano, so we could push the code out whenever we wanted. But we also needed to track how it did out there in the wild. It was time for New Relic to enter the picture.
Setting up the New Relic Ruby Agent was a snap, and gave us performance and error reporting capabilities. But to see how our deploys were impacting the app, we needed to go further. Adding Deployment Notifications to our Capistrano config meant that we had a record of everything that went out and could see how each change affected response time, error rate and other metrics. Once that visibility was in place, we made it a habit to immediately deploy after pushing to the upstream repo.
David worked on the frontend in Backbone.js. We didn’t want to hold him up while we did the job fetching and LinkedIn API work. So we manually created a JSON file that he could drop into his public/ directory and use as a fake dataset. This let him work in parallel while we did the backend.
Less Features, More Polish
As we had very limited time, an important part of our process was to make sure we always kept the very limited scope in mind. We wanted to build an app that looked and felt finished, but it didn’t need to do everything. Anytime a feature was proposed, I could hear the voice of Jim Gochee in my head, asking “What problem are you trying to solve?” There are lots of great ideas still filed in the ‘future’ column of our Trello board, but we just didn’t have the time to build them out properly. If the app proves useful for people, maybe we can go back after the contest and add them.
Give it a Try!
After working on a big app like New Relic’s RPM, it was fun to get back to basics and build an entire app in just two days. But we also strived to make something useful. Give it a try and let us know what you think on our Rumble page!