Sazbean

Lets continue our theme of Ruby on Rails reviews with the advice I give clients thinking of trying out RoR for a project.

My first piece of advice when evaluating a new language or technology is for a company to get dirty early on; get at least one small project under your belt before reaching out to a consulting group. Sure its strange advice from a consultant but it’s grounded in solid personal experience. Companies that have had first hand experience with a product or language are often more comfortable with the advantages and limitations of said product or language. That means their expectations are correctly grounded in reality. Here are some expectations that I’ve found to be true through personal experience:

• Rails is good for delivering dynamically generated textual content over the web. Really good, actually. Really really good.
• Rails is not as good at maintaining session state as other languages, such as Java Swing. This makes it a poor platform to replace that desktop accounting app. Better to look at a Java Hybrid product like Oracle Application Server with Forms and Reports.
• Rails can handle Interactive Media, but not as well as Adobe Flex.
• Rails can do AJAX well but the Scriptaculous tends to be a weighty download. It is cache-able, though so your experience may differ. I prefer JQuery Having said that, the RJS libraries in Rails makes writing JavaScript much less painful.
• If something is working in one language, don’t redo it in Rails just to keep the source code in one silo. If PHPBB works for you, great! Stick with it.
• The Rails Persistence layer ActiveRecord is very cool. It can greatly simplify database access for new users. However, don’t expect it to solve all data access woes.

My second piece of advice is to break the Test Once Live habit. This one is a tough sell since people love the time saved in development using Dynamic Languages and loath the trade off spent writing solid tests. Here is the reality, your application will run just well enough to get everyone excited about it. It will also fail you the moment you show it off to someone you want to impress. Here are some testing tips that I have learned the hard way.

• Write RSpec tests before you show it to anyone. RSpec, once you learn it, can be the stories given to a consultant. We’ll love ya for it.
• Do end user testing with JMeter and FireBug. JMeter will to load testing and FireBug will tell you more about what your browser is getting from the server.
• Once you have a working application start running AutoTest on startup. Let it sit in the background and just forget its there. Then, when you have the last second really important change you need to make before 8AM, it can catch and alert you to a test failure before you find out live.