As an experiment, I’ve ported this site across to Drupal 6.

The new version of the site is running on a test server at the moment, so you might notice a bit of a drop in performance, and one or two old links may be missing since I’ve not bothered to copy the old static content over yet.

Hopefully though, the basic stuff will work. I’m also hoping that moving to Drupal 6 will allow me to re-enable comments, and to add various other bits of functionality.

If you notice anything that seems to have gone badly astray, give me a yell!

I’ve got a number of projects on the go at the moment, but most of them aren’t really ready for prime-time.

I do have one small Mac OS X project that I would like to get some feedback on.

It’s called Replicator (at the moment), and it is a simple utility intended to give the Finder a “Create Document…” menu that allows you to right-click in any folder and make a new file of a given type.

You can find the details here, and download a free beta copy to test. And find bugs. And, hopefully, give me some feedback about what I’ve done wrong and how to do it better.

Occasionally I’ve had errors where Software Update refused to download something, telling me that I didn’t have permissions to save the updated file.

In previous systems I think these files went into the /tmp folder, but in Snow Leopard they don’t, and I’ve finally managed to work out where they do go - /Library/Updates.

On my machine, somehow, I’d ended up with a couple of folders inside this one which were owned by another user, and which didn’t have group write permission.

To fix the problem, I did the following in a terminal window:

• sudo chown -R :admin /Library/Updates

• sudo chmod -R a+rwx /Library/Updates

You need to replace with your actual user name. In fact, I suspect that it doesn't matter who owns the files as long as they belong to the admin group, so if you want to be a little bit more security conscious, you could probably do this:

• sudo chown -R :admin /Library/Updates

• sudo chmod -R g+rwx /Library/Updates

I’ve been thinking about coding standards again recently. For me a coding standard should definitely be more than just about formatting and naming conventions. That stuff matters, but it’s also relatively trivial to agree upon and then stick to.

Essentially I think the standard should clarify “the way we do things here” (wherever “here” might be for you).

The objective should be twofold:

• to educate everyone in your team, and teach them about good techniques and common pitfalls

• when there is more than one way to do something, to clarify which way to choose, so that code is designed in a consistent way and a programmer working in any area can intuitively work out how another area is likely to work, where to look when there are problems, and how to approach extending an area or adding a new one

My suspicion is that the exact choices that one makes when designing and implementing something often aren’t the most important thing. In fact, too much choice can (and often does) paralyse me. Obviously avoiding really stupid decisions is a requirement, but after that, there may well be a number of adequate solutions to a problem.

The important thing when working in a team is consistency. If you’re consistent, and agile, you can move fast. If everyone can understand the designs and the code, it will always be easy to revisit the occasional choice that turns out later to be wrong.

To achieve that, you need good standards, and you need good discipline. People need to buy into the idea of a standard, and try their best to stick to it, even the bits that they might not like.

In my experience, once you let go and just follow the standard, it’s amazing how quickly a lot of those disagreements seem to become trivial and you are left free to concentrate on the important stuff.

That doesn’t mean that designing a standard for a team is trivial. It’s pretty tricky, but very important. Once it’s done though, just go with it.

After three and half action-packed years of my second stint at Sports Interactive (which makes it about six and a half in total by my reckoning), I’ve decided that the time is right to take the plunge and go it alone.

So from June 2010 onwards, I will officially be an independent Mac and iPhone/iPad developer!

No doubt I’ll blog more about my plans as the time approaches, but for now I’ll simply say that I’m really excited about the prospect of returning full time to Mac/iPhone development, and working on my own applications.

I’ll also be up for a bit of collaboration and/or consulting from time to time, so by all means get in touch if that appeals.