Well, those were an interesting 48 hours. We built and deployed What Does this Error Mean? within the time constraints that were imposed by the rules.
What is What Does this Error Mean? ? It’s a way to search for errors and solutions, but without Google’s page ranking algorithm being in the way. You want to know what it looks like?
Click for larger version
The concept behind What Does this Error Mean? is simple: you receive some obscure error message you don’t understand. You copy it, go to What Does this Error Mean?, paste and then click “Find me some help!”. If we find similar error messages in the system from previous posters, we’ll present you with ranked solutions. If we don’t find a solution, we allow you to follow the error so you get notified of new solutions on your error.
To help us poor developers, Team GiraffeSoft even took the time to create two plugins: What Does this Error Mean? Rails Edition and What Does this Error Mean? Merb Edition (both plugins have only been tested on the latest released branch). Install the plugins, and suddenly your development error page becomes a direct link to What Does this Error Mean?.
To top it all off, James made a screencast for your viewing pleasure: wdtem_screencast.mov (QuickTime MP4, 75 Mb, 3 minutes).
If you like our idea, but most of all it’s implementation, vote for us. We will be very thankful.
Things that worked
So, what worked about this competition? Well…
- Being in the same physical location helped, a lot. This meant we could bounce ideas off each other very quickly;
- Pair programming;
- Unit testing (we used Shoulda and Test::Unit);
These are so self-evident, I don’t know why people don’t do that all the time. The RailsRumble team encouraged us to do unit testing, and I pity anyone who didn’t do that. We’re confident that our application is pretty solid, given the amount of tests we have versus the simplicity of the application:
1 $ rake stats
2 (in /Users/francois/Documents/work/team-giraffesoft)
4 | Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
6 | Controllers | 278 | 223 | 8 | 25 | 3 | 6 |
7 | Helpers | 153 | 85 | 0 | 12 | 0 | 5 |
8 | Models | 241 | 188 | 7 | 31 | 4 | 4 |
9 | Libraries | 251 | 136 | 1 | 28 | 28 | 2 |
10 | Functional tests | 730 | 588 | 11 | 13 | 1 | 43 |
11 | Unit tests | 767 | 622 | 7 | 2 | 0 | 309 |
13 | Total | 2420 | 1842 | 34 | 111 | 3 | 14 |
15 Code LOC: 632 Test LOC: 1210 Code to Test Ratio: 1:1.9
I kept an eye out on our statistics during the competition, and our code to test ratio steadily climbed. At the end of Saturday, we were at 1.2 / 1.3, and now 1.9? Wow, hadn’t really realized that.
Things that didn’t work
- While pairing with Daniel, we were stumped a couple of times. One of the most stressful ones was when we were trying to set properties on Person, and they wouldn’t be set. We were really stumped, and just stumbled upon for nearly 20 minutes. You know what? The error was that Person had an
attr_accessible declaration. Once we realized that, our test passed immediately. Daniel said he’d write a plugin so that assigning to a protected attribute in test mode would raise an exception. This will be a welcome relief!
- Realizing Sunday morning that 1.5 hours of work from Saturday was a bad design decision. Initially, we would put a 10 year cookie in your browsers. Then James realized that this had security implications. We were going to use the cookies to remember what errors and solutions you had posted so that if you ever came back and finally logged on or signed up we could just associate the anonymous postings to your person record. So, 1.5 hours down the drain… We eventually replaced that with some values saved in the session.
Thank you to the RailsRumble organizers for putting up this event for the second year in a row. I count myself very lucky to have participated in this competition with such talented coders as Daniel and James.
And good luck everyone on your own applications. May the best one win!
BTW, if you’re wondering, we only built 17 story points on Sunday. Bug fixing, you know…