I just pitched the yeast into this year’s batch of homebrew apple cider; hoping it turns out as tasty as the batch we brewed in 2010 (didn’t do one in 2011). The original gravity is at 1.063, so its potential is right around 8% ABV.

Update 9/10/2012: I just transferred the cider into secondary today, after just over a week in primary. Primary fermentation went fairly quickly, and the cider now has a hydrometer reading of 1.004, putting it at about 7.74% ABV. I plan to let it sit in secondary for about 4 weeks. A quick taste test proves the cider to be deliciously tart and dry.

Update 10/6/2012: Today was bottling day! The final gravity was all the way down to 1.000 for an ABV of 8.27%. Now for some bottle conditioning for a few weeks, and this stuff should really shine. Yield was 21 750ml bottles.

Here’s the recipe I’m brewing this year:

Recipe

Ingredients

• 5 gallons of unpasteurized apple cider (This year’s came from Draper Girls Country Farm)
• 2 lbs. raw honey (This year we used a blackberry honey from Eugene, OR.)
• 3 tbsp. whole cloves
• 9 cinnamon sticks
• 1 vial White Labs WLP775 English Cider Yeast (Lot #: 1775TTH8338341) - Store in refrigerator until ready to use.
• 3/4 cup honey (at bottling time)
• 1 cup water (at bottling time)

Equipment

• 6-gallon brew kettle
• Long-handled spoon
• Auto-siphon
• 5 or 6 feet of plastic tubing (to fit auto-siphon)
• 5-gallon plastic food-grade bucket with airlock and thermometer strip (Primary Fermentation Container)
• Wine thief or turkey baster
• 500ml graduated cylinder
• Hydrometer
• 5-gallon glass carboy with airlock (Secondary Fermentation Container)
• 48 12oz. glass “beer” bottles (not the screw-top kind)
• Enough metal bottle caps for all of the bottles (you’ll want a few extra)
• 5-gallon plastic food-grade bucket with bottling valve (Bottling Bucket)
• bottling wand
• bottle-capper

Making Cider

(“Must”, by the way, is what you call the cider prior to fermentation.)

Start out by cleaning any equipment that will come into contact with the must. Yeast organisms live everywhere, and adding whatever random yeast happens to be on your tools into the must will have unpredictable (although not necessarily unsatisfactory) results. You don’t necessarily need to have a 100% sterile environment the way some brewing guides seem to recommend; just realize that the cleaner everything is, the more predictable the result.

1. Pour five gallons of unpasteurized apple cider into your brew kettle.

2. Heat the must until it is steaming but not yet boiling. If the must begins to boil, it will start to form pectin, and you will have cloudy cider. (As long as you immediately remove from heat and stop the boil, your cider will probably still taste fine; it just won’t look as nice in the glass.)

3. Stir in 2 lbs. of raw honey and dissolve thoroughly.

4. Add 1 tbsp. of whole cloves and 3 cinnamon sticks.

5. Keep at this “steaming” temperature for about 30 minutes. (This both brings out the flavor of the cinnamon and cloves and also reduces the number of naturally occurring yeasts in the cider, which might throw off the flavor of the final product.)

6. Remove from heat.

7. Using the auto-siphon and plastic tubing, transfer the must into the primary fermentation container and install the lid and airlock to prevent contaminants from falling into it.

8. Let the must cool to around 70-75° F. (This can take a long time depending on the temperature of the room; it took mine about 15 hours in a 67° F room.)

9. Remove yeast from refrigerator and allow it to warm up for several hours.

10. Remove the lid from the primary fermentation container.

11. Using either a wine thief or a turkey baster (sterilized in either case), fill your (also sterilized) graduated cylinder with the must.

12. Gently drop the hydrometer into the graduated cylinder. Give it a few quick twists to dislodge any bubbles stuck to it. When the hydrometer comes to a rest, record the specific gravity and adjust for temperature of the must.

13. Return the must from the graduated cylinder to the primary fermenter.

14. Shake the yeast vial, open it, then pour the contents into the must.

15. Replace the lid and airlock.

16. Fermentation will usually begin within 5-15 hours. Most likely the airlock will start bubbling, but this is not always the case. Lack of bubbles doesn’t necessarily mean anything is wrong. Trust the yeast to do it’s job. :-)

17. Let it sit for about two weeks. one week. Try to keep the temperature of the must between 60-75° F, and store it in a dark place away from sunlight (placing a box over the container works, but mind the temperature as fermentation produces heat.)

18. After about two weeks, one week, use the auto-siphon to rack off the cider into the (cleaned and sterilized) secondary fermentation container. Be careful not to suck up the yeast cake and sediment at the bottom of the primary fermenter, and try not to let the cider fall through the air or splash too much, in order to prevent the alchohol from oxidizing.

19. Again, using a wine-thief or turkey baster, transfer some of the cider into your graduated cylinder and record the gravity reading (don’t forget the temperature adjustment).

20. Do not return the cider to the fermenter, since you don’t want to oxidize the alchohol.

21. Add six cinnamon sticks and 2 tbsp. whole cloves to the secondary fermenter.

22. Install the airlock on the secondary fermenter.

23. Let the cider clarify in the secondary fermenter for at least 4 weeks. As long as you keep the temperature between 60-75° F, and keep it out of sunlight, the cider can sit in the secondary almost indefinitely. Like wine, still cider improves with age. (You must use a glass carboy for this, though; the plastic fermenters will slowly leech oxygen into the cider and ruin the flavor.)

24. Again, use the graduated cylinder and hydrometer to take another gravity reading. A fully-fermented and clarified cider should be close to 1.000 after adjusting for temperature.

Bottling

1. Make sure your bottling bucket, bottles and bottle caps are clean and sterile.

2. If you prefer sparkling (carbonated) cider, dissolve 3/4 cups of honey into 1 cup of boiling water and add this to the bottling bucket.

3. Use the auto-siphon to rack the cider into the bottling bucket.

4. Attach the bottling wand to the spigot, open the spigot, and bottle your cider. Fill each bottle to just slightly above the neck, leaving 1.5-2” of headspace. Cap each bottle after filling (made easier with two people.)

5. For sparkling cider, let the cider bottle-condition for at least two weeks; the longer the better. Store the bottles at 60-75° F, and keep away from sunlight.

6. Chill the bottles in the refrigerator several hours prior to serving.

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.

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:

1

brew install reattach-to-user-namespace

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.

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.

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