I currently drive an X-reg Ford Puma and am now looking for a replacement. I've really enjoyed the Puma, it handles well, has nice pick up and as a 2+2 can carry 4 people over moderate distances. It has swallowed enough camping gear to take me and a friend to music festivals and has regularly slogged around the M25.
However the time has come to think about something else as the Puma is getting on.
What I've been looking has been some kind of successor to the Puma; another sporty coupe that fits well with my life. The trouble is that Ford no longer seems to have cars of that kind available to buy. I'd be forced to choose between one of the Ka or Focus range or end up with a barge.
I ended up casting my eyes further afield and there seemed to be three major choices:
BMW z4 Coupe
Nissan 350Z
Audi TT (New model)
By process of elimination I ended up at the Audi TT, allegedly the handling was massively improved in the new model, it was a 2+2 and can definitely shift. The reviewers had suggested that the 2.0T was nicer handling than the 3.2 quattro, so that was the one that I asked to test drive.
An old friend of mine had asked to come along on the test drive and so, having picked him up a little late, I roared on to the garage.
On arrival we spotted the new and old TT models sat side by side. It was very interesting to compare them. At first blush they looked very similar. The face of the car had obviously changed. The headlights and grille were definitely 'new Audi' and had given it a more aggressive look. The two other obvious changes had occurred at the back of the car with the introduction of a pop-up rear spoiler (my friend and I were both a little dubious - something else to go wrong) and the roofline had shifted back where it met the boot lid.
On further inspection it became clear that the new model was a little wider and a little longer. While most of the distinctive creases and curves remained, they had been subtly altered.
On entering the dealership, I was greeted by our friendly salesman Matt who had cheerfully ignored my request to test the new 2.0T and had lined me up with the 3.2 quattro. At least it had the S-Tronic gearbox so I could happily play with flappy-paddles.
The salesman took us out of the showroom and then out of town with me in the passenger seat and my friend in the back. It was obvious that the +2 seats were not much use at all except for headless people and contortionists. The roofline meant that any adult sitting in the seats had to bend their neck very uncomfortably. It was possible to provide survivable leg room.
Sat in the front passenger seat, I was able to look around the cabin. In basic trim there was quite a lot of basic plastic and, while the build quality was good, I did not much like it. The controls were very well laid out and the seats were extremely comfortable.
The noise in the interior was very pleasant - a nice V6 rumble, pleasantly audible but not overpowering.
Once we had left town I exchanged places with the salesman and prepared myself to drive the car. Fortunately the test drive took in several roads that I had often driven before in a number of cars so I was able to concentrate on the feel of the car and not on the route.
I started off with the S-Tronic box in automatic mode and attempted to pull away. Not having driven an automatic for a while I flubbed the basics - I forgot to put it in drive. Having sorted that out (and remembering to put my foot on the brake) I gently lifted my foot off the brake to see if the car would creep in automatic mode - it did. The indicator stalk on the left was used and I went to pull away. Carefully keeping my left foot out of play I manage a relatively clean pull away and quickly accelerated up to 60. The gearbox was almost unnoticeable, the only sign that gears were being changed was the change in exhaust note.
Rapidly reaching the first corner - a long right hander suitable for 60 miles an hour I simply steered around it. The steering was light but surprisingly communicative. A few hundred yards later I was coming up behind another road user and the road was about to drop away a long way down to a sharp left turn. I deliberately slowed to open up a gap between me and the car in front and let engine braking open up a good gap so that I could come down the hill at speed and take the left hander quite fast. The left hander was dispatched with no fuss. Once again I was coming up behind a small queue of cars so I eased back and followed them. I noticed that it was possible to occasionally wrong-foot the automatic and end up in a less than perfect gear on exiting the corner.
After a little pleasant gentle driving we reached a round about and fortunately the drive took us away from the other cars and onto a lovely half mile of road where I was able to plant my foot and see what would happen. The car took off and I felt that my kidneys were making intimate conversation with the seat. Half way down the road is a right hand bend which rises to a crest half way. The car handled this with ease and dropped down to join the dual carriageway back into town. Joining was no hassle, the only thing that I had to do was make sure that I did not accelerate too much.
On the way back into town I got the salesman to talk me through the gearbox and paddles and I had a pleasant time trying them out. Very neat, very easy. Move the gear stick left to be able to use it to push up and down through the gears, back right for automatic. The paddles worked at any time and could override the choice of the automatic. If I were to get the car I would probably use the paddles almost exclusively.
The final part of the test drive involved me coming up a long hill with a patch of road at the bottom that always manages to unsettle two wheel drive cars. I used the accelerator aggressively and the quattro system worked perfectly. There was no wriggle or squirm and the car accelerated up the hill again. At the top of the hill I got out and sat in the +2 seats, of that the less said the better.
Climbing thankfully out at the showroom I sat down with the salesman and went through the options and colours. The deposit was only to be £1000 and I was sorely tempted to buy then and there. The car was very handsome, the handling impeccable, the engine intoxicating and the gearbox nearly perfect.
I think that I probably shall get a TT despite the cramped rear passenger accomodation. The boot is large and the car is a very good compromise.
I may just need to invest in a guillotine.
September 26, 2006
September 15, 2006
Dulce de Leche
Despite my grandparents living in Argentina, my mother was born in Uruguay as they did not want her to be conscripted if she were a boy. As I understand it the Argentines are not always well liked in South America so my mother is often quite firm on the fact that she was born Uruguayan.
Despite largely growing up in England I was exposed to a fair chunk of another culture for which I will always be grateful. A significant part of that is South American cuisine. Dulce de Leche (Milk Jam) is one of the elements of South American cooking that plays no small part in a number of my family's stories.
The recipe for Dulce de Leche is deceptively simple:
Simply place all the ingredients into a thick pan over a low heat and cook until the mixture turns a medium caramel brown and thickens, stirring occasionally. This can take anything up to an hour and a half.
The resulting concoction can be eaten with a spoon, used in cake and pastry fillings or just spread on bread.
A rather more simple way of preparing it (not without its own risks) is to boil a can of sweetened condensed milk for 2 and a half hours. Remember to keep an eye on it and top up the water if necessary. Do not open the can in any circumstance until it has had a chance to cool. If the can starts bulging while cooking take it off the heat immediately and stand well back.
The Dulce de Leche produced in this way tends to be a little coarser and less flavoursome.
An english cousin was shown the simple recipe once but unfortunately forgot that it was cooking. 6 hours later the pan had boiled dry and the can had exploded spraying hot metal and hot overcooked Dulce de Leche everywhere. As it was my mother's kitchen and it still smelled of Dulce de Leche 3 months later she was less than pleased.
Another time a very old friend of my mother's was living in the States and started to crave real Dulce de Leche - just like grandmother used to make. She had been using the condensed milk recipe but this time it just wasn't good enough.
She called her Argentine friend in the next town, who after some deliberation said 'No I don't have a recipe for it, but if you take a tin of sweetened condensed milk...'.
My mother's friend then called an Argentine friend in the next county, who said, after some thought, 'Well if you take a tin of sweetened condensed milk...'.
Calls were placed to assorted Argentine friends throughout the Eastern Seaboard. Who without exception replied: 'I don't know the proper recipe but if you take a tin of...'.
My mother's friend not being one to give up without a fight said to herself 'Right, I'll call up the Argentine Embassy in Washington D.C.'.
The operator receiving her call was more than a little surprised by her request and had to reply that she didn't know but if my mother's friend would hold then the operator would ask around in the embassy.
Twenty minutes passed and the operator returned to the call.
'Well I asked everybody, even the Ambassador's chef and the Ambassador's wife and none of them had the recipe, but if you take a tin of...'.
A few weeks after, my mother received a letter from her friend telling this story and my mother was able to send back her own grandmother's recipe as I have recorded above.
Despite largely growing up in England I was exposed to a fair chunk of another culture for which I will always be grateful. A significant part of that is South American cuisine. Dulce de Leche (Milk Jam) is one of the elements of South American cooking that plays no small part in a number of my family's stories.
The recipe for Dulce de Leche is deceptively simple:
- Two cups of milk.
- One cup of sugar.
- A pinch of cream of Tartar.
- Vanilla.
Simply place all the ingredients into a thick pan over a low heat and cook until the mixture turns a medium caramel brown and thickens, stirring occasionally. This can take anything up to an hour and a half.
The resulting concoction can be eaten with a spoon, used in cake and pastry fillings or just spread on bread.
A rather more simple way of preparing it (not without its own risks) is to boil a can of sweetened condensed milk for 2 and a half hours. Remember to keep an eye on it and top up the water if necessary. Do not open the can in any circumstance until it has had a chance to cool. If the can starts bulging while cooking take it off the heat immediately and stand well back.
The Dulce de Leche produced in this way tends to be a little coarser and less flavoursome.
An english cousin was shown the simple recipe once but unfortunately forgot that it was cooking. 6 hours later the pan had boiled dry and the can had exploded spraying hot metal and hot overcooked Dulce de Leche everywhere. As it was my mother's kitchen and it still smelled of Dulce de Leche 3 months later she was less than pleased.
Another time a very old friend of my mother's was living in the States and started to crave real Dulce de Leche - just like grandmother used to make. She had been using the condensed milk recipe but this time it just wasn't good enough.
She called her Argentine friend in the next town, who after some deliberation said 'No I don't have a recipe for it, but if you take a tin of sweetened condensed milk...'.
My mother's friend then called an Argentine friend in the next county, who said, after some thought, 'Well if you take a tin of sweetened condensed milk...'.
Calls were placed to assorted Argentine friends throughout the Eastern Seaboard. Who without exception replied: 'I don't know the proper recipe but if you take a tin of...'.
My mother's friend not being one to give up without a fight said to herself 'Right, I'll call up the Argentine Embassy in Washington D.C.'.
The operator receiving her call was more than a little surprised by her request and had to reply that she didn't know but if my mother's friend would hold then the operator would ask around in the embassy.
Twenty minutes passed and the operator returned to the call.
'Well I asked everybody, even the Ambassador's chef and the Ambassador's wife and none of them had the recipe, but if you take a tin of...'.
A few weeks after, my mother received a letter from her friend telling this story and my mother was able to send back her own grandmother's recipe as I have recorded above.
September 13, 2006
Extension Points
This entry is dedicated to Hardev who came up and ever so politely reminded me that it has been some weeks since my last one.
I've been accumulating topics and do have a few things that I want to talk about so here is one.
A classic refrain in the IT business is 'future proofing', a dangerous and terrible thing. All too often I have sat through requirements and design meetings where people sit and try to anticipate all future ways in which the software could be used. If you ever find yourself in such a meeting, either take it over and talk about 'extension points' or run (don't walk) for the nearest exit and wait for the bloated mess that results to collapse in on itself.
An extension point is an abstraction that allows the easy extension of application behaviour by using patterns such as decorator, factory, strategy etc. Unfortunately as I've already discussed many moons ago, abstractions do make it more difficult to comprehend the code; this means that just adding extension points do have a cost. I find that the extension points that are likely to be used in the future are the ones that are 'sympathetic' to the thrust of the functionality.
In the end extension points should fall naturally out of the design process, however they can be used as a good argument to use against the 'future proofers'.
I've been accumulating topics and do have a few things that I want to talk about so here is one.
A classic refrain in the IT business is 'future proofing', a dangerous and terrible thing. All too often I have sat through requirements and design meetings where people sit and try to anticipate all future ways in which the software could be used. If you ever find yourself in such a meeting, either take it over and talk about 'extension points' or run (don't walk) for the nearest exit and wait for the bloated mess that results to collapse in on itself.
An extension point is an abstraction that allows the easy extension of application behaviour by using patterns such as decorator, factory, strategy etc. Unfortunately as I've already discussed many moons ago, abstractions do make it more difficult to comprehend the code; this means that just adding extension points do have a cost. I find that the extension points that are likely to be used in the future are the ones that are 'sympathetic' to the thrust of the functionality.
In the end extension points should fall naturally out of the design process, however they can be used as a good argument to use against the 'future proofers'.
July 30, 2006
A meeting with an old friend...
I was pleasantly surprised the other day to hear from Ian Hannaford. He wanted to benefit from what little wisdom I could muster. We had a good chat about his new role (thrown in the deep end as usual) and generally had a good old chat. Ian boosted my ego by telling me that he had directed other people to my blog (Hi other people!) and we gossipped about old friends and talked techie.
In the course of our chat, Ian told me about his pattern use but that he found the Gang of Four book a touch dry and academic. He suggested that I could at some stage write something to make it a little more approachable and relevant.
I'm going to think on this a bit and may start writing entries on situations where I have used GOF patterns and why I used them.
I'm going to toddle now and have me a bite of dinner (Teryaki beef, sticky rice and pak choi.).
P.S. I got LocoRoco on the PSP this weekend - at last I am using the PSP as a games machine instead of a mobile video player. LocoRoco is great!
In the course of our chat, Ian told me about his pattern use but that he found the Gang of Four book a touch dry and academic. He suggested that I could at some stage write something to make it a little more approachable and relevant.
I'm going to think on this a bit and may start writing entries on situations where I have used GOF patterns and why I used them.
I'm going to toddle now and have me a bite of dinner (Teryaki beef, sticky rice and pak choi.).
P.S. I got LocoRoco on the PSP this weekend - at last I am using the PSP as a games machine instead of a mobile video player. LocoRoco is great!
July 19, 2006
GPGPU with JOGL part 1.
Well I've started tinkering with the GPGPU concept that I mentioned in an earlier post. I've landed on JOGL as it seems to provide me with all the basic functionality that I am going to need and is reasonably cross-platform.
I need to be able to bind a texture (representing an input array of data) into a buffer against which I will run a shader program (the function that I want to perform on the data) and place the outcome of the shader program into a buffer from which I can extract the output array.
I'm struggling with a few handicaps -
I'm going to struggle on and hopefully I'll have a bitonic sort algorithm implemented before too long.
I need to be able to bind a texture (representing an input array of data) into a buffer against which I will run a shader program (the function that I want to perform on the data) and place the outcome of the shader program into a buffer from which I can extract the output array.
I'm struggling with a few handicaps -
- I'm using my PowerBook for this and support for OSX by JOGL is still a bit flakey.
- I've never programmed using GL APIs before so I'm having to learn them from scratch.
- Once I've grasped enought of the APIs, I still have to master at least one shader language.
I'm going to struggle on and hopefully I'll have a bitonic sort algorithm implemented before too long.
July 04, 2006
Apple and Bacon Omelette
I was visiting with some friends the other day, enjoying a very pleasant evening catching up. As I was just heading out the door to go home and cook myself supper, Henry jokingly asked me whether there was anything that he could do with some apples that he had in front of him for his own supper. In short order we had determined that there was some bacon in the fridge and in front of the bemused eyes of his mother, we had rolled up our sleeves and proceeded to cook a new omelette.
We used two to three rashers of salted rindless back bacon, two to three eggs, half a cup of milk and a quarter of a Pink Lady apple per person. The bacon was cut into lardons and the apple was finely diced. The eggs and milk were beaten together with a generous pinch of black pepper. A nob of butter was placed in the bottom of a very large pan and gently melted, we then added the bacon and cooked it through slowly, avoiding frying it to crunchiness, the apples were cooked with the bacon until soft and the egg mixture was added. The low heat was kept on until the eggs were nearly cooked through, the omelette was folded over with a palette knife and then cut into portions and served.
It was extremely delicious.
We used two to three rashers of salted rindless back bacon, two to three eggs, half a cup of milk and a quarter of a Pink Lady apple per person. The bacon was cut into lardons and the apple was finely diced. The eggs and milk were beaten together with a generous pinch of black pepper. A nob of butter was placed in the bottom of a very large pan and gently melted, we then added the bacon and cooked it through slowly, avoiding frying it to crunchiness, the apples were cooked with the bacon until soft and the egg mixture was added. The low heat was kept on until the eggs were nearly cooked through, the omelette was folded over with a palette knife and then cut into portions and served.
It was extremely delicious.
June 19, 2006
Facets
I first started thinking about facets after reading an article on java.net nearly two years ago.
I kind of liked the idea that object can gain attributes and behaviours and indeed gain and lose types through it's life cycle.
In normal OO practices where an object is defined having all the types that it is ever going to have (A String is an Object and a CharArray and that is all it will ever be). Facets would allow an object to gain and lose types (A panel in Swing could become a type of Window or a scrollable viewport in another Window). In the real world when a person joins a footbal team they gain the facet of being a footbal player and when they leave the team they lose it. The facet of being a football player brings a team association and a shirt number with it plus a lot of interesting behaviours involving a ball and a pitch.
A number of similar patterns exist such as Mixins, but mixins only really bring behaviour not type information. Unfortunately such a useful word has already been used here.
In fact the idea has already been had by this bunch, and unfortunately they have patented it as US Patent 6,513,157. I did nothing more about facets for quite some time after finding this.
A couple of weeks ago I came across some of the code that I had knocked together to play with facets and decided to bite the bullet and see if I could do something with it. I went through the patent again and realised that the patent covered an implementation of facets that did not need changes to source code. As long as I made sure that what I implemented required changes to existing objects to add the functionality then I would be fine.
I'm finally getting around to completing my implementation and when I've had a chance to explore it I'm going to make it available and blog its uses.
One thing has come out of my work on Facets - Abstract super classes are a snare and a delusion. Take an interface 'Faceted', implement it with a concrete class called 'FacetedSupport'. 'FacetedSupport' can be used as an ancestor of 'Faceted' objects OR it can be used as a support class for objects that are implementing the 'Faceted' interface. If you made it an abstract super class then you would be forced to create a sub-class to make use of its functionality.
I kind of liked the idea that object can gain attributes and behaviours and indeed gain and lose types through it's life cycle.
In normal OO practices where an object is defined having all the types that it is ever going to have (A String is an Object and a CharArray and that is all it will ever be). Facets would allow an object to gain and lose types (A panel in Swing could become a type of Window or a scrollable viewport in another Window). In the real world when a person joins a footbal team they gain the facet of being a footbal player and when they leave the team they lose it. The facet of being a football player brings a team association and a shirt number with it plus a lot of interesting behaviours involving a ball and a pitch.
A number of similar patterns exist such as Mixins, but mixins only really bring behaviour not type information. Unfortunately such a useful word has already been used here.
In fact the idea has already been had by this bunch, and unfortunately they have patented it as US Patent 6,513,157. I did nothing more about facets for quite some time after finding this.
A couple of weeks ago I came across some of the code that I had knocked together to play with facets and decided to bite the bullet and see if I could do something with it. I went through the patent again and realised that the patent covered an implementation of facets that did not need changes to source code. As long as I made sure that what I implemented required changes to existing objects to add the functionality then I would be fine.
I'm finally getting around to completing my implementation and when I've had a chance to explore it I'm going to make it available and blog its uses.
One thing has come out of my work on Facets - Abstract super classes are a snare and a delusion. Take an interface 'Faceted', implement it with a concrete class called 'FacetedSupport'. 'FacetedSupport' can be used as an ancestor of 'Faceted' objects OR it can be used as a support class for objects that are implementing the 'Faceted' interface. If you made it an abstract super class then you would be forced to create a sub-class to make use of its functionality.
June 11, 2006
Water, Water Everywhere and not a Drop to Drink
I never fail to be irritated by short-sighted stupidity.
I live in the South of England and have been watching all the green spaces where I live being relentlessly developed. I often feel that in order to eliminate the North-South divide, the government is trying to get the entire population to live in the South. Every few months there seems to be a new diktat that several thousand new homes be built in one of the Southern Counties.
One of the problems is that we are in the middle of one of the worst droughts to ever hit the Southern Counties. Why are we moving thousands of people to an area that does not have the infrastructure to support them? It seems that someone is failing their basic planning course - ensure that you have sufficient resource available before you start.
Something that adds heavily to the irony is that, as the South is already very densely populated, most of the decent land has already been used. This means that many of the new developments are occurring on less-suitable land such as flood-plains. Already people are being flooded out of their homes while they can't use their sprinklers.
Will the time come when people are forced to use stand-pipes while their downstairs is under water?
I live in the South of England and have been watching all the green spaces where I live being relentlessly developed. I often feel that in order to eliminate the North-South divide, the government is trying to get the entire population to live in the South. Every few months there seems to be a new diktat that several thousand new homes be built in one of the Southern Counties.
One of the problems is that we are in the middle of one of the worst droughts to ever hit the Southern Counties. Why are we moving thousands of people to an area that does not have the infrastructure to support them? It seems that someone is failing their basic planning course - ensure that you have sufficient resource available before you start.
Something that adds heavily to the irony is that, as the South is already very densely populated, most of the decent land has already been used. This means that many of the new developments are occurring on less-suitable land such as flood-plains. Already people are being flooded out of their homes while they can't use their sprinklers.
Will the time come when people are forced to use stand-pipes while their downstairs is under water?
May 31, 2006
More on Threads and Parallelisation
Two posts in as many days - a brand new record for me.
I talked a little while ago about the future of programming being parallel / multi-core: Good Threaded Code.
Trawling through the one of my favourite web sites I came upon this piece: The Register: Deconstructing databases with Jim Gray. The title is a little misleading, as Mr. Gray actually spends more time talking about the use of GPUs for massively parallel processing and the future of programming in such an environment. He mentions that a common language called 'Accelerator' is already being defined for programming GPUs for parallel processing within a Microsoft environment. Now what I want to know is whether there is similar functionality available for Java? If there isn't I suppose that we'll need to start something in this area.
I want to be able to implement this algorithm and see how well we can get it accelerated: Bitonic Sort.
I talked a little while ago about the future of programming being parallel / multi-core: Good Threaded Code.
Trawling through the one of my favourite web sites I came upon this piece: The Register: Deconstructing databases with Jim Gray. The title is a little misleading, as Mr. Gray actually spends more time talking about the use of GPUs for massively parallel processing and the future of programming in such an environment. He mentions that a common language called 'Accelerator' is already being defined for programming GPUs for parallel processing within a Microsoft environment. Now what I want to know is whether there is similar functionality available for Java? If there isn't I suppose that we'll need to start something in this area.
I want to be able to implement this algorithm and see how well we can get it accelerated: Bitonic Sort.
May 30, 2006
Process Singleton or Cluster Mutex.
My friend Neil and I have been discussing this pattern for some time. I finally came up with a couple of sober yet pithy names for it as to date we've been calling it the 'Talking Stick Pattern'. This pattern is intended to be used primarily in clustered applications though there is nothing to prevent it being used elsewhere.
The singleton pattern is well known and various attempts have been made to implement it within a cluster. For most instances a node-singleton is sufficient as the singleton pattern is used to prevent excessive memory usage - effectively a pool of one. However on occasions the singleton pattern is used to provide access control to a shared resource that cannot support multiple concurrent accesses or to control the running of a business process that could have issues if run concurrently. Failover is the weakness with implementing a cluster-singleton: You are either dependent on a vendor-specific approach or you have to come up with a solution of your own.
The solution that Neil and I have arrived at is derived from the 'Talking Stick' idea used in group discussions. Rather than have a pell-mell of competing voices, the talking stick is handed to an individual who can then talk, when he is done the talking stick is handed on to the next individual who is allowed to talk. When you do not have the talking stick you are not allowed to talk.
We apply this to a set of objects. Before the object can act, it must get hold of the 'talking stick'. This means that only one object can act at a time. The implementation of the talking stick must be robust in the event of a failure and we have two tried and tested implementations that work.
The first talking stick implementation is a little database dependent. The use of a row-lock in a database that supports either a read-past semantic or like Oracle supports SELECT...FOR UPDATE NOWAIT. When the transaction commits, the lock is released for the next access. If something goes wrong the database transaction rolls back and the row lock becomes available for another transaction.
The second implementation relies on a transactional JMS implementation and a message on a queue is used as the talking stick. An object waits on the queue for a message and when it has it, it is allowed to act. When it has finished it places the message back on the queue for the next object to access. Again, when a failure occurs, the transaction tolls back and the talking stick becomes available again.
Depending on whether it is being used to manage processes or manage access control I would call it a Process Singleton or a Cluster Mutex.
Edit - Gil, a colleague working with me, pointed out that the talking stick is a form of Token.
The singleton pattern is well known and various attempts have been made to implement it within a cluster. For most instances a node-singleton is sufficient as the singleton pattern is used to prevent excessive memory usage - effectively a pool of one. However on occasions the singleton pattern is used to provide access control to a shared resource that cannot support multiple concurrent accesses or to control the running of a business process that could have issues if run concurrently. Failover is the weakness with implementing a cluster-singleton: You are either dependent on a vendor-specific approach or you have to come up with a solution of your own.
The solution that Neil and I have arrived at is derived from the 'Talking Stick' idea used in group discussions. Rather than have a pell-mell of competing voices, the talking stick is handed to an individual who can then talk, when he is done the talking stick is handed on to the next individual who is allowed to talk. When you do not have the talking stick you are not allowed to talk.
We apply this to a set of objects. Before the object can act, it must get hold of the 'talking stick'. This means that only one object can act at a time. The implementation of the talking stick must be robust in the event of a failure and we have two tried and tested implementations that work.
The first talking stick implementation is a little database dependent. The use of a row-lock in a database that supports either a read-past semantic or like Oracle supports SELECT...FOR UPDATE NOWAIT. When the transaction commits, the lock is released for the next access. If something goes wrong the database transaction rolls back and the row lock becomes available for another transaction.
The second implementation relies on a transactional JMS implementation and a message on a queue is used as the talking stick. An object waits on the queue for a message and when it has it, it is allowed to act. When it has finished it places the message back on the queue for the next object to access. Again, when a failure occurs, the transaction tolls back and the talking stick becomes available again.
Depending on whether it is being used to manage processes or manage access control I would call it a Process Singleton or a Cluster Mutex.
Edit - Gil, a colleague working with me, pointed out that the talking stick is a form of Token.
May 21, 2006
Are They Running the Country or Running for Re-Election?
This is an huge question, but one which has a simple answer.
I believe that all political parties in Britain are about running for re-election and running the country is a side issue.
This has not always been the case, but the temptation to run for election is one of the great weaknesses of democracy. It is much harder to get re-elected by doing a good job of running the country than by standing around for photo opportunities and telling us what we want to hear. Especially when you consider that your opponents only have to do the photo opportunities. Of course the machiavelllian solution is to get your opponents deeply enmeshed in running the country 'in the interest of non-partisan politics'. The opposition would get credit for not being out of practice in running the country and for any good work they do. You'd increase the availability of competent people for key positions, tie your opponents up and level the field when it came time for elections. With more competent people, the country would benefit overall and you'd get the credit for that (and of course for the good work that your opposition do...).
The trouble is exacerbated by the press. We are told that a strong fifth estate is one of the great pillars of a strong democracy. Unfortunately at the moment our press is lazy and lets the politicians set the agenda. Many stories are handed to them by the current political leadership and by their opposition in their struggle to be elected. It is also in the press' interest to keep politics partisan as the latest bickering is an easy story that sells papers and airtime.
I wonder whether the press could ever be convinced that the real story is in the fact that politicians are running for re-election and not running the country. What would happen if the press were banned from naming individual politicians except when they were doing something wrong? Can democracy ever produce a leadership that truly focusses on running the country and is able to work together with their opponents for the common good? Any other ideas?
I believe that all political parties in Britain are about running for re-election and running the country is a side issue.
This has not always been the case, but the temptation to run for election is one of the great weaknesses of democracy. It is much harder to get re-elected by doing a good job of running the country than by standing around for photo opportunities and telling us what we want to hear. Especially when you consider that your opponents only have to do the photo opportunities. Of course the machiavelllian solution is to get your opponents deeply enmeshed in running the country 'in the interest of non-partisan politics'. The opposition would get credit for not being out of practice in running the country and for any good work they do. You'd increase the availability of competent people for key positions, tie your opponents up and level the field when it came time for elections. With more competent people, the country would benefit overall and you'd get the credit for that (and of course for the good work that your opposition do...).
The trouble is exacerbated by the press. We are told that a strong fifth estate is one of the great pillars of a strong democracy. Unfortunately at the moment our press is lazy and lets the politicians set the agenda. Many stories are handed to them by the current political leadership and by their opposition in their struggle to be elected. It is also in the press' interest to keep politics partisan as the latest bickering is an easy story that sells papers and airtime.
I wonder whether the press could ever be convinced that the real story is in the fact that politicians are running for re-election and not running the country. What would happen if the press were banned from naming individual politicians except when they were doing something wrong? Can democracy ever produce a leadership that truly focusses on running the country and is able to work together with their opponents for the common good? Any other ideas?
May 19, 2006
Learning: By Rote Vs, Asking Why.
I had a very pleasant lunch yesterday with two Voca colleagues, Roger and Peter. As my lunches tend to always go, we ended up discussing a number of interesting topics, this lunch steered entirely clear of technology.
We discussed counselling, consciousness, upbringing and education. I told Roger and Peter in my typical bombastic manner about a very interesting piece of research I read recently in New Scientist. The article touched on the manners in which humans and our cousins great apes learn from our parents. If you were asked which species is more likely to learn by simple, exact copying of parental activities, which species would you pick?
It turns out that humans are far more likely than any other great ape to shortcut learning by simple imitation. The example that is often quoted is the Mother making a 'pot roast', she cuts off one end of the joint and puts it in the pot beside the main part. Her daughter asks her why she does that and she is forced to reply that she doesn't know, her mother did it that way. So the Mother asks here mother who replies that her own mother always did it that way. The Mother then calls her grandmother who replies that she started doing that because she didn't have a big enough pot.
It appears that humans are extremely likely to learn by rote. It seems to be a shortcut that we have evolved. I believe that this shortcut emerged because of the volume of information that we are forced to learn in order to survive in our culture. If we questioned every single tiny fact, we would never learn enough to sustain the complexity of our culture before we were 50 years old.
That's not to say that questioning is not important. Without 'Why?' we would never have progressed our culture.
I would suggest that the best education a child can get is one that is primarily by rote that does not suppress the desire to question. In effect there is a balance: sufficient rote learning to provide a basic body of knowledge to survive in the world coupled with time spent teaching how to question this body of knowledge.
I believe that you actually have to have a basic level of knowledge before you can decide which questions are worth asking.
When I say 'Culture' I mean it in the more scientific sense of the set of learnt behaviours and knowledge that we as a species learn rather than are born knowing.
We discussed counselling, consciousness, upbringing and education. I told Roger and Peter in my typical bombastic manner about a very interesting piece of research I read recently in New Scientist. The article touched on the manners in which humans and our cousins great apes learn from our parents. If you were asked which species is more likely to learn by simple, exact copying of parental activities, which species would you pick?
It turns out that humans are far more likely than any other great ape to shortcut learning by simple imitation. The example that is often quoted is the Mother making a 'pot roast', she cuts off one end of the joint and puts it in the pot beside the main part. Her daughter asks her why she does that and she is forced to reply that she doesn't know, her mother did it that way. So the Mother asks here mother who replies that her own mother always did it that way. The Mother then calls her grandmother who replies that she started doing that because she didn't have a big enough pot.
It appears that humans are extremely likely to learn by rote. It seems to be a shortcut that we have evolved. I believe that this shortcut emerged because of the volume of information that we are forced to learn in order to survive in our culture. If we questioned every single tiny fact, we would never learn enough to sustain the complexity of our culture before we were 50 years old.
That's not to say that questioning is not important. Without 'Why?' we would never have progressed our culture.
I would suggest that the best education a child can get is one that is primarily by rote that does not suppress the desire to question. In effect there is a balance: sufficient rote learning to provide a basic body of knowledge to survive in the world coupled with time spent teaching how to question this body of knowledge.
I believe that you actually have to have a basic level of knowledge before you can decide which questions are worth asking.
When I say 'Culture' I mean it in the more scientific sense of the set of learnt behaviours and knowledge that we as a species learn rather than are born knowing.
May 11, 2006
Driving Concentration
When I first started driving I had an old MGB Roadster (known as Summer). It was a spartan driving experience the height of luxury being a heater that had only two settings off and BURN YOU TO DEATH!
My driving was probably at its best when I drove Summer, I kept my temper better, drove more defensively and was generally more considerate.
When I started racking up the motorway miles I got a new car. It was a lovely little Ford Puma (known as Sue). It was immensely more reliable and more luxurious.
However it was with Sue that my driving started to disimprove.
My concentration became worse, I failed to anticipate and, when something happened unexpectedly, I was more inclined to lose my temper. I came to realise that something needed to be done, so I thought about it and finally came to a conclusion.
It was the CD/Radio.
In dear old rackety Summer, there was no point to putting a radio in as I wouldn't have been able to hear it above the engine and the noises of the world outside. I was forced to keep all my concentration on my driving and the environment around me. With Sue the radio almost automatically went on and my concentration drifted. I've now taken to turning the radio off and my driving is beginning to return to the quality that it enjoyed before my fall from grace.
My driving was probably at its best when I drove Summer, I kept my temper better, drove more defensively and was generally more considerate.
When I started racking up the motorway miles I got a new car. It was a lovely little Ford Puma (known as Sue). It was immensely more reliable and more luxurious.
However it was with Sue that my driving started to disimprove.
My concentration became worse, I failed to anticipate and, when something happened unexpectedly, I was more inclined to lose my temper. I came to realise that something needed to be done, so I thought about it and finally came to a conclusion.
It was the CD/Radio.
In dear old rackety Summer, there was no point to putting a radio in as I wouldn't have been able to hear it above the engine and the noises of the world outside. I was forced to keep all my concentration on my driving and the environment around me. With Sue the radio almost automatically went on and my concentration drifted. I've now taken to turning the radio off and my driving is beginning to return to the quality that it enjoyed before my fall from grace.
March 29, 2006
The Real Questions.
I've been watching the various manoeuverings going on in parliament to change various aspects of the balance between the legal system and the political system in this country.
When misgivings are raised, the politicians always seem to justify their actions on two bases:
- It is necessary because the current system is unwieldy/expensive.
- Don't you trust us/me?
The real questions that should be asked of the politicians are:
- Whether I trust you or not is irrelevant. Can I trust your successors? Can you guarantee that the 2nd, 3rd or 4th set of politicians to be voted in won't abuse the powers that you are giving them?
- Don't you think it is worth the inconvenience/expense in order to guarantee a reasonable level of freedom from oppression?
I wonder whether we will ever see these questions posed clearly, well and in a situation where the politician is forced to answer.
March 16, 2006
My Preferred try...finally Semantic
Carrying on a JDBC motif from my previous entry, I want to talk about the use of try...finally blocks in managing resources.
All too often I see null-checking used in finally blocks because this kind of construct is used:
I personally prefer this kind of construct which eliminates the null check at the expense of adding another try..catch block:
This is purely stylistic, but I prefer not to have the null check and I do like having the exceptions all towards the end of the unit of code. Do not be tempted to remove the catch from the connection closure as you will mask the original cause of the error. This semantic gets even better if you need to propagate the core SQL exception up to a common handler as it then looks even tidier:
All too often I see null-checking used in finally blocks because this kind of construct is used:
Connection conn = null;
try
{
conn = ds.getConnection();
//do some work with the connection.
...
}
catch(SQLException sqle)
{
LOG.error(sqle);
}
finally
{
if(conn!=null)
{
try
{
conn.close();
}
catch(SQLException sqle)
{
LOG.error(sqle);
}
}
}
I personally prefer this kind of construct which eliminates the null check at the expense of adding another try..catch block:
try
{
Connection conn = ds.getConnection();
try
{
//do some work with the connection.
...
}
finally
{
try
{
conn.close();
}
catch(SQLException sqle)
{
LOG.error(sqle);
}
}
}
catch(SQLException sqle)
{
LOG.error(sqle);
}
This is purely stylistic, but I prefer not to have the null check and I do like having the exceptions all towards the end of the unit of code. Do not be tempted to remove the catch from the connection closure as you will mask the original cause of the error. This semantic gets even better if you need to propagate the core SQL exception up to a common handler as it then looks even tidier:
Connection conn = ds.getConnection();
try
{
//do some work with the connection.
...
}
finally
{
try
{
conn.close();
}
catch(SQLException sqle)
{
LOG.error(sqle);
}
}
//SQLException gets propagated out to another block of code handling it.
March 10, 2006
A Connection Pool That Satisfies a Previous Rant
A little while ago I was talking about how many connection pools do not properly satisfy the JDBC specifications (Here.). Many home rolled connection pools do not close the resources associated with a connection before returning it to the pool.
I finally pulled my finger out and decided to have a look for a connection pool that behaved properly. Having pulled the source code for a number of connection pools (and shuddered once or twice when reading), I found a connection pool that actually works properly: Apache Commons-DBCP. The connection pool keeps track of all Statements that are created and closes them and their associated resources when the connection is returned to the pool.
As long as this pool is used, we can avoid all the JDBC clutter in our finally blocks and just close the connection when we're done.
I finally pulled my finger out and decided to have a look for a connection pool that behaved properly. Having pulled the source code for a number of connection pools (and shuddered once or twice when reading), I found a connection pool that actually works properly: Apache Commons-DBCP. The connection pool keeps track of all Statements that are created and closes them and their associated resources when the connection is returned to the pool.
As long as this pool is used, we can avoid all the JDBC clutter in our finally blocks and just close the connection when we're done.
February 23, 2006
A Persuasive Theory on the Origin of Consciousness
I've been reading a very interesting book these past few days, Julian Jaynes' "The Origin of Consciousness in the Breakdown of the Bicameral Mind".
I've often thought about how we came to be as we are and read upon the subject, this book presents the best theory that I have yet seen.
According to the theory, consciousness is a late comer to the party.
Humanity's evolution of speech and reason did not need consciousness. Speech allowed far larger social groups to be coherent and reason allowed us to cope with the increased complexity of our environments.
As groups increased in size and settlements were formed, humanity needed some means of "sustaining" activities that have no immediate apparent reward.
The mechanism postulated is that of part of a brain that evolved to store the admonitions and advice given by parents and those in authority and to play it back. To a modern mind this playback would appear to be an auditory hallucination. Thus a non-conscious human could persist in preparing a field for planting despite the lack of immediate reward. A voice would be heard, possibly of a parent or of a leader continually reminding them to 'prepare the field for planting'.
Initially this mechanism would have been a simple playback mechanism, but driven by societal advances, it would have increased in complexity and would have been able to synthesise original commands.
The potential ramifications are interesting, the auditory hallucinations based on the voice of a person would have persisted long after the person had died, leading to a belief in life after death and even to worship of ancestors. As the complexity of the mechanism increased, there is no reason not to assume that the voices were limited to known people, and instead could have been interpreted as coming from gods.
It is interesting to note how much of the early writings available to us, talk about how people acted on the promptings of gods or goddesses and how there is very little about personal motivation. Indeed a case can be made that the introspection is a later addition to the text.
In effect early humanity were hallucinating schizophrenics (Bicameral) and much of the structure of ancient societies can be explained by this.
Consciousness only emerged when language gained enough complexity to support a concept of "I" and humanity was forced to evolve mentally by the breakdown of their bicameral societies. Consciousness emerged as an outcome of the integration of the hallucinatory aspects of our minds with the logical/active portions and the ability to conceptualise a self.
I've summarised very briefly here my understanding of a much more complete argument and have only touched on its consequences. I came across this theory first in fiction through the works of Neal Stepenson and other authors, now I can see where they took there inspiration.
I'm certain that this theory is not totally correct, but I would argue that it needs to be considered seriously as we continue to try to arrive at a full understanding of consciousness. It addresses for me how consciousness could arise without a significant physiological change.
The 'self' may be just a construct and this speaks interestingly for future human social and mental evolution.
I've often thought about how we came to be as we are and read upon the subject, this book presents the best theory that I have yet seen.
According to the theory, consciousness is a late comer to the party.
Humanity's evolution of speech and reason did not need consciousness. Speech allowed far larger social groups to be coherent and reason allowed us to cope with the increased complexity of our environments.
As groups increased in size and settlements were formed, humanity needed some means of "sustaining" activities that have no immediate apparent reward.
The mechanism postulated is that of part of a brain that evolved to store the admonitions and advice given by parents and those in authority and to play it back. To a modern mind this playback would appear to be an auditory hallucination. Thus a non-conscious human could persist in preparing a field for planting despite the lack of immediate reward. A voice would be heard, possibly of a parent or of a leader continually reminding them to 'prepare the field for planting'.
Initially this mechanism would have been a simple playback mechanism, but driven by societal advances, it would have increased in complexity and would have been able to synthesise original commands.
The potential ramifications are interesting, the auditory hallucinations based on the voice of a person would have persisted long after the person had died, leading to a belief in life after death and even to worship of ancestors. As the complexity of the mechanism increased, there is no reason not to assume that the voices were limited to known people, and instead could have been interpreted as coming from gods.
It is interesting to note how much of the early writings available to us, talk about how people acted on the promptings of gods or goddesses and how there is very little about personal motivation. Indeed a case can be made that the introspection is a later addition to the text.
In effect early humanity were hallucinating schizophrenics (Bicameral) and much of the structure of ancient societies can be explained by this.
Consciousness only emerged when language gained enough complexity to support a concept of "I" and humanity was forced to evolve mentally by the breakdown of their bicameral societies. Consciousness emerged as an outcome of the integration of the hallucinatory aspects of our minds with the logical/active portions and the ability to conceptualise a self.
I've summarised very briefly here my understanding of a much more complete argument and have only touched on its consequences. I came across this theory first in fiction through the works of Neal Stepenson and other authors, now I can see where they took there inspiration.
I'm certain that this theory is not totally correct, but I would argue that it needs to be considered seriously as we continue to try to arrive at a full understanding of consciousness. It addresses for me how consciousness could arise without a significant physiological change.
The 'self' may be just a construct and this speaks interestingly for future human social and mental evolution.
January 31, 2006
Change and Stability
I've been giving some thought of late to how groups of people are run, not just at a team level but at an organisational or even a national level.
I've been trying to draw lessons from out politicians past and present. Not many of the lessons have been how to do it well...
One of the major things that have come out of this thought is the dynamic tension between change and stability. Notice the words that I have used, another way of expressing it is the tension between chaos and stasis.
An example of this is the NHS. It is obvious to all politicians that something must be done. The trouble is they never seem to get the something quite right. The old NHS worked as well as it did before the politicians started fiddling because the patients, nurses, doctors and administrators had worked out a modus vivendi. They had discovered ways to work around the grossesr of flaws and it more or less worked. Unfortunately for the NHS it has become a political football, a month doesn't go by without some new announcement. This change is done with the best of intentions but it never gives the participants a chance to settle into the new practices and so the grossest of flaws never get worked around as new ones are introduced the whole time.
Change is essential, especially in this day and age. New technologies, new ideas and new social groups all mean that many of the old ways of doing things do not remain correct. You can't stand still.
But neither do you have to keep running.
I think that the lesson that we and our politicians need to learn is to moderate the rate of change. The real skill comes in introducing changes that only do what is needed and no more. The necessity is to fine-tune the structures we have and only do significant restructuring when absolutely necessary.
This even extends into my domain. It is very tempting to completely re-write systems from the ground up with no regard for the havoc that those changes will cause. All in pursuit of some perception of perfection.
Lasting perfection is unattainable in a dynamic world. All we can ever do is approach it by making sensible, minor changes to proven, stable systems.
The real skill may be in knowing when not to do something...
I've been trying to draw lessons from out politicians past and present. Not many of the lessons have been how to do it well...
One of the major things that have come out of this thought is the dynamic tension between change and stability. Notice the words that I have used, another way of expressing it is the tension between chaos and stasis.
An example of this is the NHS. It is obvious to all politicians that something must be done. The trouble is they never seem to get the something quite right. The old NHS worked as well as it did before the politicians started fiddling because the patients, nurses, doctors and administrators had worked out a modus vivendi. They had discovered ways to work around the grossesr of flaws and it more or less worked. Unfortunately for the NHS it has become a political football, a month doesn't go by without some new announcement. This change is done with the best of intentions but it never gives the participants a chance to settle into the new practices and so the grossest of flaws never get worked around as new ones are introduced the whole time.
Change is essential, especially in this day and age. New technologies, new ideas and new social groups all mean that many of the old ways of doing things do not remain correct. You can't stand still.
But neither do you have to keep running.
I think that the lesson that we and our politicians need to learn is to moderate the rate of change. The real skill comes in introducing changes that only do what is needed and no more. The necessity is to fine-tune the structures we have and only do significant restructuring when absolutely necessary.
This even extends into my domain. It is very tempting to completely re-write systems from the ground up with no regard for the havoc that those changes will cause. All in pursuit of some perception of perfection.
Lasting perfection is unattainable in a dynamic world. All we can ever do is approach it by making sensible, minor changes to proven, stable systems.
The real skill may be in knowing when not to do something...
December 19, 2005
Good Threaded Code.
I've recently upgraded my main x86 development machine. After a lot of to-ing and fro-ing I decided on an AMD Athlon 64 X2 processor. It has become increasingly clear that the wave of the future is multi-processor / multi-core. Intel and AMD are both talking about 8 core processors before the end of the decade, Sun have just release their Niagara core, Microsoft/IBM are using a 3 core Power PC CPU in the new XBox and Sony/IBM have produced the Cell processor initially going multi-core in the PlayStation 3.
With the advent of consumer level multi-core processors in both home computers and consoles it is becoming clear that we are all going to write more in the way of threaded and concurrent code.
I for one am looking forward to having all that processor power, but as usual the question is how are we, as developers, going to make best use of it?
A part of the solution will be the increasing rise of APIs and frameworks such as that by Doug Lea http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html for Java. By providing well designed and well tested concurrency code, programming multi-threaded applications will be simplified.
Application Servers will take up part of the burden, but at the usual price of lowered performance and increased cost.
I suspect that certain diagrams will become worth their weight in gold such as UML Activity diagrams.
Lesser known concurreny paradigms such as spin-locks will become more widely understood.
The major expense in using these multi-core systems will be in the synchronization points when different threads / processes exchange data. The skill will be in minimising the impact of the synchronization points.
I'd recommend all developers / designers / architects intending on making any money over the next decade to get their hands on this new generation of SMP machines as soon as possible and start understanding the complexities and opportunities.
With the advent of consumer level multi-core processors in both home computers and consoles it is becoming clear that we are all going to write more in the way of threaded and concurrent code.
I for one am looking forward to having all that processor power, but as usual the question is how are we, as developers, going to make best use of it?
A part of the solution will be the increasing rise of APIs and frameworks such as that by Doug Lea http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html for Java. By providing well designed and well tested concurrency code, programming multi-threaded applications will be simplified.
Application Servers will take up part of the burden, but at the usual price of lowered performance and increased cost.
I suspect that certain diagrams will become worth their weight in gold such as UML Activity diagrams.
Lesser known concurreny paradigms such as spin-locks will become more widely understood.
The major expense in using these multi-core systems will be in the synchronization points when different threads / processes exchange data. The skill will be in minimising the impact of the synchronization points.
I'd recommend all developers / designers / architects intending on making any money over the next decade to get their hands on this new generation of SMP machines as soon as possible and start understanding the complexities and opportunities.
October 20, 2005
Neil negotiating with Meeraj...
Poor Neil, another day in the Voca offices and another day trying to get Meeraj's approval for a code change.
Subscribe to:
Posts (Atom)