John Wilger

Just a bunch of antiterminologicaldisintactitudinarianism

Best Chili Recipe Ever

| Comments

I’ve had a few requests to share this chili recipe from time to time; most likely because everyone who has ever had it subsequently decides it is the best chili they have ever had. Giving credit where it’s due, this is based on Alton Brown’s chili recipe from his book, I’m Just Here for the Food, but modified to my own tastes. The sauce is rich and spicy, although it’s a nice, even keel that doesn’t get hotter and hotter with each bite.

A word of warning: I’ve gotten to the point where I throw this recipe together by feel and don’t necessarily remember the exact measurements for some of this. Where I’m unsure, I’ve noted the ingredient as “(approx)”. You may want to adjust them to taste.

Kookaburra 0.24.0 Released; Exorcised ActiveSupport

| Comments

I just released version 0.24.0 of Kookaburra to Rubygems.org. While there were no changes to Kookaburra’s API with this release, it is a minor release rather than a patch release, because I removed ActiveSupport from Kookaburra’s dependencies. Previously, Kookaburra depended on ActiveSupport >= 3.0, and this prevented it from working smoothly with Rails 2.x applications (at least in the same Bundler bundle.) Since Kookaburra only used a small fraction of ActiveSupport, it seemed easiest just to break the dependency, so that your application can use whatever version of ActiveSupport it needs.

Because of the fact that ActiveSupport makes a number of modifications to core Ruby classes, if your application does not otherwise explicitly require ActiveSupport, some of these core classes may now behave differently. Specifically, Hash and String core extensions were being used, as well as ActiveSupport::CoreExt::Module::Delegation.

Also, where Kookaburra::JsonApiDriver used ActiveSupport::JSON for encoding and decoding of JSON data, it now uses ::JSON as provided by either the json or the json_pure gems. The tests on Kookaburra itself pass just by swapping out ActiveSupport JSON library for the new one, but these tests do not comprehensively test JSON usage, and there may be differences that impact your application.

Kookaburra declares its dependency on the json_pure gem (a pure-ruby version) in order to ensure that it works cross-platform. However, both json and json_pure are written in such a way that, when you require 'json', it will detect if both libraries are installed and prefer the natively compiled json gem’s version of the library.

Tmux and the OSX Clipboard

| Comments

I started using tmux recently after a) I was informed that GNU screen is basically an outdated POS, and b) an excellent book on the subject was published. I’m glad to have made the switch, as tmux is a wonderful improvement over screen. However, on OSX, I found that the pbcopy and pbpaste commands (among other things) would no longer work from within a tmux session.

After a bit of searching, I found this post that explains how to make things right again.

TL;DR:

run this
1
brew install reattach-to-user-namespace
add this to ~/.tmux.conf
1
2
# Reattach to user namespace so that clipboard integration with OSX works again
set-option -g default-command "reattach-to-user-namespace -l zsh"

Obviously, replace zsh above with whatever you use for your shell.

Kookaburra Rewrite for 0.15.1

| Comments

After getting some good feedback on Kookaburra since the original release announcement as well as using it in a few more projects, Sam and I decided to treat all of the versions prior to 0.15.0 as a spike and rewrite the framework from the ground up. Although we certainly learned a lot about the approach with the pre-0.15 versions, the problems with continuing to grow Kookaburra from that seed became apparent as we tried to use it in more applications.

Because the original code was extracted from another project, the Kookaburra framework itself was not well tested. It had been indirectly tested due to its position within that other project’s tests, but as a seperate library it lacked tests that would help bot document the project and ensure newcomers can work on it with a good safety net. Additionally, there were a number of design decisions made in the earlier versions of Kookaburra that were…questionable. Not only would these decisions probably have been made differently if the development of the framework itself had been driven with unit tests, these decisions in many cases made it difficult to go back and add tests after the fact.

Starting with 0.15.1, which I just released a few moments ago, Kookaburra has been rewritten using a proper TDD approach. In some ways, 0.15.1 is possibly less functional than its 0.14.x cousins, but it is almost certainly easier to understand and contribute to the project from this point on. Please have a look at the new codebase, try it out in your projects, and send me a pull request with updates to the library. Also, if you have any problems getting it running, please don’t hesitate to let me know.

Using Jeweler for Private Gems

| Comments

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:

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

Acceptance and Integration Testing With Kookaburra

| Comments

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.

RPG Character Tokens

| Comments

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.

OMFG

| Comments

An image of a man covering his face with his hand and wearing a shirt with the acronym OMFG on it.

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

Switched to Octopress

| Comments

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.

Capybara, Selenium and Firefox 3.5

| Comments

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