Enlightenments from RailsConf 2008

Some people want to go to RailsConf and learn about new features coming up in Rails 2.1 -- that's not me. If I wanted to learn what's new in Rails 2.1, I could read it online and save a trip to Portland. For me, it's about meeting like-minded developers who understanding how to use Rails to do better software development. Below are some personal highlights from the conference.

Software Methodology

I enjoyed Joel Spolsky's keynote which had nothing to do with Rails. The theme was Building Great Software. In addition to learning how to build
great software by making users happy, I was happily informed that putting a picture of Angelina Jolie on a slide for 30 seconds boosts the presentation rating by 10%. I will definitely keep that in mind for future presentations.

DHH, the father of Rails, revealed nothing about new feature in Rails. A good quote from his talk:

You are tired and you keep working for another 8 hours, and you are going to spend the next 20 hours fixing it.

Scaling Rails

For me, scaling Rails is just like scaling any other web application. I am a big fan of memcached. I like to cache everything in memcached and put any slow processes into a queue. Since memcached is horizontally scalable and shared among all the Rails instances, it is a cheap and easy way to scale your application. Here are a few other good scaling techniques people mentioned in the talks:

1. Write Mongrel handlers which handle the requests without going to Rails.
2. Put Rails into EC2 so when you get stuck, it buys you time to tackle the problem without suffering from performance. Downside: you might get a big
   bill from Amazon.
3. Have good monitoring in place which helps you to analyze the issues.
4. Put in "knobs" to tune your application performance.
5. Able to throttle things dynamically.

In my opinion, scaling is not a problem for Rails in 99% of the cases. Don't think about it too much and do the simplest thing that could possibly work. After all, needing to scale is a good problem to have.

Rising Stars

• JRuby: i18n, single thread, poor memory management -- all these problems go away with JRuby. Your organization is old-school and only want to deploy Java applications? Use Warbler to create a war file for your Rails app and hand the file over to your release engineers to deploy your "Java" app. Done!
• DataMapper: Does your application have high concurrency operations that ActiveRecord is blocking because it is not thread-safe?* Does your application have a hard time talking to a legacy database which does not obey the conventions? Does your application want to talk to multiple databases or even a data source that isn't a database? DataMapper to the rescue! It's a thread-safe, flexible ORM that can easily be extended to talk to any data source. Sounds pretty cool, don't you think?
• EventMachine: Want to implement a small custom service? EventMachine is another alternative to BackgroundDRB for handling background tasks and help scaling your application.
• Others: I heard there were some good sessions talking about Rubinius, MagLev, and other things that I missed. I wish I can go to all but too bad there is only one, non-threaded instance of me. ;-)

If you combine everything together, you can create an architecture with theoretically high-performance and high-concurrency as illustrated below.

My advice:
One day, you may need a super-scalable architecture to keep up with the traffic. But before that, it's more important to focus on building a great software that makes people happy.

*Rails is not thread-safe so you'd probably want to use Merb instead of Rails.