Teasing out great development concepts from Rails
When DHH teased out Rails from the Basecamp source, the process was described as “experience-based design” - meaning that everything Rails provided from day one was born from the need to solve common development headaches met by everyday developers working on everyday development projects. The idea was to extract the largest common denominator of all common projects and throw them into one prescriptive framework.
The funny thing about that is, this particular cuddliness of Rails has seemed to split the Rails camp into two groups of people. Yes I know, generalization is bad, but it’s convenient. In one corner, we have the hardcore developers who know the entire framework inside and out. These are the ones that can break Rails down into it’s actual and somewhat separable components. They know and understand how ActiveRecord (M) is separate from ActionPack (VC), which is separate from ActionMailer, which is separate from ActiveSupport, etc. They see both the forest and the individual trees that make the forest possible. The other corner of developers couldn’t care less. They’re using Rails as an all-in-one packaged deal. Like (some of) the old MFC developers of yore, they couldn’t tell how things work under the hood, they just care that it does.
Having said all that, in the spirit of “experienced-based” teasing out of great ideas, I think Rails has gotten to the point where it’s interesting to take a look at some of the concepts from which it is comprised and acknowledge them each individually. It’s time to not just look at the largest common denominator, but each reasonably sized denominator as well. I’ll skip the obvious cookie-cutter cliche ones like MVC and ActiveRecord. I’m going for the more underrated things.
Granted, I haven’t put much thought into this. This post is just a result of me thinking: “These ideas would and should work anywhere and everywhere”. Here’s my top 5:
5) Unit-testing and testing in general. I guess this falls under “cliche”, but the fact that Rails comes with testing ready out of the box speaks worlds of how important it is to all software projects. This is a should have/must have for any project
4) Mongrel (included in Rails 2.x I believe). It’s not this particular piece of software that I like, it’s what it represents. It screams “acknowledge your entire stack”. Mongrel was written to address the specific performance issues with Rails apps, but every project should have its Mongrel - its underlying engine that makes it run and run fast.
3) DB Abstraction/Migrations. MySQL, Oracle, SQLite, PostgreSQL, WhoTheHellCaresSQL. They should all be made to behave the same. Yes, I run SQLite on development and test, but MySQL on production. As long as I keep in mind the performance characteristics (see #4), who cares which DB is running?
2) Development, Test, and Production environments. Every project has some variation of these three environments. Every project should formalize that fact! Make it configurable in a YAML file! The fact that Rails comes with this out of the box makes development so, so easy.
1) Documentation. ‘Nuff said. If you don’t document it, it never happened.