I decided I would make an attempt to deploy CruiseControl.rb to one of the hosts that I have — and do so with Capistrano. For the most part, it was pretty painless, but I did run into a gotcha or two.

First, the host I deployed to uses the Apache / Lighttpd (fastcgi) style of deployment. Unfortunately, Lighttpd just would never start up for me! After way too long, I finally figured out that I had DOS line breaks in my file that I could not see. So I zapped them with dos2unix and all was well. Unfortunately, this ate up a lot of my time as I’m not very skilled at debugging fastcgi issues.

CruiseControl.rb is a Rails app, but not your typical Rails app. It uses no Rails app, but rather stores your project information in a projects directory underneath the app root. Further, its more than just a Rails app, it utilizes additional processes as project builders.

To deploy with Capistrano, you have to preserve the projects directory so that it will persist across your releases. That’s pretty easy to do with symlinks, so that’s a piece of cake. You can use the after_update_code callback to do this.

There are two other use cases that I could see that I would need. Adding a project and starting a builder for that project. To enable those, I added Capistrano tasks for each. Both tasks rely on environment variables and both tasks could probably benefit from a bit more error-checking, but they are good enough for me.

So to start a project, I use:

NAME=GeoKit URL=svn://rubyforge.org/var/svn/geokit cap add_project

to start its builder, I use:

NAME=GeoKit cap start_builder

I added my custom tasks under config/recipes/cruisecontrol.rb and required this in deploy.rb. The custom tasks code is below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Capistrano.configuration(:must_exist).load do

  desc "Update symlink for projects directory."
  task :after_update_code do
    run <<-CMD
      rm -rf #{release_path}/projects &&
      ln -nfs #{shared_path}/projects #{release_path}/projects
    CMD
  end

  desc "Add a project to cruise control."
  task :add_project do
    unless ENV['NAME'] && ENV['URL'] 
      raise ArgumentError, "***** You must specify the NAME and URL parameters to add a project. *****" 
    end   
    run "#{current_release}/cruise add #{ENV['NAME']} --url #{ENV['URL']}"
  end
  
  desc "Start a builder for a project."
  task :start_builder do
    raise ArgumentError, "***** You must specify the NAME of the project to build. *****" unless ENV['NAME'] 
    run "#{current_release}/cruise build #{ENV['NAME']} &"   
  end
end

And with that, any of my projects can now be monitored with CruiseControl.rb.

A few caveats.

• I had to physically edit the cruise_config.rb file (on the server) for the project to include my email address and polling interval. No big deal, its a one-time thing.
• If your code is proprietary, you may want to protect the site with
  basic authentication to keep unwanted eyes from seeing your project assets.
• Since your project data is on your server’s file system, you may want to consider a backup strategy if you value your build history.

Suggestions for ThoughtWorks:

• Consider including Capistrano tasks to make it easier — mine are admittedly rough, I’m sure.
• Consider adding some element of authorization by project. For example, I have public plugins, but I also have proprietary code that I do not wish to share. Obviously, its easy enough to deploy a second site, but that’s mildly inconvenient.

I hope this is helpful to continuous integration fans out there trying to get set up!

James wrote that it would be nice to be able to reset the default_units value to enable localization.  Well, actually you can.  :default_units is modifiable through a class accessor.  Also, you can pass an optional parameter in your finders called :units which enables you to override whatever default value you’ve set.

While we’re talking about defaults, I applied a patch submitted by Hoan Ton-That which enables you to specify your preferences for units and for the formula from within the environment files.  So these preferences would appear right along side your API keys for GeoKit.  Its a small feature, but you may appreciate it.  Thanks Hoan!

Otherwise, James mentioned that :include support is lacking with GeoKit.  That’s not entirely true.  I added a passing test case which successfully pulls columns from a belongs_to relationship.  I suspect that the has_many relationships are the problem.  But if your case is covered by the belongs_to relationship, then you are covered.

There is a less-used method called distance_sql which enables you to just get the distance calculation in SQL form.  You would use this if you ever found that GeoKit could not support your exact query requirements.  Its less elegant for sure, but saves you the trouble of having to code the distance calculation.

UK geocoding is still in the roadmap, but both Andre and I have a few other projects and side endeavors going on.

My adaptations are:

• Modify user authentication to use our LDAP user repository — so users can just use their existing credentials
• Using YUI Reset, Fonts, and Grids throughout
• Modifying the markup to be slightly more semantic
• Adding Digg-style pagination
• Applying design inspiration from Odeo, SimpleBits, and Cork’d as well as others.

I’m not done yet, but its starting to look pretty decent. Here’s a peek:

1
2
3
4
5
6
7

# Geocode from and to, then calculate the distance
# between them.
dist = Store.distance_between("Irving, TX", 
                              "San Francisco, CA")

# Geocode the to, then calculate the distance to it.
dist = irving.distance_to("San Francisco, CA")

Andre has also added further flexibility to the rigin to include setting it to an array of lat / lng values. Usage looks like:

1
2
3

# Presumably some previous geocoding and then this:
stores = Store.find(:all,   rigin => [37.792,-122.393], 
                    :conditions => 'distance < 10') 

Keep the feedback coming!

The message it gives is that the DOM Inspector is not installed…except that it was in my case.  So that was pretty perplexing.  However, Firebug itself points you to an FAQ which in turn points you to a forum entry.  The grammar isn’t great, but the basic steps are:

1. Find your Mozilla directory within your application data directory and make a backup of it.
2. Go to the Control Panel and remove Firefox from your programs list.
3. Go to the directory where Firefox used to be fully installed and remove it (the uninstall doesn’t do it for you).
4. Download and install Firefox, but in a different directory than the original installation.
5. Restore your application data if it has been removed.

Some of these steps make no sense, but I followed them blindly and it worked.  I’m pretty sure that the process can be streamlined, but since I’m up and running I’ll leave that to someone else.  Since this was hard to find and harder to understand once found, I thought I would write it up for anyone who might need to do the same thing.

While not the most seamless process, I now run my code examples through my CodeRay HTML Generator and then paste them into my WordPress posts. Since I use the same stylesheets for both apps, the styles are consistent.

If you have a similar scenario, feel free to use the generator yourself. I don’t keep any snippets…but won’t I see them on your blog anyway?

First, the finders will now all accept optional :units and :formula keys to enable you to override the units and formula used by the model by default. This makes it possible to serve distance queries in miles or kms and even to modify the formula used in the query. Overriding the formula might be important if you know the proximity is close and you don’t care about precise accuracy. It might also be helpful in the event that your dataset grows beyond that which would perform using the more taxing Haversine (:sphere) formula.

The second feature is a bit more subtle and edge case-like. If you steer away from our defaults and customize the lat / lng attributes, then the rigin was previously unable to handle taking an instance of those rows that you seek. I made a change to enable it to detect that situation. So now, you can do this. I did find one issue and that’s with the distance_from method which counts on lat / lng. Hopefully, I can add the same introspection and tidy that up as well. This will enable full customization for lat / lng attributes. Of course, you can write your own accessors to get around this, but still…

If you have any additional feedback, feel free to send Andre or I an email.

UPDATE: The update is complete, you can now compare the distance of Mappable instances which customize their lat / lng attributes when running as acts_as_mappable. If you don’t understand what this means, you probably don’t need the feature, so don’t sweat it.

The Rdoc is the best place to go to learn more. We’ve set it up on RubyForge. But just to whet your appetite, just imagine not having to code any nasty trigonometry into your SQL to include distance columns or conditions. Or imagine having ready access to Google, Yahoo, Geocoder.us, and Geocoder.ca geocoders separately or in a failover configuration. If that’s not enough, imagine integrating geocoders into your finders! For instance:

1
2
3

stores = Store.find(:all, 
                      rigin => "100 Spear St, San Francisco, CA", 
                    :conditions => "distance < 10")

where the origin value serves as the anchor for the distance calculation and gets geocoded on the fly.

All this is done through a declaration like this:

1
2
3
4
5
6

class Store < ActiveRecord::Base
  belongs_to :company
  
  # Enables distance calculations and sweet, clean distance queries.
  acts_as_mappable
end

The goal of the plug-in is to clean up client code for location-based applications. I think we’ve succeeded. Enjoy everyone!

With this being my first Rails plugin, some disclaimers are in order. First, its very v0.1 and experimental. While its written to potentially support multiple databases, it not only supports MySQL. Also, as primarily a Java developer, I find it sometimes challenging to write idiomatic Ruby. If you review the source for the plugin, you may recognize opportunities for improvement. If you’d like to make some suggestions, I’m very open to receiving them. Also, any patches or bug reports would be appreciated too.

The README file contains a pretty complete guide to the plugins capabilities — it basically provides distance calculation and query services. The test suite is also fairly extensive, so you can review it to get a good idea of what you can do. In typical Rails fashion, mixing this in would like something like this:

1
2
3
4
5
6

class Location < ActiveRecord::Base
  belongs_to :company
  
  # Pretty SQL distance queries and distance calculations.
  acts_as_mappable
end

And then there’s a host of finders that become available. If this whets your appetite, give it a look.

At present, the plugin is available here, but I’ll make it available in a public SVN repository sometime soon.