Jason Zhicheng Li has written a blog article about Spring configuration. It is called the 12 Best Practices for Spring configuration. Best practice #1 was “don’t use autowiring*. That got me thinking: I feel very ambivalent about autowiring. Initially, I thought it sounded like a great idea because it reduced clutter, but then people like Jason convinced me that it was not. The more I think about it, the more usure I am.

Joel Spolsky had a blog entry seems eerily familiar: The Architecture Astronauts (in outer space) I’m starting to see a new round of pure architecture astronautics: meaningless stringing-together of new economy buzzwords in an attempt to sound erudite. I’ve seen the type, and I’m glad to say that we haven’t got any of those around. A bad architect can cause enormous damage.

I just got published last week: My article Unit Testing Hibernate Mapping Configurations was last week’s featured article in java.net. This is the first time I’ve really been published (at least been paid for it!). I found the experience interesting and (mostly) fun. Many thanks to the editor, Chris!

Any reader of my blog should not be surprised by the fact that I think software patents are pretty bogus. So y’all will forgive a little rant brought on by the examining the (pretty bogus) eolas patent. Here is the introduction to the patent, taken from eolas “technology” page: The Web Application Platform Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document

The bad news is that I am taking down the articles about Hibernate-testing from my blog. This is because I am going to publish the text as an article in java.net. (which is the good news). Stay tuned for more information. Comments: [Ash] - Sep 15, 2005 I have read some of your post on testing DAO(s) using an in memory database and look forward to your article in java.net. Awesome work!

I read an extremely intesting book last week. Cliff Stoll’s “The Cuckoo’s Egg” is a true story about how the author was tracking a hacker in the mid-eighties. It reads like a spy novel, but is appearently all true. I picked the book up at 11 at night, and was unable to put it down until I had completed the whole thing! The book gives a pretty good understanding of computer crime, crimefighting, and the basic methods of the typical script kiddie.

Updated for republication in MrBool. As readers of my blog must have noticed by now, I am somewhat of an advocate of Extreme Programming (XP). However, for the last nine months or so, my title has been “Lead Software Architect”, and I am the (proud?) author of what Martin Fowler calls “the almighty thud” documents. XP is traditionally skeptical of architects, and often with just cause. I’ve frequently heard the term “architect” defined as someone who restricts the options of developers – a definition I don’t particularly care for.

The most recent issue of the Norwegian ComputerWorld contains several articles of interest from an open-source point of view. In addition, the subject has come up for discussion at work recently. Who benefits from open-source? Primarily, it is the consumers of software. Yet the consumers of open-source devote very little resources to developing open-source software themselves. Perhaps they should? The hardest issue for organizations using open-source contribute time and money to the development of open-source is the fact that it is hard to see that this is money well spent.

I like metadata for some tasks. Luckily for all of us, Commons-Attributes implements metadata for pre-Tiger JDKs. Unluckily, it requires an extra compilation step (with Ant, no less). But no more. I’ve created an extension that does it all in memory. The class uses both xjavadoc and commons-attributes. Here is an example of usage: CommonsMemoryAttributes attributes = new CommonsMemoryAttributes("src"); Class testClass = AttributeTestClass.class; public void testClassAttribute() throws SecurityException { Collection result = attributes.

How should development teams be organized? Reduce chatty interfaces. In Lean Software Development Mary Poppendieck describes the seven wastes of production and their analogy in software development. Three of these are: Motion (software analogy: Finding information), Waiting (Waiting), and Transportation (Handoffs). I see these in many projects that I am involved in, or hear about. One problem many organizations experience is a divergence of software developed by different teams. This is a serious problem, but many organisations choose the other extreme.