Personal best practises

Joe Walnes has a very interesting diagram of his personal best practises:

I wish I had the time to draw things like this. ;-)

UPDATE: I mistyped Joe's name for some reason. Sorry about that!

Services and asynchronous message-passing style

An interesting short essay from Manageability: Loose Coupling and its connection to Robustness.

Brick Science

American Digest points out an amusing essay on the crapulence of some neer-do-well coders. Sadly, I encounter these people all the time.

I was fortunate to never have completed a course in Computer Science while at Rice. On the other hand, I was also very unfortunate as Rice has a truly fine department and I would have loved the chance to study programming languages or computer security from true experts. But I was fortunate as I learned how to write programs the old-fashioned way: by studying the code of masters and reading the right books. I had many friends who were excellent programmers, and they put me on the right course with things like the dragon book for compilers, Knuth for algorighms, or the ARM for C++. (No kidding — I learned C++ from the ARM and couldn't figure out why the compilers I tried out didn't seem to implement quite the same language as what I read. It was very eye-opening about what was right v. what was right now.) I learned Linux from the sources and studied good operating system programming from Lions. They both taught me how disgusting and unneccessary most software bloat is, and how a simple implementation is a thing of beauty.

Of late I've learned Java and its companions and become steeped in its culture, and discovered that JUnit is the best of the lot. I'll be happy to return to greener pastures, but for now I'll be satisfied simple with greenbacks for my troubles. I also learned that bird in hand isn't to be sneezed at; I can mix metaphors as well as languages.

Cool AspectJ trick

A nice trick for magically transforming new Fred() into something else from Brian McCallilster. In C++ I would provide a custom new operator, but AspectJ offers another interesting option. Too bad there are no destructors in Java.

The request, the session and the form

Struts sucks. Just kidding. Actually, struts really sucks. But it's better than nothing, and it's available everywhere, so like Microsoft Windows, it's the default bolt-on for J2EE webapps in spite of its short comings. And unlike Windows, it is open and free.

Complaints aside, I've been trying out three ways of passing data from an action to the corresponding controller:

Use the request

This is very sensible, but was not the initial approach in my current project. In the action stash the data as an attribute on the request, and fetch it back out in the controller. To ensure type safety, use wrapper methods and manifest constants (e.g., setFooId(Long) to set the FOO_ID attribute).

Use the session

This is similar to using the request, and was the initial approach in my current project, but leaves garbage littered about and occassionally tricks code into using an old value from a previous request. Avoid. I'm working on moving session-based code to request-based code as I encounter it.

Use the form

This is the most interesting choice. On the surface, the controller has no form to use, only the action has one. But the form is stored as an attribute in the request, and you can fetch it back out if only you know the key for it. Struts uses the name field of the form bean from struts-config.xml as the attribute name. This is nice if you know the name, but fragile if you ever change it. Better would be to take your action mapping, and use that to get at the form bean name. If this works, this would be the best choice of all.

Ah, but just how does one get at the action mapping from inside a controller? That is the question I am presently working on. One way is to use the request processor to give you the action mapping, but I don't know how to get the request processor. More research awaits.

tearDown()

What's the right way to use tearDown() in JUnit tests? I spent an afternoon fixing all the places in our codebase where programmer's had forgotten to call super.setUp() and super.tearDown(), respectively, in their own setUp() and tearDown(). To prevent this in the future, I changed BaseTestCase, our in-house extension of JUnit's TestCase, to catch this in the future when running tests: setUp() and tearDown() in BaseTestCase set flags when run, and I overrode runBare() to check for these flags. Voila!

But Paul Holser, a fellow ThoughtWorker on the project, pointed out that tearDown() should also be recoded. Usually everyone writes:

    protected void tearDown() throws Exception {
        // do your tear down here
        super.tearDown();
    }

But Paul suggests instead:

    protected void tearDown() throws Exception {
        try {
            // do your tear down here
        } finally {
            super.tearDown();
        }
    }

I think Paul is correct, but that means I need to go back and fix up some 50 spots and delay working on functionality. Is it worth the extra work?

AspectJ and IoC

Brian McCallister asks an intersting question:

Speaking of AOP -- a problem we have not found a good solution for is using an IoC container with AspectJ. You have no control over how aspects are instantiated at runtime, so you cannot exactly obtain them from a container.

The best we have come up with so far is to provide a static service lookup component that can provide the container to the aspect via a lookup. Yuck, completely breaks the point of the container. Static lookup to obtain a container and then use it to lookup components... far from ideal.

In cases where we've used proxy based AOP the container isn't a problem, but I find myself, and others at the company I work for, leaning more and more towards AspectJ from proxy based options.

Anyone have any ideas?

I wonder if any of my fellow ThoughtWorkers involved in these technologies have a solution?

Related to these, is a great new book I just got, Generative Programming by Czarnecki and Eisenecker. I especially appreciate the illustration of how flexible and forward-looking is C++ which this tome presents. And using Smalltalk to discuss metaobject protocols is very slick also. Too bad there isn't much Lisp. :-)

The Linux desktop

Merrick Schincariol has some excellent thoughts on the Linux desktop. And he should checkout KDE3. :-)