I really like using Jeweler to create and manage gems, but its default behavior is to publish your gem to rubygems.org whenever you run rake release. This is great for generally useful libraries that you want to open-source, but not as great when you want to use gems as shared libraries for internal use only (whether because the code contains business secrets or just because it’s not something that would be useful to the community at large.)

After a bit of poking around, I figured out how to use Jeweler to manage your versioning, gemspec and git tagging without pushing the result to rubygems.org when running the release task. It turns out to be both obvious and trivial. Just add the following line to the end of your gem project’s Rakefile:

1

Rake::Task[:release].prerequisites.delete('gemcutter:release')

UPDATE (2012-01-22): I realized this morning that the credit I gave to Sam Livingston-Gray below may not have adequately shown how instrumental he was in getting this project off the ground; especially since much of his work was done in the private repository from which this was extracted. So, thanks, Sam. This might not have gone anywhere if you hadn’t worked to put the idea in practice in our application and helped everyone on our team learn how to use the approach. I made a few minor changes below to reflect this a bit better.

We’ve been using Cucumber for acceptance testing at Renewable Funding since back when it was still part of the RSpec project (indeed, since before we were even Renewable Funding). While we’ve always liked the ability to have plain-language feature documentation that we could automatically test against, after years of adding to and maintaining a fairly large set of Cucumber scenarios, the cost of that maintenance was starting to really slow us down. The test suite began to grow fragile, and it seemed like every time one of our UX designers changed anything about the application’s interface, the development team would spend a bunch of time just babysitting Cucumber tests to get them passing again.

Last year, as I was reading Jez Humble’s excellent Continuous Delivery book, I was inspired when I came across the section titled “The Application Driver Layer” (p. 198). This section describes an approach to acceptance testing where the specification and the test implementation are isolated from the details of the application’s user interface by inserting a layer between the two that uses good old OOP to abstract the user interface components. Martin Fowler describes it as the Window Driver pattern on his website.

I started a proof-of-concept implementation of this pattern last summer, then my coworker, Sam Livingston-Gray and I started pulling it into a new project at work. After Sam and the rest of the Renewable Funding team helped improve on my original attempt while putting it to use for the last six or so months, we extracted a library to make it easier for other Ruby developers to implement this pattern in their testing. I’m happy to introduce Kookaburra to the world.

I recently started playing Dungeons & Dragons again (after not playing since I was in high school). I’m DM-ing a game for my son, Jacob, and a few other folks. We’re playing 4th Edition, which relies heavily on a battle grid and character tokens to represent combat encounters. In order to save money and hassle, I wanted an alternative to searching for and buying the correct miniatures for each encounter.

I wish this photo was a bit sharper, but it still sums up my feeling pretty well about… well… a lot of things. :-)

Sometimes it seems the only time I post to my website anymore is when I decide to switch out the software that’s used to publish years-old articles. :-(

At any rate, I’m switching over to Octopress to run this site, because a) it’s the new awesome, and b) maybe I’ll spend more time writing articles if I’m not trying to tweak my home-grown blogging engine while I do it. I chose Octopress because it has the parts I like about jekyll (I get to write my posts in vim and eaisly manage the content with git), but it has more of the rough edges smoothed out (again, so I can spend my time writing articles instead of working on the engine.)

As part of this, I’m also moving the site from Heroku to Github Pages. Nothing at all wrong with Heroku; it’s just one fewer thing for me to deal with.

I’m now going to port over old articles (a much easier task than last time, since the last version of this site was also using markdown-formatted text files.) The comment system was already on Disqus before, so hopefully I can figure out how to get the old comments associated with the new URLs.

I banged my head against this one while setting up our CI build for a new project at work and just now figured it out. I added an example integration spec that just visits the default Rails homepage, clicks the “About your application’s environment” link, and verifies the Rails version. This link uses an AJAX action to load the environment details, so I marked it as a JavaScript test, which would cause it to use Capybara’s Selenium driver.

The test passed fine on my machine (with Firefox 4 installed), but it failed consistently on CI, which has Firefox 3.5. It kept failing with the exception Capybara::TimeoutError: failed to resynchronize, AJAX request timed out. I didn’t dig enough into the guts of Selenium/Firefox to find out exactly what is going on (and a Google search for that error message turned up nothing that really explained it) but I did at least find a workable fix. Just add the following line to spec/support/capybara.rb:

1

Capybara::Selenium::Driver::DEFAULT_OPTIONS[:resynchronize] = false

The Renewable Funding technology team is moving into some new office space in a few months, and now that we’ll have our own space, I’d like to start up a variation on an apprenticeship program at work. I’m still in the early stages of designing this, and I want to gather some input from the community before deciding how we might run the program.

After growing the ProjectDX team from three to eight software developers, our release process was a complete pain, and it typically took two to three hours to get a good build on the production branch (and even then some insidious issues would sneak through). By making a few changes to our development and acceptance process, we were able to turn it into a five-minute, low-stress job.

And in other exciting news, I found a bunch of my old blog posts archived in Google Reader that go back to before I effed up and lost the repository that this site used to be stored on. I’m going to add many of them back to the archives. While I will go through and fix the egregious encoding errors, I’m probably not going to restore old hyperlinks that are getting lost in the cut-n-paste.

Yesterday, Elizabeth Hendrickson posted her Agile Acid Test in which she asks three questions to determine whether or not a team is truly “agile”. There is also the Agile Manifesto which describes the values that an agile team should adhere to. While there is nothing that I disagree with in either Elizabeth’s post or the Agile Manifesto, there are two simpler questions you can ask that get to the heart of whether or not your team is agile: Can you react immediately and without panic when external constraints on your project are changed, and does your team regularly and frequently review its processes to ensure the answer to the previous question is always “yes”?