mult.ifario.us

Not like the Paul Simon song. Like Mr. Truism. As Bob blogged, I've thrown my hat in the ring to help raise some funding for the newly formed Codehaus non-profit foundation. The Codehaus itself has been around in various forms since 2003.

The Haus hosts a bunch of recognizable projects. Some of the ones I've found personally useful are Jaxen, XFire, Woodstox, Stomp (:ttmp), and Jetty6. There were issues with the Haus's hardware back in May, and Bob, Ben, and others put in a Herculean effort to get things back to a reasonable state of sanity. (New hosting and bandwidth provided by Contegix are a step in the right direction.)

The goal for the funding is simple — Ensure that the Codehaus continues to be a great place to make software. Less process than Apache, more infrastructure than Sourceforge, and a vibrant community. There are always plenty of people out on the stoop.

OK, Yahoo!, you got my $1.99, but not because I'm a fan of Jessica Simpson's music. Like the vote I cast for John Kerry (i.e., against George Jr.), I'll vote for Jessica Simpson if it's a vote against DRM. So, what's next?

Kids are fascinated by cell phones. Just ask Woz. We regularly let the kid play with our cell phones under the assumption that she can do no harm. The camera is a hit, she regularly surfs around the web, and given enough time, she usually changes the ringtone to something silly. (I like my phone to sound like a phone.) She mostly uses her thumbs, so these are the things that are reachable with random sequences of the buttons on the keypad that are within reach. Even if she did manage to call Timbuktu, I'm willing to pay a couple bucks for a quick and peaceful diaper change.

The other night, she was playing with the phone during a diaper change, and it rang. I answered, and the person on the other end of the phone demanded to know “Who is this?” I responded with something along the lines of “Surely you know, since you called me.” After a couple more exchanges, we recognized each other. He explained that I'd sent him an animated musical valentine, and we all had a good laugh.

With enough poking around, I figured out how she did it. Maybe it's time to get a Leapster. Or maybe it's time for someone to design a phone with a “baby mode” that disables external communications until an unthumbable code is entered.

I always referred to shareholders as “investors”, but that can give someone the illusion that the private company securities that they hold are in some way similar to publicly-traded securities — which they are not. Unlike publicly-traded securities, shares of a private company are converted to cash on exit and only on exit, so a shareholder should favor activities that promote exit and enhance value.

Ideally, then, current shareholders would welcome a new round of funding. Dilution will occur, but if things work properly, then the combination of owning a smaller portion of a more valuable entity works out in the shareholders' favor. Even if the value computation is slightly unfavorable, if the investment would enhance the expected gain, i.e., the value weighted by the probability of an exit. If new capital comes with changes of control structure, liquidation preferences, registration rights, participation rights, etc., that all contributes to the expected gain computation. This is especially true if the business needs the capital, in which case the expected gain computation can be reduced to the simple question “Is expected value non-zero without the money?” “Need” is a strong word, and a need for capital never arises instantaneously. It is up to the Board and the shareholders (to a much lesser extent) to demand creativity and stewardship of capital from the management team on an ongoing basis and not just when the needle hits “E”.

Jon is writing simple text in full screen, and Cedric's trying (really) to get comfortable with managing windows on Mac OS. Merlin Mann has been regularly riffing about simplifying window management and increasing focus by getting away from multiple open apps. Little bits of chrome and a few icons aren't that distracting for me, so I'm happy with my version of simple text in full screen, which is Aquamacs with a nice theme and all other applications hidden. (WriteRoom apparently doesn't work on two-headed environments anyway, as it only blacks-out the primary display.)

Being disciplined about keeping non-foreground apps hidden is key. If I want a different application, I hide the one I'm working in (CMD-h), call-up Quicksilver (ALT-ALT), and type the name of the application that I want to either un-hide or start. To paraphrase Bob Marley, no mousin', no cry. As the screenshot suggests, that means that my extra display is little more than a fancy picture frame a good amount of the time, although it's quite useful for reference material in a browser or PDF viewer if I'm writing code (as opposed to prose).

On the topic of multiple monitors, via Lifehacker, an article in the New York Times about multi-monitor setups:

Survey after survey shows that whether you measure your productivity in facts researched, alien spaceships vaporized, or articles written, adding an extra monitor will give your output a considerable boost — 20 percent to 30 percent, according to a survey by Jon Peddie Research.

The actual study cites a 42% average increase in productivity, and I have to say that I'm incredulous but not sufficiently curious to pay for the report.

LtU carried an announcement of a paper from Martin Odersky and Phillipp Haller at EPFL called “Event-Based Programming without Inversion of Control”. To quote a snippet:

The central idea is as follows: An actor that waits in a receive statement is not represented by a blocked thread but by a closure that captures the rest of the actors computation. The closure is executed once a message is set to the actor that matches one of the message patterns specified in the receive. The executing closure is “piggy-backed” on the thread of the sender. If the receiving closure terminates, control is returned to the sender as if a procedure returns. If the receiving closure blocks in a second receive, control is returned to the sender by throwing a special exception that unwinds the receiver's call stack.

Scala has had actors in the form of scala.concurrent.Actor since version 1.x, but as extensions of java.lang.Thread they are thread-dependent. Thread-dependent means that a Scala Actor might be preferable to a Java Thread for semantic reasons but that there is no performance advantage. (In fact, a benchmark in the paper shows that it's a disadvantage, but semantics are often more important than raw performance.)

The PXE BPEL engine relies on a little-publicized Java-based actor framework called JaCOb (short for “Java Concurrent Objects”) that makes some different choices than Martin and Phillipp did but that is ultimately based on hooking closures to model the receipt of messages in the future. For a quick tour of JaCOb, there's either the source code or a detailed tutorial written by Matthieu Riou on the Apache Ode incubation wiki.) For one, JaCOb's syntax would be cleaner in Scala, as Java lacks delegates. JaCOb does not use exceptions to break the stack but instead relies on passing communication channels. (Using exceptions for control flow is generally regarded as a bad thing to do. In addition to the philosophical reasons, throwing an exception is involved and, depending on the JVM implementation (e.g., implementing exceptions as signals), can be expensive.) JaCOb doesn't include explicit support for distributed operation as Martin and Phillipp describe for their framework, but a suitable flavor of JaCOb's soup could be implemented.

I'm looking forward to checking out the event-based approach from Martin and Phillipp when it comes out with Scala 2.1.7, and in the meantime, I should finish up the JaCOb tutorial that's been mouldering on my to-do list.

The classic parable of the blind men and the elephant applies to some recent proclamations about BPEL and BPMN (and about BPM and SOA, for that matter) being at odds, and there is long line of blind men waiting to take their crack at sizing-up the BPM elephant. I started out believe that the elephant is defined by its back end, the execution aspects, and that's where FiveSight developed a specialty. Nonetheless, customers (who wanted to ride on the elephant) educated me about its other properties, and combined with the expectation that standards would help define the parts of the BPM animal, the breadth of customer expectations is one of the things that drove our specialization. In 2003, we set out to build the “best back-end in the business”, gave it the code name “JLo”, and took an OEM stance. (Note to any entrepreneurs in the audience — Either you are an elephant vendor or your customers are the elephant vendors. The middle ground is not populated by successful businesses.)

I still recall a customer encounter (probably from 2002) for FiveSight's BPM-ish product that predated our BPEL effort. A customer was interested in an email widget to mass-mail customers. (Never mind that mass emailing requires more than a bit of art in dealing uniformly with bounces, proper MIME enveloping for correct viewing by different clients, delivery throttling by large email account providers, etc.) We built one more or less blind that wrapped up some of the usual JavaMail functionality and took a string as input for the body. We showed it to the customer, including a sidebar about how easy it was to implement the widget complete with a code sample (“Even your IT staff could do it, Ms. Customer!” <wink wink>). The business analyst spoke up and asked “Can it do RTF editing? We'd like to have consistent branding with a logo and specific fonts.” Ummm, yeah...

Aside: Once upon a time, on a trip to Japan, I met someone whose title was actually “Business Analyst”. I was tempted to frame his card.

The point of the story is that there are modeling aspects and execution aspects to a process, and they are closely related but not equivalent. BPMN is a modeling notation for describing processes in business terms. BPEL is a service orchestration language for combining services that was designed specifically for a WSDL-based SOA. It is possible, by design but not without effort, to generate orchestration language artifacts from modeling notation artifacts. One could observe that if nothing below the model mattered, then the orchestration language is irrelevant, and that would be true if the processes lived in a closed, black box. But that's so BPM 0.9 — vendors should know better than to imagine that they can shoehorn their customers into an architectural stovepipe when there are other alternatives available.

Agility requires degrees of freedom, and the combination of BPMN and BPEL to bind the higher-level modeling aspects of BPM onto SOA provides two important degrees of freedom. First, the modeling tool is decoupled from the execution environment. (Note that a good backmapping from the BPEL to BPMN is important, but that's a property of the mapping used.) Second, the processes are first-class citizens of a service-oriented architecture, fueling use and reuse outside of the context of the modeling environment.