The whole experience was rather anti-climactic. In the end the bridge is just a bridge and the tunnel is just a tunnel - a rather Spartan drab tunnel at that. Given the cost one might expect some gold plate.

When we stopped to visit down town Boston I was surprised to see workers already taking down the old elevated central artery.

In retrospect I guess its probably one of the easiest tasks of the whole project.

I read someplace recently that city folk are now worried that all the pigeons who made their home under the elevated road will now invade the city. They had similar worries about rats when the project began.

I too have done some painting, drawing and sculpting. I'm not a trained artist, but have dabbled for relaxation and fun. I've never recorded any of it digitially before but it seemed like a cool idea. I've added a top level information category called Art that contains an image gallary of my current scans. All of these images are of things I created in the 80s.

I've used the PHP based photo album software called Quick Digital Image Gallary as the hosting engine.

My camera is a snazzy little Casio Exilim EX-Z3. 3.2 megapixel, SD card, 3x optical zoom.

True Companion or T.C. as he was known died yesterday from lethal injection after a short battle with cancer. T.C. was 10 years old.

A pure bred Siberian Husky, T.C, exhibited all the standard personality traits of the breed - strong willed, energetic, friendly and very vocal. In fact, his howls contained so many different tones you could swear there a language contained within.

He will be missed.

I have to admit a certain fondness for Wagnerian music and German culture in general. If you're not familiar with the Ring Cycle, this link has a good overview of the story: Der Ring Des Nibelungen.

As I think about this and the lessons it implies about software, I can't help but think of EJBs as the big bloated Zeppelins of our day. I'll show you what I mean by considering a few of the points of the article in the context of EJBS

High Unit Cost -- Complexity of building high quality EJB.
Narrow Design Base -- Design being driven by a few corporate interests
Narrow Contractor Base -- Expensive and complicated licensing
Mammoth Ground Support Equipment -- Expensive infrastructure requirements
Inappropriate Traditions -- Warmed over CORBA
Low Safety Factors -- 88.888 up time
The Publicity Spotlight -- J2EE hype machine
Fanatical Promoters -- Corporate hype machines

Today I had a few minutes and wanted to learn more about how the tree syntax mechanism works. What I found was surprisingly simple and elegant. Instead of this feature being a special part of the language, it's just a cool use of the core Groovy features. Imagine code like this.

builder = NodeBuilder.newInstance();
builder.people() {
     person("Pete");
     person("Jayne");
} 

The block

{ 
person("Pete");
person("Jayne");
}

 
protected createTree() {       
    builder = NodeBuilder.newInstance()
        
    root = builder.people() {
        person('James') {
            location('London')
            projects {
                project('geronimo')
            }
        }
        person('Bob') {
             location('Atlanta')
             projects {
                 project('drools')
                 project('jessy')
             }
        }
    }
    return root;
}

tree = createTree()
s = tree.person.find { 
    it.projects.project.any {
        return it.value() == 'jessy'
    }; 
}

person[attributes={}; value=[Bob, location[attributes={}; value=Atlanta], 
projects[attributes={};value=[project[attributes={}; value=drools], 
project[attributes={}; value=jessy]]]]]

19. A language that doesn't affect the way you think about programming, is not worth knowing.

31. Simplicity does not precede complexity, but follows it.

58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

95. Don't have good ideas if you aren't willing to be responsible for them.

104. The proof of a system's value is its existence.

This isn't just a J2EE issue either, other code can have layering designs that change the sort of exceptions that are thrown but not the basic signature of the methods. (Its just such code I'm dealing with today at work that's sparking this rant). What I'm dreaming of is support of some sort of generic exception declarations in an interface. Rather than always declaring the throws I would like to be able declare an exception agnostic interface and then derive exception explicit variations from that base version. Here's an example in my dream pseudo Java:

A simple generic interface class with no explicit throws

public abstract interface  AbstractFoo {
    void methodOne() throws *;
    void methodTwo() throws *;
}

public interface Foo extends AbstractFoo throws SomeException {
}

public interface FooRemote extends AbstractFoo 
    throws SomeException, RemoteException {
}

h = new MarkupBuilder() 
h.html() {
    head() { 
        title("Page Title")
    } 
    body(){ 
         
        h1("Hello World")
        div(id:'Foo') { 
            div("Content") 
        }
    }
}

<html>
<head><title>Page Title</title></head>
<body>
<h1>Hello World</h1>
<div id='Foo'><div>Content</div></div></body>
</html>

h = new MarkupBuilder() 
h.html() {
    head() { 
        title("Page Title")
    } 
    body(){
         
        for (x in ["World", "Pete", "Bob"]) {
            h1("Hello "+x)
        }
        div(id:'Foo') { 
            div("Content") 
        }
    }
}

>>> println( listOfPeople.findAll { it.location == 'UK'}.name );
["James"]

The Columbiad company will send you into space for only $12,500. Catch is you must be dead.

You have to love their logo - a flying urn. They have a pretty website too.

In keeping with the holiday season I wanted to share this information on one of the odder and funnier Christmas traditions I've ever heard of- the Caganer. The Caganers was originally brought to my attention many years ago by an entry in memepool.com but the links that post contains are now dead. I thought it was interesting enough I wanted to bring it back again.

The tradition of the Caganer comes to us from the region of Spain known as Catalan. The Caganer is a figurine that's typically added to Nativity displays to bring good luck. The odd thing is that figurine is depicted defecating or "paying the ground" as one maker of the figurines described it. (That's a nice earthy euphemism)

The e-shop Caganer.com has quite a collection of figurines if you're interested.

1. Common implementations of an abstract type.

Using interfaces in an API instead of classes is usually a good idea but it adds a level of indirection. You can compensate by using inner classes to make your API a little easier. Let's say you have a class and a related interface like this:

public interface Value {
   int getIntValue();
   String getStringValue();
}

public class Foo {
   public  void doit(Value v) {....}
}

public interface Value {
   int getIntValue();
   String getStringValue();

    public static class StringVersion implements Value{
         private String _s;
        public StringVersion(String s) {
             _s = s;'
        }
        public int getIntValue() {
             return Integer.parseInt(_s);
        }
        public int getStringValue() {
             return _s;
        }
    }
}

2. Exception hierarchies

Exception hierarchies are all over the place in the core Java libraries but its rather hard to keep track of the associations without following all the links in Javadoc. I think using this method of child Exceptions being declared as inner classes or the root exception keeps things simpler and easier to maintain.

public class NetworkException extends Exception {

    ....

    public static class Bind extends NetworkException {

        public Bind() {
             super("Bind Error.....");
        }
    }

    public static class Host extends NetworkException {

        public Bind() {
             super("Host Error....");
        }
    }

}

     ....
     throw new Bind.NetworkException();
     ....

Bundling associated parameters into a class or interface is a often a good idea. It allows you to modify the parameters of the method without always needing to find and modify every instance of every call. Rather than create a new top level class or interface for such a construct, use an inner class (or interface) instead.

public class Foo {
   public static class Params {
  }
   
  public Foo() {
  }

  public void method(Foo.Params params) {
  }
}

Radiation, yes indeed! You hear the most outrageous lies about it. Half-baked goggle-boxed do-gooders telling everybody it’s bad for you. Pernicious nonsense! Everybody could stand a hundred chest X-rays a year. They ought to have 'em too.