How I Learned to Stop Worrying and Love Rails

February 18, 2008 at 09:09 PM · Posted under Rails · Tagged with developing, rails, team

If I don’t get a ton of flack for advocating Rails in a new corporate environment, I immediately know something’s wrong.

Ok, so I’ve only been in two situations where I’ve dumped an application off from being PHP/Java and ported it to Rails. But both times, I didn’t do it because I was bored, or because it was the cool thing to do. I did it because the current codebase, a puzzle box that only the original developer can easily crack open, was almost impossible to work with.

A lot of people (most whom haven’t ever seriously used the framework) loathe Rails because it’s opinionated. The framework believes that things should be done a certain way, and this usually (although now not as much) came from the core committers who dwell in the aether regions, who have undoubtedly learned through experience that best practices really do exist. And these same people feel that Rails is too restrictive, and when you let them know that you can, for example, have an ActiveRecord model link to another table than the expected one, you’re likely to hear more attempts at pointing out the Failures of Rails: but it can’t scale! it’s slow! no serious company uses it! Yeah, it won’t scale when you script/server up Webrick and think you’re ready to go. Is it slow? Sure, if you’re creating a Ruby protein folding application…if a web application is sluggish, most likely the clog is due to poor design or a less than ideal server environment (in my experience, database servers usually die faster than frontends). Plenty of companies use Rails, and more come onboard every day, but because it’s a young framework, the older (and hence, more ‘serious’ companies) aren’t ready to ditch their current codebase to start anew.

Before this becomes a Ruby on Rails lovefest, let’s get back to the title of this entry. Why don’t I choke in the restrictive confines of the Rails framework? How come I haven’t run back to the safe arms of PHP, yearning for a life of more control?

Ruby is an amazingly dynamic language. Anything is possible. Blocks, closures, meta-programming, et. al. make for a genuinely rare programming experience. Because Rails is built off Ruby, one doesn’t need to feel trapped by a framework that attempts to make life easier by taking common expectations and leaving you free to decorate the carriage, rather than reinventing its wheels. There is a thing we Ruby developers love to do, and this thing is monkey patching. Anyone who’s realized the power of alias_method_chain and how to weave in and out of classes and modules, reworking the framework to fit your every need and desire, knows how liberating making Rails her own can be.

Because developing in Rails allows me to leverage Ruby in refactoring and patching the framework for my project’s concerns, I have more time to do other things. Like thinking. Not to sound like an elitist who, like Aristophane’s Socrates, walks amongst the clouds (ha!), but I’ve learned that developers who spend most of their time thinking about their project, rather than grueling over mundane tasks and busy work, do better. Their projects are stronger, easier to build upon, and organized well. These developers spend much of their free time doing things like evangelizing the MVC paradigm, reading non-fiction, and dining out. Their counterparts - those who fear the surge of extra web traffic, faulty error handling, and accidently falling into while() loops that never end - live in fear of their creation, dreading the day when their creation will turn on the parent. These developers spent too much of their time drudging in the mud, toiling and hammering away inconsistencies and blemishes - had they not had these concerns, perhaps they could have tackled their infinite loop before it got to them.

DISCLAIMER: The point of this article isn’t to attempt to prove that Ruby > PHP (though for me and my style, it is.) It’s aimed at those rugged individualists who believe that frameworks are for sissies and code should be slung about. Unfortunately, when it comes to the reality, these developers are jacks of all trades, and masters of none. And because they’re masters of none, and usually aren’t experts at every facet of a full fledged application, their work is full of holes and prone to disaster. My advice? Decorate the carriage. Let the wheelwrights, blacksmiths, and other masters of their trades dictate and develop the base functionality of your applications. It’s the mark of a hobbyist to develop everything from scratch; a master leverages other people’s ideas and expertise. If you’re being paid to make a product, or your application is mission critical, be the master!

So stop worrying about suffocating within the Rails framework, and realize you’ve been lied about the flexibility of Ruby on Rails - start thinking about the amount of time you’ll have to seriously consider what you’re working on, rather than rushing to meet deadlines and squashing bugs.

Permalink

RSS feed for comments on this post

Leave a Comment