5 Reasons to Use Rails

One axiom overheard constantly throughout the blogs and forums of the internet’s technorati, is “use the right tool for the job.” Generally this nugget is brought up in conversations questioning whether one should use framework A or framework B, language C or language D, etc… Invariably, people get pissed, comments get ridiculous, and “that guy”:http://www.geekitude.com/Pictures/Linucon2004/Ex45TronUpCloseRot.jpg eventually shows up to tell everyone that they’re retards for not using Lisp. This is not one of those articles. Having spent too much of my life reading those posts, trying to decipher if tool A is right for feature-that-needs-to-go-live-next-week-or-else-you’ll-be-replaced-by-10-indian-programmers, I’ve decided to write up some reasons why you just may want to consider to start using Rails.

Before going much further, I should state that I enjoy programming just about anything and in about any language. A good weekend for me almost always includes compilation of source code and a strong beer–the order and frequency of the two being highly dependent on the preceding 5 days. But take my opinions with a grain of salt. These opinions are from a geek working in the ad world where development cycles are extremely tiny and our requirement list is often very different from software development studios.

1. Rails deployment are now almost as easy as PHP deployments

It used to be that Rails’ biggest hurdle was deployment. Having set up many mongrel-based deployment schemes, I can understand why Rails scared away a lot of people. However, with stability of “Phusion Passenger”:http://www.modrails.com/, setting up a Rails app is now just as trivial as PHP. If you’re worried about stability, it may be worth it to know there are a handful of large websites now using Passenger, including “Shopify”:http://www.shopify.com and even “NY Times”:http://www.nytimes.com. We deploy all of our Rails sites through Passenger and have not had one major problem yet.

2. Test like a pro

If you enjoy working within the MVC paradigm and you feel guilty about writing code before you write a test, Rails provides a wealth of features proven in the .NET and Java enterprise landscape, and adapts them to the flexible Ruby language. Test and Behavior driven development approaches are easy to follow in Rails.

3. You want easy object relational mapping

ActiveRecord is a thing of beauty. Does it work for every possible situation? Nope, but it gets you pretty darn close. The first time I made a database query in Rails, my jaw dropped.

User.find(:all, :conditions => [ 'created_at < ?', Time.now - 1.days])

Even if you haven’t used Rails before, what that tiny command does is probably pretty obvious. While ActiveRecord is not an excuse for any developer to forget SQL entirely, it helps us with the low hanging fruit in our systems and lets us spend more time where we should really be using our brains.

4. You’re really tired of FTP

I have a confession – you don’t need to use Rails to take advantage of automated deployments with the amazing “Capistrano”:http://www.capify.org/ tool. Launching new deployments of client websites is now as easy as executing the following command from the command line:

cap production deploy

This line, after some configuration of course, will completely deploy my application from a repository, run any database migrations, reset my daemons, and keep a copy of the last version in case something is botched. Rolling back is easy:

cap production deploy:rollback

Boom! I’m right back to the last version before the client even saw the nasty 500 error header on their contact page. Whew! (Not that this ever happens of course…eh-hem).

5. You want easier maintainability

There is no such thing as a sealed class in Ruby. That means if I don’t like Ruby’s String class, I can easily rewrite it to suit my needs (otherwise known as *monkey-patching*) at any time throughout a program’s execution. This is both very dangerous and a very awesome for some fairly obvious reasons. If we have interoperability between 2 different software libraries, we can easily patch the deficiencies ourselves while keeping the original libraries intact. If you don’t like how Rails handles error messages, you can easily override the offending method or patch the functionality how you see fit.

Is this approach to software development raising some red flags? It should, but there’s a way to make ourselves feel better. With a strong system of unit tests in place, we give ourselves an easy way to assure that functionality remains unchanged when software updates roll out, or requirements of a component change. While the dynamic aspects of Ruby can cause us some serious headaches if we abuse this power, we can save ourselves significant work by writing small patches instead of modifying many different source files.

Conclusion

I talked about a lot of different things, and admittedly, didn’t go into a lot of depth. But if you’re curious about what it’s like to develop in Rails, check out some of the things I’ve pointed out above. For me, these 5 points have made Rails my preferred web platform of choice for small to medium-sized, database driven websites.5