Ruby On Rails
I’ve been a fan of Ruby since the first Pick Axe book was released. I’ve used it for a few simple scripty projects, but I’d never considered using it for anything major. Recently, Rails has been gaining a lot of buzz. I thought I’d post my thoughts on rails and why people should or shouldn’t choose rails for their next project.
By way of background, I’m an ‘enterprise’ java developer. I build ‘enterprise’ apps for a large bank. I use hibernate, struts and spring on a daily basis. I reviewed Hibernate in Action and highly recommend it, I bought & loved both of Rod Johnson’s books.
Pros
Rails is perhaps the most productive web development environment I’ve ever used. It’s simple, elegant and understandable. I’ve had some configuration files that are bigger than BaseCamp (4kLoc)
There’s no mapping controllers to url patterns, it’s done in the code. No mapping erb templates to view states, it’s done in the code. The use of convention over configuration is a great idea. I lose some flexibility in the naming of my controllers & views, but it’s more than made up for by the time savings I gain from not having to churn out all that XML.
If you have a green-field situation, Active Record is a lot quicker to build with than hibernate will ever be. Occasionally the SQL can be a little messy, but find_by_sql lets you fix that.
Cons
Working with an existing database is probably going to be a little challenging. The reliance on convention over configuration can fall down if your organisation’s convention doesn’t map to Rails’. I don’t know many DBA’s who’d let you call primary key’s “id”, or let your name your tables simply, without some whacked ‘standard’.
I’m still finding it a little odd to ‘just add columns’ when I want new attributes in my model, but I’m sure I’ll get over it.
Non-Cons
I’ve seen people on TSS and LoudThinking suggesting that Rails isn’t ready for large enterprises. While I think it’s probably true that a lot of large enterprises probably aren’t ready for Rails, there are a number of ‘complaints’ that are relatively unimportant.
SOAP support doesn’t matter, enterprises don’t really need it. I don’t care what IBM tells you, BPEL, WS-* and the like aren’t that big a deal when you’re building web applications.
Database support is a non-issue, it’s easy enough to write a database adapter for your favourite ‘enterprise’ RDBMS. If you can’t do it, I’m sure one of the Consulting companies will be willing to help, for a price.
Conclusion
So, with all that in mind, will I use rails for my next application? Yes and no.
If I were building an application for myself, or to start a web based business, I’d definitely choose rails. In terms of time to market and maintenance costs I don’t think I could seriously consider using J2EE or PHP. Similarly, if I were doing contract development for small or medium clients, I’d strongly urge them to consider rails.
However, I won’t be suggesting we start using rails at work. The fact of the matter is that a large company like the one I work for is almost always hiring new developers. Putting an ad out for ‘Java Developers’ will get us hundreds of CVs, Ruby developers? Maybe one or two. Until that changes I wouldn’t consider rails for our enterprise. Large companies may need to bring on developers every month, requiring rails will make that almost impossible. I don’t feel that that’s being driven by fear, just being rational about things.
Ironies
I’m about to depart for my holiday in san francisco (tips still welcome). We arrive in time for the next building of basecamp, I’m sure I’d leave that course with a strong skill base to begin working with rails. But it’s a holiday, so I won’t be going.
Similarly, we arrive in Vegas in time for Apache con 2004, I’m sure I could learn a lot there too, but it’s a holiday so I won’t be going …


KBob November 17th, 2004 @ 10:57 PM
I agree regarding working with existing databases or strict DBAs with their own set of rules. However, so far I’ve found that most of the conventions can be overridden in your ActiveRecord subclass. You can override self.table_name to specify the database table exactly. You can also override self.primary_key to specify the ‘id’ column, e.g., def self.primary_key “status_code” end. However, this could get a bit tedious when you have to do it for every table.
Brady White January 9th, 2005 @ 02:30 AM
I would love to see some of your projects where you’ve used rails. I’m hesitant to take the time to jump start into it. Great description on when to use rails and when not to. A co-worker and I have been talking about it here at work.