Colin's Journal

As many of my readers will already know, my job situation is resolved. I will be rejoining Amdocs in the UK, based in London. The role is a new one for me, and should allow me to build on my existing project management skills.

Moving to London entails finding somewhere to live, a task that will start in earnest in the second week of January. Ideally I will find a spacious two bed room flat on a quiet road within a good neighbourhood that is inside zone one or two. I’ve received some advice on places to look that are likely to be within my price range. Muswell Hill looks promising, if further out from the centre than I had hoped for. Islington is another option but seems to be rather more pricey.

Hopefully I won’t have to spend more than a few days looking, before I find something that I like. If I haven’t found a property to rent within a week of looking I will have to be more flexible in my criteria.

Tomorrow we are going to York to meet up with old friends. It’s been too long since we’ve last seen everyone, something that will hopefully not recur now that we are once again based in the UK.

We had a white Christmas this year, the first for many years. On boxing day we went for a walk, and there were still remnants of snow left in the fields.

Posted in Uncategorized | Comments Off on Moving to London

There has been a lot of talk recently about whether TAL could be integrated with XPATH, sparked it seems from Leslie Orchard‘s ideas on the subject. Replacing or augmenting TALES with XPATH wouldn’t provide as rich a transformation capability as XSLT, but it would be far simpler to understand and use. Providing XPATH support in SimpleTAL would require integrating with something like libxml2. I’m not sure whether there’s a way to customise the node instances that libxml2 returns, a prerequisite for integrating with SimpleTAL easily.

The ElementTree library provides a simplified way of accessing XML that, while not a full XPATH implementation, can still be useful. It also provides a simple mechanism by which customised Element instances can be produced, so integrating it with SimpleTAL is straight forward.

I’ve put together a basic integration, and released it as an experimental build for people to test and play with. If the integration doesn’t break anything, and is found to be useful, I’ll document and ship this as part of SimpleTAL.

The integration allows XML documents to be placed in the SimpleTAL Context. Using the new simpleElementTree module’s parseFile method creates a new object that is a subclass of both simpleTALES.ContextVariable and ElementTree._ElementInterface.

The syntax available when using this object from TAL consists of four options:

1. element/find/SEARCHPATH
2. element/findall/SEARCHPATH
3. element/@ATTNAME
4. element/SEARCHPATH

The last form is just short-hand for the first and can be used for anything where the SEARCHPATH does not start with either ‘find’ or ‘findall’ as an element name. The use of the /@ATTNAME can be combined with the first and last forms, i.e. book/find/author/@birthday is a valid path to use. The SEARCHPATH can be any valid ElementTree search path. To find an element ‘author’ that is directly under the ‘book’ element use a path of ‘book/author’. To find the element ‘author’ anywhere in the ‘book’ hierarchy use ‘book/.//author’.

The biggest piece of missing functionality with this integration is the ability to copy whole element structures into the target document. For example if the XML document you are working with contains <p>I am over <b>here</b>, not over there.</p> there is no way to extract all of this as a unit and include it into the target template. If ElementTree provided this facility it would probably be very simple to add to the implementation.

If this integration interests you, please take the time to download the experimental build, and test it out. There’s a small example included that should be a good starting point for exploring this functionality.

The picture is a reminder of the pleasant Autumn we had this year not, unfortunately, a reflection of the current weather.

Posted in Uncategorized | Comments Off on Integrating ElementTree and SimpleTAL

I’ve recently had reason to investigate the structure of income tax and national insurance in the UK. It’s always easy to take the headline income tax rate (22% basic and 40% higher) and think of that as the amount of money being handed to the government. Unfortunately the true tax situation is neither that simple, nor that low.

Take for example, a company that can afford to spend £1000 on a Christmas bonus for a basic rate employee. Using the headline income tax rate you would expect the employee to receive an £880 bonus, yet in practise they will actually receive £593.97. This is an effective tax rate of 40.6% and that doesn’t take into account VAT, which reduces spending power further to £490 (or a 51% tax rate).

Here’s how the numbers add up:

Employer budget: £1000
Amount paid to employee (this plus the NIC add up to the budget): £886.52
Employer NIC (National Insurance Contribution Class 1 "secondary" at 12.8%): £113.48

Employee tax (at 22%): £195.04
Employee NIC (Class 1 "primary" at 11% for those earning less than £31,720): £97.52

Total money in the pay packet: £593.97

Higher tax rate payers are, of course hit harder, but not by as much as you might expect. Earnings of over £31,400 attract the 40% income tax rate, but employee national insurance contributions fall to %1 after £31,720. The resulting pay received for a £1000 company expenditure is £523.05 or an effective tax rate of 47.7%.

Note: All figures are for the 2004/2005 tax year. National insurance information was taken from the Business Link’s National Insurance contribution rates and allowances site, with the latest income tax thresholds from the Inland Revenue.

I really need to make time for some more photography. It’s been an age since I got out and about with my camera, so long ago in fact that I’m now resorting to digging out old Venice photos!

Posted in Uncategorized | Comments Off on True income tax rates in the UK

Following a discussion on the Python Web SIG mailing list I’ve made some corrections and enhancements to WSGIUtils. In the previous release applications could only register with the WSGIServer for a particular URL. Now applications will receive all requests that are made for that URL and all paths beneath that URL.

In addition I’ve modified the API for wsgiAdaptor to make it more logical. I’ve also included a new method (sendFileForPath) that will send a file from the filesystem for the given path. The API modifications do require small changes to be made to any application written against wsgiAdaptor, but should improve overall usability.

I’ve released these updates as version 0.3. Feedback and bug reports are always welcome!

This photo would be better if I’d been able to expose the islands for longer without washing out the sky. I appreciate the mood that the cloudy skies and sunlight reflection create, but the photograph is lacking enough that I almost didn’t post it. The curve of light on the ocean is pleasing, but with more time and a lower position I could have improved on the composition considerably.

I’ve recently been struggling with the OpenOffice distribution that is included with Fedora Core Release 3 (FC3). I’ve encountered three major defects, and only found fixes for two of them:

1. Right clicking on misspelled words causes OpenOffice to use all the system memory and crash. The work around is to manually edit the list of dictionaries installed on the system to just the ones you need.
2. If you’re locale is set to en-gb OpenOffice will attempt to use British English templates and other localised resources. Unfortunately FC3 doesn’t include these, causing numerous problems. The work around is to manually change all references to ‘english_uk’ in the Paths configuration to ‘english’ instead.
3. Highlighted text in a multiline Text Box is automatically changed from black to white. This causes the text to disappear, and there no way to get it back except to highlight it. Changing the text box to single line solves the problem, but I need multiline to be able to read all the data in this database field!

If anyone has any suggestions for the third problem I’d by happy to hear them!

Overall the number of defects I’ve hit in FC3 has been far higher than the number I encountered with FC2. Parts of the desktop (particularly Evolution and the Gnome panel) crash more frequently than they did in FC2, various processes (again Evolution is the worst culprit) leak memory and overall memory consumption seems to have gone up.

Posted in Uncategorized | Comments Off on WSGI update & open office frustration