Colin's Journal: A place for thoughts about politics, software, and daily life.
March 13th, 2003
Recommended reading
If you are at all interested, even in a passive way, in British politics then there exists a weblog that you should be reading. Formerly known as British Spin, the author stopped blogging for a while, but is back now as good as ever.
Now known simply as British Politics I’ve added a link to my, very slowly growing, list of recommended weblogs.
March 13th, 2003
Islands and islands
Would you like to know the truth behind the story regarding the definition of an island? What about the “toys for pigs” affair?
Find some of the answers at Press Watch (via Why Do They Call Me Mr Happy)
March 11th, 2003
Small change to RSS
I’ve changed my RSS template to no longer include the Date/time in the title of the post. The change is motivated by my newly minted web-based, template driven, RSS aggregator. More on the aggregator in another post, except to say that the default template displays the date/time next to the titles of posts, so it was looking a bit strange on my own feeds…
March 9th, 2003
Bug fix release of SimpleTAL
I’ve just uploaded a bug fix release of SimpleTAL, now at version 3.1. This release also introduces the new code layout and distutils support, so installing should be even easier. The only thing to bear in mind when upgrading is that the import statements need to be changed to: from simpletal import simpleTAL, simpleTALES.
March 6th, 2003
Object Prevalence and data accessibility
On Monday I read this brief article regarding Object Prevalence [slashdot.org], but I’ve only just got around to writing down some of my thoughts on the subject. Object Prevalence is essentially just a mechanism for object persistence, with the added bonus of using a log to try and ensure some level of recoverability in the event of abnormal shutdown.
The comments to the article include some good points regarding the problems with this approach. It obviously can not scale to large enterprise applications like those seen in telecommunications and other such industries. It does not provide atomicity and transactions, limits the ability to use 3rd party reporting products, and restricts the ability to perform ad-hoc queries of your data. All of this is well and good, but it’s also rather obvious. There is a bigger issue with using the Object Prevalence approach, even when the size of your dataset, nature of transactions, and reporting requirements would otherwise lead you to thinking it’s a suitable solution.
The problem is one of data accessibility. An application is ultimately only a tool, it’s the data that you care about. The data is the thing that differentiates your installation from all others, it’s the data that you are dealing with that contains the value of what you are doing. Object Prevalence though locks your data into the implementation of the application, it’s only this particular application that can load and makes sense of the data that you have. This is in turn causes two other problems, one of integration and one of application lock-in.
The issue of integration is potentially the most serious. If you want any other application to be able to access that data then you need to interface at the object level, or the application that hosts the data needs to be modified to be able to extract the data in another, non-application specific, form. Either route will almost always require modification of your Object Prevalence based application, especially if you want the data sharing to be real time. Often integration of systems is a two way exercise, you want to be able to send data the other way as well, which in turn means your Object Prevalence application must also support an import mechanism or some object level API to specifically allow this kind of integration. By the time you have made the changes to your application to support these interfaces you have done much of the work that you were trying to avoid by using Object Prevalence in the first place.
Most integration between applications happens at a very crude level. Often it’s just a matter of reading data out of this database and writing it into a flat file, and conversely loading out of this file and putting it into that table. The reason that these integrations can be done cheaply and easily is because the storage mechanism where the data sits is widely understood, and completely application independent. Transferring data between spreadsheets and databases often is done using files in a CSV (Comma Separated Values) format, one of the crudest but simplest ways of formatting data around.
The other draw back, that of application lock-in, has the same root cause, but occurs when it’s time to move to a different application or system. Any team looking to migrate data from an old application to a new one wants the old data in a database or nice simple, application independent, format. If the data only exists as live data object written out using Object Prevalence, your estimated cost of migration has just increased significantly.
Ultimately, if your data matters to you, you have to understand how it’s stored. A relational database is preferable, but an easy to read file format (XML, or at a push fixed field format) is fine as well. Anything that is stored in it’s own, application dependent, format should be avoided unless the application has proven support for exporting and importing in an application independent format. It should always be possible to get your data out of an application specific format, but the opportunity cost of simple integration, as well as the actual cost of eventual migration should be thought on heavily before going in that direction.
March 4th, 2003
Flipping pancake
We actually remembered Pancake Tuesday this year, and made some excellent pancakes. Lots of lemon juice and sugar topped them off nicely, and the tossing went well enough that there none of them ended up on the walls, floor or ceiling.
March 4th, 2003
The future of the NHS?
There’s a bunch (although more than one hundred probably counts as more than a bunch) of labour MPs that are opposing the introduction of foundation hospitals. A foundation hospital is one that is not run by the government, but rather run as an independent not for profit organisation. They are, at the same time, still part of the NHS and “monitored” by stakeholder councils.
Obviously the effectiveness of the scheme will depend a great deal on the amount of control that remains with central government and the monitoring council. Too many targets and diktats from the government will eliminate the independence of the foundation hospitals, forcing them to ignore local concerns, and losing the opportunity to experiment and innovate on how provision is made. There is also the potential for abuse, especially in areas where there is no real choice as to which hospital NHS patients are sent to, and this presumably is what the monitoring councils are meant to stop.
Whether any of this will work is very open to question, but it is hard to see it being poorer than the centralised system that is in place today. The reasons given for opposition tend to focus on the fact that only qualifying hospitals will be given this independence, so leading to a “two-tier” hospital system where the independent hospitals can set their own wages and, the presumption is made, deliver better care. The obvious answer would be to make all hospitals independent, and while the government claims to have this aim, it seems unlikely to happen quickly. The opposing MPs however are against any differentiation in the service, still holding the ridiculous belief that all hospitals across the board can be brought up to the same level. This has never been achieved in the private sector (even when the product is identical, like the telephony market, there is still differentiation), and I can’t think of a public sector service that is of uniform quality across the board.
While MPs waking up to their responsibility of questioning the government is to be welcomed, it seems to me that they have picked a poor subject to do this over. Hopefully this new assertiveness will also be applied to those issues where the government is truly heading in a poor direction.
(Inspired by Why Do They Call Me My Happy?)
March 3rd, 2003
Distiled SimpleTAL
Thanks to the efforts of Michael Twomey the next release of SimpleTAL will be packaged in a more python friendly way with distutil support. Installation will be as simple as ‘python setup.py install’.
The timing of the next release will depend on the presence of any bug reports…
March 1st, 2003
SimpleTAL version 3.0 released
Version 3.0 of SimpleTAL is now available! The major new feature in this release is support for METAL. METAL is an HTML/XML macro language that augments TAL. It allows a sub-tree of a document to be associated with a macro name, and additionally for customisation points (slots) within that sub-tree to be defined. Once a macro has been defined in this way you can then graft the sub-tree into a (potentially different) document and optionally customise the macro by passing in another sub-tree (i.e. filling the slot).
While METAL is pretty nifty, it’s also very hard to explain without an example. So if you are unsure what it is and why you might want to use it, take a look at this example.
Software
The full list of my published Software
Email: colin at owlfish.com