The Torre del Mangia, the 'Eating Tower' in the Piazza del Campo, Siena.
 

An inlaid granite floor from Siena's cathedral. 

One of Siena's medieval streets. 

Salt cod. 

More good food: Aubergines, tomatoes, red onions and garlic. 

A view from the breakfast room at the Fattoria Montelucci, 

The front of Florence's Cathedral. 

The tower of Florence's Cathedral. 

A glass of Selvapiana vinsanto. 

Wine in the Selvapiana cellars. 

A view across the valley from the Selvapiana Vineyard. 

Focaccia bread with tiny grapes. 

Pouring the milk over the sealed pork. 

Rib of pork tied up and rubbed with salt, pepper, olive oil and thyme before baking in milk. 

The mixture before freezing. 

Mixing the ice cream. 

Plums cooking down to make ice cream. 

A selection of the produce that we were to cook with. 

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.

IntelliJ 4.5, OS X Panther and Subversion

I recently bought an Apple Powerbook to serve as my major development laptop and also to teach me a little about BSD. Installing IntelliJ 4.5 was a doddle, but having got used to Subversion integration I wanted that too.

After a lot of trial and error, I used the follow steps to get it all working.

1. Install Fink (http://fink.sourceforge.net/).
2. Use Fink to download and install the latest versions of the svn-client and svn-javahl packages from the devel section. If you are working in a secure environment you may need to also pull down the SSL versions of these packages from the crypto section.
3. Download the svnup and svn4idea45 jars from http://svnup.tigris.org/ (I used version 0.9.1 of both jars.)
4. Create a svn4idea subdirectory below the IntelliJ plugins directory (parent directory usually called IntelliJ IDEA.app) and in the svn4idea directory create a lib directory.
5. Place the 2 jars from tigris and the svn-javahl jar from the /sw/share/java/svn-javahl directory (if the Fink default install options were taken) and place them in the newly created lib directory.
6. Find in the directory that contains the plugins directory find a directory called Contents and below that directory find a directory called Resource.
7. In the Resource directory create a directory called Java (note the case).
8. From a Terminal window, copy the libsvnjavahl.jnilib alias from the /sw/share/java/svn-javahl directory into the newly created Java directory.
9. Restart IntelliJ and select the now available Subversion option as your version control and enter connection details for your Subversion server.

If you run into javahl library problems check that the alias has not been broken by the copy and also check that the Java directory that was created in step 7 is on IntelliJ's library path (the complete library path is listed in the error message from IntelliJ). If it is not present choose another directory from the library path for the copy destination in step 8.

Hopefully you will now have full refactoring/version control goodness.

An Erosion of our Humanity by the Justice System.

Something has been niggling me for some time about our approach to crime and punishment. Why is it that whenever a crime is committed, large or small, a whole raft of extenuating circumstances are brought out and the sentence reduced?

This worries me deeply, a criminal being able to say that he/she did something because of all these external factors and so should be mercied. I believe that one of the fundamentals of humanity is the ability to make a conscious decision, weigh all the pros and cons before acting. I wonder what the message is then when leniency is shown, the messages that I can see are:

• Either, if you make a conscious decision to break the law, having weighed all the factors, that's OK, it's not that bad really,
• Or, it's alright to break the law because you didn't really think about it, didn't think about the damage that you were doing and were only conscious of a small part of your decision making process.

The first message is bad enough. It takes the judgement of Solomon to determine whether there really were mitigating factors, and the mitigating factors have to really outweigh the negative consequences, not just outweight them in the mind of the offender.

The second message is far more dangerous, it goes to the heart of what makes us part of an human society. This means that it's alright to act as a criminal as long as you didn't think clearly about it, you didn't act as a thinking human being so we'll allow you back into human society sooner. That is a very bad thing. It attacks our humanity in general, it means that there is a general belief that we are unable to aspire to be rational beings and it's fine just to act without thought.

I take this very, very personally.

Simplify and Add More Lightness

My immediate family has a preponderance of engineers, not software engineers but the old fashioned kind that build physical objects. I always find it enlightening to observe the similarities and differences between classical engineering disciplines and software engineering.

One dictum that has come down to me that I always follow, 'Simplify and Add More Lightness'. My father applied it when designing racing cars, my sister a trained engineer applies it in her chosen engineering discipline - dressmaking (just think about it).

So what are the ramifications?

Primarily it means, as the XP programmers have it, that a piece of software should only be as complex as it needs to be to do the job and no more. I agree whole-heartedly that the avoidance of abstractions, neat tricks and anything that obscures the intent of code is to be avoided. The problem is that, despite whatever the sellers of methodologies tell you, there is no substitute for experience in determining how complex a piece of software needs to be.

I have a few questions that I use to make this judgement call:

• What are the invariants of a system? An often difficult question to ask, but rewarding. The invariants are the parts of the system that should have the fewest or even no abstractions. They can be certain key business objects and behaviours, certain work flows or even the fact that communication between components is to be asynchronous or synchronous. I tend to use these invariants to define the skeleton of systems that I am designing and they throw into stark relief the next question.


• How fluid are the variant elements of a system? An equally difficult question to ask. The degree of fluidity helps one to decide which level of abstraction to define. If something is unlikely to change during the lifetime of the system, then maybe just an interface should be defined. If an element is likely to be changed several times perhaps a factory should be written. If the element is likely to vary continuously, then some form of declarative configuration should be used, whether an XML file or even an end user defined set of rules in a rules engine.


• What is the likely skill level of the support staff? A question that is not asked as often as it should be. If there is likely to be a high turnover of the support team, giving them little or no chance to learn the system, or there is likely to be a preponderance of junior staff then this question is vital. A compromise will often need to be reached between the efficiency and simplicity of a system. An efficient system sometimes uses sophisticated techniques to be performant, however it often leads to complexity which then has to be supported. It is worth remembering that the more complex a codebase, the more prone it is to bit-rot.

A second important ramification of this dictum is that a piece of software should be as 'light' on the system it is using as possible. With certain exceptions (see above), overly complex systems are not performant, if messages are flying backwards and forwards, the code tends to be tangled and to make inefficient use of resources.

A good physical example of the application of this dictum is that of a bicycle, the most invariant elements are the carriage of a person, pedal power and two wheels leading to the relative simplicity and inflexibility of a frame. The more fluid elements are direction, speed and incline. Direction is handled by a simple steering abstraction. Speed and incline require a much more complex abstraction, that of gearing. It is interesting to note that there is still room for valid variation in the design of the 'skeleton'of the bike (prone bicycles) but the frame remains a static structure.

In the early days of bicycles, they were designed to be maintainable by non-specialists, either blacksmiths or the cyclist themselves, and were thus extremely simple and made of basic materials such as iron. With the rise of cycle technicians, more sophisticated materials were used such as steel, aluminium and now composites; the gearing solutions became increasingly complex and now there is even non-essential complexity, suspension systems.

I always try to design systems to be as simple as possible, but I am sophisticated in how I do this.

Naked Collections are a Design Smell.

I've been thinking some time about a malaise that seems to afflict the codebase of most applications that I work with:

Collections.

Don't get me wrong, Collections are an important part of the programming toolkit, but every time I see them exposed in a method signature I wince. Collections are used as a convenvient shortcut instead of actually thinking in an object oriented way. The Collection is as far as many people go in modelling the bulk properties of groups of objects.

We model individual objects very carefully. If we are properly object-oriented we provide methods to the object that we are creating and end up with a beautifully crafted object. Yet when we come to model a group of objects, most often they seem to just get chucked into a Collection. The only bulk behaviours that we get are those of the Collection and none of those of the group.

Properly clothed collections.

When a collection class is wrapped in a 'group class' we create better object models. We can make our code more robust and easy to understand.

• A wrapped collection can be strongly typed through the methods provided by the 'group class'.
• When one comes to write bulk and batch methods they have a more natural home than the proliferation of helper classes that one normally has to sort through.
• A group class can provide facets to the enclosed objects, for example when an instance of a 'Person' class is added to an instance of a 'Football Team' group class they become an instance of a 'Football Player' class. The addition of the 'Person' to the team should be accomplished through a method that has the necessary additional parameters for defining them as a football player, such as shirt number and position.

Using naked Collections is not object-oriented, when I see them used I know that someone has skimped on the modelling.

Groups of objects are objects too.

A little bit about me and my blog...

Well, this is my first venture into the world of Blogging and I am somewhat nervous. I know that there will be very few people viewing this blog initially and hopefully mainly my friends, but I'm still nervous as I know that I will be revealing more about myself here than I normally show to anyone.

Who am I?

That is the question that I have lived my whole life so far to answer, and it will never be completely answered until I have died. From your point of view however we'll start with basics and the rest of the blog will go some way to filling in the blanks.

The first and most obvious definition is my name. My full name is 'Robert Morris Maitland Boothby', a mouthful I know. My mother is about the only one who calls me 'Robert', the rest of the world knows me as 'Bob'. 'Bob' came about because at school there were too many Roberts, I was left with a choice of 'Bob' or 'Bert' and I really did not feel like I was a 'Bert'. That name was left to a gentleman called Peacock to whom, as a scion of a Yorkshire/New Zealand sheep farming family, it seemed eminently suited. To be honest I never fathomed whether he liked the name, but it's too late to swap now.

The second definition of me comes from what I do for a living. I am a Java programmer with design and architecture pretensions. I have my own small company though which I work primarily in the enterprise Java arena. I can't really claim a specialisation as I have worked in so many areas with a wide range of (not exclusively java) technologies. The companies I have worked for are equally eclectic with a bias towards the financial.

My work to date has been almost exclusively based in England. I did work for a short but happy period in Ireland, a small town called Castlebar in County Mayo but that will likely be a topic for another entry.

The third definition of me comes from what I do socially. I am not an instinctively social animal in many ways and it is often a conscious effort for me to get out there. I have started going regularly to gigs with good friends such as Dan and Ed, a particular favourite being the a pub called the Greys. Every year I go to the Cropredy Festival and every year I attend the South of England Show. I sporadically attend motor sports event (my father raced) and the rest of my socialising is in and around pubs and cafés. I have ambitions to get dining chairs and hold an honest to goodness dinner party, but I'm not hopeful.

What will this blog be about?

Anything and everything that takes my interest, this will include but not be limited to Java, OOAD, poetry, cars, politics, philosophy, poetry, music, movies and cooking.

I would say that that's enough for a first post so I'll stop.