Depending on what your client needs, Ruby on Rails may or may not be a good technology choice. Whenever someone is looking for a new project I go through this mental checklist to see if Ruby on Rails would be the best fit for them:
1. Does the project call for a web based application?
Ruby on Rails can work outside of the web environment but it loses some of its productivity. Pseudo-web environments like web services will lose some of the productivity but the new REST features is making Ruby on Rails a good contender.
2. Is this a “greenfield project” where no legacy code is in place?
If the client has legacy code in place that they are wanting to keep, the project will have problems when the time come to integrate the two codebases. Ruby on Rails can work in those places, it would just take some more effort and a very good deployment plan.
3. Are you skilled with Ruby on Rails or do you have access to a skilled development team?
A lot of people get into Ruby on Rails thinking it is a magic bullet. Unless you have programmed in Ruby before, you are going to have to be a fast learner. Learning a new programming language (Ruby) along with a large framework (Rails) is going to be painful. Luckily Ruby is a very beginner friendly programming language, and you can pick up the major points in a few weeks.
Because Ruby on Rails is very productive, it might be a good investment for a newcomer to take two weeks and write a simple throwaway application. I’m not new to Ruby or Ruby on Rails but I learned a ton of things in the 48 hours for the Rails Rumble 2007.
4. Does your client have high quality hosting?
Sad fact, Ruby on Rails needs a more powerful computer to run than something like PHP. But one thing to remember, do you really want to have a client spend $10,000 on a web project and then throw it onto a $10 month web host. A 256MB virtual private server is enough to get a good Ruby on Rails website running happily. I recommend Slicehost (referral link), they have hosted my websites since March 2007 and I have not had any problems at all.
5. Is the project going to use AJAX effects?
There exists many libraries to help add in AJAX effects to any programming language or framework but Ruby on Rails has a lot of built in helpers that can make adding AJAX one line changes. Ruby on Rails also makes it easy for your AJAX effects degrade gracefully for non-JavaScript users.
I love Ruby on Rails but I find most of the headaches come from someone who uses Ruby on Rails because it is cool technology, and not because it is the best solution to their specific problem. Remember these are some of my guidelines that I use for my client projects.
What guidelines do you use to decide Ruby on Rails is your best choice?
Eric
Eric, I love how pragmatic you are about this. You love RoR, but are totally willing to concede that it is not a “silver bullet”
Thanks!
I also enjoyed this post. I’ve run into an interesting situation. I was asked to build a Web front – end to some existing functionality – sort of a replace-existing-app++ kind of thing.
This went fine until the (1!) technical resource in charge of all of the back end stuff left the company. Fixes to this infrastructure now fall to me since a) I know Java and that’s what it’s done in and b) I’m the only one to do it.
So I’ve run into a situation where I started out doing an RoR app., but now I’m stuck doing Java maintenance as well.
But more to the point, I’m glad that I used RoR for this app., as I have learned a great deal about the limits of ActiveRecord and doing Ruby development on the Windows platform. What I’ve taken away is you can probably handle any integration that you need to do with foreign technologies, but you may have to work at it. The ease of development of the “pure” RoR work has made the extra effort to integrate more than worth it.
Wes
@Wes: Ouch, I have never had the *pleasure* of working with Java but I do know what its like to inherent someone’s old project. It amazes me that RoR can stretch to accommodate so many different integration environments but still stay simple for the majority of development work.
Thanks for the tips on when RoR is appropriate, Eric. I will definitely keep this information in mind.