Advanced ActiveRecord Techniques
Chad’s talk was about refactoring your Rails code to use ActiveRecord the way it was meant to be used. It was a perfect example of a more advnaced (though still easy to understand), technical, & code-heavy talk. As such, I don’t have much in terms of notes (His slides will be available from Smashing Robots into Other Giant Robots at some point soon). He mentioned that in order to refactor effectively, you must have a good solid test suite or you will break things you never knew could break! He talked about moving code from the controller to the model, he talked about using callbacks, modules, and mixins where appropriate. I can’t really go into depth on the path he took to refactor a bunch of code, but it was a terrific opportunity to validate how I write code and know that what I do is sanctioned by others (or at least one other person). He had this nugget of wisdom that I thought sums up the talk quite well:
A great metric for your controllers (and code in general) is ‘can you put it up on a slide’. If you can’t, something’s wrong.
Keynote – Rails Panel
Chad opened the panel by announcing that RailsConf2009 will likely not be held in Portland next year. He mentioned Las Vegas as a possibility, but I don’t know if he was joking. He also said that RailsConf will be sponsoring CabooseConf next year for free. Just example #10001101011 of why the Ruby/Rails community is so amazing.
The core team started by answering a question about the roadmap of the framework. They said that although they want to do some cleanup and refactoring in ActiveRecord, there is no roadmap for what’s coming up. Then they answered a question addressing plugin support (breaking compatibility with popular plugins) and DHH pointed out that they have really had to start dealing with an issue where “Many people don’t want to build against edge because things can change or be added or removed, but edge can’t be released until it is tested“.
DHH plugged the docrails branch on github that makes it much easier for developers for contribute documentation about Rails. They also pointed out that github pull requests on the Rails core do not go anywhere, they just disappear. I thought that was good to note, as I was curious how they handled pull requests. DHH also mentioned that he isn’t happy with a log of the view helpers such as ‘error_messages_for’ and a few others, so if anybody was looking for something to work on in Rails core.
I got up and asked about how moving to git and lighthouse has impacted their work. I got a good response that both git and lighthouse have improved their process because they can better track issues using lighthouse and that git makes merging patching much easier. There was also a great question about handling security issues. When Rails had a major security issue discovered the first time, they were unprepared for the process they had to go through. They are more aware of that process now and have a more formal security handling protocol in place. Awww…Rails is growing up!
And that’s the end of the conference! Look for my final notes shortly!