a convenient truth

I don’t know what has happened to Guido - first decorators, now Static Types!

He’s come up with a scheme for optional static typing of methods. I can’t think of one case in which I’d use it. He gives an example:

def gcd(a, b):
    while a:
        a, b = b%a, a
    return b

Which “pretty much only makes sense with ints”. Well, I can imagine that would make sense with a whole load of complex types, potentially, with overloaded % operators. One critical pattern in python, and one that I think makes it so powerful, is that you don’t test for types, you test for behaviour.

After all, it doesn’t matter if you are adding two things together what they are, only that they support the add method. It’s up to the caller to ensure that calling your function makes sense. You can determine that as the function author.

Part of the reason this works so well is because python code is available - no obfuscated bytecode distribution or .o files. You can read the source of the function you are calling.

So, no need for static typing. ewwww.

The first real-world use of the decorator syntax I’ve come across: PyCategories. I’m not sure I agree even that the decorator syntax is necessary, and I dislike the syntax Guido chose.

Of course, Guido knows what he is doing (he isn’t BDFL for nothing). This project is an example of why I don’t like the syntax though - it seems to have enabled something that wasn’t needed in the first place. Although there are some semantic differences with Mixins, I think Mixins work perfectly well. Syntax is, at core, a bad thing and to be avoided if possible.

I’m moving into an office, opposite Lambeth North tube station. This is going to make life sooooooo much easier.

I found it very difficult to get wifi cards compatible with linux. I used to get Prism II chipset cards, which worked beautifully. The Prism chipset (formerly Orinoco) is ancient, and so drivers have been around for a long time.

Unfortunately most manufacturers who used to use Prism chips now use one of the more recent chipsets that are unsupported in Linux - generally because the manufacturers are unwilling to publish any details about how the chips work, presumably because they are very badly built.

So, I was pleased to discover that the Atheros chipset is supported with the dubiously named MadWifi drivers.

Although they’ve still not cut a proper release, the CVS version works very nicely, even on my still quite bleeding edge 64-bit Athlon system. Some issues around WEP, but with some experimentation it works very well with 802.11b and g. I haven’t tried the 802.11a support yet in Linux though.

The MadWifi drivers have a closed-source component which is a real pain - it means the drivers will never be accepted into the mainline kernel (although the closed-source HAL might be loadable somehow). The excuse given is pretty garbled, and it doesn’t really make sense.

Apparently:

1. Some regulatory agencies wouldn’t like it
2. Some unspecified naughty people might be naughty

What precisely these regulatory agencies would do if the source were published I am not sure (perhaps they’d switch off the Internet to stop people discovering this secret-that-must-not-be-known?). Similarly, exactly why I should care about some people who might do bad things is beyond me.

These are just the kinds of feeble excuses that have always been used for keeping things secret, and they are just as wrong.

This brilliant, lightweight piece of software is an example of what I was talking about yesterday.

It’s a combined wiki, ticket tracker and subversion browser. This seems a bit odd until you use it, and you see the vision behind it. Using very simple notation you can link to and from tickets, changesets, milestones, source and wiki pages.

This means, for example, that when you commit a change, you can link to the tickets that you close. Or in a ticket you can refer to a wiki page that contains documentation. Or you can link to changesets that contain the broken code.

This brilliantly simple idea provides everything you need for a real software productivity tool - every project I’ve used it on has benefited, and one project has been literally saved because of the use of Trac.

I can’t recommend it enough. And of course, it is all written in God’s Own Language.

The Incredibles is a brilliant film. Go see it.

There has been a lot of debate about whether Free Software is better or worse than proprietary software, or indeed as to whether the freeness of software is orthogonal to quality. Eric Raymond’s famous claim in The Cathedral and The Bazaar is that “many eyeballs squash bugs” - that a large educated user population with source access contributes to code quality.

Personally I think he’s missing the point - Free Software is better than proprietary software, but it is because of the emergent properties of the processes used by the development team, not because of anything inherent in freeness. The practices that emerge from a disparate developer team without formal leadership are those that naturally ‘work’.

Here are some practices that I think are good examples:

• Design Review: all designs are open to argument by anyone. No centrally appointed “architect”.
• No Code Ownership: it is common practice in proprietary development for classes to be “owned” by their author, and others are loathe even to look at them, let alone make changes to them. This is often caused by…
• Source Code Control Discipline: propertiary projects often have no SCC at all amazingly, or they use it just like a file system, without using the branching, merging and logging facilities.
• Code Talks: no complex UML design tools to communicate ideas - even the most illustrious team members are expected to put together prototypes when they’ve got a new idea.

Some of these processes are prevalent in corporates, but they generally use them not because they actually wish to improve quality. What happens is that a project goes badly wrong, and costs a fortune. There is a huge blamefest. Someone senior proclaims that Something Must Be Done.

More junior management are under pressure to fix whatever went wrong. However, they probably don’t understand what went wrong. Software projects are Hard. Sometimes the proejct was never, ever going to work anyway - the real brief was impossible. That is not a conclusion anyone will willingly come to. The idea that risk is inherent in these projects so sometimes you pay the price is anathema to management.

They latch onto the primary tool of management: Process. Process is an excellent tool to solve some problems. Unfortunately, the problems that make software projects go wrong are not those kind of problems. Since nobody understands what went wrong, the process implementation quickly becomes an exercise in avoiding blame.

On the surface, the techniques used sometimes even resemble those effective ones I listed above - Source Code Control for example is an obvious good move. However, when the purpose for using it is to avoid blame, it becomes an obstacle rather than an aid. Things like permissions and locking become the emphasis, things that are entirely unrelated to making good code.

So Winter’s First Law: Any Process Introduced Purely For The Purpose of Butt-Covering Will Have an Adverse Effect on Quality.

In July the company I was CTO at (ICP Europe) was sold to a publishing group, and I asked to be made redundant - the company that did the purchasing are not technically oriented, and there wasn’t really a role for me there.

Since then I’ve been freelancing with my own company Isotoma Limited. Things have been going very well, and I’ve been if anything too busy. I’m doing a range of things, some for previous ICP Customers. I’ve built EUbusiness and the new Netimperative.

Also some more interesting projects for some other clients. All the code I can is being released under various Free Software licenses - see the links from the Isotoma website.

Almost all the work I’m doing involves either Python or Plone, or both.

If you have a project that you think I might be interested in, the light at the front of the IT Taxi is on.

A very funny test at BoingBoing
of Microsoft’s new blog product, and it’s censorship.

Censoring blogs is such an odd idea. They are so (in Ben Hammersley’s words) dismal, that it seems pointless even subjecting them to scrutiny.