I’m sitting in Erik Hatcher’s JUnit talk at the Lone Star Software Symposium. Via Rendezvous and iChat, Daniel Steinberg messages me from the other side of the room: “Have you worked with CruiseControl?”
I sent back that Mike Clark had written about CruiseControl and an alternative, AntHill, earlier in the week. “I’m on it,” Daniel replied. As I was looking up Mike’s blog entry, I noticed that Erik was the one who told Mike about AntHill.
What I didn’t know was that AntHill was written by another guy we know, Maciej Zawadzki. Also unbeknownst to me, Maciej was sitting behind me. And later in the talk, Erik got around to mentioning both CruiseControl and AntHill. Fun.
Last night during the panel session at the Lone Star Software Symposium, nobody was surprised that an audience member brought up the infamous Pet Store benchmark. None of the panelists thought much of it as a useful or accurate benchmark, for a lot of good reasons.
One part of the discussion centered on the decision to build each version of the pet store according to the vendor’s recommended “best practices”. This resulted is that neither version of the app has an architecture I would recommend to clients—but more importantly, the .NET application is optimized for raw performance, while the J2EE application is aimed more at flexibility, maintainability, and robustness.
Jason Hunter had a really nice suggestion for the next round: instead of measuring the performance of the things, let’s set up two development teams, one for each version of the application, neither of them having seen the code before. Give them new features to implement, and see how long it takes. Given the existing code quality (poor) and some of the choices made in the J2EE version, it still wouldn’t be a really representative test. But it would at least be interesting, which is more than you can say about the original.
I’m a blissful Mac OS X user when I have my way, but I have a Windows 2000 machine on my desk at my current client, and they use Outlook for email.
A few minutes ago, I heard the voice of a coworker over the cubicle wall: “You’ll love this picture I just sent you.” I kept typing away on the document I was writing, and about 10 seconds later Outlook—sitting quietly in the background, behind Word—crashed. I didn’t open the message, or even click on Outlook. Fetching the message from the server was enough to make it crash.
Restart Outlook. Now I can’t log into the Exchange server. No more mail for me!
(And of course, the answer to all mysterious problems on Windows is to reboot, which is why I have time to write this blog entry.)
This morning, as usual, I listened to Morning Edition on the way to work. Bob Edwards was interviewing a Norwegian singer named Sissel about the release of her first U.S. album. Sissel has sold a lot of albums in Europe, but is virtually unknown here. (Selling a lot of albums doesn’t necessarily impress me, but touring with The Chieftains does, and what I heard of her music this morning sounded pleasantly accomplished and eclectic.)
She spoke about one of the songs on her album, “Lær Meg Å Kjenne,” which is an old Norwegian hymn. Translated, the title means “Teach me to see your pathways.” The story behind the hymn is of a man coming home from a pilgrimage to find his house burned down and his family killed. He falls to his knees, and the hymn is his prayer.
Bob Edwards said, “And you sang this at a wedding?”
Sissel replied, “Well, yes—it’s a song of trust, of knowing that there’s a plan.”
From what I heard of the song, I’m with Sissel. A wedding is joyful, of course, but the joy comes from the binding of two lives together, as much to stand by each other through the hard times as to share the joys of the good times. In a ceremony that contains the words “for better or for worse, for richer or for poorer, in sickness and in health, ‘til death do us part,” a song like “Lær Meg Å Kjenne” has a place.
There’s an English hymn with a similar history. In 1873, Horatio G. Spafford received word that his family had been lost in a shipwreck. His response? The magnificent hymn “It Is Well With My Soul.” There is certainly sadness in it, but also calm assurance, as well as triumphant joy:
My sin—oh, the bliss of this glorious thought—
My sin, not in part, but the whole
Is nailed to the cross, and I bear it no more.
Praise the Lord! Praise the Lord, oh, my soul!
It’s no surprise that poor marketing can really hurt a product. Today I saw a perfect example of how too much marketing can hurt a product.
I’ve known about JMX for at least three years—probably four. Several times in the past few years, I’ve had a few minutes of spare time, and gone to check out JMX. What did I find? Marketing-speak. Too much hype, too many claims, not enough technical substance for me to understand what JMX really was. In each case, I came away wondering if there was really any there there.
I have a background in system and network management software, so it’s not like JMX should be difficult for me to understand. But the overview documentation was always too fluffy to tell me anything in the short bits of time I had available, and I didn’t have time to go dig into the spec. So I always came away unconvinced. I was nearly convinced that there really wasn’t anything worthwhile in JMX when all of a sudden I started hearing the JBoss folks raving about JMX. That piqued my interest again, because those guys are very smart.
I’m at the Great Lakes Software Symposium this weekend, and Oliver Schmelzle of Covasoft gave me a short overview of JMX. I got it in about three slides. It’s simple. Extremely simple. And it’s real, and it’s useful, and I can see why JBoss is using it.
The really frustrating thing about the JMX marketing fluff is that the people who are likely to grasp and recommend the use of JMX are techies—the kind of people who respond to example code and scenarios, not extravagant claims. Oliver agreed with me that JMX’s big problem is that most of the people who should be interested in it don’t get it. And the reason is because it’s been marketed nearly to death.