Best & Worst of 2008: Technology

January 5th, 2009  |  Published in etc  |  3 Comments

This is the first in a small series I’ll peck at over the next week or so. Today I’m doing my favorite and least favorite tech things from 2008, then I’ll do entries on books, music and life.

So first up is the best: (or you can skip to the worst)

Best: Ruby & Rails

I wrote my first database application while I was stationed at Fort Bragg. It was a sloppy but detailed affair I used to track training and administrative information on a 150-solider signal company, and it had the unfortunate effect of making me think in terms of desktop db apps like Access and Filemaker.

When I switched to Macs, I picked up another unfortunate dependency on AppleScript. AppleScript is an easy target for abuse from serious programmers for reasons I won’t dispute: It’s showing its age in a number of ways and there are some things that should be easy that are not. I’m less receptive to complaints about its natural language syntax because AppleScript’s problems start well before one enters the uncanny valley induced by AppleScript’s take on English.

Despite its issues, AppleScript can also be very useful, especially when an application developer has taken the time to flesh out the app’s AppleScript dictionary. Most applications have basic AppleScript controls for things like opening and closing document windows or accessing their text content, but with an enhanced dictionary more possibilities open up. Safari’s dictionary, for instance, provides ways to programatically access the URL, title, text or source of a given tab; and it also has a “do javascript” action for manipulating a page.

For people uncomfortable using AppleScript to do some things it doesn’t do very well (like sorting), it also offers an escape hatch in the form of the “do shell script” action. So a scripter stumped for a way to manipulate content retrieved from an app can pass the content out to the Mac’s BSD shell environment for processing via traditional tools like sed, grep, or sort. Even for things AppleScript can do, like return the current date, do shell script makes life easier for people rooted in Unix who might be more comfortable with date and its strftime conventions. do shell script can relegate AppleScript itself to a barebones glue that offers a way to get information out of GUI apps and into the BSD userland without having to build a ton of logic in AppleScript’s clunkier syntax.

I first started pecking at Ruby for some basic Web scraping with scrubyt, feeding the output back to applescripts, but soon learned about rb-appscript, which provides a mostly reliable way to do application scripting on a Mac in Ruby, Python or Objective C, using an object-oriented interface to the same Apple Events AppleScript communicates through. There’s a handy companion application–ASTranslate–that even offers a way to translate existing AppleScript code into its Ruby equivalent, which is immensely helpful for figuring out how to rough in a script. Here’s some sample AppleScript:

tell application "Safari"

set myTitle to the name of document 1

set mySource to the source of document 1

end tell

and ASTranslate’s translation to Ruby:





which points a clear path to :


<p>page = app("Safari").documents[1]</p>

<p>myTitle =</p>

<p>mySource = page.source.get</p>


And from there, the Ruby advantage widens:


<p>doc = Hpricot(mySource)</p>


and go nuts with it.

rb-appscript was an interesting novelty until I got an ASUS eeePC and was reminded of the value of portability. None of my AppleScript was going to run on anything besides a Mac, so I started the process of taking a lot of my AppleScript code and porting it over to Ruby so I could have it on the eeePC. Some things were trickier to do than others: Getting a URL out of Firefox on Linux was more involved than getting one out of Safari on OS X. Ultimately, some of my scripts were moved from AppleScript to Ruby CGIs tied in to bookmarklets.

I don’t have much to say about Ruby’s “competition” in Perl & Python. Like a lot of people, I got curious about Perl in the late ’90s. It never really took with me, though. Same with Python. Something about Ruby clicked, partially because the syntax seems very sensible to me, partially because rubygems “just worked” the crucial first few times I needed it to, and partially for the reason a lot of people hate it: its expansive and forgiving syntax. (I’m at pains to point out that the preceding link is … problematic. If you read the entry, also read the comments, because some of the examples given to demonstrate Ruby’s inferiority are contrived in the same way national security hypotheticals based on 24 episodes are contrived.

A few early finds in the Ruby world that cemented the relationship:

  • scrubyt, a Web scraping library that seems almost magical: You feed it a bit of sample markup from a page, it figures out the DOM scripting needed to get everything like that sample.
  • hpricot, an HTML parser that makes it really easy to process pages and get the good stuff out of them. (sorry for the cache link — site’s down at the moment)
  • tidy, an interface to HTML Tidy. Hpricot can do some of this stuff, but Tidy is the gold standard. Most of my HTML extraction stuff ends with a pass through tidy to brush off the lint and snip the hanging threads.
  • feedtools makes RSS/Atom parsing simple.

And that brings us to ….


I started playing with Rails last year, but it never really stuck because I didn’t have a concrete problem to solve with it. This year, though, I spent a few weeks trying to build a database for my job and found myself badly frustrated by the state of desktop database apps. FileMaker Pro is out there for several hundred dollars, OpenOffice comes with a free database app similar to Access, and FileMaker also makes something called Bento, which is meant to be “a database for the rest of us,” but it’s meant to serve more as a sort of GUI glue for Apple’s Address Book and iCal apps, and it’s frustratingly limited, no doubt to protect the $300 Filemaker from cannibalization.

So I roughed in what I was after in Ruby and soon realized there was no point in building a GUI out of something like FXRuby when HTML is a perfectly serviceable way to write a simple database interface. So armed with a goal–write a database app that could track invoices–Rails suddenly made a ton of sense.

Rails is very nice for writing stuff you don’t plan to deploy on an open port. It uses SQLite, so there’s no need for something like MySQL if you don’t care for it; and it has its own lightweight Web server running on port 3000. Grab a CSS framework like Blueprint to handle prettifying things and making layout easier, and you’ve got a database app that’s very extensible on the fly. Given a database tracking articles and authors, I can extend the Article class with ease to add a “performance” method that tells me how much I paid per pageview for a given article:

    def performance

     author = Author.find(self.author_id)



Then build on that to give me a report on how all articles published in the last 90 days have performed:

def self.performances

  articles = self.find(:all, :joins => :author,

    :conditions =>  ["pubdate > ? and = ?", - 90.days, true])

  articles.sort!  {|a,b| b.performance.to_i <=> a.performance.to_i}


For the Invoice class, I can add methods to help me track whether I need to follow up on a given invoice:

def followup_date submit_date + 45.days end def needs_followup? submit_date + 45.days <= && cleared != true end [/sourcecode]

There’s a part of me that thinks “gee, that’s probably not very efficient and there are surely better ways to do it …” and then another part that thinks “it has run on your MacBook for weeks at a time and the report those samples drive eats less cycles retrieving the information than Safari does rendering it. It’s not like I’m trying to write the next Twitter or something.”

Rails has saved me a lot of money in software costs and I’ve got two more projects in mind for it that will spare me further expense and dependence on outside applications that I can’t tailor to my needs with the precision I can manage with Rails. It took a few days to get the foundations of my first app set up just the way I liked, but once everything was in place I knew I’d found a tool I’ll be using for a while.

Some Ruby and Rails items of interest, if you’re curious:

  • Why’s Poignant Guide to Ruby is a wonderful introduction. Or take a look at Try Ruby!, a language tutorial you can run in your browser. Neat.
  • The Rails Way–Nice mix of cookbook and instruction manual.
  • O’Reilly’s Rails Up and Running is great for impatient people.
  • O’Reilly’s Ruby Pocket Reference is nice to have on hand for basic stuff like string, array, hash and file methods or conditionals. You can get all that stuff via, but the presentation found in the reference is a little friendlier and usually offers better examples.

Worst: GTD Software

I think “Getting Things Done” is going to get its own Internet geological age, and I’m still sorting out how to feel about Merlin Mann deciding to pull a Paul Atreides and denounce his own jihad, but I’m done with all the GTD-people hating either way. Oh … weird … I guess I’ve been done with it since late 2005 … so that’s good to know.

None of that does anything to let GTD software off the hook as something I consider an awful trend.

Here’s the rundown:

Before there was software, people doing GTD lived pathetic existences. Some of them kept hand-written lists on paper, some used outlining software or to-do list apps like Remember the Milk to organize their contexts and actions and such. That situation made a lot of people profoundly unhappy, as a simple search on “use * for gtd” reveals. Hardworking software developers detected an opportunity and pounced. I don’t blame them for that, so please drop whatever “why do you hate the free market?” objections you’re ready to raise. I don’t hate the free market for selling GTD software any more than I hate Stalin for his ugly haircut.

The typical GTD application is to GTD as the typical Harry Potter movie is to its source novel: no fan-upsetting omissions or changes, resulting in something that’s twice as big as it needs to be to do its job with anything like economy. I mean, here’s the typical GTD workflow:

  • figure out all the stuff you have to do
  • break it down into bite-sized actions
  • list those actions by context, i.e. the places you do things
  • when you do something, cross it off the list
  • every now and then, make sure you’ve crossed stuff off the list that needs to be crossed off, and add stuff that needs to be added.
  • have an inbox and keep it tidy
  • turn all the above into something hopelessly complex involving thumbtacks, a custom-built Linux box, a fancy waist coat and a rabid stoat with an org chart tattooed to its back

GTD software is tasked with automating all that, so you end up with lots of menus and buttons to set contexts and mark things done or not done or pending or past due or never due necessarily or reviewed or unreviewed or critically in need of review or most emphatically not in need of review (level 5) or potentially reviewable (because it’s orange, not green).

I read a user review of one popular Mac GTD app that led with a comment about how you “need to be a GTD blackbelt” because the app was “like the cockpit of a jet fighter in terms of complexity.” That struck me as very wrong. You’re keeping lists, for pity’s sake, not acting as comptroller of a mid-size city. Or maybe you are acting as comptroller of a mid-size city, in which case doubling your workload to manage your workload seems like kind of a rip-off.

Why all the heat? Because I bought one of these goddamn apps (beta tester/previous app it replaced discounts) right at the start of the year and found myself having a harder time the more I entrusted to it, especially when I let it helpfully decide what I needed or didn’t need to see at any given moment.

Some people have the sort of bandwidth you might need to use complex organization applications, and I do not begrudge them any pleasure they take in doing so. But having spent eight months being 40, the one concrete change of life I can point to is a marked increase in my impatience with new tools. I do not want to die with my last thoughts being preoccupation over whether “mark as done” is cmd-shift-ctrl-d or opt-cmd-ctrl-tilde.

If you need some sort of electronic organization, I’m happy to recommend Remember the Milk, which is free and simple. Mac users may also like TaskPaper, which pulls off the neat trick of citing David Allen right there at the top of its homepage to chop the entire GTD market down to size. TaskPaper is still more than anyone really needs to keep lists, but after bingeing on the more expensive and complex apps, a few minutes with it is like a New Year’s Day walk in the cool air to shake off a cheap champagne hangover. And it’s a plain text format, so even if the app is too much, you get to keep all your lists and they’re organized sensibly even without the software to interpret them for you.

If you want something free andmiserably complex, introduce the lurking horror that is org-mode to your .emacs.d/site-lisp and don’t blame me when you become depraved enough to start using W3M and GNUS.


  1. BacarliW says:

    February 6th, 2009 at 8:30 pm (#)

    your worst list is similar to mine. but i feel like i’ve gotten lucky this year. everyone’s starting to get it. for example, Outlook Track-It has been amazing. (small toolbar that improves the followup function out outlook, as a plugin). it’s been saving me the last few weeks. thank you for this post!

  2. CJW says:

    February 26th, 2009 at 11:54 pm (#)

    bacarli, I just started using Outlook Track-it. It’s pretty great so far. Helping my business, too.

  3. Pow! etc. :: dot unplanned says:

    April 15th, 2011 at 3:41 pm (#)

    […] all makes me think back to 2008, when I wrote about my recent discovery of Rails: The combination of Sinatra, Pow! and Rack does even more to provide me with a comfortable […]

Leave a Response

© Michael Hall, licensed under a Creative Commons Attribution-ShareAlike 3.0 United States license.