-- David A. Black
Rails choices seems like a new or paradoxical concept. We've heard forever that Rails is opinionated software and "forces" you into design choices.
But David sees this paradigm shifting. He attributes the origins of this shift to Josh Susser and his blog post, "The Tyranny of Choice."
In fact, David sees signs of these choices even in the earliest versions of Rails. He is even writing a book about those choices called, appropriately, "Rails Choices" (Pragmatic Bookshelf, forthcoming). And this is where he will focus this particular talk.
Rails 3 is more modular than any of its predecessors. Modularity is slightly different than choice in that modularity has a bigger effect on architecture. So we'll first go through some everyday choices and then we will dip into modularity, specifically in respect to "choosing" a DB layer other than ActiveRecord.
To complete the transparency of his book, this talk, and the motives behind it, David goes on to describe his goals:
-- avoid "this sux/this rulez" - just deliver factual information so that the attendees can make up their own minds.
-- Factor in organizational realities (if he didn't before, he now has his fair share after spending three months on a client site as a Cyrus developer). Who gets to see what? Who gets to change what? Are some decisions already made (like in any legacy application)? In this case we need to evaluate the costs vs. the benefits of change. Choice, then, is loaded in a way that it is not in a brand new project.
-- Provide a good number of techniques. This is not an in-depth how-to. But the book should touch on things the reader isn't intimately familiar with. For example, and in-depth discussion of ORM validations vs. DB constraints. David also mentioned Liquid architecture as an alternative.
-- Stick close to the framework. This is not a rundown on every plugin or gem. It's not a how-to on adding these programs to your framework. However, some plugins get 'privileged' treatment such as RSpec, HAML, and Liquid.
In Rails 3, many things that used to just come wrapped up with the package are now installed via plugins. David also wants to open the subject of "supplemental code" - add-ons, overrides, project-specific libraries, etc... I like this coverage. For the longest time on my first Rails project I just stuck everything that wasn't an M, V, or C into the lib directory. Things got messy in a hurry, as you might expect. I'd like to learn more about this. Application organization best practices.
An aside: David HATES scaffolding. As he sees it, scaffolding obscures the real work that must be done to set up your first piece of functionality. One should be able to get through the preliminaries without being tied into scaffolding.
David has set up a site called http://anecdotes.rubypal.com/. This is supposed to augment or supplement his new book. From the site itself:
What's the "anecdote" thing?
I'd like to include some stories from people who've developed Rails applications and have real-life experience making Rails choices. Each anecdote will be about 1/3 to 1/2 a page long.
Why did you choose RSpec over TestUnit? Are you using HAML or Liquid instead of RHTML? Does your team use migrations, or does your DBA do it all?
And why? That's what I'm interested in: why you made a particular choice, in the context of your project and your team.
If your anecdote is chosen for inclusion in the book, you'll get a free copy of it when it's published.
Act 2 of David's Talk: Choice and Modularity
The demo will be a replacement of ActiveRecord with GDBM in Rails 3. Live coding here. (In GDBM, for each record, you have a file.) David shows us a Rails application console where a model acts exactly the same way it would were it interacting with ActiveRecord. Only it's not AR; it's GDBM under the hood. In showing how the replacement was implemented, David points out the freedom he has to write his own class methods from which his models extend. He then shows us the abstract_oxm.rb file that is responsible for "gluing" the object mapping layer to ActiveModel. This is the part where Rails 3 becomes very modular. You really have the choice to utilize one configuration file to map the rest of Rails to whatever database mapping layer you want. There are a few methods that "have" to be implemented in order for ActiveModel to play nice. The rest is up to you. Very cool!
David puts sums up succinctly. To paraphrase: there is a very small contract to which you must adhere in order to implement your own choice of persistence layer. And this is not limited to database layers. Templating and the ability to more quickly and easily work with Rack are other examples of where Rails 3 provides modularity.
No comments:
Post a Comment