mult.ifario.us

I've been taking the bus to work, and if I haven't charged my PowerBook or am forced to stand, this gives me time to ponder imponderables, like how much does Superman eat?

If the comics are to be taken at face value, Superman can do things like lift buses over his head and fly at great rates of speed. Buses are heavy, so lifting one would take a lot of energy. A calorie consumption benchmark says that 10 minutes of "vigorous" weightlifting burns around 120 calories for a 250 pound human. Just for the sake of argument, let's say that 10 minutes means five sets of 10 repetitions of clean-and-jerk at 180 pounds, so that's about 9,000 cleaned-and-jerked pounds per 120 calories or 75 cleaned-and-jerked pounds per calorie. Lifting a (40-foot, diesel, unoccupied) 40,000 pound bus burns around 533 calories or just about exactly one Big Mac.

So, my unscientific answer would be that Superman eats... a lot.

Matt Asay made a post about work/life balance that brought to mind a random thought about the pants of tomorrow. (Kind of like the House of Tomorrow, but pants.) Many science fiction views of the future have humans evolving into cerebral creatures with big brains, but my view is different — we'll evolve bigger and bigger backsides for sitting on...

When my wife and I visited Kyoto a few years ago, we stopped at Niji-Jo, a 17th Century castle built by the first Tokugawa Shugun. Part of the castle has "Uguisu-Bari" of "Nightingale Floors" — wood floors specifically designed to squeak with every step, ensuring that no one could sneak up on the Shogun without alerting his bodyguards.

I don't think that the floors in our 1911 house here in Seattle were necessarily designed with the same goal in mind, but they do seem to serve the purpose of alerting the Shogun to our activities in the dead of night...

The initial migration (and a subsequent upgrade from 2.6.0 to svn trunk) was pretty much painless, but the database migration didn't take care of mapping permalinks or date queries from the WordPress scheme to the typo scheme. Enter a little mod_rewrite and Ruby (at which I'm a newbie).

The first step is to grab the query string on the old server, e.g., to grab the WordPress-style permalink:

http://oldblog/?p=69

to a new entry point in typo like:

http://newblog/wp/69

the required bit of mod_rewrite script is:

RewriteCond %{QUERY_STRING} p=([^&;]+)
RewriteRule ^/$ http://newblog/wp/%1? [R=301,L]

(The trailing ? drops the query string in the redirected URL, and back references use the % in place of the $.) The 301 response code is "moved permanently", so well-behaved clients should get the idea. The same technique applies to the query string-defined syndication protocols that WordPress uses for the RSS and Atom feeds.

The next bit of work in Ruby is a bit painful because of the way that the database migration script maps the IDs. (If I was in the mood, I could have modified the migration script to dump an id cross-references, but I wasn't and didn't.) The first piece is a new route in config/routes.rb:

map.connect 'wp/:wpid',
  :controller => 'articles', :action => 'wp'

And then a bit of Ruby in app/controllers/articles_controller.rb:

def wp
  begin
    wpid = params[:wpid].to_i
    case wpid
      when (109..109) then wpid = 97
      when (100..101) then wpid -= 15
      # etc.
    end
    # imitate the "read" method here...
  end

And that should do it. (So far, the most difficult part of Ruby is not typing a ; at the end of a line...)

On December 6, Intalio announced that it acquired FiveSight, the company that I founded in 1999 and then led through six years of ups and downs.

SteveShu has a few comments on the FiveSight experience. (Steve has always been too humble for his own good; he was a vital member of the team from the moment he joined and played a key role in every win that the company had, including our relationship with Union Pacific and our distribution partner in Japan.) I can still remember Steve's first day on November 6, 2000. He showed up at my apartment in Chicago, and we went over FiveSight's "books" (an Excel sheet) at the kitchen table. That was just before FiveSight kicked-off in earnest with the original crew of six in a big loft in downtown Chicago, complete with a coffee maker, a pool table, and a fish tank.

Looking back, I like to think of FiveSight like a piece of software. We had a pretty good v1.0 release with a good product and some great customers, all driven by the moxie to turn minimal funding and maximal ambition into a going concern. FiveSight v1.0 won awards for rapid growth (426% for 2002, not half bad...) from Deloitte & Touche and the Chicago Software Association. We hit growing pains in 2003, trying to get over the $3M/year revenue hump against an increasingly competitive Java EAI market and the IT spending doldrums that followed the bubble burst and the 9/11 attack.

PXE was FiveSight's v2.0 business. We took stock in the middle of 2003, ramped-down FiveSight v1.0, and decided to bet on BPEL as a standard that would decouple design and protocols from execution. The first version of the BPM component for our previous platform morphed into Maciej's elegant design for the PXE execution core, and we were off to the races with an OEM-focused strategy that emphasized our strengths in low-level Java and high-level, targeted sales focused on the build/buy proposition. (I picked Sleepycat (for their OEM business) and Zope (for their community) as businesses to emulate, but I also started with the assumption that the market for BPEL execution and the overall market context would be completely different — FiveSight v2.0 would have to find its own way.) Open source was part of the thinking from the beginning but not part of the public strategy until June of 2005, when we posted PXE as open source to accompany SUN's tooling demo at JavaOne.

I'll be watching Intalio's progress from my seat on the sidelines, but more on that later.

Never use the same communications channel to both handle load and send management information or control.

Here are two instances of the Nagging Nanny Management Antipattern in action, one with MQSeries and one with Ruby on Rails.

What do you get when you cross queues and topics? In the olden days of FiveSight (like 2000), we had an integration server product that made it relatively easy to hook JMS queues (and other sources of "messages" like directories, sockets, etc.) to business logic. (Think of it as an early approximation to something like Mule or ServiceMix.) The first incarnation of product the used JMS topics to transmit management messages (like "pause", "stop", "deploy") from a management console to one or more remote servers. This was all well and good until our first MQSeries deployment (5.1, I think; more ancient history), and at the time, MQSeries simulated topics on top of its queues. The result was that a heavily-loaded server would be unable to respond to management messages buried amongst thousands of other messages running through the same queue manager. We refactored the design to use a separate communication pathway for management messages, and things worked as intended.

Are you busy? Some folks were making a similar mistake managing web server instances at TextDrive recently. A good number of users were using an innocuous looking nanny script to ensure that their instances of lighttpd/RoR were up and running. However, note that the nanny script asks the server how it's doing by sending a request:

/usr/local/bin/curl -I http://YOURDOMAIN.com:YOURPORT

Thus, if the request times out because the server's loaded down and unresponsive, the nanny script will bounce it, making the problem worse. Some further complications with not cleaning up resources spawned by the killed lighttpd instances made it even more fun.

Steve Shu's entry about cockroaches got me thinking about the flip side of being resourceful and resilient — failure. It's a shame that failure and mistakes have such a negative connotation, because neither need be negative.

I've been meaning to blog about failure as a necessary part of entrepreneurship and a skill to master. The mythology of entrepreneurship is full of people whose "sticktuitiveness" sees them through in the end. Sorry if you just bought a bunch of Horatio Alger books, but that's bu115h!t— more likely than not, those people were continuously questioning their intuition, making subtle adjustments, learning from the mistakes of others, abandoning non-working ideas, and building new relationships. Or they were simply in the right place at the right time. (Maybe that "or" should be an "and"...)

Not being willing to fail is a curse for the clever. Clever folk aren't used to failing as a natural occurrence, since the contrived educational system only puts solvable problems in front of students. Worse, they're usually clever enough to figure out to how to stay afloat in difficult seas when sinking and starting over might be a shorter path to success.

Note that I'm not advocating giving up easily or failing spectacularly. Rather, I'm advocating failure in small, frequent, and controlled doses as means of iterating toward a successful outcome.