Well this is working out well so far. I'm really liking the Passenger (mod_rails for Apache) extension. Right now I have this Mephisto site running it and it seems to be doing really well. Also, most people do not do this, but I run a full development stack Apache/MongrelCluster to mimic production boxes the best way I can. Now I am running mod_rails on all my development hosts.

Some Things I Like

• I do not have to fuss with OS X launchd startup scripts for my mongrels, just Apache.
• Typically in a high volume site that runs mongrel behind an Apache proxy balancer, will get a large timeout and proxy error even if the mongrels are immediately available. Passenger has a nice way to restart the app, just touch the tmp/restart.txt file.

Some Things I'm Waiting For

• The RailsEnv can not be set per virtual host. You have to set RAILS_ENV = 'development' in each app if you want to run mixed virtual hosts with different environments.
• Normally I would pass environment variables to the console when issuing mongrel cluster starts. I would really love to see Passenger support apache environment variables.

Here is how to get a playlist of sounds that will be hooked to both your autotest :red and :green callbacks. Basically this gives you a folder of sounds that are played one after another, in a loop, as your tests pass or fail. See this move below for a quick example.

I just had an issue pop up today that seemed to be an issue for a few others. It seemed that all of a sudden that my autotest was stuck in an infinite loop after a failure or error. At first I thought it was related to some additions to my ~/.autotest file but after commenting out the whole lot of additions there, I realized it was something else. Here was my fix. Basically I think these errors are always related to a file that has changed during your test run. Now we just have to find out what that files are. Here are the steps I took to find out.

OK, so you want to keep your code placement REALLY organized. You have read about my persnicketyness and now you want to practice the best in concern placement and keep those controllers of yours really slim. Like me, you may want to try and keep controller feature additions to very specific one liners of code. Organizing your controller code to do just that with ActiveRecord models or even your own custom classes is a pretty easy task, but how do you keep things simple when dealing with controller actions that have to send email AND you want that single email link of code to be responsible for everything in it's own encapsulated way.

One of the things that I have really grown persnickety about is the placement of code. For example, I am a huge advocate that controllers in a rails project should read like a mini Domain Specific Language (DSL) and that as much logic as possible be delegated to the models. In my opinion the best way to do that in a Rails project is to learn the proper usage of ActiveRecord Association Extensions. You can check out the Rails API on this page and scroll down to the section called "Association Extensions" if you read the official docs. In short:

After attending Rails Edge in Reston, Virginia I decided to move some common tasks from my ~/.irbrc file and put them into Rake. I thought I would share a task that reads and writes the ActiveRecord schema table. Sometimes in migrations this is either good to know or manually change. Simply copy this in a foo.task file in your project/lib/tasks directory and use rake -T to see the description and usage. I have placed these tasks in the db:version namespace.

Only now do I really get this image from DHH's blog. I am really beginning to despise SOAP for some reason, but I guess I will "get it" as I learn more about it -- as it seems to be the only way to do business with the big players out there. For a glimpse of some of my hell, check out this Ruby + SOAP4R + WSDL Hell article.