Ok, I usually stay pretty much on topic. But I know we’re all trying to figure out how to make money with Ruby. Now you’re in luck:

Ruby Red Riches

Remember me when you’re filthy stinkin rich.

I posted the wrong URL to the new fcgi_handler. Here’s the correct one (I’ve also corrected the original post).

This has been working really well the last couple of days. I haven’t seen ONE 500 error.

http://dev.rubyonrails.org/svn/rails/trunk/railties/lib/fcgi_handler.rb

I apologize for the error!

Thanks to those of you using my DreamHost banner or listing me as your referrer! I appreciate it very much.

I’ve now set up a promo code for new signups to get a discount. (Sorry, you can’t apply it to an existing account.) To get $50 off, use CADHDISC when you sign up. This will split my referral reward about in half with you (you: $50, me: $47).

DreamHost rewards are another pretty attractive reason to host here. With just a couple a year you can sure cut down your hosting costs.

This is a very handy Rails windows help file.

It’s full text searchable and very quick.

Got Firefox? Sure you do! Here’s an extension to put all the docs in a sidebar.

I’ve gotten rid of the majority of my Rails 500 errors over the last few weeks, but there have continued to be the niggling few that just won’t go away. (Well, also I’ve continued to add new functionality which may be contributing.)

I haven’t had any luck matching these to application errors – they just seem to be processes gone bad.

Today I noticed there’s a new version of fcgi_handler.rb available in the rails svn:

http://dev.rubyonrails.org/svn/rails/trunk/railties/lib/fcgi_handler.rb

This is post rails 0.13.1, and you’ll need 0.13 or newer to use it. From the log message:

“Dropped the ‘immediate close-down’ of FCGI processes since it didn’t work consistently and produced bad responses when it didn’t.” -DHH

I’ve run it (it’s running this site right now) on my test machine and after a couple of hours, when it seemed to be perfectly compatible, on my production machine. I haven’t seen any 500 errors since then, and everything seems to be running fine, so maybe this will clean them up a bit.

Now my fastcgi log looks like this:

[16/Aug/2005:19:57:06 :: 6621] asked to terminate ASAP
[16/Aug/2005:19:57:26 :: 6621] terminated gracefully
[16/Aug/2005:20:38:41 :: 15577] starting
[16/Aug/2005:20:38:45 :: 18456] starting

And those graceful exits don’t correspond to 500 errors.

I haven’t managed to get a process to exit with an error yet, but it looks like we should get more info about the error now:

"Dispatcher failed to catch: #{e} (#{e.class})n" +
    "  #{e.backtrace.join("n  ")}n#{msg}"

I’m actually looking forward to seeing what I get there. On my test server at least.

It seems that as promised in their announcement of 27 July, DreamHost is now switching the default rails environment over to production. This should be a good thing, but if you have an application that’s currently running in development mode it’s going to be unhappy until you set it straight.

You’ll need to edit environment.rb changing:
RAILSENV = ENV[‘RAILSENV’] || ‘development’
to:

RAILS_ENV  = 'development'

Or the production environment will be selected at the ||=.

In general you should probably stick to doing most development work offline and using DreamHost for production or integration testing. FastCGI is just not very happy about the kinds of errors you’ll be seeing while in developement.

14 days ago I wrote which mentioned a forthcoming deployment tool for rails. Well, here it is.

Using SwitchTower you define tasks and create a ‘recipe’ that automates the deployment of your application. It can check the latest out of Subversion, upload it to the server, update your database and restart your server processes.

And then when you find out you broke your app, you can roll back to a previous version with ease.

To get it, download the latest rails from svn.