perl -wne'while(/[\w\.\-]+@[\w\.\-]+\w+/g){print "$&\n"}' original.txt | sort -u > extracted_emails.txt

There’s probably room for improvement here—any ideas, please comment!

I know how to avoid this mistake and in a moment, so will you!

Writeboard and Basecamp are actually separate products, much as Highrise and Campfire are separate. Basecamp provides Writeboard integration, and most people I know just think of it as a Basecamp feature (which is fine).

See, this is actually a Writeboard URL, and we’re not in Basecamp right now.

If you copy-and-paste the URL from the Location: field, you’re actually capturing a link to your Writeboard account, and not your Basecamp project. That’s why 37signals provides the “Share this Writeboard” link. If you want to link to this document Basecamp-wise, you must right-click the “Share this Writeboard” link, and select “Copy this link” (on a Mac, that is). You do not want to copy the 123.writeboard.com URL.

This is oddly inscrutable for a 37signals product and I hope it gets improved someday. In the meantime, we’ll just have to suck it up and make ourselves remember to link to Writeboards the right way and not the wrong way.

New Relic is the best way to track a Rails app’s performance, no question, but it still confounds me at times. Here’s something I learned today.

New Relic reports the number of instances per host; until today, I was reading this as the size of our mongrel pool.

It’s not, actually—it’s more like the ideal size of the mongrel pool. New Relic is actually counting individual instantiations of mongrels, which is to say the number of mongrels which have run. If you’ve got a pool of 8 mongrels (who could ask for more?), and 2 of them have restarted, then New Relic is going to report that you had “10 instances”.

It makes perfect sense in retrospect, but I didn’t realize this until Justin at New Relic pointed it out to me. They’re very responsive at their support site.

I haven’t had the opportunity to see how New Relic displays instance counts for Phusion Passenger deployments; if you have anything to add, please post in the comments!

"You don't have permission to access / on this server."

After spinning my wheels for a little while, I discovered it was because I had turned on FileVault (in Snow Leopard, but I believe it’ll happen the same way in Leopard).

The fix was simple:

chmod +a "www allow search" /Users/username

I hope this saves some Googler  a few minutes…

One problem you may have seen is during a deploy — when all the mongrels are restarted at once, haproxy ends up running around in circles, unable to find anyone to serve the latest request. In such a situation, you might get the dreaded 503 Error.

Here’s a cool workaround — have Capistrano reboot one mongrel at a time, so that haproxy always has something to hang its hat on:

namespace :mongrel do
  desc <<-DESC
  Rolling restart: 1 mongrel at a time.
  DESC
  task :rolling_restart do
    for i in 6000..6004 do
      ENV['HOSTS'] = ""
      find_servers(:roles => :app).each do |server|
        ENV['HOSTS'] = "#{server.host}:#{server.port}"
        puts "Restarting #{i} on #{server.host}:#{server.port}..."
        sudo "/usr/bin/monit restart mongrel_thepoint_#{i} ; true"
        puts "Sleeping 30 seconds before the next mongrel."
        sleep 30
      end
    end
  end
end

namespace :deploy do
  desc <<-DESC
    Deploy, with a rolling restart
  DESC
  task :rolling do
    update
    mongrel.rolling_restart
  end
end

There are two things you'd want to adjust here for your particular environment -- the number of mongrels in your cluster, and the number of seconds to wait between each restart request. (In this example, 5 and 30, respectively.)

There's a catch here -- this won't work if you have migrations to run, because you probably don't want stale mongrels hitting your newly-migrated database.

For now, we're just using this when there are no migrations, and using a conventional deploy:long when there are.

Can anyone suggest a way to adapt this approach in a way that could accommodate migrations?

Credit is due to Engine Yard, of course, for pointing us in the right direction. Thanks krutten!

Nice — this is going to be really easy to build into CMSs and best practices.

Some useful perspective on Web hosting.