This post originated from an RSS feed registered with Ruby Buzz
by Dave Hoover.
Original Post: Rails Rumble 2008: Developing Run.Track.Run.
Feed Title: Red Squirrel Reflections
Feed URL: http://redsquirrel.com/cgi-bin/dave/index.rss
Feed Description: Dave Hoover explores the psychology of software development
Leah Welty-Rieger joined Obtiva a couple months ago. She is an apprentice in our Software Studio. (She also recently earned her PhD in Particle Physics from Indiana University.) About a month or so ago, Leah and I were walking back from lunch and started talking about our shared interest in running. Then she told me about an idea she had for making simpler, easier, more informative running software for planning and tracking your training. A couple weeks later I found a link to Rails Rumble 2008. I'd wanted to rumble in the past, because I'm a fairly speedy programmer, and I love competition. But having very little CSS-fu and lacking any inspired 48-hour-sized ideas, I'd never rumbled. Until this year. I immediately thought of Leah's idea and realized that with the addition of CSS-ninja Dan Nawara to our Studio team, we had sufficient skills to rumble. And just because I had the luxury of doing so, I asked Fred Polgardy to join us as well, because, well, Fred's a genius, particularly with JavaScript.
We got together 3 times before the competition to formulate our plan of attack. This helped us start on the same page. We understood the domain model (Users have Runs have Splits), and we knew we were going to integrate with the Garmin Forerunner, and we knew we were going to use Flotr to build the HTML-canvas-based graphs that Leah had specified. We decided to use HAML and SASS, which I had never used, but found perfectly intuitive and productive (and now prefer it). I decided to stick with good old test/unit for TDD. I'm still much more productive in test/unit than any other Ruby testing framework and I needed something dead simple since I was going to be running low on energy. I also planned to use TDD strategically. Basically, I used it to test my models, but developed my controllers without tests. Ironically, this helped keep my controllers really skinny, since I ended up extracting logic into models (such as the Garmin XML file processing and matching scheduled runs to actual runs) and wrapping them in tests. We also decided on the name for the app: Run.Track.Run. We were both excited and disappointed to find out a day later that Relevance had created Run Code Run and would be offering free continuous integration for rumblers, and thereby leading everyone to assume that we copied their name.
The competition started on Friday at 7pm Chicago time. My wife, kids, and I with friends in their house. I rudely, and suddenly grabbed my laptop and bluetooth-enabled modem/mobile-phone and started the process of setting up our github repository with Bort, installed Debian on Linode (with Apache+Passenger, MySQL, Postfix), hooked our build into Run Code Run, and pushed our first Capistrano deployment up to the server. The next morning the 4 of us met at the office and started rumbling as a team. The rest of the story is actually pretty mundane. I got really pissed off, swearing loudly at the Garmin JavaScript libraries for a while until Fred came over and solved the problem. We did a lot of pair programming. And mostly just kicked ass consistently for 48 hours. I got to pair with Leah, Dan and Fred (sorted in order of amount of pairing time). I think everyone paired with everyone. And everyone got enough sleep. And with an hour to go, we were kicking back with beer and making final tweaks. In the end, we launched Run.Track.Run., which I'm particularly excited about, since I'm one of the (currently) 75 runners who are already using the application.
Previous Topic
