blog.jdhuntington.com

For years, I've wanted to try my hand at roasting my own coffee. Hoping to do it cheaply, I've always been looking for a very specific type of popcorn popper that will work for this purpose. However, given the trend that popcorn poppers seem to have taken, I'd more or less given up on the idea.

A few months ago, Matt was kind enough to let me borrow his Fresh Roast Plus that he had since replaced. It's a great little roaster, and given what I now know, I'm glad this was the first roaster I've used. It does have its drawbacks, but it's a great roaster to learn on. Most notably, the build of the unit let me see what was happening to the beans throughout the roast, and also let me hear the audible cracks of the coffee beans. Now that I've done a little bit of roasting, I'm planning on moving up to a unit that can roast a half-pound or a full pound at a time. The Fresh Roast can accommodate only 3 ounces at a time, which means that to have fresh coffee consistently, one would have to roast nearly every day, depending on coffee consumption.

I started by ordering a sampler from Sweet Maria's, which gave me 8 different types of coffee to try roasting. I've liked them all, and it's amazing to taste the vast differences in flavor. Up until very recently, I had been letting beans sit for 12-24 after roasting before grinding and brewing, which I'm now realizing likely contributed to too much acidity. My most recent batch rested for about a week, and the flavor is much more apparent.

The roasting process itself is drop-dead simple. All it takes is putting the beans in the roaster, turning it on, then waiting for the appropriate signals to know when to stop. I used a guide from Sweet Maria's which has plenty of information on the roasting process.

I can tell I've got a ways to go before the beans rival those of my favorite local roaster, but they're a heck of a lot better than any of the national chains.

I love the integration between github and lighthouse. (If you're not familiar with this, have a look.) However, I always found myself forgetting which ticket I was working on when writing commit messages. At first, I wrote this script just to add the ticket number in the git commit message, but it quickly evolved to help throughout the workflow.

When starting on a new ticket, this script helps by

• Assigning a ticket to when starting work
• Creating a local branch with an intelligent name

On completion it will

• Set the state of the ticket to a user-defined value (through the git commit msg)
• Clear the active user (also through the git commit msg)

Workflow

Here’s an example of the workflow…

Setup

Install Bugflow

Just grab this script and put it wherever you like. (I prefer ~/bin)

Install Gem

Grab the lighthouse gem from github:

$ gem sources -a http://gems.github.com
$ sudo gem install Caged-lighthouse-api

Project Config

Finally, create a file in the root of your project called .bugflow.yml and add the following data:

Also, it’s a good idea to add this file to your .gitignore.

$ echo ".bugflow.yml" >> .gitignore

Happy hacking!

After pairing with a coworker using Textmate's Blackboard theme, I decided I wanted it for emacs. The font lock I'm using in emacs for ruby didn't let me recreate it perfectly, but it's certainly close enough for me.

Here's my first crack at it: color-theme-blackboard.el

Update: Screenshot.

While at cabooseconf last month, I found out about one of the coolest time tracking tools ever: punch. (Thanks to cardiod from OG)

According to its own description, it's a

k.i.s.s. tool for tracking the hours spent on various projects. it supports logging hours under a project name, adding notes about work done during that period, and several very simple reporting tools that operate over a window of time.

For those of you who use OmniFocus and won't be getting an iphone, this one could really come in handy. It's a ruby script that talks to OmniFocus via OSA, grabs all the items in a given context, then writes them as poorly-formed html over ssh to a predefined destination. Cheap and dirty, but it's the quickest way I've found to get stuff like this available anywhere, especially in a mobile phone browser.

#!/usr/bin/ruby

require 'rubygems'

require 'rbosa'

require 'net/ssh'

of = OSA.app 'OmniFocus'

shopping_list = of.default_document.contexts.collect { |x| x if x.name == 'Errands' }.compact.first.contexts.collect { |x| x if x.name == 'Shopping' }.compact.first

items = shopping_list.tasks.collect { |x| x.name unless x.completed? }.compact

def post_file( shell, file, datum )

shell.touch(file)

shell.send_command("echo \"#{datum}\" > #{file}")

end

def build_html(items)

"<ul>#{items.collect{|item| '<li>' + item + '</li>' }}</ul>"

end

Net::SSH.start( 'myserver.dreamhost.com' ) do |session|

shell = session.shell.sync

post_file shell, "~/shoppinglist.mydomain.com/index.html", build_html(items)

shell.exit

# session.loop

end

The latest post at Rands in Response started a bit of a heated discussion with a group of friends, and I thought I'd touch on a few of the reasons I think it is absolutely imperative to automate, even if the automation only saves a second.

The concept of automation is an old one. In fact, automation is the reason computers were built in the first place. They were used to automate processes that were too complex or laborious for humans to tackle themselves. In early days, these complex tasks were simple by today's standards; "discover the trajectory of a bomb" or "calculate one plus two". However, as computers have become cheaper they've started to automate everyday things. This is painfully obvious to anyone who lives in the 21st century, but it's a fact that programmers shouldn't forget. A good programmer is someone who's always looking for redundant tasks that can be automated; both to save time and to reduce human error.

Saving time, however, is a concept that carries with it many externalities. The day of writing this post, I have been working on a fairly complex shell script with many moving parts. This itself is not a problem, but the fact that I've been asked to respond to a few emails at random times during the morning provides a significant complication. As "sufferers" of N.A.D.D. will understand, taking 60 seconds to send off an email may well torpedo 30 minutes' worth of productivity. Extrapolate that to 3 separate yet short tasks, and I've lost about half of my morning. This is an important measure to bring into the cost/benefit ratio when discussing automation. Typically, the equation used to calculate a processes' automated value is the following:

a = Amount of time for task (un-automated)
    * Number of times task performed
b = Amount of time for task (automated)
    * Number of times task performed
    + Amount of time to automate the task

However, this simplistic equation misses the issue entirely. If my automated task is short enough to keep me from getting sidetracked by any of the hundreds of windows on my desktop, then it's paid for itself after two uses.

I was one of the lucky few to get an account in the first round of AppEngine signups, and today I started in on my first app.

I recently found Edward O'Connor's backpackit entry on Personal Unit Tests, and I thought this would make a great little app to get started with. It's like a daily goals tracker, but with a very slightly different focus. More on that tomorrow.

Overall, I was very impressed with the amount of minor annoyances google has removed with this new setup. Having worked with these types of webapps for a number of years now, I know that they're rarely easy to host and deploy, but google has certainly taken the grunt work out of the equation.

I was most impressed on the user account tie-in they've built. It's absolutely trivial to let people use their own google accounts [gmail accounts] instead of creating a new account on each site. Effectively, they've built their own OpenID implementation into the framework.

At the end of the day, I'm reminded a bit of GeoCities and Tripod, who brought static webpages to the unwashed masses. With AppEngine, all that's needed for a small app is a handful of yaml, some html, and a few hundred lines of python.

Ever since reading "The Little Schemer", I knew I had to write my own implementation of scheme. I started, and I didn't get very far before I noticed someone else had the same idea, and a better implemented one at that.

"bus-scheme" is the name, and I'm loving working with it [on the MAX]. Definitely worth checking out if you're interested in compilers, languages, scheme, or any combination thereof.

(In case you're curious, here's the version that I started.)