tail -f development.log

Cerberus 0.4.0 was officially released last night on RubyForge.

The new major features include the Twitter publisher support that I added and the Git SCM support added by Rob Kaufman. Several other minor updates and bug fixes were also included.

Cerberus is a lightweight Continuous Integration package written in Ruby. The package hadn’t been under active maintenance lately, but I hope to be able to get some new work done on the project now that I am on the development team.

Recently, I set up Cerberus for continuous integration for our internal project at Park Assist. I chose Cerberus over other CI servers like CruiseControl.rb due to its lightweight install and setup and the fact that it doesn’t need to run constantly in the background and consumes fewer resources.

Unfortunately, Cerberus doesn’t seem to still be under active maintenance as the most recently commit on the main RubyForge SVN repository was back in July of 2007. Since Cerberus was written under the MIT License, I made a copy of the repository and posted it to GitHub.

At the moment, Cerberus appeared to be missing two major features as far as I was concerned. First, no git support for an SCM and second, no Twitter support for posting build success and failure notifications.

A quick search of Github revealed that Rob Kaufman had already added git support so I went ahead and added Twitter support to Cerberus.

I plan on pulling the git support into my git repository and submitting a patch to the official Cerberus project. Hopefully the original developers are still around and willing to update the repository. If not, feel free to clone or fork my copy of Cerberus for the new features.

Most OS X users are using or have heard about Growl, the OS X notification system. I use a growl tool called growlnotify from several different scripts to give me notification alerts during script execution. In particular, I spend quite a bit of time doing Ruby coding and using autotest.

The problem is that growlnotify doesn’t play nicely with Leopard and only actually gives notifications about 15% of the time (my rough estimation). This isn’t a show stopper for me with autotest, but it has been quite an annoyance, so I finally set out today to try and find a solution.

Fortunately, after only about 5 minutes I came across a blog post by Hans Fugal with a solution.

What I did was create a new shell script that I simply called growl with the following contents:

#!/bin/bash
wrappee=/usr/local/bin/growlnotify
exec $wrappee -w "$@" &

I then moved growl to my bin directory:

mv growl /usr/local/bin

and now just use the growl command from my scripts instead of calling growlnotify directly.

I’ve updated and released version 0.8 of my the BBRuby library today. Go ahead and grab the latest code from GitHub.

To download the newest gem just do the usual gem install:

sudo gem install cpjolicoeur-bb-ruby --source=http://gems.github.com

For those of you who want to use the library as a rails plugin, install like normal:

./script/plugin install git://github.com/cpjolicoeur/bb-ruby.git

The new version includes updated (and corrected) README docs as well as a better test suite. Also, the :enable and :disable parameters should now be fully functional. Sorry for the issues some of you reported with the prior version.

Recently I began looking into using Phusion Passenger for running all my Rails apps instead of the normal nginx+mongrel stack that I normally use. Since its release, Passenger has been getting quite a bit of publicity and hype and I figured it was time I started looking into it on my own as well.

Dreamhost was the first shared hosting provider to offer Passenger on all their shared hosting plans so that was a natural place for me to start. I planned on using my Dreamhost box as a staging server for a few small apps as I started to get a feel for Passenger.

The major problem I ran into was trying to set RAILS_ENV to “staging” so that my apps would run from the staging environment. The way Passenger gets configured, the RAILS_ENV setting is configured in the Apache virtual host file, which I don’t have access to on Dreamhost (or most other shared hosting providers).

You can set the RAILS_ENV constant in your config/environment.rb file to ’staging’ and Passenger will pick the setting up; but, of course, this won’t work because then I would be required to constantly manage and change my environment.rb file depending on whether or not I was working locally in ‘development’ or on ‘production.’

What I decided to do was just add a custom task to my capistrano deployment recipe file (config/deploy.rb) and manually insert the RAILS_ENV variable into the top of my config/environment.rb file after deploy.

namespace :deploy do
  desc "set ENV['RAILS_ENV'] for mod_rails (phusion passenger)"
  task :set_rails_env do
    tmp = "#{current_release}/tmp/environment.rb"
    final = "#{current_release}/config/environment.rb"
    run <<-CMD
      echo 'RAILS_ENV = "#{rails_env}"' > #{tmp};
      cat #{final} >> #{tmp} && mv #{tmp} #{final};
    CMD
  end
end

after "deploy:finalize_update", "deploy:set_rails_env"

Now based on my cap deployment command, the RAILS_ENV will be set to ’staging’ or ‘production’ automatically. Really, staging is all that I needed since production is the natural environment on my production server already.

Hope this helps and saves someone else an hour of searching.