thinking-out-loud

iPod product box - MS style

This is a fantastic paradoy of what the iPod Product Box would look like if Microsft had desigend it. 

Now, as true and funny and truely funny as the parody is, I have to say that I like the User Experience improvements going on with the MS server products.  SQL Server 2005, Team Foundation Server, and the new Office System 2007 Server Components are greatly improved from a UI point of view.  And I think the product boxes are better, too.

Avoiding pass-by-ref

I've been working (along with Jef) on a project in Java as of late.  Today I received a question from the client on passing object references by ref.  Turns out that it can't be done in Java - and that's a good thing. 

A couple of months ago I converted some VB.Net code to C# with a utility that didn't do a very good job of converting the "ByRef" parms.  I had to go through and fix them by hand.  In the end, I couldn't stand the CRAPPY code design that required the "ByRef" in VB and "ref" qualilfier in C#.  Today I went looking for an equivalent in Java and came across this nice article.  The last section is the best - how to avoid using multiple return values.

Always amazed

One of the things that always either amazes or amuses me, but of which I never tire, is when I recognize a solution pattern being reapplied at different levels of abstraction. For instance, I was reading Paul Graham's essay on stopping spam, and it occurred to me that Challenge-Response filtering is similar to the role of queues in the tcp stack of [at least] Solaris. Solaris has two queues up in front for incoming connections, the incomplete connection queue, and the completed connection queue. The first is a primary buffer against denial of service attacks. This requirement that the client complete the three-way handshake is very similar to the challenge-response filtering.

SSL/TLS is another place that I think is ripe for the harvest, especially in the realm of web services protocol design. The TLS protocol has a handshake in which both sides negotiate algorithms, secret keys, and the like, somewhat like dogs sniffing butts. This is analogous to the ws-metadataexchange, policy, etc, handshakes that are inevitably going to be a part of soap service life in the future. Of course, Pareto would tell you that 80% of the time, none of that would likely be necessary, and simple xml over http will do. But if you're in that other 20%, you might want to read the TLS spec, and also look into some of the holes that were found and plugged, etc. Those are likely analogs to ws-splat in some manner.

Standardization ain't innovation

Tim Bray has an interesting perspective on the Atom specs. The key sentence in the post, to me, is:

<blockquote>Ever since then, I’ve been convinced that standards organizations shouldn’t try to invent technology. </blockquote>

Right on. Don't invent standards, standardize inventions. In a similar vein, don't document patterns until they are seen at least three times in the wild, and capture the intersection of the appearances, and the unions only as variations, if even that.

Inject Dependencies Here

I dedicate this message to all of the singleton users everywhere. May your singletons be gasping their last breath.

Many, many moons ago, component-based development was born. And with components came containers.

And the age old riddle was born: "Which came first, the component or the container?"

Time wakes from a nap... water trickles from the leaf of an old, wise tree.

Many, many moons ago, Microsoft created MTS as a better way of managing COM on the server side.
Sun plaigarized it, making some things marginally better (e.g. message driven beans are marginally cleaner than queued components)
and many things dramatically worse (entity beans, anyone?). Ah the good old days. The container meme spread.

Space stretches and yawns...

Many moon ago, the Apache group gave birth to the Avalon Framework as a kinder, gentler container technology. And it evolved and grew. And it talked about the "Inversion of Control (IoC)" pattern. And there was wailing and gnashing of teeth, for the name hinted at ideas long ago codified in the venerable GoF (hollywood principle/template pattern/dependency inversion, anyone?).

Time sneaks up, slaps Space firmly on the backside, "Adopted Dimension, Adopted Dimension" and takes off running, maniacal laughter in the air.

IoC containers start popping up on every street corner, like so many hotdog stands. Pico, Nano, parts of Spring, XWork.

A few moons ago, Martin Fowler got fed up with it and wrote an article explaining IoC and renaming it "Dependency Injection," to help with the confusion. IoC is a cooler abbreviation than DI, but the teeth are less gnashed, and so the veneers may safely be avoided.

The extra dimensions remained curled in their ball off in the corner, secretly plotting an attack down the Tau axis.

In the Microsoft camp, things were relatively silent. A moon passed, then another. Two more, and then the urban potato cleared his throat and spoke up, saying, "eh hmmm, excuse me. I would like to show you System.ComponentModel":

A moon passed. Space said, "Look, I'm tired, and besides, South Park is coming on." Time relented.

And Daniel Cazzu, MS XML MVP extraordinaire, followed up, tying the knot between System.ComponentModel and DI, so to speak.

Robert Martin wrote about this notion when the ether floated above the water (summer, 96?)

Obtaining Consensus

Jared M. Spool of User Interface Engineering Fame published a new article today on the K-J technique, a prioritization/consensus technique.

Some of the biggest hurdles to enterprise architecture in general and service-oriented architecture in particular are gaining buy-in and establishing priorities to scope incremental releases (Down with Big Bang). As you adopt a service-oriented architecture, if you start to recognize that you are struggling with priorities or consensus, try it out. Heck, try it out even if you don't recognize that you are struggling.