GTD and Backpack

In late 2005, I had the good fortune to stumble across Backpack. Even today, I am still amazed at how something so simple can be so incredibly useful. If you haven't looked at it you should. Really. Right now.

I am a novice practitioner of GTD -- that is, I'm reasonably good at the writing down part and abysmal at the review part. In no particular order, here are some scribbles on how I (ab)use Backpack for GTD:

1. I use the lists for actions and the notes for projects. The next action for each project on a page is always in one of the lists on the same page. I put the project in curly braces after the action to remind me to promote the next action from the project when I finish the current one. E.g. "take pictures of old LPs { sell stuff on ebay }".

2. One page for home stuff, one page for work stuff, one page for my shopping list (each list is stuff I'm likely to be able to get on the same trip), one page for stuff I'm waiting for, one page to keep track of people's wish lists (one list per person).

3. If an action has a specific due date, annotate it with the date at the beginning. E.g. "[ 2006Apr15 ] file tax return". This makes it much easier to rearrange the list by due date as needed.

I'm always looking for ways to use tools more effectively. If you've come up with ways to GTD better with Backpack, please let me know!

WSDL and XSLT, yada, yada, yada

Last December, I finally got off my butt and completed a developerWorks article I'd been working on since mid/late-2004. This past Tuesday, they actually posted the drivel I managed to slap together! If you ever have a burning desire to do unholy things to WSDL documents using XSLT, give it a read; if you want to show off at the next web-service-geek party, give it a read; if you ever have difficulty falling asleep at night, give it a read; if you're someone who likes to write glowing reviews of material you've never actually read, give it a read.

Zen and the Art of Using a Computer

I've recently had cause to use and learn several new applications and programming languages that I had not previously been exposed to. As is typically the case, some of these systems "feel" right to me (Ruby, Backpack and GMail, for example), and some just don't resonate (PHP, STAF/STAX and urpmi, for example). I'm not trying to denigrate this latter set -- each serves a useful purpose for thousands (in PHP's case, millions) of people every day.

The problem here is Zen. All of my past experiences have shaped my mind so that I think about the world in a certain way. When faced with a new situation, my brain immediately starts matching it against these entrenched paradigms and patterns so I can select an appropriate response. Thus when I design/write new software, my zen dictates how I address not only the large issues that invariably arise, but the myriad of smaller choices as well. When it's finished, the software is as much a reflection of me and my own thought process (my "zen") as it is a reflection of the original requirements.

Taking the next step, I postulate that the software that feels right to me was written by folks with a zen simliar to my own. That is, their minds approach and solve problems similar to the way my mind does. Stuff that rubs me the wrong way, conversely, was most likely written by folks whose minds work very differently than mine.

While it may be true that on the Internet no one can tell you're a dog, I suspect we're never going all like the same dog food.

<not-a-programming-language/>

I've recently had the chore (nee "opportunity") of putting together some test scripts using STAF/STAX. To be fair, I should also mention that IBM internally also has several layers of test tooling built on top of STAF and STAX to make testing "easier". "Easier" in the previous sentence was originally going to be "easier [sic]", but I'll withhold final judgement until I learn enough to have an informed opinion.

STAF makes a lot of sense to me -- it's a simple service-based distributed framework with enough low-level services (processes, events, logging, file manipulation, etc.) provided that you can build more interesting higher-level services.

STAX, however, just rubs me the wrong way. STAX is a programming language for test environments. For some reason known only to their mothers and respective deities, the folks who put together decided to use XML for a programming language. Now don't get me wrong -- I have nothing against XML per se. I have used it to represent data on several occasions and am continually amazed at the XSLT tricks that skilled practitioners manage to pull out of their butts. Let's consider briefly what makes XML a good way to express data.

1. It is self-contained. That is, you don't HAVE to have any external meta-information (character set, schema, etc.) to successfully parse it. This makes working with XML data fairly simple -- any XML parser can read any XML file. Note that this assumes you don't need to do validation -- that still requires some meta-information about what constitutes "valid".

2. The data is extensible. Namespaces allow 3rd (or 4th or 5th or...) parties to augment the data in any way they see fit without hosing each other.

3. There are really cool mechanisms like XPath, XQuery and XSLT that allow the data to be easily reorganized and combined with other data in ways the original author never intended.

How many of these are applicable to test scripts? Let's see...

1. What kind of metadata do you need for a test script? Perhaps some information about the environment needed to execute the script, change history, build instructions, etc. Does STAX let you put any of this in the test script? Not as far as I can tell. How about having multiple parsers? Only a test script interpreter/compiler is ever going to read these. We've known for decades how to define programming languages precisely enough that multiple people can independently write compilers.

2. You can't add new constructs to a programming language without hacking the interpreter/compiler.

3. I can't tell you how many times I've wanted to know how many "if" statements there are in my test scripts. Oh wait, yes I can -- NEVER!

And not only does using XML as a programming language NOT give you any benefits, you get to do a lot of extra typing as well! I need to scrounge some venture capital to start a company that manufactures steel <, > and / keys.


But the insanity doesn't stop there. The folks who put together STAX *were* bright enough to figure out that XML was totally inappropriate for writing expressions (which you tend to do a lot of in programming languages). Kudos for that. They elected to use Jython for expressions. Kudos again.

Now why the hell didn't they figure out that they should have used Jython (or Ruby or JavaScript or ...) for the whole language!?!