WWDC wind-down

As everyone is getting on their respective planes and flying back to their respective homelands, it’s time to look back on what happened and what the conference means.

The event itself was great fun, as ever. Meeting loads of new people (a big thank-you to the #paddyinvasion for my dishonourary membership) as well as plenty of old friends is always enjoyable – especially when everyone’s so excited about what they’re working on, what they’ve discovered and what they’re up to the next day. It’s an infectious enthusiasm.

Interestingly the sessions and labs content has more of a dual impact. On the one hand it’s great to see how new things work, how I could use them, and to realise that I get what they do. The best feeling is taking some new information and being able to make use of it or see how it can be used. That’s another reason why talking to everyone else is great – they all have their own perspectives on what they’ve seen and we can share those views, learning things from each other that we didn’t get from the sessions. If you were wondering what the animated discussions and gesticulations were in the 4th Street Starbucks at 7am every morning, now you know.

On the other hand, it makes me realise that OS X is such a huge platform that there are parts I understand very well, and parts that I don’t really know at all. My own code spreads a wide path over a timeline between January 1, 1970 and September 2009 (not a typo). For instance, it wasn’t until about 2003 that I knew enough NetInfo to be able to write a program to use it (you may wonder why I didn’t just use DirectoryServices – well even in 2003 the program was for NeXTSTEP 3 which didn’t supply that API). I still have a level of knowledge of Mach APIs far below “grok”, and have never known even the smallest thing about HIToolbox.

There are various options for dealing with that. The most time-intensive is to take time to study – I’ve got a huge collection of papers on the Mach design and implementation, and occasionally find time to pop one off the stack. The least is to ignore the problem – as I have done with HIToolbox, because it offers nothing I can’t do with Cocoa. In-between are other strategies such as vicariously channeling the knowledge of Amit Singh or Mark Dalrymple and Aaron Hillegass. I expect that fully understanding Mac OS X is beyond the mental scope of any individual – but it’s certainly fun to try :-).

Posted in carbon, cocoa, conference, darwin, nextstep, WWDC | 2 Comments

Unit testing Cocoa projects in Xcode

Unlike Bill, whose reference to unit testing in Xcode 3.0 is linked at the title, when I started writing unit tests for my Cocoa projects I had no experience of testing in any other environment (well, OK, I’d used OCUnit on GNUstep, but I decline to consider that as a separate environment). However, what I’ve seen of unit testing in Cocoa still makes me think I must be missing something.

The first thing is that when people such as Kent Beck talk about test-driven development, they mention “red-green-refactor”. Well, where’s my huge red bar? Actually, I sometimes write good code so I’d like to see my huge green bar too, but Xcode 3.1 doesn’t have one of those either. You have to grub through the build results window to see what happened.

Sometimes, a test is just so badly broken that rather than just failing, it crashes the test runner. This is a bit unfortunate, because it can be very hard to work out what test broke the harness. That’s especially true if the issue is some surprising concurrency bug and one test breaks a different test, or if the test manages to destroy the assumptions made in -teardown and crashes the harness after it’s run. Now Chris Hanson has posted a workaround to get the debugger working with a unit test bundle target, but wouldn’t it be nice if that “just worked”, in the same way that breaking into the debugger from Build and Run “just works” in an app target?

Posted in cocoa, objc, unittest, xcode | Leave a comment

Follow-up-and-slightly-over on safety/security

The one thing which makes this a less-than-standard follow-up is that the original was not posted here, but over on paranym Graham Cluley’s blog. I originally wrote about the (fictitious) difference between safety and security. For those who didn’t clickety the linkelode, I wrote that Jon Gruber’s distinction between safety and security was just a neat lexical game to sidestep popular Mac-press opinion. I also wrote that I wanted to cover the original article, Snow Leopard security is all relative. Well, now I shall.

So Dennis Fisher argues that “very few users will switch to a Mac or from a Mac because of security”…”But if Snow Leopard turns out to be a major security upgrade over the current versions, that’s an important step for Apple and its customers.” I’m not sure I agree there. As far as I can see, the fundamental place where Fisher and I start to disagree is on what value security marketing has.

I infer from the article that Fisher takes security marketing to be a zero-sum game between the competitors: every time Apple wins, Microsoft necessarily loses: Microsoft have “out-secured” Apple and it’s up to Apple to “out-secure” them back. I believe that many consumers consider security as a “hygiene factor”; invisible most of the time, but unacceptable when it becomes an issue. That would make it hard to market a secure OS, but impossible to sell an insecure one. An important distinction, let me explain. People will not consider security as a factor in any product which seems secure enough, but will not touch any product which does not seem secure enough. Therefore a loss for any one company pulls its rep down with respect to the competitors, but there isn’t really any such thing as a security marketing “win”.

Where does that leave Apple? Well, a “major security upgrade” could go in one of two directions. Either it means moving from 0 concern over Mac security to a smaller value of 0 concern; or it could lead people to think that there were some security holes in Leopard that Apple decided not to tell us about and patched up in Snow Leopard. It seems to me that there is, at best, no value in marketing based on the security posture of the OS (though security features are, admittedly, different), however there certainly is value in improving the security posture to avoid the negative market perception of vulnerabilities. There is also value in responding openly and quickly to security issues to stem the rep bleeding any problem would cause.

Knowing Apple, though, they’ll find the other way; the way of making security posture a winnable marketing game and winning that game.

Fisher’s article states that the real question “is whether Snow Leopard will be more secure than the current version of OS X” – whereas for the moment the real question is whether Snow Leopard will continue to be secure enough.

Posted in AAPL, leopard, msft, security | Leave a comment

chord graphics

Ha, crossover humour! It’s like Core Graphics, which is a Mac thing, only it’s chord, because I’m talking about music, but I’m a Mac guy…oh, never mind.

When I’m trying to think of chords in music I always end up with a mental image of a piano keyboard, with the notes that make up the chord pressed. That’s all well and good, but I don’t have a piano! Apart from some set pieces like barre chords, I can’t really think of note combinations in the same way on a guitar, and certainly get flustered trying to harmonise on a violin. What I really need is a piano to sit down and work out harmonies at, which I could then play on the instrument of my choosing (playing a string of notes on any of those instruments isn’t so much of a problem).

Unfortunately the biggest piece of floor space I currently have access to is about 1.3m x 0.4m. Maybe some cheap Bontempi would fit there, but not an 88-key upright. If there were a real-space version of the GarageBand digital keyboard, that would certainly fit…in fact it would probably fit in one of my nostrils. One octave doth not a piano make. Some people have suggested Clavinova, MODUS or similar electric pianos before. The thing is, they cost around £2k, whereas an upright is <£500.

Posted in whatevs | 4 Comments

Prepping for WWDC

With the obvious first question being which parties do I go to? See you there?

Posted in AAPL, conference, WWDC | 3 Comments

The rokeg blood pie^W^W^Wplot thickens

So, having already discussed Klingon Anti-Virus, the under-research Klingon threat detection tool made available by Sophos, it seems that more information has been made available. From no less, or indeed more, of a source than the blog of my Clu-ful conym.

This seems to confirm the impression that the tool has been developed for some special internal use and might not be downloadable much longer. It’s hard to tell, though; most of the company is being very quiet about it (indeed it wasn’t until today that much internal noise was generated about the tool at all).

Of course, maybe I’m being duped. This could be some sort of company experiment to see, well, either how much free marketing they can get or who in the company is responsible for the press leaks. If it’s the latter, then I need you all to take a look at my CV as I’ll probably be relying on it – and you – soon ;-).

Anyway, take a look at the tool if you’re interested, I’ve had reports that it works well but still haven’t heard much feedback about the quality of the translation. BTW, interested in a Mac version of the tool? I can’t promise anything but leave a message after the beep and I’ll forward requests…

Posted in enterprise, klingon, security, star trek | 1 Comment

Detect the gagh lurking in your system!

Following up on my previous ability to get to the top of a Google search for a Klingon word (that one was chuvmey, as in my post Model, View, chuvmey) here is yet another attempt. At what? Why, at skewing the mental associations between science fiction television and the digital security industry, of course!

Sophos Klingon Anti-Virus is a threat detection tool for Windows computers, but in Klingon. Ever wondered what Conficker and Rokeg blood pie have in common? No, neither have I. In fact, I doubt anyone has. Nonetheless, try out the tool and see what Romulan back-doors have been installed on your box.

(N.B. this means we have to expand our remit from “Enterprise” security software, to include at least the “HMS Bounty” from Star Trek IV)

Posted in enterprise, klingon, security, star trek | Leave a comment

Rootier than root

There’s a common misconception, the book I’m reading now suffers from it, that single-user mode on a unix such as mac os x gives you root access. Actually, it grants you higher access than root. For example, set the immutable flag on a file (schg I think, but my iPhone doesn’t have man). Root can’t remove the flag, but the single user can.

Posted in darwin, security, UNIX | 3 Comments

On dynamic vs. static polymorphism

An interesting juxtaposition in the ACCU 2009 schedule put my talk on “adopting MVC in Objective-C and Cocoa” next to Peter Sommerlad’s talk on “Design patterns with modern C++”. So the subject matter in each case was fairly similar, but then the solutions we came up with were entirely different.

One key factor was that Peter’s solutions try to push all of the “smarts” of a design pattern into the compiler, using templates and metaprogramming to separate implementations from interfaces. On the other hand, my solutions use duck typing and dynamic method resolution to push all of the complexity into the runtime. Both solutions work, of course. It’s also fairly obvious that they’re both chosen based on the limitations and capabilities of the language we were each using. Nonetheless, it was interesting that we both had justifications for our chosen (and thus One True) approach.

In the Stroustroup corner, the justification is this: by making the compiler resolve all of the decisions, any problems in the code are resolved before it ever gets run, let alone before it gets into the hands of a user. Whereas the Cox defence argues that my time as a programmer is too expensive to spend sitting around waiting for g++ to generate metaprogramming code, so replace the compilation with comparitively cheap lookups at runtime – which also allows for classes that couldn’t have possibly existed at compiletime, such as those added by the Python or Perl bridge.

This provided concrete evidence of a position that I’ve argued before – namely that Design Patterns are language-dependent. We both implemented Template Method. Peter’s implementation involved a templatized abstract class which took a concrete subclass in the realisation (i.e. as the parameter in the <T>). My implementation is the usual Cocoa delegate pattern – the “abstract” (or more correctly undecorated) class takes any old id as the delegate, then tests whether it implements the delegation sequence points at runtime. Both implement the pattern, and that’s about where the similiarities end.

Posted in C++, cocoa, conference, objc, ooa/d | 2 Comments

Did you miss my NSConference talk?

The annotated presentation slides are now available to download in Keynote ’08 format! Sorry you couldn’t make it, and I hope the slides are a reasonable proxy for the real thing.

Posted in conference, macdevnet, security | Leave a comment