humandoing software

Presently upgrading to Snow Leopard, and this kicked me in the teeth. The latest Vlad gem is 2.0, but the documentation is still, um, rough (that’s being generous).

$ script/console
Loading development environment (Rails 2.3.2)
default formats are encoded in ISO-8859-1
>> require 'vlad'
=> ["Vlad"]
>> Vlad.load :app => :passenger, :scm => :git
MissingSourceFile: no such file to load -- vlad/git

Anyways, it turns out that as of Vlad 2.0, the git portion of Vlad (probably others as well) are separated out into their own gems.

To fix:

sudo gem install vlad-git

Thanks to Richard Hart, through whom I found the solution.

There might be an easier way to do this without escaping the regex to grep, but for my small brain to remember later on – I wanted to grep the output of rake routes and search for two strings (logical OR):

rake routes | grep “\(give\|gift\)”

…then the DNS has propagated, and all is good with the world. Well, maybe not the whole ‘good with the world’ thing, but definitely the DNS has propagated, which means you’re viewing the site on it’s shiny new Linode  VPS running on mod_rails (AKA: Phusion Passenger).

Media Temple was a great host, but something changed over the past several months, and my Capistrano deployments were no longer working. It was less of a headache to get a better host than it was to figure out what actually went wrong, and it’s about time I started bumbling around in happy server deployment land again. It doesn’t hurt that mod_rails drastically reduces the Ibuprofen required in the deployment of Rails apps.

As an aside, it’s been so long since I’ve looked at Apache configs in any depth, that it took me a few minutes to figure out how to use the same VirtualHost config for both humandoing.net and www.humandoing.net. The answer (at least the one I used) was ServerAlias. I’m surprised that this didn’t appear anywhere in the mod_rails docs, but I guess it’s more of an Apache thing than a mod_rails thing.

See my config below:

<VirtualHost ip_goes_here:80>
  ServerName humandoing.net
  ServerAlias www.humandoing.net 
  DocumentRoot /var/www/apps/humandoing/current/public
</VirtualHost>

I’m doing deployment using Vlad instead of Capistrano, but man, the documentation sucks. I think that the problem is almost that it’s too easy to use, but that aside – the documentation still seems uber-lacking.

I’ve started to use Paperclip on a pet project I’m working on (a recommendation from Josh Owens), and the API is great, except for the fact that I couldn’t get it to work.

Files were being uploaded fine, but my thumbnail and other variations were not generating. The documentation says that the whiny_thumbnails option defaults to true, but my reality seems to dictate otherwise.

After I added that…

has_attached_file :receipt, 
                  :styles => { :medium => "600x600>", :thumb => "100x100>" }, 
                  :whiny_thumbnails => true

…I was at least getting an error:

/tmp/stream.13496.0 is not recognized by the 'identify' command.

At long last, I figured that the error message is totally inaccurate. What it really meant is “I’m looking for ‘identify’ in /usr/bin instead of /opt/local/bin even though /opt/local/bin is in your user path”.

For fixing:

cd /usr/bin
sudo ln -s  /opt/local/bin/convert convert
sudo ln -s  /opt/local/bin/identify identify

You’ll probably only have this problem if you installed ImageMagick via MacPorts (as I did). I probably could have fixed it by adding /opt/local/bin to the $PATH used by the web server user, but whatever. This worked.

A few days ago I ran a sudo gem update and unwittingly got a Capistrano 2.0.0 upgrade that broke my ability to deploy a bunch of existing Rails apps.

cap deploy
the task `deploy' does not exist

Hmm. That sucks. Nick to the rescue. Here’s the culprit:

gem list | egrep -v "^( |$)" 
...
...
capistrano (2.0.0, 1.4.1, 1.4.0)
...
...

Needed to uninstall all the Capistrano gem versions, and install the last working one (apparently 2.0.0 is not backwards compatible with 1.4.1 – which I didn’t know until today).

Here we go:

sudo gem uninstall capistrano -v 2.0.0
sudo gem uninstall capistrano -v 1.4.1
sudo gem uninstall capistrano -v 1.4.0

Say Yes when it asks you to uninstall the cap and capify binaries.

Now let’s install 1.4.1 again:

sudo gem install capistrano -v 1.4.1

Yay! It works! Time to fix those deploy scripts… when I have time.

I wrote this article for IBM developerWorks a while back, but never ended up blogging about it. So at any rate, here it is: Ruby on Rails and XML – for better or for worse.