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.

Day two started with an illuminating session by Jeff LaMarche about the Objective-C runtime, and some of the nice dynamic and introspective things you can do with it, such as iterating through your own properties, methods, etc. A couple of days ago in Drew’s concurrency workshop I was thinking about the need for some good Objective-C wrappers for OpenCL, as there’s a lot of boiler plate setup code that you have to do. It’s there for flexibility, but probably you do the same thing for most apps, so why not wrap it in some simpler objects. Some wrappers probably already exist somewhere, but it struck me that one of the techniques Jeff was describing would be perfect for supporting OpenCL kernel parameters. Instead of having to write code to poke the parameters into the kernel, wouldn’t it be great to just be able to subclass an OCLKernel class, define some properties on it, and automatically have setters implemented which loaded the property values into OpenCL, and getters which retrieved the values.

Next up was Andy Finnell, giving a session that was supposed to be about Core Image, but was actually more about OpenCL. Everyone reported that this was an interesting session, but I sort of got distracted because I was starting to hack together the OpenCL wrapper classes that I’d thought of in the previous session (I’ll post them up when I’ve done them). Having said that, if there’d been more actual OpenCL in Andy’s presentation I would probably have been drawn back in to it, but actually he mentioned himself that he’d wrapped the calls in a class hierarchy, and went on to focus on the physics, which whilst interesting wasn’t really of much general use. In the end, from what I heard, it was more about the physics of watercolour pigments and their interaction with paper - which whilst interesting, wasn’t really what I was there for!

Next up were two half-length sessions thrown together at short notice because one of the other speakers had to drop out.

First a quick overview of some source control systems by Dave Dribin. This was a tough job in such a short time, and I felt that it was a bit light on the right details. He spent too long on the purpose and history of version control, and not enough time on a discussion of the idioms that we use in the real world, and how they do or don’t fit into the models provided by Svn, Git, Mercurial or Perforce. Not that the history and purpose isn’t interesting, but in half an hour you can’t really do it justice on its own, so it was probably better to focus on telling people who understand version control and use one every day how the one they use compares to the other major options. I found this frustrating because I use a very large Perforce system at work (it’s pricey, but excellent, and I’m not convinced that the other systems could do what we do with it), and run a Subversion server at home (which is simple, but I want to change to something else, probably git or mercurial). What I really wanted was answers to some fairly complex situations that happen in the real world - like “how well can you manage multiple concurrent release branches”, “how does it cope when you have twelve devs continuously hacking on a branch”, “how well does it deal with large amounts of data - e.g. graphics assets”, and “how does system XYZ recommend managing your own shared library modules that are used by more than one project that you also have under source control?”. None of which were really answered.

This was followed by a very whistle stop tour of code signing from Graham Lee. Although brief, this was actually useful as he told me how to do something that I didn’t know how to do before. He delivered it with his customary humour, and the session was most notable for re-christening Wolf Rentzsch as “The Dog Spanner”.

After another excellent lunch we had our final “proper” session, from Aaron Hillegass, on data persistence. He started with an excellent set up, posing some interesting questions about how relevant the file system is any more, and whether “the file” is actually dead, to be replaced largely by the data cloud. Quite possibly, he suggested, our local machine hard drives are just local caches from here on in. I think this is a great topic which could have been explored further - for example, if files on our local hard drive are just caches, shouldn’t we be trying to find ways to structure them better so that they can be synchronised with the cloud in a non-monolithic way. One big fat 10Mb file is a bit hard to sync unless you’ve got a detailed schema describing the internal structure, and permission to mess with it. Anyway, I think that side could have been explored further, but Aaron switched tack somewhat to talk about the BNRPersistence framework that he’s created. Which was an interesting topic in it’s own right.

Finally, we had the “Cocoa Rumble”, which was a light hearted competition between three teams composed jointly of the session presenters and volunteers from the crowd. I didn’t really feel that it worked that well this year, despite generating some good presentations at the end. Somehow I don’t think we’ve yet managed to find a way to end NSConference which matches the old “Stump The Experts” sessions at WWDC (which were kind of cool back in 1993 when I first went, and still good fun back in about 2002 when I last went!).

So there you have it - two days of great Mac related sessions. I’ve learnt a fair amount, met some nice people along the way, and had a splendid time. I’ve eaten far too much, and drunk lots of bad beer and bad cider. And tomorrow, there’s another whole day of iPhone stuff. Phew…

Speaking to various folks at NSConference, I realised that there are quite a few regular developer meetings around the country, in addition to the one that I used to organise in London (which still exists but has mutated into the NSCoder london night).

I figured that it would be handy to list them all in one place, for anyone who might find themselves in a strange town for a while in need of geek-based social contact…

I’ve updated my uk-mac-dev-meeting page accordingly, so that it now lists all of the ones I’ve heard about.

If you know of one I’ve missed, please let me know.