Connection Pools and Resources.

As 'contract scum', I've often worked with a lot of client's implementations of database connection pools.

They all have one thing in common, they all wrap the underlying java.sql.Connection implementation with their own connection-pool-aware version, and fail to truly meet the contract of the interface.

The problem comes where they override the behaviour of the close() method, to implement the connection pool behaviour, the override returns the connection to the pool.

Spot the obvious error here.

Go on, if you can you'll be streets ahead of all the really experienced people that implement these things.

Think about what happens to a non-pooled collection when the close() method is called. The outstanding transaction is either committed or rolled-back, and all open resources are released.

These behaviours are what are missed by many custom-rolled connection pool implementations.

The results are various:

• Either an experienced developer will write a lot of boiler place catch and finally blocks to close resources.
• Or an inexperienced developer will generate memory leaks left, right and center.
• Connections may be returned to the pool in an inconsistent transactional state.

I dream of the day when these connection pool implementations are replaced by complete implementations and I no longer have to scatter catch and finally blocks across my code.

The Right Tool for the Right Job

I've been working in IT now for a good many years and as my job is done on entirely different client sites I've seen a wide range of working practices, both on the IT and the business fronts.

One common theme unites all my experiences in annoyance, the 'One Tool Wonder'. Virtually everywhere I go I encounter someone who once had success using a tool or technique and insist on applying it everywhere.

It's a lot like the fellow who was really happy with how much better a hammer was for knocking nails in than the heel of his shoe, he now spends all his day working out how to use a hammer in all his home improvement problems. Don't scoff, I once spent a very interesting afternoon watching someone put up fence panels, hammering the screws into place. I looked at the fence only a couple of months ago and the wood around the screws is beginning to rot beautifully, mangled as it is by the forceful passage of the screw.

One of my perpetual mantras is now 'The right tool for the right job.', whenever I am doing something I try to use the best tool for that piece of work. A lot of good tools are supplied on site or by the OS that is in use. but I also have tools that travel with me.

• IntelliJ - Possibly the best java editor bar none.
• Ultraedit - My personal poison when it comes to text editors.
• Ant - The most flexible build tool available, partly this is due to my knowledge of this tool, but also I feel that tools such as Maven only suit a sub-set of projects. I will use Maven where appropriate, but...
• Castor/JAXB - I tend to use one of these two, depending on the Java/XML binding capabilities required.
• Middlegen/XDoclet - EJBs do have a ridiculous quantity of boilerplate, I find that the combination of these tools make life a lot easier.
• DBVisualiser - There are various fantastic database specific tools, but as most of my work is in Java, I tend to favour a tool that works with the JDBC drivers that I will be using so I can check out issues independent of my code.

I am always ready to substitute tools with one that is more appropriate for the particular job, but generally these are my preferences.

In my life outside of work, I apply this mantra too. I have a garage of tools for my classic car and for overclocking and my kitchen is well stocked with the correct utensils.

In many ways the most abused tool in the developer's toolbox is XML and it's associated technologies. Here are a few examples of abuse.

• Storage of simple key-value pairs, that is what a properties file is for. Properties files are expressly designed for this form of data, are simple to maintain, easy to grasp and are fast. Admittedly there is the converse scenario where the properties file has complex keys and data and really might be better in another form such as XML.
• 500k or larger XML configuration files, where most developer time is taken up with these files as the configuration has become so complex that the XML dialect is a programming language itself. This is where a known scripting language or the base language itself should be considered. You've hired Java developers, yet they spend 95% of their time editing your pig-awful configuration file structure. Sorry, brief flashback there.
• Overuse of XSLT. It is a wonderful tool, but a few rules of usage need to be established. The core premise of XSLT is converting one data-complete XML format to another. The further you move away from that, the less appropriate it is. Also, while XSLT is sufficient for writing a ray-tracing engine, I really wouldn't recommend it.

I really could carry on ranting from here on in, but the best thing for me to do is stop and just plead with you to really think about the right tool for the job.

Just because you can see how to solve a problem with a particular tool doesn't mean that it is the best tool or will solve the problem in the best way. Always spend time learning and looking at new tools so that your toolkit has the best chance of solving problems well.

An example of my knotwork. 

A Little Bit More About Me

I've defined myself in three ways so far, these three ways are probably the most visible, public definitions. I feel that they define only the most public aspects of me and as such are quite shallow definitions.

Deeper definitions come from what I like to do with my spare time and what I believe.

Hmm... Where to start?

Probably with what I do in my spare time.

I do spend a chunk of time playing computer games, primarily Space Sims, Adventure and RPG. My all time favourite game would have to be Ultima 7 and all its expansions, closely followed by Ultima Underworld I & II and by System Shock I & II. Deus Ex also sticks in my memory. As a guilty pleasure, Dungeon Siege ate an awful lot of my spare time.

Aside from that I love poetry, I particularly enjoy G.K. Chesterton's poems, 'Lepanto', 'The Deluge', 'Elegy in a Country Churchyard' or 'The Rolling English Road'. I think that Andrew Marvell's 'To His Coy Mistress' is the height of genius and I even learnt it (for much the same reason that he wrote it.).

Cars have long been a passion, but that is rather on a back burner. I can be described as having champagne tastes on a beer budget, so until I have enough spare cash I'll leave well enough alone.

Cooking is my major stress relief. At home when I was growing up I was able to draw on both British and Argentine cuisines and since then I have developed into an experimental cook with good results. Last week I got back from a cooking holiday in Tuscany with Tasting Places, highly recommended. My favourite cuisines are probably Argentine, British, Italian, Thai and Chinese.

Celtic knotwork is a long time hobby, it is immensely therapeutic and challenging, I'll post an example of my work after this entry.

I read voraciously, Science Fiction, Fantasy, Horror, Thriller and History are topics that are well represented on my book cases.

I have just taken up kite flying, power kites mainly.

This will do as a summary, next time I will talk about my beliefs

Enlightened Self Interest

Doing a Google search today for the phrase 'Enlightened Self Interest', it came up at 35,300 hits. Yet most people who I say it to look at me blankly.

To me it is one of the founding principles of my ethics. While many of my ethics come from my Christian upbringing, I am by nature a person that likes to understand the why and the how. 'Enlightened Self Interest' (ESI) answers both these questions.

What is it?

'Enlightened Self Interest' is the understanding of the boundary where selfishness stops being productive and starts being harmful. Applying enlightened self interest means a lot of thinking, it means that you strive to see where short term selfishness will lead to long term self harm, it means that you work hard to understand the other people around you in order to be able to choose those with who to cooperate to mutual benefit and on a wider scale you have to grasp how your actions impinge on society and how they will cause society to impinge on you.

A little selfishness leads you not to give away your ability to support yourself and so not become a burden on others.

As a philosophy it is a little less than inspiring, the acknowledged ideal is to be perfectly selfless. Unfortunately that ideal only works if everyone around you is equally selfless. A selfless person encountering a selfish person has no defence.

As a simple example, enlightened self interest can address the basic tenet of most societies. 'Thou shalt not kill.', the short term benefit of killing someone in order to gain some advantage is outweighed by the long term risk that it becomes alright for anyone to kill you. In modern society this fact is (dangerously?) less obvious, in older societies a killer became an outlaw and thus fair game for others to kill.

I would ask everyone to consider applying ESI to their everyday lives and ethical decisions, as it allows one to approach the ideal of selflessness, promoting cooperation while still protecting you and society from the selfish.

Temporal Arcs

Why don't people ever look at relationships through time?

Almost every object model I see seems to deal in the now and does not deal with the past or the future.

Consider a relationship that crops up in almost every object model, a person and an address. A model usually resolves this relationship by saying that a person has an address. The reality is usually more complicated.

If one starts addressing the temporal element the model starts to get more interesting. A more accurate way of modelling is to say that a person has an address at a particular point in time. People move houses all the time.

The most robust way of modelling this is using a time constrained relationship. The object representing this relationship consists of the following attributes:

1. The person.
2. The address.
3. The point in time that the relationship starts.
4. The point in time that the relationship ends.

The first three attributes are mandatory, the last is optional. The most recent address is the one with no relationship end time. The current address is the one whose relationship includes now.

This allows us behaviours that are extremely useful in a business sense. One can work out the address a pay cheque went to or a change of address notification can be filed and automatically used when the move occurs.

Temporal modelling is an essential part of object modelling and should never be ignored.