Rails 3 at RailsConf 2011
May 17, 2011
A keynote by DHH kicked off Day 2 of RailsConf, where much of his talk was spent discussing new asset behavior in Rails 3.1. Here’s a run down of a few topics I found worth noting:
Rails 3.1 now assumes the default of CoffeeScript and scss (Sass). Jason discussed a Sass talk he attended yesterday at BohConf which includes things like nesting to reduce duplicate code and variables to improve maintainability. I haven’t worked with CoffeeScript much, so I’ll just link to the CoffeeScript documentation and possibly attend a CoffeeScript talk tomorrow. The argument between setting defaults and setting no defaults was revisited, and defaults won. The new defaults use Bundler to include Sass and coffee-script in the Gemfile:
gem 'sass' gem 'coffee-script'
And these can simply be commented out of the dependency list if desired. In my case, if I were developing a Rails app tomorrow with a limited budget, I might choose to use Sass since I’ve worked with it before, but pass on CoffeeScript until I learned more and felt confident working with it.
Scalability and Compiling
Another question that comes up with these new defaults is the scalability and compilability. A new rake task is introduced:
We need a photo break. A Honey Badger.
The second talk I attended was “SOLID Design Principles Behind the Rails 3 Refactoring” by José Valim, a member of the Rails core team.
Single Responsibility Principle
Jose spent the most time talking about the single responsibility principle, or that a class should have one and only one purpose. José discussed the evolution of the ActionView::Base that was responsible for tracking details, finding templates, compling templates, and rendering to gradually be divided into the following components and responsibilities in Rails 3:
- View Path: holds resolvers
- Resolver: finds template. The resolvers abstraction no longer restricts templates to the filesystem (can be anywhere in the app, web service, or even database) which simplifies testing and therefore improves maintainability.
- Lookup Context: tracks details, lookup context object is passed to the view.
- AV::Renderer: renders templates
- ActionView::Base: renders context
By applying the single responsibility principle to the view rendering functionality in Rails, modularization now allows us to extend or override individual points of the process (such as grabbing a template from a CMS-driven database, or passing a different lookup context object to the view) and ensure maintainability by enabling more testable code.
José talked about the other principles, but some pertain to static languages more so than Ruby as the book was originally written with static languages in mind. These included:
- Open/closed principle: José discussed extending ActiveRecord::Base for one modular bit of application but not another.
- Dependency Inversion Principle
- Liskov Substitution Principle: José’s example here in substitution can be applied to the argument between DataMapper versus ActiveRecord and Rails 3.0 took steps to define an API working with an ORM to make it more substitutable.
- Interface Segregation Principle
Since I missed a few points here and there, feel free to check out the conference keynote videos here and I’ll add a link to José’s talk when it becomes available. Undoubtedly, Rails 3.0 and related Rails 3.0 topics will continue to be a highlight of the conference and I look forward to sharing more!