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.
Tools
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 http://jabakobob.net/2012/03/nsconf/.
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.
Unicode
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.
Storyboards
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.
Summary
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.