New found liking for dessert wines.

I have just had a bit of an education...

I've just spent a weekend on the Isle of Wight with my sister; Saturday afternoon was spent sharing a significant part of my whisky collection with some old friends. Chris (who happens to be a very talented musician) returned my collection of CDs that I accumulated on my '03 roadtrip and told me how much he had enjoyed 'Los Hombres Calientes'. I'd forgotten that those CDs were in that particular part of my collection, but was very please to know that they had given him so much pleasure.

After a couple of hours drinking whisky, we drifted across into discussing wines. I stated that I had never come across a dessert wine that I liked, with the honourable exception of the occasional Italian Vinsanto. I declared that they were all too sweet and sickly.

Rather well lubricated by this stage, Chris returned with a wax-sealed bottle and introduced me to 'Royal Tokay'. I had heard of 'Tokay' before, but today was the day when I discovered that it was a tiny wine producer in Hungary, costing £30 for an half bottle of the 'Royal Tokay'. I'm not a wine writer so I won't even try to describe what it tasted like; but after cleansing my palate with a little water, I enjoyed one of the finest flavours that it has been my pleasure to experience.

I am now on the look out for Tokay, and I want to try the 'Imperial'.

The Speed of Light?

THe night before last I must have been having some corking dreams, because I woke up this morning with a question that I would love an answer to.

'How does the quantum foam effect the speed of light?'.

For my readers who are not physicists, let me break this question down.

The 'quantum foam' is a descriptive term for the fact that there really is no such thing as a vacuum. Due to the probabilistic nature of quantum mechanics even in a space where all matter as we recognise it has been removed, particles continually pop in and out of existence. Energy is conserved because these particles disappear as rapidly as they appear.

This being the case, I wondered whether the speed of light is in some way determined by it's interaction with this quantum foam.

A side query is whether the increase in mass associated with objects moving relatively faster (most obvious as the speed of light is approached) is in some way connected with interactions with this foam. as masses move faster relatively speaking, they sweep out more and more space, vastly increasing their chance of interacting with these virtual particles.

Singleton - Pattern or Anti-Pattern?

It's interesting to see how various developers respond when you ask them about the singleton pattern. Most react positively, others say that it is an anti-pattern of the worst form.

Why it is considered an anti-pattern by some?

1. In Java it doesn't always meet the contract of the 'Singleton Pattern' as defined in the GoF book. Classloaders mean that more than one instance of a Singleton can exist in the same JVM.
2. Developers often use it as a dumping ground for de facto global variables, harking back to the most unstructured early days of programming.
3. Implementations often feature 'Singleton' in the names of implementing classes and other code becomes dependent on the fact that it is an instance of the singleton pattern.

I believe however that there is nothing wrong with the singleton pattern, just in implementations of it.

One should think of the singleton pattern as an implementation pattern for the factory and pool patterns. Developers should be handed a factory or pool and told only that it will give them an instance of a particular class or interface on request. They shouldn't know that it is the same object instance each time.

This allows the developer of the pool or factory to make efficient use of available resource, if possible, but also allows the implementation to be changed if necessity dictates. By hiding the usage of singleton behind the pool or factory patterns, code fragility is avoided.

J2EE misconceptions - Part 1 (of quite a few actually).

On every project I never fail to be surprised at how little supposedly experienced J2EE developers actually know. This week I found myself asking team members if they actually had read the EJB specification and the answer came back a resounding 'No!'.

It seems that all too often when people are learning J2EE and EJBs in particular, they go and look at the specifications with a beginner's eye and form the impression that the specification documents are dense and impenetrable. They never go back with a more experienced eye and have another go. When I went back and re-read the specifications half way through my first J2EE project I suddenly realised that they were really useful and were packed full of vital information that allowed me to treat J2EE more as a science than as the black art practiced by so many.

The misconception that I want to address with this post is around Container Managed Transactions (CMTs). Let me ask you a question and please be sure what you think your answer is before you move on.

In what circumstances do CMTs roll back?

Take a second or two.

The answer that I usually get is: 'When an exception is thrown.'

Trouble is, the answer is sort of wrong.

The correct answer is: 'When an unchecked exception is thrown out of the transaction context or when EjbContext.setRollbackOnly() is called.'

What many of the developers I talk to fail to realise is that checked exceptions do not roll the transaction back.

So did you get the right answer?

UML Abuse

Had a mixed day at work today, good and bad.

The bad today was around a discussion of how we were going to use UML to analyse use cases. All was going well until we got on to discussing how to model the user interface. We need to record the navigation between screens, the decision made was to do this with a mixture of class and statechart diagrams. I argued against this and suggested Visio, but was overridden on the basis that we wanted to do it all in UML via Rational Rose.

Thinking back I realise that I have actually seen this a lot, people determinedly using UML when another style of diagram would have been more appropriate. I seem to recall that Jacobson, Grady and Rumbaugh, when they first wrote up UML, were quite clear that while the diagrams covered the majority of design cases, they by no means covered them all. Where has this attitude gone?

Does anyone else see UML abuse as a problem?

Name Dropping

I had an interesting day yesterday, some guys from JBoss came over to sell a support package to the project that I am working on. So I found myself, just before lunch, shut in a meeting room hearing the pitch made by a commercial venture on the back of open source software.

I can certainly see that there is money to be made by their business model. In commercial and public sector there is the concept of 'due diligence' hereafter known as 'arse covering'. The support packages on offer provide exactly the right feeling of security for management and customers, in this case backed up by genuine knowledge of the product.

Certain of the more rabid open source fans I have met believe that this is a dilution of their long term goal. At present I have to disagree, because of this commercialisation the rate of development in JBoss is extremely high and that benefits anyone who needs an application server and can't afford the cost models imposed by companies like BEA. I don't know whether a successful business can be established long-term by paid for arse covering, but we will see.

After the meeting I adjourned to the cafeteria to share a coffee with the gentlemen from JBoss and had an interesting time talking to one of the more vocal EJB3 supporters that I have come across. He was very clear that the current 'issues' with JDO are all the fault of the JDO specification team and how they 'snuck out' the candidate specification over Christmas. I certainly agree that it was not a time best calculated to make the right impression. I have a suspicion that the actual cause of the release date was the feeling 'Right let's get it finished and have a good Christmas.'

I have to admire the detachment displayed in discussing how the current situation was in part due to the frictions between a specification driven by large business and a specification driven by a thriving user community. I found myself agreeing that there was room for both specifications. Having more than one persistence specification allows me to exercise one of my dictums: 'The right tool for the right job.'.

My radical proposal to resolve the current problem is to go ahead and put the mechanisms in place for migration from JDO and EJB3, but also state that mechanisms for the reverse migration should be part of the EJB3 specification.

Motorway Driving.

With my current contract, I'm having to do a lot of motorway miles, to and from work. I tend to odd hours and so tend to avoid the worst of rush hour. However there are a few things that I need to get off my chest...

I hate:

• Under-takers - Not the sombre men that come to take away granny, but the fast furious drivers that come up inside lanes past a queue of cars. When they get to the slower moving obstacle in their lane that has caused the stack of cars in the outer lanes, they force their way back out causing everyone else to brake.
• Underpowered White Van Men - White Van man is an acknowledged hazard of modern driving, but in his way he is predictable and possible to get along with. The only one I have any problems with are the ones with heavy loads and small engines. They zoom downhill in the outside lane at 80 mph. I have no problems with them zooming, it's when they go uphill and they use that brief spell of 80mph to justify remaining in the outside lane as they crawl uphill at 60 mph or below.
• Sticky Drivers - I define a sticky driver as someone who stays in a lane regardless of whether the inner lane is empty. They are the cause of a lot of dangerous driving, either because a marginally faster driver is forced to overtake them, or because a significantly faster driver is forced to undertake them, or (worst of all) an impatient driver trying to persuade them to move drives right up their backside.

There are many minor irritations on the roads; roadworks, speed cameras and potholes; but it seems to be a constant that other road users cause the most irritation.

First impression of OptimalJ

Well, I've been using OptimalJ 3.2 for 4 days now and I can say that my first impression is 'stability' or more to the point the lack of it.

Part of the problem is that it is based on 3.5 of Netbeans, which was never noted for it's fabulous robustness, but a large amount of the instabilities that I have encountered are in the OptimalJ functionality. This is a tool that promises to give great productivity enhancements, but to be honest they have all been soaked up by the time spent trying to work around the issues.

This instability reflects on an idea that I've been kicking around for some little time now. The limits of complexity that can be achieved in a piece of software. The improvements in development; assembler, functional programming, procedural programming, object orientation, UML etc.; have all increased the complexity of software that can be produced.

I get the feeling with OptimalJ that this particular software is pushing the complexity limits of the development processes used to produce it.

PVRs, what I really want in one now.

Been chatting with my friend Dan about my upcoming purchase of a Hauppauge DEC 3000-S USB Satellite decoder. We were uncertain about the lack of an hardware encoder for recording until we realised that Digital Video Broadcasts (DVBs) are encoded in MPEG II in the first place.

I got to thinking about what it is that I want in a PVR beyond what is currently available and the major one is being able to view one channel while another is being recorded. This is something that is available with the current analogue technology VCR and television as they each have their own hardware to decode the signal and either display or record it.

Ideally I would like a modular PVR being able to plug in additional receiving/decoding units, so that I can view/record across as many channels as I have decoding units.

Of course there are practical design problems, it would be possible to overwhelm both the CPU and the filing system with the amount of data being written. Within those practical limitations I would love to be able to record 3 or 4 channels at a time.

I suppose the next thing I need to do is look at what can be cobbled together now with available technologies. The easiest thing to prove the concept will be to use two USB compatible decoders. Next will be to sort out drivers and software capable of dealing with two separate streams. I think that I'll probably have to start with MythTV and carry on from there. I know that the Hauppauge software won't cope.

Anyone reading this with ideas, I would appreciate your feedback.

Scrambled Eggs - My Way.

Well, this is going to be my first cooking post; I've been cooking since I was 7 when my mother first came down with M.E., it was only baked beans but I have come a little way since then.

It has taken me quite some time to perfect my scrambled eggs recipe. The quest began when I realised that the white of an egg and the yolk of an egg need quite different cooking regimens to achieve perfection. Undercooked whites are slippery and unpleasant, overcooked yolks are dry as dust and taste vaguely sulphurous.

So here is how I cook my scrambled eggs now:

Ingredients:

• Eggs, 1 or 2 per person depending on famishment and size of egg.
• Milk, about 50 ml per egg. I prefer organic full fat for this but it does work with semi-skimmed.
• Vegetable oil (I prefer sunflower oil).
• Seasoning

Put enough vegetable oil into a small saucepan to cover the base and swirl around the sides. Separate the egg whites from the yolks, putting the whites in the saucepan and the yolks in a bowl with the milk.

Place the saucepan containing the whites and vegetable oil on a low heat. The intent is to cook the whites without frying them to crunchiness. While the whites are cooking whisk the yolks and the milk together.

When the whites have solidified, you can take the opportunity to pour away any excess oil from the saucepan. A little oil gives sheen and prevents sticking, too much oil is just plain greasy.

I now tend to use the edge of a wooden spoon and break the cooked whites down into pieces. The size tends to reflect how 'refined' I'm feeling. Now add the yolk / milk mixture to the pan and return to the heat.

How high I now have the temperature tends to reflect how much attention I am prepared to pay to it. If I'm in a hurry and am prepared to stir continuously I will up the temperature; if I want to pay attention to cooking other things, I will leave it on the lowest possible temperature and stir occasionally.

Before long the scrambled eggs will start to go 'blop' and steam slightly, this is the signal that you have to pay attention and stir to stop it sticking to the pan. Hereafter it is up to you as to how thick and well set you want your scrambled eggs, the longer you cook it the harder they will get. Don't forget that they will continue to thicken slightly after you take them off the heat.

Serve the scrambled eggs and only now apply seasoning. If you add salt any time before this you risk the eggs curdling and separating giving you a texture of grit floating in tasteless water.

I personally like my eggs served either on wholemeal pitta bread or a nice malted wholegrain toast. Cooking up a few bacon lardons and sprinkling them on top can look really smart too.

The final thing to do is enjoy eating them!

A chance to experience MDA.

'Model Driven Architecture'.

There has certainly been a lot of discussion over the past couple of years about MDA. I have sat on the sidelines, an interested observer, wondering quite how well the whole thing will work.

Unlike most development approaches, the model is the primary artifact and not the source code. This leads to the following concerns:

• The versioning of the model will be interesting. Depending on how it is stored and encoded. Remembering the nightmares with Rational Rose Models I'm not sanguine.
• XMI and UML are not of themselves programming languages and so are not able to encode business logic. This means that a significant secondary artifact is the business logic code. The interaction between the model and the business logic will be interesting.
• Tuning and customisation. The templates for conversion from the Platform Independent Model (PIM) to the Platform Specific Model (PSM) may be adjustable, but how far can you go? Can you apply specifc tunings/customisations to specific components?
• The tools to accomplish this seem likely to be complex, what is the scope for vendor lock in?

I've tinkered with AndroMDA and had mixed results. However I will be working with OptimalJ now, so as I gain experience, I will try and record what I learn here.

Connection Pools - are they always a good thing?

Sorry about the hiatus, it was mainly because I had nothing that I wanted to say... I suspect that that is going to change.

I had a talk with a friend (hi Meeraj!) yesterday and we were discussing a connection pool that he was using. After certain queries anything up to 100 megabytes were consumed and not garbage collected. The theory that we arrived at was that the PreparedStatement caching was the problem. I don't know if that was the case, I hope that Meeraj will let me know, but that set me to thinking.

Why did we introduce the complexity of a connection pool to our code in the first place?

I don't just mean the complexity of writing them (that's mainly dealt with by DB vendor's own implementations nowadays); tuning them and ensuring the robustness of our own code around them can be an headache.

As I recall the major reason for pooling connections was the relative expense of creating the connection in the first place. This expense was only large compared to the time that a small query would take to run and be used. It made a lot of sense to reuse a single connection for several of these little queries. The longer running the queries the smaller the amount of time (proportionately) was spent in creating the connection.

So, for a system in which queries are long running and the connections tend to consume a lot of resources, does it make sense to have a connection pool? Would it be better to have some more simple form of connection management?

The 'meta' lesson is that even for the most frequently used patterns / components, we should always remember why they were used in the first place and recognise the situations where they add no value or perhaps even cause problems.

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.