Another excellent day, with some good sessions (core animation looks cool), and a fun finale.

I must confess to being a little bit weary now, and glad to be sitting at home. Tim & Scotty and the others must be knackered - I hope they have the chance to get thoroughly rat-arsed tonight.

Inspired by Andre Pang’s presentation at NSConference, and pointed out to me by Alasdair Allan…

http://www.willamette.edu/~fruehr/haskell/evolution.html

No really, it is funny, honest.

I’ll get my coat.

I had a conversation last night which reminded me of this sneaking suspicion I have about Extreme Programming - which I may have blogged before (but I can’t find my own post if I did!).

Basically it revolves around the fact that I’d be far less likely to want to work with a programmer who had absolutely no knowledge of or interest in XP, unit testing, refactoring etc.

Conversely, I’d be instinctively keen to work with someone who is interested in it, or already doing it. To the extent that I suspect I wouldn’t really care whether we actually DID it at all.

Which leads me to wonder just how much the actual process matters, and how much it’s just a filter to use in order to select the right people to work with.

In recent years Apple has started doing something that I regard as pretty dumb - tying versions of XCode to a particular system, and/or not supporting older XCode versions on newer systems. XCode 3.0 required Leopard, and I suspect that the next big XCode update will go the same way.

What’s even more annoying is that the distributed build system is tied to your system, architecture and xcode version. I can see why the version of the tool chain used by each node in a distributed build needs to match, but Apple should really spend some time making this stuff work a lot better.

The IDE should really be far more de-coupled from the tool chain, and I really ought to be able to participate in a shared build system running on a number of system versions (for that matter the IDE is a horrible monolithic lump which should really be broken down into smaller components and updated in a far more agile way, but that’s another topic).

The main reason why the Xcode thing is such an issue for me, is that it’s a really big barrier stopping me doing early testing of system updates. One way or another I’ve been getting pre-release systems from Apple for the last 20 years or so. Until fairly recently, I was very happy (keen, even) to live on the edge. Maybe not for alphas, but certainly by the time the system got to beta I’d typically install it and live on it for my main development machine. Crashes and glitches notwithstanding, I wanted to know what was coming, try it out, and give feedback on it whilst there was still time to change stuff.

Now, however, access to pre-release builds is next to useless for me. I simply can’t live on pre-release systems, since I immediately lose access to the other 5-10 macs that are normally happy to help out with my builds (and believe me, I need them to help compile Football Manager, which contains a lot of code!). For the amount of time & effort it takes to install a new system, it’s barely worth it just to click around for half an hour to see what’s changed, before switching back to my “real” system.

I can’t believe I’m the only person who has this problem, and it seems to me that the quality of the feedback that Apple receives must suffer as a consequence.

First day of the conference proper - and an eclectic mix of excellent sessions.

A lot of stuff wasn’t directly relevant to the day job, but as always with these events it’s fantastic to just get the time & space to think about the issues, and to be pointed in some new directions. What wasn’t relevant today may well become the future.

Plus, of course, the ability to simply meet and hang out with a bunch of like-minded geeks is priceless.