Alex headshot

AlBlue’s Blog

Macs, Modularity and More

NSConference 2012 Day 1

2012 Nsconf Conference

This year’s NSConference continues to be in the same DeVere venue in Wokefield Park as previous years.

The sessions this year are combined with the blitz talks in the main room. This avoids the problems with last year where everyone was running back and forth between the main room and the breakout rooms; but the downside is that the main room is now occupied for 100% of the time with very little break (and certainly not bright enough to have general conversations between the sessions). Unlike previous years, I’ve not been able to have any decent conversations between the main presentations; basically, everyone is staying in the same seat for most of the day. Still, at least the lunch sessions and evening sessions provide an opportunity social interaction.

How to Sabotage a Release

Kevin Hoctor (@kevinhoctor) provided an entertaining look at how to sabotage releases (including his own experiences from the recently-released but much riled MoneyWell 2). These included:

  • Announce future features
  • Cannibalise features for future releases
  • Rewrite all of the code
  • Do documentation last
  • Extend crunch time for months

All of these things were things that he found impacted the development (and release) of MoneyWell 2 – leading Scotty to complain that the actual release had robbed him of at least half of his jokes during NSConference.

The same effect is now known as the Osborne Effect, after the computer manufacture Osborne, who announced the replacement of the Osborne 1 before it was ready, leading to collapsed sales of the current model and thus making future cashflow nearly impossible to survive.

Platform Differences

Graham Lee (@iamleeg) gave an entertaining review of cross-platform differences, and kicked off by an impromptu Morris dancing session. The reason for the demonstration was that there are particular moves which have evolved or are specific to certain parts of the country; although they all have the same history, they have evolved since.

He related this to the History of Unix, where several branches of Unix (all philosophically related if not through code) did things in different ways – with the last few being the survivors of that path of evolution.

This corresponds to the current ecosystem on iOS and Mac, where they can all trace their history back to a few roots, but use different UI components because some have been produced more recently. If you’re developing a cross-platform app you might want to use the same business logic on all platforms but handle the UI components in a platform-specific way; for example, using a delegate or strategy pattern to provide subclasses of a common UI component for each platform.

In order to determine what platform you are running on, you can either use some form of dynamic introspections (such as NSClassFromString("TheName") to see if the class exists, or respondsToSelector:) or whether there should be some kind of pre-processor type flag (such as provided by the TARGET_OS_IPHONE flag). There are of course multiple Objective-C runtimes, including the Cocotron, which allows Xcode projects to be compiled for Windows platforms, and GNUstep, which provides an environment for Objective-C applications across a number of different platforms.

OpenSource Home Automation

Eric Barieux from Open Remote talked about the future of home automation. There’s a lot of interest in home automation, but the commercial aspects mean that most systems are incompatible with each other.

Open Remote aims to bring a level of compatibility between systems, by providing a central ORB as a broker to act as a translation and user interface manager. There’s an online designer which you can use to build the UI components; it can also be downloaded and run locally as well. The Open Remote project also has a number of mobile clients which can be used to host user interfaces.

The goal is to provide a standard application which can be used on any number of mobile (and touch screen) devices, whilst allowing existing hardware to use the same control hardware that currently exists.


Nathan Eror (@neror) talked about the importance of tools and learning how to use the most effective means for driving the computer, citing pbcopy and pbpaste as power utilities every developer should know.

One advantage of seeing how other developers work is finding out about all sorts of small functionality hidden away, which isn’t otherwise obvious. In this case, the ability to create Xcode Behaviours (via the Preferences) which can be assigned keystrokes – which can then be used to hide the various components in an Xcode interface (as per screenshot above). This allows the otherwise cluttered interface to be ‘reset’ to a clean environment for specific tasks, such as debugging or writing code. (These are akin to perspectives in Eclipse, which do much the same thing.)

Nathan also mentioned about the various tricks and tips involved in performing custom breakpoint actions; so when a particular method or function is called, you can trigger a certain behaviour. Using an NSLog() in the breakpoint means that code does not need to be recompiled in order to work; it also allows (say) sounds or speech to be fired when a certain condition occurs. By selecting the ‘continue after’ checkbox it’s possible to get a running feel of how the app is running without requiring the application code to be modified or recompiled.

Subject Matter Experts

Marcus Zarra (@mzarra) talked about Subject Matter Experts, which was really a talk on how to act professionally (and some sage advice about soap). Those who have been consulting for a while will have no doubt found most of the advice practical and useful; but the key point was that people tend to hire subject matter experts for their expertise in a particular field.

Threading and Race Conditions

Jakob Egger talked about how to perform image loading on a background thread, by using a combination of performSelectorOnMainThread and using a NSConditionLock to perform state transitions. The presentation and sample code project are available at

By using a helper object to perform the loading, and by receiving notifications to ensure loose coupling, the images could be loaded in the background and then once the data was available, redrawn onto the main thread.


Ross Carter (@rosst) presented more information than anyone could possibly want to know about Unicode, and why the current NSString functions are lacking in both their documentation and implementation.

For starters, Unicode is a 21-bit character set (rather than the 16-bit unichar type that OSX declares). Most of the characters are in the ‘basic multilingual plane’ (aka Plane-0 of 17) so do fit in that space, but it means that the index into a 16-bit character string may not always be a valid character.

Secondly, the strings can be encoded in different ways. The character é can be represented as either U+00E9 or U+0065 U+0301 since this combines the e character with the acute symbol ́ to form a single letter.

Thirdly, there’s various representations of letters, owing to how existing code points were factored in, such as U+0041 and U+0410 being both A. This can cause problems with regular expressions or other pattern-matching software (including spam sites and spam mails, which often use these to get out of the known bad sequences).

To get around this, there are known ‘encoding forms’ (aka C and D) which can normalise strings. However, NSString isEqualTo does not perform normalisation, so strings which might otherwise be considered the same by a human may not look the same to a computer. Fortunately, the compare method does provide normalisation and so can be used to do comparisons.

With the addition of the U+1F4A9 emoticon (and others) in plane 1, the existence of these kinds of strings can be expected to occur more frequently in the future.

There was also some interesting observations about how to encode strings in either UTF-8 or UTF-16: specifically, that for UTF-8 characters 1-7 bits are left as is, with 8-11 bits being represented as 2 bytes and 12-16 being represented as 3 bytes (and 17-12 as 4 bytes). The same is also true for UTF-16 (which is what unichar uses); for characters 1-16 bits they are left as a single integer, and for 17-21 are represented as 2 integers in a ‘surrogate pair’, the first of which begins with 0xD800..0xDBFF and the second begins with 0xDC00..0xDFFF. This also permits a string decoder (such as charAtIndex) to determine whether it is pointing to a surrogage pair, and to therefore provide a means of addressing it.

Finally, the Unicode Character Database provides a collection of code points and properties, which includes groups such as Hex_Digit that includes not only the A-Z, a-z and 0-9 code points, but also other encodings of ‘fullwidth’ characters used in CJK computing.

Fortunately, the groups (like Hex_Digit) can be matched in NSRegularExpression with the \p{Hex_Digit}+ property group.


Martin Winter (@martinwinter) talked about Story Boards in iOS, including highlighting the fact that you could have branches between boards, including optional skip steps to move from one board to another. He also noted it’s possible to have story boards in different files, but if you do that, you need to set up the transition in code.

He pointed out the problem with story boards being specific to iOS 5 (and thus not available on older devices) as well as the duplication between data in the iPhone and iPad versions of the application.

App Design

Drew McCorkmack (@drewmccormack): Couple of interesting points from this presentation; the first highlighted with the above car. The reason that there’s more than one type of car is that there’s more than one type of person (or persona) who wants it. The variety exists because of the different user types; rather than trying to be everything to everyone (e.g. GIMP) it is better to target the application to those users who really want to use it.

He also said developers should follow the Consistency, Repetitive, Alignment and Proximity principle of application design, and also that there is only 10% of the app visible to the users (which he named the ‘iceberg principle’). Other thing to note from this was the reference to the Non-Designers Design Book by Robin Williams (no not that one, another one).

Core Data Bit Me

Frédéric Sagnes (@ndfred) gave an overview of Core Data, and how relationships between objects can quickly impact the speed of processing (particularly with insertions and bidirectional relationships).

The slides and presentation are available on GitHub.

What Would Steve Jobs Do

Finally, Mike Lee (@bmf) gave a tribute presentation to Steve Jobs, with a number of video clips from interviews with the man over the past couple of decades. If it could be summed up into three words, it would be:

Build Great Products

Although there is a certain amount of bad press regarding some of Steve’s decisions (aprticularly with saying ‘no’ and firing) most of these are to keep A-players together with other A-players; because once you hire a B-player, they’ll hire a C-player and then ultimately you’ll be surrounded by bozos.

Mike also suggested that perhaps the reason for some of the lack of inter-personal flares may be related to sleep deprivation, since the effects are quite similar.

Finally, he noted that Everything is a remix and nothing is really original. Furthermore, in a functional team, it is likely that any conclusion arrived at is a product of collaboration and not any one individual’s work.

Mike is working on a book, One More Thing.


As the first day draws to a close, I’m left wondering about the scheduling aspects to the talk. Since we’re all in one room for the main and blitz talks, the majority of attendees just stay in the same room and the lights stay on low. This doesn’t invite the kind of conversations and meetings that historically NSConf has encouraged.

Still, the dinner was great (and the wine greater), so much so that Scotty wasn’t seen the next day. That’s got to be something.