First day on Rails
Well, my first weekend, actually. I spent most of the long weekend diving into RubyOnRails with David. Rails is the hot new framework developed by David Heinemeier Hansen of 37Signals (whom you may recognize from earlier praise) while he was building 37Signal's first application, Basecamp.
Rails has been making lots of noise in the developer community lately: people are claiming enormous increases in productivity over traditional Java development. Even Justin Gehtland, author of Better, Faster, Lighter Java, who has a lot of great things to say about reducing the complexity of the average Java webapp, is a Rails fan.
And after this weekend, I can now say that I'm a Rails fan as well. You can do so much with such little effort. We got big chunks of a sample application written (signup, login, list items, pagination) in 205 lines of code. Add to that 240 lines of tests. (How cool is that? We wrote more test code than functional code. That's gotta be a good sign!) Plus 283 lines of template code — and there's a ton of refactoring we could do there. So 728 lines of "code" (if you count the HTML) and we're probably a third of the way through version one of our sample app.
It did takes us three solid days to get this far. But we were starting from scratch. Neither David nor I had written so much as a line of Ruby before Saturday. In general, we swung wildly between “What the hell is going on here?” to “I can’t believe it was that easy.” But there was far more of the latter than the former.
There are lots of tutorials for starting with Rails. But unfortunately, we couldn’t find anything that got you started with Ruby at the same time. We spent a lot of time trying to figure out what the syntax really meant. What’s the difference between “users”, “:users”, “Users, “@users” and the mysterious “@@users”? Not to mention “user”. I’m still not convinced we really know. The tutorials got us started but left many of our questions unanswered. I wish there were something a little more comprehensive.
The thing I like best about Rails so far is testing. It’s easy. It’s fast. And best of all, they’ve got functional testing built right in. I’ve been searching for a usable functional testing framework for ages. HTTPUnit seems to be the favoured option, it still seems very rough. I haven’t found anything that seems simple and reliable enough to actually use.
Despite some technical challenges, David and I had a great time because we were able to spend the weekend practicing real XP for the first time in ages. Pair programming. Test first development. Refactoring. Simple design. Small releases (only 1 day long). It was exhausting, but it felt great! (I now understand why XP insists on limiting you to eight-hour days. We had originally planned to work late into the night on Saturday and Sunday, but after eight hours of solid programming, we were both pretty fried.)
After three days of the drinking the XP KoolAid again, I’m reminded again how far we fall short at my day job. Our tests are a mess, we don’t pair nearly enough, we don’t do test first development. Our ability to refactor is terribly constrained. (My group doesn’t control the application model. Every DB-affecting change has to go through a multi-step approval process with a different group in a different office. It’s so inefficient.) And I don’t think I’ve had eight hours of uninterrupted programming the entire three years I’ve been at my current job.
But after an inspiring and energizing weekend, I’m a little less excited to go back to work tomorrow. I’ve missed the thrill of learning something new. And our home-grown Java framework feels really clunky after a weekend on Rails. So my hat is off to DHH. He’s built something really amazing. It very nearly lives up to all of the hype. And it’s gotten me terrifically excited. I can’t wait to get comfortable with it so I can really start moving. I’m off; I may be able to add one more feature before bed.
P.S. Oh yeah, I’ll leave you with our number one tip for programming in Rails:
If something doesn’t work, try making it plural. Or singular. Or whichever. There is obviously a very complicated and particular set of rules for naming things in Rails, but we have yet to fully internalize it. And I haven’t seen it written down anywhere. So we just guessed. But it was always a fair debugging strategy to just change the pluralization of whatever variable we were trying to work with and try again.