I just got back from an ice cream social with Ruby on Rails creator David Heinemeier Hansson (aka DHH). I had come across his blog post about this casual event last week and figured I’d make my way over there, particularly since the location (Michael’s Gelato & Cafe) in downtown Palo Alto is only 5 minutes from my house.
There were probably about 20 other people (mainly Rails developers) at the event, and since the space was pretty small and we didn’t have a dedicated room, it was initially difficult to actually speak with David. But towards the end of the evening the group started getting smaller, which made it easier to participate in the conversation.
In terms of what David had to say, I did not catch too many noteworthy items that are not already known in Ruby on Rails circles. But a few things seem to be key to understanding both the history and the future of Rails:
David created Rails to solve his specific problems. It wasn’t meant to directly solve every possible problem out there, and if there are useful features missing from it that simply means that he (or presumably the rest of the core team, now that it has become a larger community project) has not needed that particular functionality, not that it would not be useful.
Rails is (as we all know) a very opinionated framework. It makes a lot of reasonable assumptions about various things (such as the names of “id” columns), which enables developers to accomplish a lot with very little code. However, all of these opinions are purely about the internals of the system and therefore relevant for developers, but never affect the end user in any way. David is strongly against including any features in Rails that would result in any default application flows or otherwise affect the actual behavior of the application. That’s why Rails still does not (and probably will never) include a built-in authentication system.
Otherwise, he seems pretty indifferent about a lot of the details about how people are working with Rails. For example, Ruby and Ruby on Rails’ performance was good enough for him several years ago, so this area has never been too much of a concern of his. He also doesn’t feel strongly about using Test::Unit vs. RSpec. In his opinion, Test::Unit is good enough, and actually easier to understand for someone who does not have much experience with testing, whereas RSpec probably has more of a learning curve (and he did not seem to excited about the particular syntax). He felt that the most important thing that BDD and RSpec brought to the table is the “should” keyword, and that changing Rails to allow this in test method names made a big enough difference in readability and helped enforce the convention of using a single assertion for each test case. (I actually was not aware that you can use “should” in Rails test names; I’ll have to look into this.)
I probably missed a bunch of other nuggets of wisdom because the room was a bit noisy and crowded, but I’m sure that all of these have been posted on various blogs and mentioned in various keynote speeches before.
Anyway, it was nice to meet David in person. He seems like a great guy, and I definitely appreciate that he took the time to meet with a small fraction of his user base tonight. It’s refreshing to work with technologies that are owned and driven by real-world people like this, rather than large corporations that have lost touch with their user base.