In Part 1, we built QFeedReader, a simple and scalable web-based RSS reader backed by DJ.

Queueing is a critical tool for building truly scalable web apps. Don’t do any heavy lifting in the web processes (mongrels); instead, put jobs on a queue, let background workers do the work, and then display the results to the user in another request.

Like many folks, my early experience with Ruby was largely entwined with Rails. ActiveSupport provies a lot of handy little helpers that are generally useful; and once I got used to having them, I found myself annoyed that they weren’t available in my pure Ruby programs. Like 3.days.ago, or string.blank?.

Jeremy Kemper merged my patch to wrap migrations in a transaction into Rails edge last week. (This was a two year old patch - props to Tarmo Tänav for some mad rebasing.)

Rails provides a standardized way - convention over configuration - to do all the common tasks a CRUD web app would want to do. One rather glaring omission, however, is that there’s no standard for what to do to set up a new app.

The dreaded “wedged Mongrel” - your app server stuck on one request, with others piling up, waiting infinitely for it to come free - is a problem all production Rails apps face sooner or later. The solution most commonly used is to restart the app servers frequently, via something like Monit, or just on a cron job.

Places you’ll find me at Railsconf this year:

• Giving my talk about custom Nginx modules on Saturday afternoon. The talk has evolved quite a bit since I wrote the description, so expect some broader topics, like why I think HTTP is the critical enabling protocol in the era of Rails and cloud computing.
• Attending the Heroku product talk, in which we propose why you may never need to think about servers or hosting again. This is inconveniently scheduled immediately before my session talk, so I’ll have to duck out partway through.
• Signing books along with the other recipe contributors to Mike Clark’s Advanced Rails Recipes at the Powell’s Books booth at the lunch break on Friday.
• Hanging around our booth, where I intend to hack on Heroku and my open source projects, listen in on Geoffrey Grosenbach's podcast interviews, and meet everyone that stops by. So… stop by! :)

Advanced Rails Recipes by Mike Clark is now shipping. I’m pleased to have contributed to the chapter on nested resources.

After Dreamhost's post that shared hosting with Rails is too difficult to implement, and DHH stated that he (mostly) agrees</a>, Peter Cooper of RubyInside suggested that we need a mod_ruby. Now I’m going to chime in with a few thoughts of my own.

For a while, everything that we did in Heroku to extend the functionality of Rails, or interoperate with it, has been done through extension mechanisms. Monkeypatching via plugins, use of the somewhat obscure Mongrel GemPlugin, and tweaking of the user’s Rails app files directly. (We try to avoid that last one whenever possible. Early on we did a lot of it, but more recently we’ve managed to avoid it almost entirely, much to my relief.)

Nested resources were introduced in Rails 1.2 and are touted as the Right Way to do REST with parent-child model associations. If your app has a url that reads something like /employees?company_id=1, a switch to nested resources would cause it to read /companies/1/employees.

The Rails 2 upgrade has been surprisingly painless on the half dozen or so production apps I’ve upgraded. One problem seems to be that not all the mirrors are updated, so you get “no such gem” and have to repeat the command a few times until it finds a mirror that has it. But the other one is that for some reason, the Rails 2.0.1 package doesn’t find the newly-added activeresource dependency. So the full upgrade becomes:

When overloading an ActiveRecord setter, I’ve often done this: