Lessons Learned from the first Hack Omaha

This weekend I took part in Hack Omaha - the city's first hackathon with a focus on making apps from public data. We built an app that gameified health inspection data. It was awesome. Nate's already written up an hour by hour recap of our team's experience, but I thought I'd share specifics of what I learned.

• Pitch an idea, even if it's not a winner. Nick Wertzburger started the pitch session off with a joke app (I think) that he tweeted earlier. It was one of only a handful of pitches, and his team ran with it and melded it into an awesome heatmap page; my favorite project of the weekend.
• Sinatra rocks. My day job consists of writing Web Services, with a capital W and S. The process is often heavyweight, cumbersome, and requires numerous approval and manual configuration steps. It was beyond refreshing to just write a get /matchup method, paste in some JSON, and have a working service. Prototyping service design before you've even gotten a dataset gives you lots of flexibility to change your design on the fly.

• Heroku is great, except when it isn't. We ran the app's service layer on a shared (read: free) Heroku instance and a shared Postgres database. This was my first experience hosting apps on Heroku, so I relied on Steve's expertise. Pushing changes was simple as pie, but we ran into numerous issues getting Rake migrations to function correctly. We ended up creating databases on my machine, and using Heroku's backup/restore feature to load up production. It's not pretty but it got the job done.
• Designers are worth their weight in gold. With all due respect to Nate's work, we could have used someone to help with the usability, icon design and overall polish of our app. Most projects were in the same boat. But they were in extremely limited supply here.
• ORM flexibility is helpful. Since you have no idea what tech stack you'll be working with, you don't want to require teammates to have a particular database already installed. For example, Steve didn't have Postgres installed on his MacBook, but we just configured a SQLite instance on his box, set up his ActiveRecord configuration to connect to it and he was off and running.

• Don't let your VCS hold you back. We decided to use GitHub to host the source, but only half the team had any git experience. Rather than try to learn a crash-course on git, they used a shared Dropbox folder as the repository location.
• Colocation isn't necessary. We spent most of Saturday working from our individual houses, and we stood up a Google+ Hangout to help. The video chat and screensharing worked really smoothly. We probably had an advantage over the folks who worked at the hackathon venue, as wi-fi was spotty the whole weekend.
• We could have been more ambitious with our tech stack. We were familiar with almost every piece of what we built. Then I look at Omaha Bounty Hunter, which was developed against a five-day old JavaScript framework, and I feel a little sad that we didn't try something farther out there. At the very least, we could have tried a document database like Mongo, given that nothing we were doing was relational.
• Keep projects small and focused. We were essentially finished with our app by 6pm on Saturday. After that, we spent the rest of the time play testing, tweaking the design, and adding features like analytics, win/loss counting, etc. But having a small, achievable project meant we weren't scrambling to get basic functionality working at the last minute.

• I don't know Ruby very well. I kept running into syntax issues, like trying to return early out of a block (which isn't allowed). I also spent a ton of time learning the methods on Enumerable, and figuring out how attributes in ActiveRecord models function. You only have to look at the number of Hash.new and Array.new in the codebase to see that we're still noobs at this.
• Untested code becomes legacy code, fast. We cranked out the services with nary a unit test in sight. If it didn't cause a syntax error, we shipped it. By the end, all code was making into Sinatra routes, which meant we had to reload our web app each time we wanted to change a `group_by`, or see if our ActiveRecord query was right. This slowed us down noticeably, even by day 3 of the project.
• Not all prepwork is fruitful. I tried to learn two new technologies before the hackathon: Neo4J and PostGIS. I thought each might be helpful, and I spent weeks trying to learn just enough to fake knowing it for a weekend. But I ended up using neither. Rather, a 2-hour session with Twitter Bootstrap proved far more useful than anything else I knew.