Sometimes you inherit a non Ruby based web app written in PHP, Perl, Java, C#, or Python and you want to create an automated functional/acceptance test suite to minimize the amount of manual QA you need to do. Selenium is a great tool for doing just that and at Common Sense Media I created the Selenium Continuous Integration Runner to make it easy to run Selenese based tests from your Continuous Integration Server such as Hudson, Cruise Control, or Teamcity. That said, Selenese based tests leave something to be desired in terms of readability and maintainability.

The Ruby camp is often at the forefront of great testing frameworks with Aslak Hellesøy often leading the charge with innovations like RSpec and Cucumber. I’d read and played around with Cucumber on Rails based apps and was loving the concept of english language specs that are actually executable as well. But when my friend and former colleague Chris Kimm mentioned that the testing group at his company was using it to test their Java application, I started to get excited as that was the problem I was about to try and tackle at VolunteerMatch.

However, getting the project structure in place required a little help from the Cucumber mailing list and in the hopes of saving others the time, I’ve published the Standalone Cucumber Test Suite to Github. It’s simply a Cucumber project designed to test a non Ruby web application with a sample search.feature that uses Google search as the basis for the test. It uses Capybara with the Selenium Webdriver on the backend but you can also switch it to use Culerity or Webrat if you don’t want it actually firing up a real browser to run the tests. Fork it or download it to start testing your existing website with Cucumber!

One of the jobs of a good programmer is to make their code readable and in this case by naming the variable sum it’s obvious what’s going on to the right so if you can simplify the anonymous function or use syntactic sugar to reduce the amount of code there’s a good chance you can improve the readability as follows:

Then even if the programmer reading the code is coming from another language and doesn’t know :+ or _+_ you’ll still have improved readability because they certainly understand how a sum is computed and can move past the line of code instead of having to read 3-4 lines of a for loop for something as simple as a summing operation. I love the balance of being very concise with the simple stuff so that I can be more verbose with the complex stuff, whereas in Java even the simple stuff is often extremely verbose.

There is of course the extreme of making your code too concise. Look no further than write-only languages like Perl to see where too much conciseness and obfuscation can lead to unmaintainable code.

This example is only trivial and somewhat contrived but I find that newer languages like Ruby and Scala give you significantly better tools to elegantly dial up or down the conciseness than Java or C# resulting in less code + more readable code = easily maintainable code.

As an example, I used just about every conciseness trick in the book I knew of when composing my submission for the 3rd Ruby Challenge’s Shortest Path Algorithm and I only discarded the ones that I thought obfuscated the intent. I like to think the reason my submission won was precisely because it was concise while still being readable. Writing that same algorithm with the same level of readability in Scala would be easy but in Java it would have tripled the lines of code hurting readability somewhat.

Update 7/8/2009: With the latest batch of contributed patches standalone migrations now works just like Rails migrations
Update 12/26/2008: I switched standalone migrations to use a Rakefile instead of a Ruby script.

In my work managing websites I end up working in Ruby, Java, and PHP. In everything but Rails managing the schema requires rolling your own solution. As a result I’ve started using Rails migrations in non-Rails projects to manage the schema. It’s not much code but I figured others might benefit from it so I created a little Github project called standalone migrations.

It’s based on Lincoln Stoll’s blog post titled Stand-alone ActiveRecord migrations and David Welton’s blog post titled Using Migrations Outside of Rails.

Assuming you have Ruby and Gem installed on your machine, here’s how to use it:

gem install -y activerecord rake mysql
wget http://github.com/thuss/standalone-migrations/zipball/master (or fetch it using git)
unzip it, and mv to something like my_non_rails_project/db
cd my_non_rails_project/db/ (or wherever you put it)
cp config/database_sample.yml config/database.yml
vi config/database.yml
./new_migration some_user_story
vi migrations/*_some_user_story.rb
rake db:migrate (this applies your newly created migration)

• acts_as_sluggable
• acts_as_urlnameable
• acts_as_slugable
• acts_as_friendly_param
• permalink_fu

Obie’s recent post on search engine friendly URL’s in Ruby on Rails 1.2 and greater couldn’t have been more timely. I was about to tackle search engine friendly URL’s on my little local san francisco bay area boating classifieds site and after reading his blog post, 15 minutes later it was done. Here’s the old URL structure:

http://gearandboats.com/forums/1/topics/51

and the new (longer for humans but much better for SEO):

http://gearandboats.com/forums/1-boats/topics/51-fantasia-35-mark-ii-cruiser

The most important thing is that the URL’s are backwards compatible because everything after the ID is ignored which is key for pages that are already in the search engines!

To achieve this I combined Obie’s approach with Ricks Permalink_fu plugin (for converting text to permalinks):

script/plugin install http://svn.techno-weenie.net/projects/plugins/permalink_fu

Then in my topic.rb model object I do:

and I double checked to make sure that the views always call link_to passing the model object rather than the ID (so that the to_param method has access to the id and the title). Fortunately beast.caboo.se (which is what I based my site on) make heavy use of named routes:

After that I was pretty much done but I had some really long URL’s so I truncated the title to the first 5 words by changing

to

.

Per Thomas Aylott’s suggestion on my previous post Keeping Rails Running at Dreamhost Part 2 I’ve decided to release my Dreamhost signal handling code as a Rails plugin. I’m using it on a Rails 1.2.1 site and a Rails 1.1.6 site.

Here’s the deal:

1. Get your Rails site running on Dreamhost (the wiki should you get you there).
2. Once you’ve got it working, if you experience occasional 500 errors try my signal handling plugin. I still had 500 errors with the frao_handler approach described on the wiki, but if my plugin doesn’t work for you it can’t hurt to try it.

Here’s how to install the plugin:

script/plugin install http://gabrito.com/svn/plugins/dreamhost

With the plugin installed, the dispatch.fcgi will defer exiting when Dreamhost sends your dispatch.fcgi process a TERM signal if it is in the middle of handling a request, otherwise it behaves normally. This has reduced the 500 error rate on my two rails based sites to zero, your mileage may vary though. If you still have problems please don’t comment here and say it doesn’t work, instead figure out the problem and email a patch to thuss [at] gabrito [o] com!

The subversion repo for the plugin is at http://gabrito.com/svn/plugins/dreamhost. If you have other Dreamhost related fixes that make sense for this plugin send them to me and I’ll incorporate them.

My first attempt to keep my Ruby on Rails sites running at Dreamhost involved modifying dispatch.fcgi to implement the frao_handler approach as described on the wiki. This left me with a 3% 500 error rate. Ughh!

My second attempt involved gracefully restarting dispatch.fcgi’s every hour or two to avoid the wrath of the Dreamhost process monitor. This reduced the 500 error rate down to 0.2% which was still too high!

I’ve finally gotten my 500 error rate down to 0 by making some minor changes to the signal handling code of dispatch.fcgi. If the dispatch.fcgi process is in the midst of handling a request I defer letting it be killed until the request is complete. I did this by installing a custom TERM signal handler that protects the dispatch.fcgi process while a request is being processed. This solution works for my Rails 1.1 and Rails 1.2 (previously Edge) based sites. Here’s my complete dispatch.fcgi:

#!/usr/bin/ruby1.8

require File.dirname(__FILE__) + "/../config/environment"
require 'fcgi_handler'

class RailsFCGIHandler
 private
   def busy_exit_handler(signal)
     dispatcher_log :info, "busy: asked to terminate during request signal #{signal}, deferring!"
     @when_ready = :exit
   end

   # Dreamhost sends the term signal and if we're handling a request defer it
   def term_process_request(cgi)
     install_signal_handler('TERM',method(:busy_exit_handler).to_proc)
     Dispatcher.dispatch(cgi)
   rescue Exception => e  # errors from CGI dispatch
     raise if SignalException === e
     dispatcher_error(e)
   ensure
     install_signal_handler('TERM', method(:exit_now_handler).to_proc)
   end
   alias_method :process_request, :term_process_request
end

RailsFCGIHandler.process!

piston switch http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-1 vendor/rails

For starters, if you’re still using svn:externals to manage your vendor/rails directory it’s time to switch to using Piston. svn:externals is so Q4!

However, if you’re already running Piston, now that Rails 1.2 is out you may want to switch from running Edge (the trunk or head branch) to the stable 1.2 release for your production applications. Here’s how to make the switch with Subversion and Piston:

cd your_app
# Remove the old Piston checkout
svn delete vendor/rails
svn commit -m "Deleted edge" vendor/rails
svn update
# Checkout 1.2.1 (or newer)
piston import http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-1 vendor/rails
svn commit -m "Rails 1.2.1" vendor/rails

It’s exciting to see the convergence of my two favorite languages coming along!

Update 1/24/07: I’ve finally solved my Dreamhost 500 error problems with a different solution described in Keeping Rails running at Dreamhost part 2

This weekend I moved two of my newer Ruby on Rails based sites (http://windandtides.com and http://gearandboats.com) over to Dreamhost. You simply can’t beat their prices for hosting a small site (if you prepay for 2 years and use coupon code GABRITO to save $50 the total is $140.80) and I’ve found their customer service to be pretty responsive too.

I followed their Wiki based Ruby on Rails instructions and had the sites up and running with Capistrano in no time. However, I soon discovered that their process monitor likes to kill off long running processes (effectively taking my sites offline without warning) and the only indication of what’s wrong is this error in the apache error.log:

FastCGI: comm with (dynamic) server "/path/to/dispatch.fcgi" aborted: (first read)
  idle timeout (60 sec), referer: http://gearandboats.com
FastCGI: incomplete headers (0 bytes) received from server "/path/to/dispatch.fcgi",
  referer: http://gearandboats.com

To fix this I wrote a short ruby script fcgimaint.rb that I run once per hour via cron to restart my dispatch.fcgi processes (first with a USR1 and then a kill -9 if the USR1 didn’t work). This has the added benefit of cleaning up accumulated FastCGI processes and starting with a fresh memory footprint in case of a memory leak:

Crontab entry: 33 * * * * /home/myuser/bin/fcgimaint.rb

#!/usr/bin/ruby
def dispatchers()
  ps = `ps ux`.grep(/dispatch\.fcgi/)
  ps.map {|p| {'pid' => p.split[1], 'start' => p.split[8]}}
end
dispatchers.each { |d| `kill -USR1 #{d['pid']}` }
sleep 30
# Kill dispatchers that didn't restart nicely
dispatchers.each do |d|
  if (Time.now.hour != d['start'][0..1])
    `kill -KILL #{d['pid']}`
  end
end

One other tool I found useful (especially during this process when the sites were going down periodically) was using Geoffrey Grosenbach’s modifications to dwatch to monitor my sites and email my cell phone if there was a problem.

Caveat: if your site does more than 10,000 page views per day then a shared hosting plan is not the answer, you should be looking at dedicated or VPS hosting.