ZenLinux Blog

Clifford Heath wrote a sarcastic yet poignant list of all-too-common screw-ups people can make when creating and deploying a Ruby on Rails project.

Sometimes you laugh because it’s funny. And sometimes you laugh because it’s true.

Within a couple of days of the release of Ruby on Rails v1.2.4, an important security fix was announced and rolled into yet another release (v1.2.5). This time, however, I will not be giving you a diff of changes between the versions. It turns out this is not necessary!

I just recently learned of a rake task you can use to upgrade your Rails application which applies version upgrade diffs for you. Now, to upgrade your Rails app, simply update your gem, update the RAILS_GEM_VERSION constant in your config/environment.rb file to the latest version number and run

rake rails:update

If this little tidbit wasn’t included in the official announcement of v1.2.5, I would never have known. Lesson learned: it’s worth spending some time looking at the output of rake -T to see what useful recipes you might have but be unaware of.

Don’t forget, tonight is the October NHRuby.org meeting. I’ll be giving a talk on deploying Rails applications using Vlad the Deployer.

The Ruby on Rails crew has stamped the final release of the v1.2 series of Rails. Go get it with your standard gem update command. They did a good job this time keeping changes within the gem itself. If you want your existing v1.2.3 app to use the same code base as a fresh v1.2.4 app, you only need to make the following changes:

config/boot.rb:

Remove the following code from the top of the file (sorry, the indenting is off in this post due to WordPress issues with the <code> tags):

unless defined?(RAILS_ROOT)
root_path = File.join(File.dirname(__FILE__), '..')

unless RUBY_PLATFORM =~ /(:?mswin|mingw)/
require 'pathname'
root_path = Pathname.new(root_path).cleanpath(true).to_s
end

RAILS_ROOT = root_path
end

And in its place add the following code snippet:

RAILS_ROOT = "#{File.dirname(__FILE__)}/.." unless defined?(RAILS_ROOT)

Finally, just update the RAILS_GEM_VERSION constant in your config/environment.rb to ‘1.2.4’ – that’s it.

I deployed a Ruby on Rails application using Vlad the Deployer for the first time today. Vlad is a much, much simpler alternative to Capistrano, which I’ve also used.

However, the process wasn’t as smooth as it could have been. I ran into the following issues that required some digging:

1. My subversion repository is accessed via an https web server, which happens to use a self-signed SSL certificate. The svn program prompts you to verify and save this certificate the first time you perform a checkout. Vlad hung on this prompt until I logged into my deployment server as the user and manually completed a checkout from the repository.

2. My subversion repository is also password-protected using HTTP authentication. Vlad apparently doesn’t know how to deal with this, as I couldn’t find any documented variables to set an svn username or password. However, I could override the subversion command, and add switches for the username and password in my deploy.rb file:

set :svn_cmd, "svn --username=\"USERNAME\" --password=\"PASSWORD\""

3. The vlad:start task runs apachectl to give apache a kick after starting up mongrel. That binary was not in my user’s path, so I had to edit the user’s .bashrc file to add /usr/sbin to the $PATH environment variable. Second, the apachectl command needs to be run with root privileges, and Vlad seems to have no knowledge of sudo. To fix this, I was going to override the vlad:start task, and started poking around the gem sources to see how the original task was defined. That’s when I noticed that it sets the variable :web_command internally, so I was instead able to override that with another addition to my deploy.rb file:

set :web_command, "sudo apachectl"

These weren’t a huge deal, but that’s only because I’ve dealt with Capistrano and have an idea of what variables should exist to configure these kinds of options. I’m liking Vlad a lot.

In fact, I’m pretty sure for October I’ll be doing a presentation for NHRuby.org on Vlad the Deployer.

Tonight’s NHRuby.org meeting in Portsmouth should be a blast. Nick Plante and I will be coding up a web application from scratch, as decided upon by members of our email list. As we develop the app, we will explain how and why we’re doing what we’re doing. We want this to be a collaborative group discussion, not just a presentation. So head on down to RMC Research tonight at 7pm and take part in the development of this web app! For more details, see our wiki site.

Tomorrow night at the Portsmouth Public Library I’ll be giving a presentation on how to deploy a ruby on rails application.

I’ll be discussing setup of a deployment environment based on Apache 2.2, mod_proxy_balancer, Mongrel, and MySQL. Then I’ll be giving an introduction to Capistrano, a wonderful ruby tool for automating the deployment of your rails application from source code repository to production server(s). Plus, there will be free book giveaways!

For more details and directions, check out the NHRuby wiki.

Prepare for an electrifying event this coming Tuesday, as the NHRuby.org user group will be holding a series of Lightning Talks at the Portsmouth Public Library. I’ll be giving a demo of ProgpressPuppy, a Rails-based successor to my previous Thought2Action task manager. ProgressPuppy is still a scrappy side project that I haven’t done much on, but that makes it a perfect example to demonstrate how to do various things in Ruby on Rails.

For more details, see the NHRuby.org wiki.

In the book Agile Web Development with Rails, it is recommended that you move your HTTP session data from temp files (the default) into your database for speed and scalability. One problem this can create if you’re stuffing lots of data into your sessions is that database fields are of a limited size. MySQL uses text as the default type for the data column.

I ran into some limitations regarding this earlier this week, and the surefire symptom of it is the error “marshal data too short” in your logs. Fortunately, a quick Google search resulted in a few clear answers. I even found a migration example to change the column type from text to mediumtext (you can also use longtext if you’re really paranoid).