mult.ifario.us

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.

Not so long ago, I used an ATM ("automated teller machine", called other things by people in other parts of the world) just down the street from our condo in Chicago. According to the bank's fraud detection folks, that ATM has been used for a good amount of suspicious activity, so they suspended my ATM card. Then, the next morning, they called to badger my wife about it:

Bank: Hello, this is Bank X. We need to speak to Mr. Brown.
Mrs. Brown: He's not here, but I'm his wife. How can I help you?
Bank: Please give us your husband's social security number for verification purposes.
Mrs. Brown: No. How about you prove to me who you are first?

And that went around in circles for a few iterations, ending in stalemate. My wife was right, and I'm not just saying that... The caller supposedly from our bank could have been anyone who might have guessed the name of our bank and decided to phish by phone.

Phishing and other phorms of phraud have highlighted that fact that identity is a symmetric problem while most solutions are one-sided. So, how about, for every account that a user has with a provider, both the user and the provider have the means to authenticate each other? A naive solution could be as simple as having two passwords -- one to give and one to receive.

An entry on Boing Boing has a link to an animated version of an anti-pattern in productivity. This reminds me of some advice I got from a friend over a decade ago...

Sometime in early 1993, it was around 4AM, and I was in a room heated by a herd of humming SUN 3/50's with another graduate student. (That room was on the 8^th floor in the building where vi was written...) He was finishing his dissertation, and I was preparing for my qualifying exams. In conversation, I asked how he got started on his line of research. His response was simple and succinct:

The only way to get something done is to do it.

A tautology at first glance, this is the only solution to the preparation/refinement conundrum. As an argument against premature optimization, creating and experimenting with a prototype often supplies information that was previously unavailable, so many a posteriori conclusions could not have been drawn a priori anyway.

One suggestion along these lines is that cat makes a perfectly good text editor if you're suffering from writer's block. Simply:

pbpbook$ cat - >> work.txt
Type.
Do not backspace; do not edit a line.
Hit enter frequently.
Do not exit until the thought has been expressed.^C

In extreme cases of refine-itis, even a simple text editor can be too tempting.