blog.jdhuntington.com

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.)