mult.ifario.us

After experiments with Microsoft Word and DocBook (both of which turned out to be poor choices but for different reasons), we're using the Confluence wiki for the documentation for PXE, and I've been enjoying TimTam instead of a browser-based client.

Named for the tasty cookie from Oz that can be used as a straw, TimTam is an Eclipse-based thick client (a "thiki", as I would call it) for Confluence with a useful interface -- left-hand tree for wiki pages and a normal-sized window with reasonable key bindings, content-assist for macros, and a source/preview dual view for editing content. TimTam's still pre-1.0, but the tip builds and works well on Mac OS X with Eclipse 3.1M5a.

I've added a tag to my del.icio.us bookmarks for academic work about BPEL. The list is non-exhaustive, and I'll add items to it as I come across them. (If you know of something substantial that I'm missing, let me know.) Thanks to del.icio.us, you can also get the items as an RSS feed.

Collaboration and "groupware" are justifiably hot, since most of the current offerings suck, and every company and working person are potential customers of something that's truly better. I'm doing my best to keep track of JotSpot, Hula, and whatever Google decides to do in the way of a calendar. (Hey, Yahoo, how about supporting calendaring standards before Google eats your lunch (again)?) Nonetheless, there is still something missing.

I need software that helps me collaborate with myself, and one thought is to have a "thicki" that cuts across applications and rolls in some combination of desktop search and backlinking functionality. (A "thicki" is a wiki with a thick client instead of a web client.) I'd like to be able to attach the notes from a meeting to the calendar event for that meeting to the attendees to all of the emails that I've ever sent... (Hard-core text UI folks may recall Emacs PlannerMode.)

In this vein, I've been experimenting with a simple thiki called VoodooPad for note-taking and doodling. VoodooPad has some nice goodies in it like a little sketchpad. It's still short of what I'd like in terms of hooks into other applications, but you can hardly blame VoodooPad for the the under-instrumentation of other applications and the operating system...

On the subject of hooks into other applications, there is a fabulous tool for Mac OS X called Quicksilver. The best way I can describe it is an autocomplete search engine for application verbs (i.e., scripting hooks). The way it works is that you trigger the agent via a gesture or key combination and then it proposes matches for what you type next. (For example, with my configuration, I type [ALT] [ALT] pause [ENTER] to pause iTunes playing. Or, [ALT] [ALT] mail [ENTER] brings Mail.app to the foreground.)

Some combination of VoodooPad and Quicksilver may be what I'm after, e.g., [20050224] in a thiki page is a link to that day in iCal or [Paul Brown] brings up a list of options like "find all references to Paul Brown in other thiki pages", "find all emails from Paul Brown", "open Paul Brown in AddressBook", "dial Paul Brown on T616 via bluetooth", etc.

I'm no fan of the DOM, and I'm not alone -- probably anyone else who's used it extensively feels the same way. (If you must know, it's the b0rked namespace support that gets on my nerves the most.) I wasn't on the committee that designed the original DOM and its successors, but I'll throw some stones anyway: the current state of affairs is the result of short-sightedly valuing compatibility over correctness. It is possible to make mistakes, and those mistakes should be acknowledged, corrected, and then avoided.

While I'm DOM-bashing, here's a quote from Elliotte Rusty Harold in an interview with Bill Venners:

There's a phrase, "A camel is a horse designed by committee." That's a slur on a camel. A camel is actually very well adapted to its environment. DOM, on the other hand, is the sort of thing that that phrase was meant to describe.

And some comments from Michel Kay from a discussion of the TrAX interfaces on the xml-dev list:

Sadly Java seems to have got itself into the hole that interfaces cannot evolve - or at least if they do, it causes serious disruption. I've had to do major reengineering of Saxon to keep it working across JDK 1.4/1.5 because of changes to the DOM interfaces. (Though if this hastens the death of the bloated monster called DOM, I won't be sorry.)

Amen.

I happened across Ian Landsman's post about starting a micro ISV, and I was disappointed to find one piece of advice missing. In fact, these questions are missing from most advice for entrepreneurs, even though the answers are fundamental to eveything that follows:

1. What do you want to be — famous, comfortable, rich, or wealthy?
2. What do you want your company to be?
3. What do you want to be in the company — CEO, CTO, crazy scientist with a corner office, or a janitor with a lot of options?

If you align your plans with your goals, then you have a shot at both success and some reasonable amount of happiness. If you do not, then you have a great shot at having neither.

To go with all of the great things about using Mac OS X, there is the cruel myth of tools.jar. In spite of the fact that it says absolutely nothing about archive names, paths, or anything remotely like that in the JVM Specification, even otherwise well-informed developers insist on believing that there is a magic tools.jar that lives in some subdirectory of JAVA_HOME. It just so happens that a tools.jar exists in a number of JVM implementations from a number of companies, but its presence or location are absolutely not things to be relied upon.

The fact is that it's relatively easy to avoid a dependency on tools.jar by simply checking the environment for the shell-based launcher, Ant build, or application and not including it on the classpath when on Mac OS X. Many but not necessarily all of the useful goodies in tools.jar on some platforms are in the main archive on Mac OS X, which happens to be located in $JAVA_HOME/../Classes/classes.jar:

$ jar tvf $JAVA_HOME/../Classes/classes.jar | grep javac
  1385 Wed Sep 01 09:02:38 CDT 2004 com/sun/tools/javac/Main.class
  1595 Wed Sep 01 09:02:38 CDT 2004 com/sun/tools/javac/v8/CommandLine.class
 14627 Wed Sep 01 09:02:38 CDT 2004 com/sun/tools/javac/v8/JavaCompiler.class
[... etc ...]

Last year, I had an opportunity to give a keynote on BPM and workflow at Lockheed-Martin's annual conference, and some of the recent buzz (like posts from Bill, Matthieu, and earlier on from Tom) around workflow and orchestration has reminded me to get my slides posted on-line.

So, here they are.