The Boothby Fogcutter

My Boothby grandfather was an interesting man aside from his exotic pets he was a bit of an inventor. He came up with all kind of things, mainly aeronautic despite being a naval man.

His one invention that has directly impacted my life was the 'Boothby Fogcutter'. Described as a 'catch-up drink', he invented it so that when he arrived at parties late where everyone was several drinks merrier, he could be as merry as them within 10 minutes.

The recipe is as simple as it is fiendish:

• Take a half pint glass.
• Add 1-4 shots of dark naval rum depending on how much catching up you need to do.
• Fill the rest of the glass with cider. I preferred dry but with a sweet cider it is described as tasting like an inferior Tokay.

The real problem with this drink is gauging how much to catch up. It is all too easy to overshoot. It is also worth noting that under no circumstances should this be drunk at any time other than at the start of a session of drinking as I have learnt to my cost.

I introduced the 'Boothby Fogcutter' to my college at Cambridge in my second year and I don't think that Corpus Christi ever recovered. A number of deplorable incidents ensued, usually because the drinkers did not judge the shots of rum correctly or drank it later in the evening after already getting merry.

The incident that sticks most in my memory was at one of Corpus' annual Rugby Club dinners. These were alway boozy affairs.

The routine of the evening was extremely well defined. The club members would meet up in the college bar for a few pints at six o'clock. At around half past seven we would head up to a reception room to make a start on the sherry. At 8 o'clock we would be seated to eat, accompanied by the mandatory fellow of the college who would have to sit in on any function making use of the college facilities. There were invariably three courses, each accompanied by a different wine. The main course was alway a posh variant on steak and chips. After dessert we would start in on the port and after that was finished various people would be sent to the college bar for further supplies of alcohol. At about 10:30 we would pour ourselves out and adjourn to the bar for a few more convivial drinks and, if any of us were still standing, we would see what else would happen.

The year that I introduced the 'Boothby Fogcutter' proceeded along the lines of any other I was pretty well lubricated by the time that the port was finished and when volunteered to get further supplies I decided that this was an opportune moment to introduce the rugby club to a new drink.

I staggered into the bar and somehow managed to convince the bar manager that what I really wanted was 22 'level 2' Boothby Fogcutters. I felt that 2 shots of rum each would be sufficient. Carrying a heavily laden tray I made my way back to the dinner.

Looking back, the major warning sign came when I tried to mount a flight of steps carrying the tray and lost my footing. I fell, but was in that peculiar elevated state that the very drunk have that allows them to keep their containers of alcohol intact. There was a little sloshing but I managed to keep all 22 glasses on the tray and largely full.

Arriving back at the table of drunken rugby players I dispensed my largesse. A couple of people declined and despite my suggestions to the contrary the responsible, senior fellow decided to have two. My last recollections of the evening were of the start of a round of the 'I have never' game where you stand up and drink if you have.

I woke up the following day in a terrible state. I had mixed grain and grape and had had a 'Boothby Fogcutter' halfway through a nights drinking. I had lost my glasses, I was pretty sure that I had been sick given the state of my mouth and chin and had an enormous bruise on my left shoulder.

Over the course of the next couple of days I reconstructed what I had done. I had made it back down to the bar and then gone into the JCR (Junior Combination Room - basically a common room with seating) where I had decided to join in a game of rugby using a rolled up newspaper. My fellow prop forward Tom and a guy named Ed had tackled me and I had gone shoulder first through the closed double doors of the neighbouring television room, taking one of them off their hinges. I then staggered forwards through the assembled viewers to the front of the television room and stood being sick out of the window behind the television for about 5 minutes. At the time I had not realised that there was a bicyle under the window and with uncanny accuracy I had targeted the seat.

After that night I never drank heavily again. The 'Boothby Fogcutter' continued to cause mischief around college and I'm pretty sure continues to cause havoc wherever Corpus people go.

I leave my final thoughts with the fellow of the college who became the first to be up before the Dean for discipline in several decades. I still don't know what he got up to after the second fogcutter.

Smoked Cod and Chips

When I lived in Ireland one of the great pleasures in life was to adjourn to a local chippy called Caffola's and devour a beatifully cooked smoked cod and chips. The cod was only lightly smoked, more to give flavour than preserve and added a delightful high note to a wonderful dish. It was a truly great way to prepare for an evening out at Rocky's followed by Badger Brown's.

I've always loved smoked fish; salmon, mackerel, haddock etc.

I've recently found smoked cod becoming available more widely in the UK so I decided to attempt to recreate the experience.

In consulting various cookery books and looking online I discovered an argumentative group of people who either create or collect frying batter recipes and my goodness there are a lot of them.

In the end I settled on a batter recipe that was a synthesis of several of the others and so here it is:

• 2/3 cup of strong flour
• 1/3 cup of cornflour (For Americans that is cornstarch)
• 1 generous pinch of salt
• 1 spoonful of castor sugar
• 1 cup of good water (mineral or filtered)
• 2 egg whites whipped to soft peaks

Sift the dry ingredient together in a mixing bowl and add the water gradually, mixing until a smooth paste is formed - I would normally expect to have some water left over. Fold a little of the egg whites into the paste to loosen it, fold about half the remaining egg whites in and finally fold the remaining egg whites in.

To batter and cook the smoked cod I cut it into nice fillets, dried them with kitchen towel and coated in a little flour.

I had a wok with combined sunflower and avocado oil ready heated - I tested the temperature by dropping a small piece of batter in and checking that it puffed and crisped within a few seconds.

I passed the prepared cod through the batter and slowly lowered it into the wok so that the batter in the oil had a chance to seal and puff before it came into contact with the base or sides of the wok or other cooking pieces. For a large piece of cod I allowed 12 minutes cooking time and for a smaller one I allowed 9 minutes. The cod floated as it cooked so I turned it over every few minutes to ensure that both sides cooked evenly.

For a first pass I didn't do any chips, I just served it with a herb salad and a large piece of lemon.

It was really quite good. In fact it was bloody delicious.

I'm going to take a little more time on the batter to get it absolutely perfect but so far, so good.

Techniques for working with Temporal Databases.

I've been working recently with a temporal database and have gone back over my blog as a result to see what I've written on the subject.

All that I've written so far is a simple diatribe on temporal modelling.

I think that it is about time that I share a hard won lesson about working with temporal databases in multi-user environments: It is alarming how frequently concurrency can be messed up.

The problem begins with the fact that classical key based uniqueness checks just don't work. In a temporal database you must be able to support many rows referring to the same entity, each row covering a period in the entity's life. This means that any time that you wish to retrieve a view of an entity you either retrieve a set of rows defining the whole life of the entity or you choose a point in time and use a BETWEEN ... AND clause to select a single row indicating the state of the entity at that point in time. Effectively any key has a temporal element. The full key being the identity of the entity, a start date and an end date for the period of time for which the attached information was/is/will be correct.

So far so good, however databases are just not set up for checking this kind of key. They can trivially check the uniqueness of a key - the fact that a given row representing an entity does not have the same combination of identity key and start and end dates. Can you sport the flaw though? What is needed is the ability to check that the row does not have start and end dates that OVERLAP with those of another row for the same identity key. If they do overlap then we end up with two valid sets of data for an entity on a given day - obviously no good.

Keeping up? Then on with the complexity! The first pass attempt at fixing this is to add application or database level programmatic checks that check whether there exists a row that overlaps. That seems fine as far as it goes, however there is a problem - if two users are performing an update at the same time then standard 'transaction isolation' causes a problem. In most databases the default behaviour is that a user can only see committed work done by other users this means that if both users are updating the same entity then the programmatic checks will not see the changes being done by the other user until they commit it and the overlapping rows can still occur.

I've seen a number of bizarre solutions that attempt to solve this, two of the least satisfactory were to either relax transaction isolation so that each user can see what the other is working on (doesn't work in the end) or to have processes that find overlaps and manually resolve them (oh the work!).

The proven solution is to use a sensible locking strategy. The locking strategy can be used to ensure that the programmatic checks are run correctly despite multiple users maintaining the data. You can't use the temporal rows to do this useful locking. Typically I would analyse the data model and either identify non-temporal entities that can be used to lock sets of temporal entities or create my own non-temporal entities for the locking. This kind of non-temporal entity used to lock temporal entities can be referred to as a lifeline/timeline lock. When the lock is obtained you are locking out the entire lifeline of the entity being maintained and preventing other users/processes working on it simultaneously.