Colin's Journal: A place for thoughts about politics, software, and daily life.
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.
February 27th, 2003
Chicago
I finally saw Chicago tonight, after looking forward to seeing it for some time. It’s an entertaining, fun movie with some good dance numbers and a nice flow. It’s also a little disappointing.
I was hoping for something on a par with Moulin Rouge, and while Chicago is a good watch, it isn’t that good. I think part of the problem for me was having no sympathy for the main characters. I wanted to know how it ended, but didn’t really care one way or the other.
Catherine Zeta-Jones is superb, a great performance and a good presence on the screen, but Renée Zellweger was disappointing. The rest of the cast did a fairly good job. It’s possible that a second viewing, where the story would distract less from the musical elements, may improve my rating of the film.
February 26th, 2003
Closer and closer to the METAL
I’m nearly done with METAL. It’s all working, but I need to package it up, maybe write a few more tests, and certainly update the documentation on how to use it. I might even put together an example or something!
Overall then it’s going to be later this week, maybe Friday or weekend before it gets released to the world.
February 24th, 2003
An example of why copyright should expire
I’m starting this post with a diversion: take the name of the BBCs book reading activity “Book Group”. It can’t be a “Book Club” because the good name of book clubs is now tied too closely to those horrendous enterprises where you sign up to buy overpriced books, for the rest of your natural life.
Neatly passing the diversion onto the main topic, this years candidates for the BBCs Book Group are all old enough to be out of copyright, and available for free off Project Gutenberg. This is a good example of why copyright should expire after an adequate amount of time has elapsed to allow an author to benefit from their labours. I may even make time to read the chosen book, although I really should finish off the other three I’m half way through first (two are collections of short stories, and so shouldn’t really count).
February 22nd, 2003
The future of SimpleTAL
On a slightly less political note than my last post, work is once again underway on SimpleTAL. This time it’s thanks to an enquiry by Kevin Smith regarding support for METAL in SimpleTAL. METAL is a macro language that can co-exist with TAL, and which provides a way of copying parts of a document tree into a template and customising the part that was copied.
I’ve got an initial implementation working, but there is much to do before it is ready for release. I need to make sure that SimpleTAL implements the Zope behaviour for METAL, and that the existing TAL functionality integrates well with it. If all goes to plan however, I should have METAL support released within a few days.
Software
The full list of my published Software
Email: colin at owlfish.com