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.