Open Sourcery

Strangely enough this started as a request from Tyler Bird after reviewing my Capistrano presentation. He was interested in learning how I use Capistrano to update external site dependencies, like a local cached copy of the Google Analytics JavaScript files.

Originally all I did was have this task in my Capfile, and hooked it in after the “deploy:symlink” task:

desc "Update local urchin.js file"
task :update_urchin, :role => :web do
  run "wget -O #{current_path}/public/urchin.js http://www.google-analytics.com/urchin.js"
end

I then simply changed the configurations of the Google Analytics plugin to point to local urchin.js file.

Wow, thats simple enough, but what’s the catch?

Two things bothered me, support for the newer ga.js file, and not having access to Rails’ timestamping of assets for far future caching.

I pointed out to Tyler that I’m revisiting a lot of things we do with Capistrano and will post them here as I go along. The Analytics issue was one that bothered me constantly, so I set out to correct it.

I made my own fork of the Google Analytics plugin over at GitHub, and added support for having local copies of both the legacy and new Analytics JavaScript files, complete with Rails timestamping in the mix. I also added a rake task to help out with keeping the files up to date.

So the capistrano task I mentioned earlier would be changed to look like this now:

desc "Update local Analytics cached files"
task :update_analytics, :role => :web do
  run "cd #{current_path} && rake google_analytics:update RAILS_ENV=#{rails_env}"
end

Now you can neatly update your cached copies on each deployment.

Please visit the GitHub fork for more information on the plugin itself. I’ll set up a local project page on this blog tomorrow. The whole excercise was aimed at showing how to use Capistrano for updating external dependencies, although I have to admit it got a little lost in the noise as I carried on.

I’ve completed the zone templates in BIND DLZ on Rails, unless I missed something obvious. I’ll first complete all the missing specs before continuing with the standard zone management tools.

Changes over the last four days include:

• Prototip 2 test implementation, for DNS insight
• Getting the $TTL of zone templates to behave the same way as normal zones
• Fixed broken seed data
• Restructured views to be more RJS friendly, and easier to manipulate with RJS

Lessons learned so far:

• Flock interferes with prototype’s event listening, or maybe firebug in flock
• Getting tables and nested forms to be manipulated by JS is not a walk in the park
• UI design can actually show holes model design

Stay tuned for more changes coming this week, we have a hectic deadline to get this application production ready in a very short time.

I’m proud to announce the first push to Github of the BIND DLZ on Rails project. Its still pretty much a work in progress, but this is the first draft and opens the door for feedback by the community before the project has evolved too far.

Highlights so far

• Multiple roles (admins or domain owners)
• Zone & Record Templates
• Fairly good test coverage with RSpec
• Some documentation

For those who are curious, its built using:

• Rails 2.0.2
• Haml 2.0
• restful_authentication plugin (and acts_as_state_machine, role_requirement)
• will_paginate
• seed-fu
• rspec and rspec_on_rails

Installation

This might be a little sketchy, apologies in advance. I’ll work on a proper document as part of the source code.

Requirements

• Ruby 1.8.6
• Rubygems v 1.0 or later
• MySQL (other databases will work, although I haven’t tested them)
• Git

After installing the prerequisites, you need to create a database for the application to use. By default it expects “bind_dns_development” as the database name, you can however change config/database.yml to point to anywhere.

To get the database structure in place, with some seed data to play with, run these commands

$ rake db:schema:load
$ rake db:seed

The seed data will create a single user called “admin”, with the password “secret”.

To start a server, do this

$ ./script/server

This shows you the interface on port 3000.

Stay tuned

Please watch/fork the repo as appropriate, and file tickets on Lighthouse. As I’m typing this post I realize you much documentation is still lacking for non-Rails developers.

Thanks

Thanks to ISP in a Box for allowing us to build this project in company time and giving us the required infrastructure, support and human testing during the development, now and in the coming months.

Thanks to Carlos Brando and the team of translators for delivering the “Ruby on Rails 2.1 – What’s new?” ebook for FREE download.