ATTENTION: This blog has moved to a new location. Please update your bookmarks, browsing habits, and aggregators.

	Monday, October 20, 2003

Switching Up to SnipSnap I've moved my blog to the SnipSnap weblog/wiki tool; the new URL is http://blog.fivesight.com/prb/. (The trailing slash is important!) The RSS URL is http://blog.fivesight.com/prb/exec/rss. All old entries are up on the new blog, but this site will stay up until my subscription runs out. 9:54:44 AM

	Tuesday, September 30, 2003

FiveSight in the D&T Chicagoland Fast50! This post (and this weblog) has a new home. I recently received notice that FiveSight was recognized as one of the Chicagoland Technology Fast50 by Deloitte and Touche, meaning that we're one of the 50 fastest growing technology companies in Chicago. Here's a general press release. (We're in the midst of turning-up a new website — with an updated marketing message — on a new hosting provider, so an official press release from FiveSight will coincide with the launch of the new site in mid-month.) Considering that my focus is ahead and not back, it was nice to stop for a minute and think about where we've been, what we've accomplished, and all the people (customers, employees, investors, partners, advisors, acquaintances) who deserve thanks for helping us get here. 4:11:28 PM

	Sunday, September 28, 2003

Some Thoughts on StAX This post (and this weblog) has a new home. StAX is a new pull-oriented API for streaming XML that is part of the JCP as JSR-173, and XML.com has an introductory article from Elliotte Rusty Harold. A pull-oriented API allows an application to request events from the underlying parser, while a push-oriented API (e.g., SAX) feeds events to listeners or handlers. Both approaches have advantages and disadvantages. Push-oriented APIs typically require awkward and complex programming patterns to manage state, and pull-oriented APIs typically require big switch statements and if/else blocks. Comments on StAX The StAX specification was recently released for public review, and I had time to kill on a plane ride from the west coast — so I had a look. I'm generically in favor of having an XML pull-parsing API for Java (and XMLPull needed some work and broader support), but I also found a few items worth commenting on: One of the requirements is: R03: When parsing an XML document that uses namespace prefixes, the API must be able to create a new XML document that uses the same namespace prefixes as the original document. And this broken in a subtle way because the only reason for having this requirement is that someone down the chain is depending on the prefix instead of the URI. Some of unsupported items in section 3.1, e.g., the ability to maintain attribute order or the whitespace between attributes, are downright heretical, so while I'm happy to see that they are optional, I'm concerned that they were even considered. There is no reason to clutter a pull API with functionality for round-tripping markup, i.e., functionality that is only useful for a text editor implementation. None of the documented use cases justify the requirement. I'm on the fence with R11: R11: The API must provide the ability to configure the processor to stop a subset of information items from being delivered (for example ProcessingInstructions, Comments & Ignorable Whitespace). APIs should generally steer clear of implementing non-canonical functionality (SAX does a great job.), and R11 violates that rule by specifying functionality that could (i.e., should) be supplied by a trivial filter implementation. (On this subject, the XMLInputFactory class has several superfluous methods, e.g., three createXMLEventReader() methods that all wrap trivial functionality for dealing with InputStreams and Readers.) Ignorable whitespace doesn't make sense, either, given that ignorable whitespace is only determined in the presence of a grammar (i.e., a schema or DTD) but that grammars are out of scope for StAX. R20, which requires a bi-directional mapping to SAX, is a much more reasonable requirement because there is a canonical implementation. For those who don't read the permathreads on xml-dev, XML namespaces is contentious, and two distinct versions of the W3C recommendation exist in practice, the original recommendation from 1999 that states that the xmlns is not bound to any URI and the errata that states that the xmlns prefix is bound to the URI http://www.w3.org/2000/xmlns/. SAX obeys the original recommendation, and DOM (as of L3) follows the errata. (Namespace processing with DOM is a royal mess, and it's easier but still no picnic with SAX either; see Simon St. Laurent's overview for some levelheaded discussion.) Thus, I'm initially confused by: R14: The API must support XML 1.0 and XML Namespaces. While the references only cite the recommendation, Section 4.8.2 suggests that StAX takes the perspective of the errata. The handling of entity replacements as optional (see the list of features) is ill-posed becaues the XMLEventReader interface doesn't provide a way to deal with entity replacements in attribute values. The javax.xml.stream.Location interface needs to specify the numbering of the columns and lines, i.e., starting at one or starting at zero. Do we really need another interface named XMLFilter? Having a couple of ContentHandler interfaces around (one in org.xml.sax and one in java.net is bad enough. The XMLResolver behavior seems awkward. I may just be used to the SAX InputSource behavior, but a single encapsulation with one behavior (instead of an arbitrary series of fallbacks) seems like a better fulfillment of the simplicity requirement from the specification. For general applications, such as streaming XML events from a database query, non-XML markup, or other source, implementers will have to supply their own factory implementations. The NamespaceContext interface assumes that there is a bijective mapping between prefixes and URIs, but that isn't necessarily the case. Thus, the getPrefix() should return an Iterator instead of a String. (Or getPrefixes() and getURIs() methods should be supplied.) There is no per-instance way to set an XMLReporter instance on an XMLEventReader or XMLStreamReader; this has to be done via a method on the XMLInputFactory. The central role for XMLInputFactory with no generic encapsulation for input source (i.e., like org.xml.sax.InputSource) makes the StAX API unattractive or awkward for implementing sources based on input other than XML markup on a byte stream. And now I'm out of time for this plane trip. I feel (only a little) guilty taking cheap shots from the sidelines without making any constructive suggestions, but in addition to seeing at least one more revision of the specification before release, my wishlist would be: Less reinvention. Among other things, use the existing SAX encapsulations, e.g., InputSource and EntityResolver. These encapsulations are already part of the Java world, e.g., in the TrAX APIs. Less markup-centric. Fine-grained control over markup (e.g., entity replacement) is inappropriate for a streaming API; that's the domain of internal parser constructs. Less implementation-think. The API feels like it was extracted from an implementation as opposed to created by an architect with a goal in mind. I'll be watching for the next version. Pull Alternatives The three pull-oriented API alternatives that I'm aware of are: XMLPull, the original pull-parsing API for Java, whose creators sit on the JSR working group; xmliter from Mark Hayes that builds on SAX; and NekoPull from Andy Clark that builds on XNI. 9:31:25 PM

	Thursday, September 18, 2003

More on the Evils of PowerPoint This post (and this weblog) has a new home. John Porcaro has also blogged some appropriate comments about Tufte's groundless debasement of PowerPoint and said some kind things about my suggestions as well. 11:54:40 AM

	Wednesday, September 17, 2003

UML to BPEL This post (and this weblog) has a new home. On Developerworks this week, there is a nice article from Keith Mantell about a mapping from UML to BPEL via XMI. The example BPEL looks like the loan approval example from the specification (section 16.2 as of the 1.1 draft). This provokes some thoughts about the trade-offs of model-driven architecture (MDA) and programming in the large, but that definitely deserves it's own entry. 8:56:35 AM

	Tuesday, September 16, 2003

Made the Move to Mac This post (and this weblog) has a new home. After the hard drive in my otherwise faithful Thinkpad T23 died a couple of weekends ago and the recent rash of Windows viruses, I decided to leave Windows behind and move to Mac OS X running on a 17" PowerBook. (I first resurrected the Thinkpad; see below.) As a NeXT user from 1989-1994 and owner since 1991 (slab, turbo slab, color turbo slab, and a turbo cube at various times), I felt a combination of deja vu and nostalgia when I saw the rainbow-colored spinning disk and recognized the names and sounds of the system beeps from NeXTstep. (It's funny to see the spinning disk still present, considering that almost no one remembers the optical drives from the early NeXT cubes that the image represents.) Now, if only it came in a black magnesium case... So far, I'm impressed: everything is simple, and everything works. For example, Mail doesn't have the vertical preview pane of Outlook2003, but it is multi-threaded (so that I can still edit an email while it runs rules) and includes a reasonably good bayesian SPAM filter. The overall migration from the ThinkPad wasn't difficult at all, in large part thanks to a little tool called Outlook2Mac that took care of exporting my 5 years and 10Gb of Outlook information from Office2003 beta to formats for Mail, iCal, and AddressBook. (Outlook2Mac does not migrate Notes or Tasks, but that's not a big deal considering that it only costs $10.) I simply copied most of my files across a local network connection, and that was it. There are some minor annoyances, and if someone knows better, I'm happy for the correction. The one-button mouse is an anachronism at this point, originally introduced by Apple to ensure that users couldn't push the wrong mouse button. (Seriously, and this was part of the design philosophy that went into the old-school Macintosh. Another example is that no control key and no escape key appear on the old-school Macintosh keyboards in an effort to make computers as friendly, even on a semantic level, as possible.) There is a control key on the PowerBook, which oddly enough is the modifier to get right-click behavior. Keyboard navigation is sorely lacking in terms of use of application menus and super-sufficient in others, since Emacs keybindings for navigation work in most textpanes; I like to be able to do most of my work without taking my hands off of the keyboard. (There may be some way to accomplish this through AppleScript?) The fact that I can't tab onto drop-down controls in web pages is particularly frustrating. Third, there is no docking station available for the PowerBook, and that's a little inconvenient for me since I treat a laptop more like a portable desktop. (The form factor of the 17" makes it comfortable to use as a desktop replacement without a dock.) Note on Hard Drive Failures The best way to deal with a drive failure is to have run a backup recently... Unfortunately, this is usually not the case. The recipe for poor-man's data recovery is: a new 2.5" (laptop) IDE drive, a copy of Ghost (or the equivalent), an extra IDE interface on a desktop machine, some laptop IDE to desktop IDE connectors (like a QVS CC2200), some jumpers so that you can make one of the drives a slave, and several hours of free time. The several hours of free time is necessary for the formatting (low-level) the new drive, integrity checking the old drive, and the disk-to-disk copying process. With the hardware issues in this particular case, the copying process worked but required almost 15 hours to complete. 11:26:20 PM

Web Services Transaction Framework Updated This post (and this weblog) has a new home. An update from the Cover Pages: A revised "Web Services Coordination (WS-Coordination)" specification has been published by Microsoft, BEA, and IBM, together with a new "Web Services Atomic Transaction (WS-AtomicTransaction)" document. The Atomic Transaction coordination type is used when strong isolation is required until a transaction completes. A third "Web Services Business Activity (WS-BusinessActivity)" document will be added to the Web Services Transaction Framework. Pluses include integration of WS-Policy and a focus on WSDL, but I'll continue to hold my breath until there is a specification of a reliable network protocol in a WSDL-suitable form... 10:45:51 PM

	Saturday, August 30, 2003

PowerPoint, the Misunderstood Dictator This post (and this weblog) has a new home. With some talks to prepare, I've been re-thinking the best way to deliver information to an audience. A direct mailing on this very topic grabbed my interest, and in Friday's evening mail, I received my copy of Edward Tufte's essay The Cognitive Style of PowerPoint. Bill Gates != Uncle Joe Tufte makes some good points to puncutate a barrage of discursive hyperbole and unsubstantiated claims, but by and large, he spends more time critiquing the exposition of particular presentations than the thinking that PowerPoint induces in authors and audiences. The mixure of benign exaggeration and invective lurches between misinformation and actual ignorance with To describe a software house is to describe the PowerPoint cognitive style. as the crown jewel. Proscription without prescription is void, and I can find little to take away from the essay other than a generic admonition on argumentation and craftsmanship. I am no fan of PowerPoint or Keynote or their ilk, but when in Rome..., I unquestioningly accepted PowerPoint as a substitute for chalk and slate when I made the transition from academia to the business world. PowerPoint was part of the top-to-bottom swap-out that included Word for Emacs and TeX, Outlook for Mutt, and Windows for Linux and Solaris. More than any other member of the Office suite, PowerPoint is a brand name that has ascended to noun status like BandAid, Xerox, or Kleenex. Before I continue, I should make a few confessions. I have used PowerPoint Phluff (Tufte's term), and I did inhale. I have labored over gradient-shaded backgrounds with embossed company logos, tweaked animated slide transitions, and struggled with the level, number, and content of bulletted items on a slide. PowerPoint in Perspective Like any tool or framework, PowerPoint makes a set of simplifying assumptions intended to aid users in presenting information. Information is delivered in screen-size increments that use one of a number of pre-fabricated layouts or a custom layout that consists of widgets from PowerPoint (text boxes, simple graphics, basic tables and figures) or pasted-in from other applications for more complex items. The speaker performs the primary function of communication in a presentation with the aid of slides, demonstrations, or props as focal points and with notes provided by the speaker and/or taken by the audience for future reference. These focal points should be dense information: the statement of a mathematical theorem, a work of art for discussion, a graphic demonstration of a physical law, or the visual encapsulation of a large set of data. The proper role of PowerPoint in this scheme is underscored by its own terminology, i.e., "slides", and from this perspective, one should rail not at the quality of the narrative in a PowerPoint presentation but at the fact that it contains narrative at all. Sizzle v. Steak and Abuse of PowerPoint Internal corporate communications and external corporate communications (e.g., marketing and sales presentations) are the most common uses of PowerPoint, and PowerPoint provides a host of features for making presentations visually appealing and for conveying branding. While templates, slide transitions, animations, and clip art convey little or no useful information, many presentations are in fact commercials. As such, these presentations are no different than a spokesmodel, "NEW! IMPROVED!", eye-level shelf position, and videos of happy, fish-throwing workers as tools to influence but not necessarily inform an audience. Contrary to Tufte's rhetoric, the software industry deserves no more blame for the applications of PowerPoint presentations than Gutenberg deserves for junk mail. Ensuring uniformity of information delivery is a key to achieving economies of scale in communications in the 21st century, just as division and uniformity of tasks was a key to achieving economies in manufacturing in the early part of the 20th century. Abuse of PowerPoint in corporate communications comes from treating PowerPoint slides as a set of cue cards for the speaker and the audience alike, and the prescription is simple: Keep the cue cards off the screen and the big ideas in front of the audience. Guidlines for Good Presentations Here are a few guidelines for good presentations: Speaker's notes belong in front of the speaker, not in front of the audience. Slides or other visual displays should be used exclusively for dense information or for thesis-level text. Narrative should be interactive and audience-driven in terms of the depth and pace of delivery. Detailed, take-away information should be provided to the audience in the form of notes. 3:56:56 PM