Saturday, September 01, 2018

Farewell, Friend

Anton The Cat
In 2001 my wife and I decided that our son - four years old - should have a companion. My wife voted for a dog (we were both brought up with dogs) but I managed to hold out for a cat.
My Wife and son then found a cat with a litter in a local shelter, with just one kitten left .... all the others had found homes.

Good friends of ours were adopting a son - Anton - so this adoptee became Anton-the-Cat for ever more.

That was in 2001.

It's 2018 now.

Anton the Cat was 17 this year, but his health was failing 
and he was increasingly uncomfortable and unhappy.

Anton the Cat has left us now. 
He leaves us the best of memories.

Thanks to Nick Irwin for the photos.

Monday, June 25, 2018

The Three Fundamental Principles of Programming

Well! Quite a serious topic!

A very long time ago, over an amount of beer that I suspect would be termed "binge drinking" these days (but was simply normal daily intake then!), I came up with some advice for beginning programmers.
The more I see modern bloopers the more I think that maybe these should be taught in school!

There are only three, and below are some explanations.
  1. If you don't absolutely, positively, have to do it, then simply just don't !!
  2. Perspective! Remember where your towel is!
  3. If it's getting really really really difficult then don't do it like that!


  1. a.k.a. wasting cpu cycles is the ultimate sin and you will be inserted into a DEC RP04 for your stay in Hell!
  2. You can go swimming in a pool full of people and not forget this; don't forget why you're writing your code!
  3. The the whole universe runs on e = mc**2 so just how hard can programming be?
    If it's getting really tough then either you're doing it the wrong way or else you're doing the wrong thing!

Finally, before wrapping up, 
a mandatory cat-picture 

because,..... well, ....... because 

this is the InterNet, you know, 

and cat pictures get everywhere!

And that's it. 
(from Cu Chulainn and me!)

Tuesday, April 24, 2018

Sweet & Sharp Pork Tenderloin

I'll admit to stealing this a while ago, but I've now no idea from where! I've made it a few times and it's always been devoured with murmurs of sated satisfaction. The nicest part (from the pov of the cook) is that it's easy to prepare and tastes great. Surprisingly it's usually quite cheap too!

This is an easy recipe that involves much more hanging around waiting than actually doing stuff, which means that you can make other things to go with/before/after it while the meat is just doing all the work!

2 tablespoons honey2 tablespoons dijon mustard
1/4 cup white wine vinegar1 tablespoon dried thyme leaves
1/2 teaspoon freshly cracked black pepper1 1/2 pounds pork tenderloin (1 piece)
Potatoes, peeled and boiledSweet Corn


  1. Whisk together honey, mustard, vinegar, thyme, and pepper. 
  2. Place pork tenderloin in a large zip-top bag and pour in honey mustard mixture. 
  3. Squish around to make sure pork is completely covered. 
  4. Refrigerate at least one hour.
  5. Heat oven to 425F. 
  6. Lightly oil a baking dish.
  7. Place pork in dish, reserving marinade. 
  8. Roast 35 minutes to an hour (depending on the thickness of the tenderloin), checking internal temperature at 30 minutes. Pork is done when a thermometer inserted into the center reads 145F. 
  9. Remove from oven and rest 10 minutes before slicing.
  10. Place reserved marinade in a small saucepan and boil 5 to 10 minutes or until thickened, adding water as needed to keep from sticking and to maintain the desired quantity.
  11. While working with the marinade to make gravy, you can use some Bisto (original) powder or granules to thicken it and give a good colour.

I serve the pork drizzled with the honey mustard gravy, and with boiled potatoes and sweet corn.

Note: 425F is a good temperature for roasting baby potatoes or vegetables, so cook them at the same time on a sheet pan while the pork is cooking.

Enjoy your meal - I'll add pictures when I make it next!


Saturday, October 21, 2017

Cooking Cheese

It's called Baked Brie. 
I was recently on an engagement in Chicago and lucky enough to ask the hotel night staff as I arrived just after midnight, very early one Monday morning, about where I might get some food. So lucky, indeed, that they recommended Bijan's Bistro, which was just around the corner, one block from the hotel.

So, if you take a look at Chicago on Google Maps and compare it with the clip above, you'll find it. Baked Brie as a dish I already knew from living in Germany; I'd very seldom had it here in the USA, but the restaurant proclaimed itself as being European, so I tried it.
Very very good!
It's also very simple, so here's how I reproduced it:
Ingredients (for two people)
  • One small Brie, cut into eight pieces.
  • Two good handfuls of almonds. Half will be toasted.
  • A couple of dozen grapes.
  • Honey to taste.
  • Soppressata salami, sourdough bread, arugula (rocket) 
  • Start the oven at 350F (175C)
  • Put four eighths on the Brie into each of two bowls. Make Maltese Crosses of them in order to allow space for the cheese to melt and run.
  • Sprinkle a quarter of the nuts over each bowl
  • Drizzle honey onto the cheese. 
  • Bake the bowls of cheese for about 10 minutes, until the cheese starts to run.
  • Slice fresh bread, soppressata to fill out the meal
  • Chop fresh green salad (I like rocket because it's sour, contrasting with the cheese and honey)
  • Toast the rest of the almonds
  • When the cheese starts to run, bring the bowls from the oven
  • Sprinkle the rest of the nuts and some of the grapes over the bowls

Arrange the ingredients around the bowls 

(which will be hot! Warn your guests!!!).




Saturday, October 14, 2017


So I'm on this project to move a (big!!) database to a new home. Upgrade the hardware and RDBMS too, but mainly split up into a more logically planned set of databases (plural), instead of schemas all within one database.
Sounds easy, doesn't it - especially to data-ninjas like all you out there reading this.
Yeah, well, not so much.
The thing that everyone looks at is size - if it's huge (tens of terabytes or more, say) then it must be difficult.
But that's not really so. It's kinda like logistics - once you've done it once then you know how, so doing it again is easy ... it's the organising of doing in 10 billion times at the same time that takes skill.
In this case it isn't the size of the data that makes things hard - it would be as hard with 1 MB or 1 GB or 1 TB or 1 EB of data - but it's the interconnectivity between objects that's the killer.
Not when you move something in a lump - that's when the size becomes a pain - but when you move things relative to each other - that's when things get really awkward!
You see, if you have two things sitting next to each other, so to speak, is (let's say) Schema_a, then one can refer to the other directly by just the name - like this:
select Field_a, Field_b from Table_a
If you move Table_a to another Schema (Schema_b, say), then you need to say
select Field_a, Field_b from Schema_b.Table_a
to distinguish it from the version that stayed home, back in Schema_a. Then you take it to another database in the same instance
select Field_a, Field_b from Database_b.Schema_b_Table_a
and then move it off to another server .....
select Field_a, Field_b from Server_b.Database_b.Schema_b_Table_a

All this seems very simple - and it is. However, there's a certain amount of work involved to change from the first to the fourth example:
1. Find where the external reference is
2. Open the code for editing
3. Edit the code (correctly!)
4. Save and close the code (compiling it as needed)
Which also is simple, albeit taking a little longer than just realising that it needs to be done.

In fact, the difficult pieces are not the ones in that list above, but these:
1. Locating all the places where the code will have to be changed, missing none.
2. Doing it all within the inevitably unrealistic time-constraints imposed on you by people who agreed to the time scheduling without knowing what had to be done.

So the first thing you do is write some code. This code finds every piece of code that refers to any of the objects that's going to move. That could easily be just a few, but if you're working with a database that's grown slowly over the last ten years or so, it's quite possible to number in the thousands.

Then the number of connections ........... what you would call the interconnectivity. Just how many of the queries in your code depend on information that's suddenly going to be in a new place? Will it be hundreds (lucky you!), or will it be tens of thousands (unlucky you!).

Either way, upping your Courage Vitamin might be good .

Good luck!