A very successful macro shot in the butterfly garden, if I do say so myself (and I do). This is a Green-veined White butterfly – apparently very common in the UK, but looking quite stunning with its wings folded. You can really see the mottled grey pattern on the surface of the eye.

GreenVeinedWhiteButterfly 6961
WWDC has begun and more information is trickling out about Mac OS X 10.6 "Snow Leopard". I like what I see, but one thing really stood out as intriguing: default gamma will be 2.2 rather than the traditional Mac setting of 1.8. It's one of the many items mentioned on this page: http://www.apple.com/macosx/refinements/enhancements-refinements.html. This is going to be important for photographers and graphic artists in particular.

What does it mean? Gamma refers to the way numerical colour representations are mapped to real colours on the screen – specifically how the luminance is mapped, i.e. how light they appear. Wikipedia explains gamma in full, complete with some neat sample images to show how different gamma settings affect the way an image looks. Windows PCs traditionally use system gamma setting of 2.2 whereas Macs go for 1.8, which means that the same image tends to look darker on the PC than on the Mac, assuming that the image doesn't contain colour profile information, which is the case for most images and videos on the web. Mac users create pictures to look just right on their monitor and are disappointed when the image looks dark and dingy on their PC using friends' machines. Conversely, the PC artist is surprised that the image they create looks bright and washed out on their friends' Macs. And neither of them generally have a clue that this is because of the different gamma settings of the systems!

It seems that Apple have decided to bite the bullet and get in line with the popular 2.2 standard to end this perennial confusion. This is a major step for Apple to take and I imagine they had to think long and hard over it, but it's probably for the best in the long term.
A common classic in the field of weissbeers but, on this tasting at least, nothing to get too excited about. It's good, but not stunning. Maybe you have to be in the right mindset and the right physical location to really appreciate a beer like this. It doesn't live up to the Edelweiss that I enjoyed on a hot day a couple of weeks back.

Erdinger 6862
I've been working on an iPhone app that uses location data extensively. From poring through the raw data that comes from CLLocationManager I've learned a few interesting things. In particular it seems that CLLocation objects with negative (i.e. invalid) verticalAccuracy value were likely derived from non-GPS sources – e.g. triangulation from cell towers or SkyHook WiFi positioning. In my app I really need only the purest, most accurate data so I'm choosing to ignore non-GPS data and this is how I can tell it apart in order to do that.

It took a while for this realisation to dawn on me as I was seeing occasional poor data points mixed in with the good ones, and this seems to be because it occasionally slips in a non-GPS location in certain circumstances.
Objective-C can be a difficult mistress at the best of times, but I've been pulling my hair out over the useless exception traces it gives when my iPhone app falls over. For example:

2009-06-02 22:22:39.036 GPSDraw[31024:20b] *** -[CLLocation timeIntervalSinceReferenceDate]: unrecognized selector sent to instance 0x40add0
2009-06-02 22:22:39.038 GPSDraw[31024:20b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[CLLocation timeIntervalSinceReferenceDate]: unrecognized selector sent to instance 0x40add0'
2009-06-02 22:22:39.039 GPSDraw[31024:20b] Stack: (
    2532991147,
    2419396155,
    2533020330,
    2533013676,
    2533013874,
    2532962733,
    23499,
    22944,
    2520474771,
    2532494021,
    2532494456,
    827745792,
    827745989,
    816114848,
    816160924,
    11116,
    10970
)

Which is all very exciting, but how about telling me the line of my code that threw the exception? That's what any sane IDE would do, but XCode is different and prefers to give an unhelpful list of numbers instead. The stack that the debugger shows is always just some arbitrary point in the main run loop, with the only bit of my code in scope being main.

However I've stumbled across the crucial way to get the behaviour that should be enabled by default. Whilst debugging, select Run > Manage Breakpoints > Add Symbolic Breakpoint. Now enter "objc_exception_throw" without the quotes and it should actually break at the point in your code that the exception is thrown.
If you go to Pizza Express, this is what you must order to drink! They may only serve two different beers (the other being bog standard Peroni) but it’s worth it just for this one. At 6.6% and packed with malty flavour (Birra Doppio Malto as it says on the label) it’s a real standout bottled lager. I was seriously happy to see it in the supermarket, and it tastes just as good at home, especially at a third the price the restaurant charges. Repeat – this is not an ordinary lager – just look at the colour in the glass. It is to be savoured.

PeroniGranRiserva 6861
This is a challenging beer. It sticks two fingers up to you, even from the shelf with it's "I'm not a fuddy duddy ale" packaging. Once you've picked it up the label continues with the bolshiness, suggesting that you're probably not man enough to drink it. Challenge accepted!

It's a proper old-school IPA at 6% and heavily hopped – as were the original India Pale Ales, to survive the long journey by boat from England to India, if I've got my beer history right. However the bitterness of the hops is a bit too no-holds-barred for my liking and any other subtle flavours are mostly bashed into submission. I wouldn't drink more than one in the same sitting.

PunkIPA 6861  
I’m now on twitter. Shame on me.

Summer is clearly here. I can tell because it’s been raining most of the day and Springwatch is on tele. But on the Bank Holiday Monday it was glorious and the countryside around St Albans was lush and verdant.

SummerGreens 6703
I'm working on an iPhone app right now, which mostly involves dev/test against the simulator, with occasional runs on a real iPhone to check everything is running the same there. But every time I flip that menu in the XCode toolbar from Simulator to Device and hit cmd-R I spend five minutes of confusion trying to figure out things aren't working even nearly right.

Picture 2
After a while and maybe a bit of debugging I'll get a hunch that all is not as it seems, I'll do a complete clean and rebuild and then my code will behave perfectly, with XCode whistling cherubically with an innocent look on its face. All that remains is for me to check the Build menu to reassure myself that cmd-R does in fact do "Build and Run" which it most certainly does.
I can only assume that there is a bug in XCode that doesn't correctly reset build state when switching between targets, so it thinks my build is up to date when in fact it's ancient.