Exhibit A, Exhibit B

Foote and Yoder's The Selfish Class provides a pattern language for software artifacts that survive.

[Via Ted Leung]

I'm one of those people who's so obsessed with organization that he's poorly organized. I'm constantly trying out new ways to manage the notes I scribble on various physical and electronic media, so much so that the frequency of change leads to greater disorganization.

I've tried a number of "information management" tools, including index cards, sticky notes, notebooks, a Franklin planner, Microsoft Outlook, and various outlining, mind-mapping and PIM programs, and found them all wanting in one way or another (maybe it's me). Paper based systems were too hard to search and too static in their organization. Lacking a PDA, electronic systems weren't portable enough. No matter what the system, I'd always spend more time trying to set up organizational categories than I ever saved by using them. In fact I had pretty much broken the habit, falling back to a collection of loosely organized text files that I could easily scp to and from whatever workstation I was currently using.

About a year ago, I got a Sharp Zaurus, and since that addresses one of my recurring PIM complaints--having something that's always readily available, my hopes for finding the perfect PIM system were renewed. I've played around with a number of the PIM systems available. Using the bundled Address Book/Calendar/To Do List/Email Client was too jumbled. The "outliner" IQNotes was promising, but a single hierarchy is inflexible and using it to create dated journal entries requires too much manual effort. In the end, I came back to a loosely organized collection of text files, this time stored on the Zaurus.

Back in my first post, I mentioned that one of the reasons I was interested in blogging is that I had become interested in journaling in general. These two concepts--the search for the perfect organizational system and interest in journaling--interrelate.

As I'm sure I'm not the first to suggest, it seems that the ideal PIM system presents at least two perspectives on the information to be managed:

1) A time based view, answering such questions as "what have I been working with recently?" or "what else was I working on around that time?"

2) A "concept network" view, answering such questions as "what's related to this topic?" or "what else do I know about this subject?"

Clearly, I presume, blog-like software is an excellent starting point for the former, and wiki-like software is an excellent starting point for the former. Fortunately, a number of projects have begun to explore combinations of the two, either by implementing a blog-as-wiki (like SnipSnap does) or by adding blogging features to a wiki engine (like JspWiki and no doubt others do).

Having a fair amount of Java experience (indeed, I've built a little wiki or two in Java), my first thought was to get a Java based wiki up and running on my Zaurus. JspWiki looks nice, and like most Java-based wikis is Servlet/JSP based, so I endeavored to get a WAR-friendly Java Servlet engine up and running on my Zaurus. Having tried both Tomcat and Jetty under both the Jeode evm and Personal Java cvm, I came close, but fundamentally failed to do this. (I note that my SL-5500 had just barely enough disk space or memory to do this as well.)

I briefly considered setting up a stand-alone (i.e., non-Servlet/JSP) Java wiki engine on the Zaurus, but without a moderate amount of development that seems like an awkward environment for templating and modification, and non-servlet Java web development feels like dead-end development. (Its only a matter of time before a reasonably micro servlet engine is available.) That's when I stumbled across PhlIp's Mini Ruby Wiki, which implements a featureful, stand-alone wiki server in around 1000 lines of Ruby code.

(For the record, one could readily build a similarly featured wiki in Java, and probably a number of languages, in roughly the same number of lines, it might not be as much fun.)

It still took me a while to get a Ruby interpreter up and running on the Zaurus (after trying a few different builds, I finally got the one from Vincent Fiack working), but the resulting binaries are smaller in terms of disk and memory footprint than the JVMs I was playing with. Perhaps more importantly, as a purely interpreted language, the engine itself is easier to tweak. And this gives me a reasonably good excuse to hack out some Ruby code. I've already added/modified a few minor features, adding some simple blog-like features to the calendar features that already existed. If I come up with something I'm not to embarrassed to share, I'll post it here or submit it to PhlIp's RubyForge project.

My only problem now is resisting the temptation to continually tweak the wiki engine code.

I'm a sucker for quirky bugs. Recently, I've been hacking around with PhlIp's excellent Mini Ruby Wiki (more on that later), and discovered one such bug.

There's a block of code in MiniRubyWiki that renders a small calendar in HTML, not unlike your typical blog calendar widget. Here's a small subset (the actual code is more interesting that this) which is largely although not completely unchanged from the original miniWiki.rb source. See if you can spot the bug.

  # here's a constant, declared elsewhere in the program
  SecondsInDay = 60 * 60 * 24
 
  # ...
 
  # In this loop we're rendering a four-week calendar,
  # from the beginning of last week until the end of the week after next.
  # "beginningOfLastWeek" is a Time indicating the Sunday of last week
 
  today = Time.now()
  (0...28).each do |day|
    dayOnCalendar = beginningOfLastWeek + day * SecondsInDay
    # break the row every seven days
    calendar += '</tr><tr>' if day.divmod(7)[1] == 0
    calendar += '<td'
    # highlight today
    if today.mday() == dayOnCalendar.mday() then
      calendar += ' bgcolor="#88ff88"'
    end
    calendar += '>' 
    # show the month for the first day in the calendar or in the month
    calendar += dayOnCalendar.strftime('%b') + ' ' if dayOnCalendar.mday == 1 or day == 0
    calendar += dayOnCalendar.mday.to_s() 
 
    # ...snip some stuff displayed within the calendar...
 
    calendar += '</tr>'
  end

 

I've been running this code on my Zaurus, sometimes launching it from the EmbeddedKonsole on the Zaurus itself, and sometimes from an ssh terminal running on a remote machine. Eventually I noticed something funky about this. When I launch the server from the ssh terminal, 1 November 2003 is listed, correctly, as a Saturday. When I launch the server from a terminal on the Zaurus itself, 1 November isn't listed at all (the last day on the calendar is 31 October 2003, listed, incorrectly, as a Saturday). In fact, when I launch the server from the Zaurus, Sunday, 26 October 2003 is listed twice.

Adding a "puts curDay.to_s" line inside that loop makes the problem obvious. This output like the following:

Sun Oct 19 00:00:00 CDT 2003
Mon Oct 20 00:00:00 CDT 2003
Tue Oct 21 00:00:00 CDT 2003
Wed Oct 22 00:00:00 CDT 2003
Thu Oct 23 00:00:00 CDT 2003
Fri Oct 24 00:00:00 CDT 2003
Sat Oct 25 00:00:00 CDT 2003
Sun Oct 26 00:00:00 CDT 2003
Sun Oct 26 23:00:00 CST 2003
Mon Oct 27 23:00:00 CST 2003
Tue Oct 28 23:00:00 CST 2003
Wed Oct 29 23:00:00 CST 2003
Thu Oct 30 23:00:00 CST 2003
Fri Oct 31 23:00:00 CST 2003

That's right, sometimes 24 * 60 * 60 is the wrong value for SecondsInDay. Due to the switch from CDT to CST, 26 October 2003 has 25 hours, so adding SecondsInDay to the midnight time isn't sufficient to advance the day.

For whatever reason, when launched via remote ssh terminal, the interpreter doesn't seem to be aware of the locale (it shows the times as UTC), but when launched from EmbeddedKonsole, Time.now() is aware of the locale and manages the switch from CDT to CST automatically, leading to the bug.

Cute, no?

About mid-way through September I had written off blogging for the month because of professional and personal demands on my time, but here we are mid-way through October and still no posts. I guess blogging is an easy habit to fall out of. I'll see what I can do to rectify that.