Extending Rails

Rails is the silver bullet. It's not perfect, but it strives to be and does nearly every thing you'll need. Of course, the context is that you are building a web application with a small team of 5 or less and that 2 of you rarely work in the same area at the same time. Oh, and you don't mind a test suite that takes a few minutes to run, but that isn't a big deal because you TDD now and then, but you mostly test after anyway. And, most importantly, you have the authority to say "no" to features that turn out to be a bit too complicated to implement.

Fortunately, a lot of Rails applications are built in environments similar to the one above. Unfortunately, the impact of Rails will be limited as long as it only provides solutions for those environments.

I'm not one for reinventing the wheel, that's not what this post is about. This post is about using Rails in unintended ways and how to adapt the framework to make it more productive in those environments as well.

I like web apps and small teams, but I do have a different view on testing. I like testing, it makes my job easier. I prefer TDD, and I run the tests very, very often. Since my work style utilizes the test suite, I need it to run quickly. My style differs from many Ruby/Rails developers and I think that's okay. The standard Rails testing is significantly better than nothing and I think it's great for everyone who's happy using it. If you aren't happy with it, I might have a few ideas for you. What I find interesting is the violent reactions that appear when anyone suggests a solution that doesn't follow traditional Rails suggestions.

Obie recently quoted Zed.

If DHH ain't doing it, you don't fucking do it. (Seems every time some clever fellow gets into trouble it's because of that.) -- Zed Shaw

Obie's post was a funny read, but there is almost always truth in jest. The "one true way" sentiment of the Rails community doesn't make sense to me.

I'm not sure how the community adopted the attitude. Rails clearly encourages you to extend it to your needs. The entire plugin system was designed to help you extend Rails. In fact, the plugin system has helped evolve Rails in many ways. Sexy Migrations began as a plugin announced on Err the Blog. Simply RESTful led the way for the Rails REST revolution. Despite the success stories of some plugins, many Ruby/Rails developers are very averse to extending Rails in anyway. Personally, I find this attitude disappointing and destructive. The next great feature to Rails core could come from any one. However, the "one true way" attitude may cause an unsure developer to remain quiet about their ideas, thus stifling innovation.

All applications are not created equally. Some are large and complex, others small and simple. Rails can be used to deliver in both environments; however, it's the customizations that can be the difference between delivering on time or far ahead of schedule. Rails is the foundation, but it's your responsibility to build on that foundation in the way that provides the most value. Sometimes that means adding your own patterns to help deliver for your specific domain. That's okay, in fact, sticking to vanilla rails at the price of productivity isn't a decision that I expect any good developer to make. There's a reason that David and Jamis introduced the presenter pattern into Highrise. They are good developers looking for each opportunity to improve their tools. Ultimately, David didn't like how the pattern worked for him; however, Marcel Molina Jr has a new presenter implementation that looks very promising. That version may make Rails core, or not, but that isn't the point. The point is that the Rails core team doesn't stick to vanilla Rails, and (provided you have a need) neither should you.