iamleeg

LLVM projects you may not be aware of

2010-05-12T09:49:00.001+01:00

All Mac and iPhone OS developers must by now be familiar with LLVM, the Low-Level Virtual Machine compiler that Apple has backed in preference to GCC (presumably at least partially because because GCC 4.5 is now a GPLv3 project, in addition to technical problems with improving the older compiler). You'll also be familiar with Clang, the modular C/ObjC/C++ lexer/parser that can be used as an LLVM front-end, or as a library for providing static analysis, refactoring and other code comprehension facilities. And of course MacRuby uses LLVM's optimisation libraries.

The LLVM umbrella also covers a number of other projects that Mac/iPhone developers may not yet have heard about, but which nonetheless are pretty cool. This post is just a little tour of some of those. There are other projects that have made use of LLVM code, but which aren't part of the compiler project - they are not the subject of this post.

LibC++ is a C++ library, targeting 100% compatibility with the C++0x (draft) standard.

KLEE looks very cool. It's a "symbolic execution tool", capable of automatically generating unit tests for software with high degrees of coverage (well over 90%). Additionally, given information about an application's constraints and requirements it can automatically discover bugs, generating failing tests to demonstrate the bug and become part of the test suite. There's a paper describing KLEE including a walkthrough of discovering a bug in tr, and tutorials in its use.

vmkit is a substrate layer for running bytecode. It takes high-level bytecode (currently JVM bytecode or IL, the bytecode of the .Net runtime) and translates it to IR, the LLVM intermediate representation. In doing so it can make use of LLVM's optimisations and make better decisions regarding garbage collection.

WWDC dates announced

2010-04-28T15:52:00.001+01:00

The entire of Twitter has imploded after noticing that Apple has announced the dates for WWDC, this year June 7-11. That's too short notice for me to go, and having only recently started working again after a few months concentrating solely on Professional Cocoa Application Security, I can't scrape together the few thousand pounds needed to reserve flights, hotel and ticket at a month's notice.

I hope that those of you who are going have a great time. The conference looks decidedly thin on Mac content this year, and while I still class myself as more of a Mac developer than an iP* developer that shouldn't be too much of a problem. The main value in WWDC is in the social/networking side first, the labs second, and the lecture content third - so as long as you can find an engineer in the labs who remembers how a Mac works, you'll probably still have a great week and learn a lot.

The difference between NSTableView and UITableView

2010-04-15T13:32:00.001+01:00

A number of times, I've chased myself down rat holes in iPhone projects because I've created a design or implementation that assumes UITableView and NSTableView are similar objects. They aren't.

The main problem I come across is related to how the cells are treated in Cocoa and in Cocoa touch. An AppKit table comprises columns, each of which uses a cell to display its content. A cell contains the drawing and event-handling stuff of a view, but nothing to do with its place in the view hierarchy or responder chain. It's essentially a light-weight view. For each row in the table, NSTableColumn takes its cell, configures it for the content in that row and then draws the cell at its location in the column. No matter how many rows there are, a single cell is used.

UIKit works differently. Of course a UITableView only has one column, but it also displays views rather than cells. This is good, but leads to the key distinction that always trips me up: you can't use the same view more than once in a table view. Of course, sections in a UITableView will often have more than one row, but each row that is visible on-screen will needs its own instance of UITableViewCell (which is a subclass of UIView, and therefore a view in the traditional sense rather than a cell). If you try to re-use the same instance multiple times, the table view will configure each row but only the last one it prepared will be drawn.

So what's this -reuseIdentifier? stuff? That's related to caching views for scrolling. Imagine a table view with 10 rows, of which 4 can be seen on screen at once. Each uses the same type of cell in this example. When the table view first becomes visible there will be 4 UITableViewCell instances in use, displaying rows 0-3. Now you start to scroll the view. UITableView finds it needs an extra cell to display row 4, which is now partially on-screen and row 0 is starting to slide off. When row 0 disappears completely, the table view could just delete its cell - but rather than do that, it adds it to a queue of reusable cells. When row 5 starts to appear, the table view can re-use the object it's already created for row 0, because it's the same type of cell as the one for row 5 and is currently unused.

So, that's that really. Note to self: don't treat UIKit like it's just AppKit, you'll end up wasting a day of code.

On writing a book

2010-04-02T12:20:00.001+01:00

Well, I've performed my final author's review, and Professional Cocoa Application Security is all with the printers. This post is about my experiences writing the book, not the book material itself.

My original motivation for writing PCAS was that it was a topic someone needed to talk about, and nobody had hitherto done the talking. I was actually initially approached by Wiley to see if I'd write anything at all - their commissioning editor had seen my Objective-C FAQ and this blog, and liked my style. I said that I didn't want to write a book, I wanted to write this book. It was the best way I could pay back the community that has helped me so much in the years I've been a Mac developer.

It took about 6 months to write the draft - my original estimate was much shorter but once we realised I couldn't meet that we revised it, after which I stayed on track with the updated schedule. That's six months of nearly full time work. Some other books probably don't take so long, but in this case I had set myself a very ambitious scope and needed to research quite a lot of the topics before I could write on them. If you've already got a series of blog posts, training material or something that you just want to turn into a book, I can imagine the drafting process being much quicker.

I've found that book authorship is not the best vehicle for self-study. You get a biased view of the material, looking for things that would be interesting to readers rather than things you will need to use yourself. Because the goal of the book is to provide utility to the readers, you end up with a gotcha-oriented approach to research, looking for the subtle benefits or issues that are not obvious on a casual inspection. That said, it was still a good motivation to learn about the technologies I wrote about, so I'm glad I did it. Parts of the writing process were a lot of fun: I got to find out about some cool frameworks and APIs, absorb loads of information and re-emit it in a form that is, I hope, engaging and interesting. I've looked at my bookshelves and have about 6ft of books that I used as source material - and that doesn't include websites, ebooks and journal papers. On the other hand, I'm not going to deny that I had occasional days that just felt like a long slog to get the day's section written. I didn't mind solving hard problems, but there are some subjects that just seem impossible to say anything interesting about. It's when writing those sections that you find yourself staring at a half-written sentence for an hour, wondering just what it was you were thinking when you wrote the ToC.

You're not going to get rich off the advance :). I was in a good position where I could live off practically no income while writing, meaning that devoting a few months to producing the drafts was not a problem. What I have become rich in is exposure and recognition, even before the book was published. Because both the proposal and the book content must be peer-reviewed by a technical reviewer, "I am writing a book" says "there are people out there who trust that I know my subject". Of course, "I have written a book and you can read it" carries more weight, so I expect this exposure to increase after publication.

I've worked on reviewing proposals too, and the things you really need to make sure if you are trying to punt a proposal to publishers are:

You need to tell the publishers that the market for your book exists, who is in that market and how big it is. They're not going to go and look for the buyers on your behalf (but they will get a reviewer to make sure you're not talking bullshit).

Having identified your reader, the goals and content of the book must be appropriate to the reader. Don't put an introduction to Xcode in your Advanced iPad Apps book, just to make up an example.

This theme carries on into the review process for the actual content. The technical reviewer (a role I've also taken before) is not just there to check that the code compiles. Responsibilities include verifying the accuracy of the content and appropriateness for the target reader, and indeed review comments I've made on book drafts have been split roughly evenly between "this isn't quite right" and "your reader won't understand this" (though I'm more verbose in the actual review).

So, in short, you will not make money writing a book. You will gain kudos and satisfaction. If you've got something that you think the world desperately needs to know, and you know that you can explain it in a way the world will want to pay attention to, then by all means write! If you want to make a few thousand dollars, or want an easy project between apps, then I'd suggest finding something else. Writing's fun, and it's worthwhile, but it's certainly not an easy life.

Rehearsals in beta!

2010-03-30T12:22:00.001+01:00

I have a new application, Rehearsals, an online practice diary for musicians. If that sounds like the kind of thing you're interested in, and you have Mac OS X 10.6 or newer, then please download the beta release and test it out. There's absolutely no charge, and if you submit feedback to support <at> rehearsalsapp <dot> com you'll be eligible for a free licence for version 1.0 once that's released. There are no limitations on the beta version, so please do download and start using it!

You can follow @rehearsals_app for updates to the beta programme (new releases are automatically downloaded using Sparkle, if you enable it in the app).

How to hire Graham Lee

2010-03-02T12:22:00.001Z

There are few people who can say that when it comes to Cocoa application security, they wrote the book. In fact, I can think of only one: me. I've just put the final draft together for Professional Cocoa Application Security and it will hit the shops in June: click the link to purchase through my Amazon affiliate programme.

Now that the book's more-or-less complete, I can turn my attention to other interesting projects: by which I mean yours! If your application could benefit from a developer with plenty of security experience and knowledge to share in a pragmatic fashion, or a software engineer who led development of a complex Cocoa application from its legacy PowerPlant origins through Snow Leopard readiness, or a programmer who has worked on performance enhancement in networking systems and low-level daemon code on Darwin and other UNIX platforms, then your project will benefit from an infusion of the Graham Lee magic. Even if you have some NeXTSTEP or OPENSTEP code that needs maintaining, I can help you out: I've been using Cocoa for about as long as Apple has.

Send an email to iamleeg <at> securemacprogramming <dot> com and let's talk about your project. The good news is that for the moment I am available, you probably can afford me[*], and I really want to help make your product better. Want to find out more about my expertise? Check out my section on the MDN show, and the MDN security column.

[*] It came up at NSConference that a number of devs thought I carry a premium due to the conference appearances, podcasts and other material I produce. Because I believe that honesty is the best policy, I want to come out and say that I don't charge any such premium. My rates are consistent with other contractors with my level of experience, and I even provide a discounted rate for NGOs and academic institutions.

On multitasking

2010-02-09T10:36:00.001Z

TidBITS unwittingly hits the nail on the head while talking about iPad OS multitasking (emphasis added):

It's easy to imagine wanting to use an iPad to read text in Mobile Safari, copy some text to a Pages document, and send that document to a colleague via Mail. That specific example may turn out to be possible with the current iPhone OS, but it points toward needing more ways for iPad apps to work together in the future.

Let me break down the user's workflow here:

User reads text in Mobile Safari.

User copies text to a Pages document.

User e-mails that document to a colleague.

The flow of tasks is linear. The user does not need Mail open while reading the text in Safari, nor Safari open while pasting text in Pages. Whether a platform supports multiple simultaneous applications or not, users typically work with one at a time.

The advantage of multiple open apps is that the user can switch tasks really quickly (the other oft-quoted benefit, of being able to see context in multiple places at the same time, is actually a feature of a windowing UI: a different technology, and one that iPhone OS lacks). The disadvantage is a technical one—the operating system must allocate resources to applications that the user isn't currently working with. The iPhone (and, I presume, the iPad) provides fast task-switching anyway, through its recommendation that app developers retain app state on termination and recover it on launch. The act of moving between apps via the home screen is supposed to feel like switching tasks, even if it's implemented by a kind of pause-and-resume.

Core Data Haiku competition results!

2010-02-04T10:40:00.001Z

I was sent a review copy of Core Data: Apple's API for Persisting Data on Mac OS X by Marcus Zarra. The problem is that I already own a copy. So I held a Core Data Haiku competition on Twitter; best haiku about core data posted with the #coredatahaiku tag wins the book. Sorry if you wrote a great haiku without using the hashtag, but I didn't read it.

Anyway, the results. My decision is final, no correspondence regarding the judgement shall be entered into, the squirrel flies south to Leningrad.

Non-entering sample haiku for comparison purposes

This is mine:

Archiving does not
Make schema changes easy
So #lickahoctor

very much of its time, you'll agree.

Dishonourable mentions

A couple of people sent entries via Facebook, which didn't count within the rules of the game. So without naming the guilty parties:

I don't want the book

I just like writing haiku

Nothing wrong with that!

When learning Cocoa,

Reasonably new to it,

The more books the bett-

Honourable mentions

The standard was very high, so I'm pleased to publish every entry, congratulations to you all for some inspired poetry. In a way, there are no losers, because you all helped to make the world a better place. In reverse chronological order (because I'm pasting from the Twitter search page):

I do not know what

Core data is. Need the book.

Please let me win it. — OrigamiTech

Lost In Winter Ills

Result Sets Unsorted Again

Managed Object Found — chwalters

With multiple stores

Inside one application

Little kittens weep — inquisitiveCode

object tree...

query is made

leaves rustle — ErikAderstedt

Core Data Haiku

NSManagedObjectCon

Text just doesn't fit — hatfinch

its way too complex

painful big design upfront

I'll Archive instead — alancfrancis

Core Data framework

You manage object models

NSPredicate — adurdin

Core data is fun

makes storage easy and fast

elastic wombat — GreyAreaUK

The Winner!

Core Data haiku winners and immortal beings played by Sean Connery share an important characteristic: in the end, there can be only one. And it's this one, from adurdin:

SELECT * FROM thing

WHERE value =… fuck it—

just use Core Data.

Congratulations! I'll contact the winner via Twitter to send him his prize.

Unit testing Core Data-driven apps, fit the second

2010-01-10T17:12:00.001Z

It took longer than I expected to follow up my previous article on unit testing and Core Data, but here it is.

Note that the pattern presented last time, Remove the Core Data Dependence, is by far my preferred option. If a part of your code doesn't really depend on managed objects and suchlike, it shouldn't need them to be present just because it works with (or in) classes that do. The following pattern is recommended only when you aren't able to abstract away the Core Data-ness of the code under test.

Pattern 2: construct an in-memory Core Data stack. The unit test classes you develop ought to have these, seemingly contradictory properties:

no dependence on external state: the tests must run the same way every time they run. That means that the environment for each test must be controlled exactly; dependence on "live" application support files, document files or the user defaults are all no-nos.

close approximation to the application environment: you're interested in how your app runs, not how nice a unit test suite you can create.

To satisfy both of these properties simultaneously, construct a Core Data stack in the test suite which behaves in the same way but which does not use the persistent store (i.e. document files) used by the real app. My preference is to use the in-memory store type, so that every time it is created it is guaranteed to have no reference to any prior state (unlike a file-backed store type, where you have to rely on unlinking the document files and hoping there are no timing issues in the test framework which might cause two tests simultaneously to use the same file).

My test case class interface looks like this (note that this is for a dependent test case bundle that gets embedded into the app; there's an important reason for that which I'll come to later). The managed object context will be needed in the test methods to insert new objects, I don't (yet) need any of the other objects to be visible inside the tests but the same objects must be used in -setUp and -tearDown.

#import <SenTestingKit/SenTestingKit.h>

@interface SomeCoreDataTests : SenTestCase {
    NSPersistentStoreCoordinator *coord;
    NSManagedObjectContext *ctx;
    NSManagedObjectModel *model;
    NSPersistentStore *store;
}

@end

The environment for the tests is configured thus. I would have all of the error reporting done in tests, rather than that one lone assertion in -tearDown, because the SenTest framework doesn't report properly on assertion failures in that method or in -setUp. So the -testThatEnvironmentWorks test method is a bellwether for the test environment being properly set up, but obviously can't test the results of tear-down because the environment hasn't been torn down when it runs.


#import "TuneNeedsHighlightingTests.h"

@implementation TuneNeedsHighlightingTests

- (void)setUp
{
    model = [[NSManagedObjectModel mergedModelFromBundles: nil] retain];
    NSLog(@"model: %@", model);
    coord = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel: model];
    store = [coord addPersistentStoreWithType: NSInMemoryStoreType
                                configuration: nil
                                          URL: nil
                                      options: nil 
                                        error: NULL];
    ctx = [[NSManagedObjectContext alloc] init];
    [ctx setPersistentStoreCoordinator: coord];
}

- (void)tearDown
{
    [ctx release];
    ctx = nil;
    NSError *error = nil;
    STAssertTrue([coord removePersistentStore: store error: &error], 
                 @"couldn't remove persistent store: %@", error);
    store = nil;
    [coord release];
    coord = nil;
    [model release];
    model = nil;
}

- (void)testThatEnvironmentWorks
{
    STAssertNotNil(store, @"no persistent store");
}
@end

The important part is in setting up the managed object model. In using [NSManagedObjectModel mergedModelFromBundles: nil], we get the managed object model derived from loading all MOMs in the main bundle—remembering that this is an injected test framework, that's the application bundle. In other words the MOM is the same as that created by the app delegate. We get to use the in-memory store as a clean slate every time through, but otherwise the entity definitions and behaviours ought to be identical to those provided by the real app.

CocoaHeads Swindon, January and February

2010-01-01T13:15:00.000Z

The next CocoaHeads Swindon will take place on 4th January, at the Glue Pot in Swindon. Get here at 8 for some NSChitChat with your (well, my) local Mac developer community.

There is no February meeting of Swindon CocoaHeads, on account of NSConference Europe taking place in Reading on that weekend. So buy your NSConference ticket and come along to say hi!

Nearly the end-of-year review

2009-12-29T16:47:00.001Z

My first post (Farkers, feel free to replace that with "boobies") of the year 2009 was a review of 2008's blog and look forward to 2009. It's time to do the same for the 2009/2010 blogyear bifecta.

Let's start with the recap.

2009 was a comparatively quiet year for iamleeg, with a total of 45 posts (including this one). Although I gave up on LiveJournal, leading to an amount of "mission creep" in the content of this blog, I think that the vast increase my use of Twitter led to the decline in post frequency here. I've come to use Twitter as a replacement for Usenet, it's much easier to share opinions and discuss things on Twitter where there's more of a balanced conversation and less of iamleeg telling the rest of the world how things should work. The other main contributory factor was that I spend my days writing for a living currently, split between authorship, consultation and the MDN security column. I'm often all written out when it comes to the end of the day.

So, the mission creep. 2009 saw this blog become more of a home for ideas long enough to warrant a whole page on the internet, losing its tech focus—directly as a result of dropping LJ, which is where non-tech ideas used to end up. However, statistics show that the tech theme is still prevalent, with only four of the posts being about music or dancing. Security has become both the major topic as well as the popular choice; the most-read article was Beer Improves Perception of Security.

During August and September the focus started to shift towards independent business and contract work, as indeed I made that shift. Self-employment is working well for me, the ability to choose where I focus my effort has let me get a number of things done while still retaining a sense of sanity and a balance with my social life.

So what about next year?

Well, the fact that I have a number of different things to focus on leads to an important choice: I need to either regroup around some specific area or choose to remain a polymath, but either way I need to be more rigorous about defining the boundaries for different tasks. My major project comes to an end early in 2010, and after that it's time to calm down and take a deep look at what happens next. I have a couple of interesting potential clients lined up, and have put onto the back burner my own application which will definitely see more work. I also have some ideas for personal development which I need to prioritise and get cracking on. The only thing preventing me from moving on a number of different projects is convincing myself I have time for them.

So the blog will fit in with that time-management strategy; I won't necessarily decide that 9:00-10:14 on a Monday is always blogging time, but will resolve to put aside some time to writing interesting things. One thing I have found is that working on one thing for a whole day means I don't get much of it done, so factoring that into my plans will let me take advantage of it. Half an hour working on a new article at lunchtime could be the stimulus required to get more out of the afternoon. My weapon of choice for organising my work has always been OmniFocus, it's time to be more rigorous about using it. It doesn't actually work well for time allocation, but it does let me see what needs to be done next on the various things I have outstanding.

Obviously what becomes the content of this blog depends on what happens after I've shaken down all of those considerations and sorted out what it means to be leeg. Happy new year, and stay tuned to find out what happens.

On Operation Chokehold

2009-12-17T11:19:00.001Z

So Fake Steve Jobs has announced Operation Chokehold, a wireless flashmob in which disgruntled AT&T customers are to use data-intensive apps for an hour in protest at the poor service and reduced investment AT&T provide on their network. At time of writing, Operation Chokehold has 3,000 fans on Facebook - a small fraction of the ∼82M AT&T Mobility subscribers in the U.S. Fake Steve has latterly wondered whether it is illegal (using the "it's now out of my hands" defence, popular with people who don't understand what incitement means), and seemingly back-pedalled, considering aloud whether people might try a shorter duration or physical flashmob of AT&T stores instead. It would appear that the FCC (the U.S. agency responsible for regulating national and international communications) has weighed in, declaring a wireless flashmob to be irresponsible and "a significant public safety concern".

How is it a concern? Due to the way the phones work, you don't need to the capacity to support all of the users, all of the time, in order to provide a reasonable service. Think of running a file-sharing service like DropBox or Humyo. If you offered up to 10GB storage per customer and have 10,000 customers, then you need 100TB of storage, right? Wrong. That's the maximum that could be used, but let's say in practice you find average use to be 100MB/customer. It turns out that 1TB of storage would be the minimum you'd need to satisfy current demand, if you had even 1.5TB then you'd comfortably support the current customer base while allowing for some future use spikes or growth. The question most businesses ask then is not how risky it is to drop below 100% capacity, but how much risk they can accept in their buffer over average capacity. The mobile phone network operates in the same way. To avoid dropped calls you don't need the bandwidth to support 100% of the phones operating 100% of the time, you need to support the average number of phones the average amount of time, plus a little extra for (hopefully foreseen) additional demand.

The argument by AT&T and the FCC against the wireless flashmob then is that because the network is oversubscribed as an accepted business risk, it would actually be possible for the concerted operation of a large number of users to cause disruption to the network. This eventuality is evinced every year in the early morning of January 1st, as people phone or SMS each other with New Year greetings. People making legitimate calls during this time could be disconnected or unable to place a call at all—while that would undoubtedly make the protest noticed by AT&T it's that aspect of it which makes it a potential public safety concern. Personally, I find it hard to believe that the network doesn't have either dedicated capacity or priority quality of service (QoS) treatment for 9-1-1 calls, but it's possible still that some 9-1-1 calls might not get placed correctly. That's especially true if the caller's handset can't even connect to a tower, which could happen if nearby towers were all saturated with phones making data connections. While it's possible to mitigate that risk (dedicated cell towers for 9-1-1 service, which emergency calls are handed over to) it would be very expensive to implement. There's no business need for AT&T to specially support emergency calls, as they don't make any money from them, so they'd only do that if the FCC mandated it.

But then there are all the non-9-1-1 emergency calls—people phoning their local doctor or hospital, and "business critical" calls made by people who somehow think that their business is critical. Even the day-to-day running of government is at least partially conducted over the regular phone networks, as was seen when the pager traffic from New York on September 11th 2001 got posted to WikiLeaks. These calls are all lumped in with the regular calls, because they are regular calls. The only way to mitigate the risk of dropping these is to increase the capacity of the network, which is exactly the thing that people are saying AT&T don't do to a satisfactory level. If the contracts on AT&T Mobility are anything like the contracts on UK phone networks, then subscribers don't have a service level agreement (SLA) with the provider, so there's no guarantee of provision. The sticking point is the level of expected provision doesn't match that. If the providers operated multi-tier subscription services like the broadband providers do in the UK, then they probably would do QoS management so that preferential customers get better call service—again, assuming the customers can connect to the cell tower in the first place. But again, that's a business issue, and if the guy participating in Chokehold has a more expensive plan than the girl trying to phone the hospital, his connection will win.

Will Chokehold fulfil its goal of making AT&T invest more in its infrastructure? I don't know. Will it actually disrupt public safety services such as 9-1-1? I doubt it. Is it a scale model for a terrorist attack on the communications infrastructure of the US? Certainly not. Much easier to jump down a manhole and snip the cables to the data centres.

Consulting versus micro-ISV development

2009-12-15T17:42:00.002Z

Reflexions on the software business really is an interesting read. Let me borrow Adrian's summary of his own post:

Now, here’s an insider tip: if your objective is living a nightmare, tearing yourself apart and swear never touching a keyboard again, choose [consulting]. If your objective is enjoying a healthy life, making money and living long and prosper, choose [your own products].

As the author himself allows, the arguments presented either way are grossly oversimplified. In fact I think there is a very simple axiom underlying what he says, which if untrue moves the balance away from writing your own products and into consulting, contracting or even salaried work. Let me start by introducing some features missed out of the original article. They may, depending on your point of view, be pros or cons. They may also apply to more than one of the roles.

A consultant:

builds up relationships with many people and organisations

is constantly learning

works on numerous different products

is often the saviour of projects and businesses

gets to choose what the next project is

has had the risks identified and managed by his client

can focus on two things: writing software, and convincing people to pay him to write software

renegotiates when the client's requirements change

A μISV developer:

is in sales, marketing, support, product management, engineering, testing, graphics, legal, finance, IT and HR until she can afford to outsource or employ

has no income until version 1.0 is out

cannot choose when to put down the next version to work on the next product

can work on nothing else

works largely alone

must constantly find new ways to sell the same few products

must pay for her own training and development

A salaried developer:

may only work on what the managers want

has a legal minimum level of security

can rely on a number of other people to help out

can look to other staff to do tasks unrelated to his mission

gets paid holiday, sick and parental leave

can agree a personal development plan with the highers-up

owns none of the work he creates

I think the axiom underpinning Adrian Kosmaczewski's article is: happiness ∝ creative freedom. Does that apply to you? Take the list of things I've defined above, and the list of things in the original article, and put them not into "μISV vs. consultant" but "excited vs. anxious vs. apathetic". Now, this is more likely to say something about your personality than about whether one job is better than another. Do you enjoy risks? Would you accept a bigger risk in order to get more freedom? More money? Would you trade the other way? Do you see each non-software-developing activity as necessary, fun, an imposition, or something else?

So thankyou, Adrian, for making me think, and for setting out some of the stalls of two potential careers in software. Unfortunately I don't think your conclusion is as true as you do.

Poke the other one, it's got bells on

2009-11-01T14:48:00.001Z

Originally the title for this post was to be "Why a Morris organisation should adopt social media (and why they probably won't)", with what is now the title being reduced to the rank of a subtitle. Then I remembered that I am leeg, and as such humour is always better than content (certainly a lot easier). So we have the title you see before you.

Please bear in mind when reading the epistle located below that I'm fairly new to the whole world of Morris, and especially new to its political fiddle-faddle. If anything here seems to stereotype people or their motives, it's based on the experience of someone who can at best be considered an informed outsider. [And for those who are even more of an outsider than I am, Morris dancing is the name for a roughly-related collection of traditional English dancing styles, performed by groups called sides or teams. It's both good fun and a decent workout, give it a go.]

It seems to have been a problem for at least the length of my lifetime that Morris lacks any relevance to what, for sake of pomposity, I shall refer to as the man on the Clapham omnibus — taking the irony fully on board. That your average person sees no reason to engage with or appreciate the Morris. Why? Has the Morris really made much of an attempt to engage with or appreciate the life of the average person? Not, I would argue, at any concerted or large-scale level, leaving the final impression most people have of Morris dancers the same as their first impression: a bunch of old men in silly clothes hitting each other with sticks.

So, shouldn't I have mentioned the social media by now? Yes, I'm just coming to that, it's only a couple of paragraphs away now. First some context. There are three umbrella organisations for the Morris in the UK: the Morris Ring is the oldest, with its infamous men-only rules; the Morris Federation (whose website was broken at time of writing) started life as the less-infamously women-only Women's Morris Federation; then there's Open Morris, which to my knowledge has never had any infamous membership rules and is the youngest of the three organisations. None of these organisations takes on a promotional or advocacy rôle — or at least, if they do, they've done a bad job of it. They represent more of an internal support network, offering guidance, information, training and the like to the sides. If you don't believe that they aren't promotional bodies, take a look at their websites.

As a digression I will use this paragraph to mention the English Folk Dance and Song Society, which does indeed have advocacy, promotion and outreach as its goals. However, I'm not aware what the relationship between the EFDSS and any of the sides or morris umbrella groups is. That's definitely lack of knowledge on my part, rather than indicative of a lack of interaction. Certainly the three groups named above have all contributed to the EFDSS's magazine, ED&S, recently, although I haven't read their contributions. There's a lot of morris-related material in the EFDSS archives, too. By the way, I'm reliably informed that the society's name is pronounced "EFdəs".

There are, then, four groups identified who either do, or could take on if they so chose, a rôle in promoting the morris to the general public. Given the continued and increasing popularity that web-based media, particularly social media, has in the world, let's examine the part each of these groups plays.

Twitter Presences: 0.

Official Facebook Presences: 2. The EFDSS has a fan page. There's a group for Open Morris too, which looks like it could be run by the real organisation. I think that counts as user-generated content is part of the world of social media.

Official YouTube Channels: 0. Or at least none that I could find.

Myspace Presences: 1. EFDSS again.

Podcasts: 0.

RSS feeds (that scraping noise you hear, it's the bottom of the barrel): 1. It's the Morris Ring's news feed. I nearly fell out of my chair.

For completeness, I'll also mention that there's an unofficial mailing list called MDDL (Morris Dancing Discussion List) which is very active with a strong signal-to-noise ratio.

Now, why should any of this be important? Well, as you're reading this, you're consuming a blog. You either thought "I would like to know what leeg is up to, I'll read his blog", "I heard that some guy on the interwebs really lays into morris dancing organisations, I'll check it out", or something else which made you decide to spend time engaging with social media and user-generated content on the web. That's time which the various morris groups could have spent injecting your brain with Morris Dancing. Are they doing that? No. They're writing internal newsletters bemoaning the lack of traditional dancing in the national curriculum, and press releases for the Torygraph to pick up, claiming that morris dancing is dying out because all of the practitioners are getting too old. In fact, it's been nearly a year since that last one was done.

The problem is that you and I and everybody else don't give a shit about the Morris Ring Circular or their press releases, in the same way we give a shit about, say, procrastinating on YouTube, following interesting people on Twitter, catching up with friends on Facebook and so on. The people who complain about morris dancing fading into irrelevance are even managing to complain about it in an irrelevant fashion. Irony. They're doing it right.

And the most galling thing is that the social media and traditional dancing could go together so well. Take a photo like this, which I took at the Morris 18-30 in WakeField:

You may wonder why everyone's wearing different costumes; well the answer is that they're from different sides. A mash-up could tag the dancers with their side's name, and a link to their website. Your next question would, of course, be the same as mine: "but where the hell is Packington, anyway?" A map showing the location of each side could be available, perhaps even showing proximity of their practice venue to your current location and when they'll next be practising (please, do not get me started on the existing SideFinder pages. You would not like what I would become). Had I remembered what dance was being danced (I think it's Skirmishes, though I'm sure someone would be able to spot it from the photo), then information about that dance and videos of sides performing it could be available.

[Another aside: the relative obscurity of some teams' locations has consequences for those teams' performances. As an example, the fool of Adderbury Morris always wears a hat made of fox skin during the dances. This is because when the first team was formed, the fool went home to tell his wife about his new position. Her response is recorded as being "Adderbury? Wear the fox hat".]

"Aha," you hypothetically cry. "But I would not have seen the photo in the first place, had you not talked about it on your blog." Indeed no, but the point of blogs, Twitter, Tumblr and the like is that you get personal recommendations from people you either trust or consider expert in their field. So I think it's fair to have introduced the photo in that way; and that there's a space online for personal recommendation of trying out morris dancing. And that there ought to be some organisation helping people to do that promotion.

Incidentally, the Morris 18-30 is actually a good example of a group (or phenomenon, I suppose) building a decent website with good amounts of information, and providing an easy way for people to get their photos online. There are many sides which have done the same; Westminster Morris Men's YouTube channel has a decent set of videos including some from the archives. My point is not that this information is not being made available, nor that an effort is not being made — I chose the 18-30 photo for my example because I took the picture and have the right to re-use it in this blog.

I don't think that the fact some sides do well at promoting themselves affects my argument; those who don't have the skills or resources to do this work themselves are not being helped by the national/international bodies. People who might be interested in traditional dancing aren't finding out about it, because the nearest side who have any skill at marketing are in the next county. In a world where information can travel the world in a fraction of a second, that's ludicrous.

So the fact that 18-30 has a good website where people can share information easily is a good thing. The various mash-up suggestions I made would all be good improvements, and were they implemented by an umbrella group then everyone could take advantage of them. My point is that the umbrella organisations should be taking and collating the vast amount of morris-related information out there, and making it easy for people who are not (yet) in the morris to find. They should be using it to promote the dance form and the social activities that surround it, but they aren't. They should be providing a central service to make it easier for sides to share their own material, but they aren't. They should be taking their existing archives and making them available online, but they aren't. They should be looking at the innovations made by some of their members and applying them at the international level, but aren't.

In addition to existing content, there is plenty of scope for promotional material based on novel content distributed over the internet. The dances, music and even pub sessions could make great segments for a vlog or video podcast. Even mini-instructionals could be presented as video podcasts or on a YouTube channel, so that people can try things out without having to join a side first. "What's the point of dancing a team dance on your own?" — leaving jigs aside as PhD-level morris, some people may just want to find out whether they can do some of the basic stuff on their own before turning up to a practice session. If you're not sure whether you want to take part in an activity, would you have your first try in front of twenty people who've been doing it for years, and are each armed with a big stick? Maybe not.

So there's plenty of space for morris information to be distributed digitally. But, really, who gives a toss? That's where the promotional aspect comes in. I've already mentioned the personal level of promotion through Twitter and the like. There are obvious places where morris could be promoted; what's on guides, tourism sites, tradition-reporting sites and the like. But how about novel audiences? Dancers, like many British people, enjoy a Beer in the Evening. Given decent information feeds like the things I described a few paragraphs ago, morris data could be highly Mashable, featuring in those little Facebook games. If people like what they see, they will Digg it. Were one of the umbrella orgs to hire a dashing, intelligent, handsome developer-dancer they could even promote through the iPhone app store (though where would they find such a person?).

And what Americans like to call "the kicker" is this: real people drink beer, use websites and download apps. Most of the dancers I've met are either from families of dancers or already had interest in folk music; in that sense the person on the street is an "unexploited vertical" for the marketers of morris, and probably has been since the end of the first world war.

OK, so that's what could be done, who should be doing it, and why. Is it fair for me to put words in the mouths of the umbrella orgs in suggesting why they aren't currently doing it? No, but I will anyway. If you think this blog is fair, then I've got a slightly-used iBook I'll sell you for a great price.

I think that for a large part, the people in charge probably just don't use and therefore don't understand the potential of social media. But that doesn't explain why the morris umbrella organisations don't do any promotion whatsoever. At least one of the organisations may be wary of getting too much publicity for themselves; I'm not a lawyer of course, but the equality bill currently awaiting its 3rd reading in the House of Commons could require the Morris Ring to change its membership rules, as it "Extends discrimination protection in the terms of membership and benefits for private clubs and associations". I expect there isn't much in the way of training available to the organisations in the general field of marketing. I'm not sure what kind of budgets these groups run on, but maybe the three of them together could afford a part-time marketer.

Of course, there's some appeal to the idea that you're in a secret society, isn't there? It's quite exciting to think that you do something enjoyed by few others, and it's easier to become important in smaller social groups. Not that I'm suggesting that's a related point, oh no.

I apologise for writing such a long post. I didn't have the time to write a shorter one.

Unfamiliar territory

2009-09-25T00:36:00.001+01:00

People who've seen me play music more than once will probably have noticed more than a slight sense of a pattern - give me a fiddle (or if you're really unlucky then I'll bring my own), and I play English folk music. Give me a guitar and I'll play rock and roll. That's just what my fingers are used to - to me the guitar has six strings of rockabilly and the fiddle has four strings of constant billy. No, I didn't write this piece just to get that pun in, though I am glad that I did. I can now go to my grave a happy man, safe in the knowledge that I have compared fishes flying over mountains with blues-derived country music. Classy.

Well, I think it's time to change things around a bit. I want to leave my violin all shook up, and my guitar all in a garden green. It probably sounds quite easy, given that I already know all the tunes, and just want to play them on different instruments, but really it isn't. There are two important issues which make it hard for me to just swap over.

The first is that in many cases I don't actually know the tune at all, I just use muscle memory to get my digits moving in the right places for music to occur. That's particularly true in the case of rock n roll music, where there really aren't tunes at all. There are just 'licks', basic one or two bar figures which are strung together into a twelve bar part. But it's also true in folk music which has a similarly hypnotic repetition but with longer figures. So taking a tune to a new instrument means discovering what it is I'm actually playing on the first instrument, then trying to reproduce that on the second.

The second issue is that just playing the notes from one instrument on another isn't necessarily the correct thing to do, nor even particularly easy. For a start guitar strings are tuned to fourths (mainly) while violin strings are to fifths, and as the bridges are different shapes the instruments invite playing a different number of strings simultaneously. So what I need to do is not even to work out how to play the same tune on the other instrument, but what that instrument's version of the tune should be and how to play that.

I expect that the outcome of this little experiment will be mainly a cacophony, but with some increased understanding of what the instruments can do and how to play them. If I focus on cacophony then I'll probably get quick results, though.

Next Swindon CocoaHeads meeting

2009-09-18T09:21:00.002+01:00

At one time a quiet market town with no greater claim than to break up the journey between Oxford and Bristol, Swindon is now a bustling hub of Mac and iPhone development activity. The coming meeting of CocoaHeads, at the Glue Pot pub near the train station on Monday October 5th, is a focus of the thriving industry.

I really believe that this coming meeting will be a great one for those of you who've never been to a CocoaHeads meeting before. We will be having a roundtable discussion on indie software development and running your own micro-ISV. Whether you are a seasoned indie or just contemplating making the jump and what to find out what's what, come along to the meeting. Share your anecdotes or questions with a group of like-minded developers and discover how one person can design, develop and market their applications.

You don't need to register beforehand and there's no door charge, just turn up and talk Cocoa. If you do want to discuss anything with other Swindon CocoaHeads, please subscribe to the mailing list.

Unit testing Core Data-driven apps

2009-09-06T15:36:00.001+01:00

Needless to say, I'm standing on the shoulders of giants here. Chris Hanson has written a great post on setting up the Core Data "stack" inside unit tests, Bill Bumgarner has written about their experiences unit-testing Core Data itself and PlayTank have an article about introspecting the object tree in a managed object model. I'm not going to rehash any of that, though I will touch on bits and pieces.

In this post, I'm going to look at one of the patterns I've employed to create testable code in a Core Data application. I'm pretty sure that none of these patterns I'll be discussing is novel, however this series has the usual dual-purpose intention of maybe helping out other developers hoping to improve the coverage of the unit tests in their Core Data apps, and certainly helping me out later when I've forgotten what I did and why ;-).

Pattern 1: remove the Core Data dependence. Taking the usual example of a Human Resources application, the code which determines the highest salary in any department cares about employees and their salaries. It does not care about NSManagedObject instances and their values for keys. So stop referring to them! Assuming the following initial, hypothetical code:

- (NSInteger)highestSalaryOfEmployees: (NSSet *)employees {
	NSInteger highestSalary = -1;
	for (NSManagedObject *employee in employees) {
		NSInteger thisSalary = [[employee valueForKey: @"salary"] integerValue];
		if (thisSalary > highestSalary) highestSalary = thisSalary;
	}
	//note that if the set's empty, I'll return -1
	return highestSalary;
}

This is how this pattern works:

Create NSManagedObject subclasses for the entities.

@interface GLEmployee : NSManagedObject
{}
@property (nonatomic, retain) NSString *name;
@property (nonatomic, retain) NSNumber *salary;
@property (nonatomic, retain) GLDepartment *department;
@end

This step allows us to see that employees are objects (well, they are in many companies anyway) with a set of attributes. Additionally it allows us to use the compile-time checking for properties with the dot syntax, which isn't available in KVC where we can use any old nonsense as they key name. So go ahead and do that!

- (NSInteger)highestSalaryOfEmployees: (NSSet *)employees {
	NSInteger highestSalary = -1;
	for (GLEmployee *employee in employees) {
		NSInteger thisSalary = [employee.salary integerValue];
		if (thisSalary > highestSalary) highestSalary = thisSalary;
	}
	//note that if the set's empty, I'll return -1
	return highestSalary;
}

Abstract out the interface to a protocol.
```
@protocol GLEmployeeInterface <NSObject>
@property (nonatomic, retain) NSNumber *salary;
@end
```
Note that I've only added the salary to the protocol definition, as that's the only property used by the code under test and the principle of YAGNI tells us not to add the other properties (yet). The protocol extends the NSObject protocol as a safety measure; lots of code expects objects which are subclasses of NSObject or adopt the protocol. And the corresponding change to the class definition:
```
@interface GLEmployee : NSManagedObject <GLEmployeeInterface>
{}
...
@end
```
Now our code can depend on that interface instead of a particular class:
```
- (NSInteger)highestSalaryOfEmployees: (NSSet *)employees {
	NSInteger highestSalary = -1;
	for (id <GLEmployeeInterface> employee in employees) {
		NSInteger thisSalary = [employee.salary integerValue];
		if (thisSalary > highestSalary) highestSalary = thisSalary;
	}
	//note that if the set's empty, I'll return -1
	return highestSalary;
}
```

Create a non-Core Data "mock" employee
Again, YAGNI tells us not to add anything which isn't going to be used.
```
@interface GLMockEmployee : NSObject <GLEmployeeInterface>
{
	NSNumber *salary;
}
@property (nonatomic, retain) NSNumber *salary;
@end

@implementation MockEmployee
@synthesize salary;
@end
```
Note that because I refactored the code under test to handle classes which conform to the GLEmployeeInterface protocol rather than any particular class, this mock employee object is just as good as the Core Data entity as far as that method is concerned, so you can write tests using that mock class without needing to rely on a Core Data stack in the test driver. You've also separated the logic ("I want to know what the highest salary is") from the implementation of the model (Core Data).

OK, so now that you've written a bunch of tests to exercise that logic, it's time to safely refactor that for(in) loop to an exciting block implementation :-).

CocoaHeads Swindon is this Monday!

2009-09-05T09:53:00.001+01:00

The town of Swindon in the Kingsbridge hundred, Wiltshire is famous for two things. The first is the Wilts and Berks Canal, linking the Kennet and Avon at Trowbridge with the Thames at Abingdon. Authorised by act of parliament in 1775, the canal first passed through the town in 1804 and allowed an explosion in both the industrial and residential capacity of the hitherto quiet market cheaping.

The second is, of course, the local CocoaHeads chapter. Founded by act of Scotty in 2007, Swindon CocoaHeads quickly brought about a revolution in the teaching and discussion of Mac and iPhone development in the South-West, its influence being felt as far away as Swansea to the West and London to the East. Unlike the W&B canal, Swindon CocoaHeads is still thriving to this day. On Monday, 7th September at 20:00 there will be another of the chapter's monthly meetings, in the Glue Pot pub near the train station. Here, Pieter Omvlee will be leading a talk on ImageKit, and the usual combination of beer and Cocoa chat will also be on show. As always, the CocoaHeads website contains the details.

Indie app milestones part one

2009-08-27T00:44:00.001+01:00

In the precious and scarce spare time I have around my regular contracting endeavours, I've been working on my first indie app. It reached an important stage in development today; the first time where I could show somebody who doesn't know what I'm up to the UI and they instinctively knew what the app was for. That's not to say that the app is all shiny and delicious; it's entirely fabricated from standard controls. Standard controls I (personally) don't mind so much. However the GUI will need quite a bit more work before the app is at its most intuitive and before I post any teaser screenshots. Still, let's see how I got here.

The app is very much a "scratching my own itch" endeavour. I tooled around with a few ideas for apps while sat in a coffee shop, but one of them jumped out as something I'd use frequently. If I'll use it, then hopefully somebody else will!

So I know what this app is, but what does it do? Something I'd bumped into before in software engineering was the concept of a User Story: a testable, brief description of something which will add value to the app. I broke out the index cards and wrote a single sentence on each, describing something the user will be able to do once the user story is added to the app. I've got no idea whether I have been complete, exhaustive or accurate in defining these user stories. If I need to change, add or remove any user stories I can easily do that when I decide that it's necessary. I don't need to know now a complete roadmap of the application for the next five years.

As an aside, people working on larger teams than my one-man affair may need to estimate how much effort will be needed on their projects and track progress against their estimates. User stories are great for this, because each is small enough to make real progress on in short time, each represents a discrete and (preferably) independent useful addition to the app and so the app is ready to ship any time an integer number of these user stories is complete on a branch. All of this means that it shouldn't be too hard to get the estimate for a user story roughly correct (unlike big up-front planning, which I don't think I've ever seen succeed), that previous complete user stories can help improve estimates on future stories and that even an error of +/- a few stories means you've got something of value to give to the customer.

So, back with me, and I've written down an important number of user stories; the number I thought of before I gave up :-). If there are any more they obviously don't jump out at me as a potential user, so I should find them when other people start looking at the app or as I continue using/testing the thing. I eventually came up with 17 user stories, of which 3 are not directly related to the goal of the app ("the user can purchase the app" being one of them). That's a lot of user stories!

If anything it's too many stories. If I developed all of those before I shipped, then I'd spend lots of time on niche features before even finding out how useful the real world finds the basic things. I split the stories into two piles; the ones which are absolutely necessary for a preview release, and the ones which can come later. I don't yet care how late "later" is; they could be in 1.0, a point release or a paid upgrade. As I haven't even got to the first beta yet that's immaterial, I just know that they don't need to be now. There are four stories that do need to be now.

So, I've started implementing these stories. For the first one I went to a small whiteboard and sketched UI mock-ups. In fact, I came up with four. I then set about finding out whether other apps have similar UI and how they've presented it, to choose one of these mock-ups. Following advice from the world according to Gemmell I took photos of the whiteboard at each important stage to act as a design log - I'm also keeping screenshots of the app as I go. Then it's over to Xcode!

So a few iterations of whiteboard/Interface Builder/Xcode later and I have two of my four "must-have" stories completed, and already somebody who has seen the app knows what it's about. With any luck (and the next time I snatch any spare time) it won't take long to have the four stories complete, at which point I can start the private beta to find out where to go next. Oh, and what is the app? I'll tell you soon...

On XP mode

2009-08-17T23:54:00.001+01:00

This is a reply to @gcluley, who linked to this ZDNet story (which in turn took its quotes from Sophos Podcasts).

The second most crazy thing about the entire "XP mode" issue in Windows 7 is that the feature is entirely unnecessary. Corporate customers of Windows are already, for the most part, comfortable with managing virtual Windows desktops through third-party products with much better management options or at least have trialled such products. Home users of Windows just take whichever version is pre-installed when they buy the PC and if it means buying new versions of some apps, that's what they do. They're used to it. The group of people who could benefit from XP mode - people with a strong need for app compatibility with XP but with no experience of virtualisation - just doesn't exist.

The very existence of the XP mode feature is a microcosmic example of the way Ballmer has been running Microsoft - if there's a market out there that MS isn't in, MS needs to be in it pronto. Bing, Morro, Web-Office, Zune and now virtualisation are all testament to the inability of Microsoft to concentrate on what it does. What Microsoft really does is to sell two things; an enterprise computing environment and an OEM software distribution. Forget that Windows and Office are accounted as two separate products; MS sell Windows+Office to businesses and Windows to computer makers.

Now the interesting question to ponder is which of Microsoft's (real or perceived; remember they aren't necessarily in this market) competitors the "XP mode" feature is a response to. My interpretation is that it's not actually VMware and its ilk at all - Microsoft is once again responding to nonexistent competition from Apple. Boot Camp and the third-party desktop virtualisation offerings on the Mac (including, without hint of irony, VMware) let users use OS X as their shiny new OS with an "XP mode" of sorts for legacy applications. I think what Microsoft are trying to do here is to show that Windows can be the new shiny with XP as the legacy mode, and are therefore positioning XP mode as a counter to the fictitious competition from Apple. Oh, and if you don't believe me when I say that the competition from Apple doesn't exist - Apple sell all of the premium computers while Microsoft take the aforementioned corporate and OEM markets.

OK, so if that was the second most crazy thing about XP mode, what is the most crazy thing about XP mode? It's also that the feature shouldn't exist. Windows has always had a problem with segregating distinct services which other operating systems don't suffer from. While Microsoft's avoidance of this issue has allowed a whole new software industry to spring up around it, the fact that they need to start a second copy of Windows just to get some applications running in Windows 7 doesn't give me much hope for the future.

The next million-dollar iPhone application

2009-08-14T18:53:00.001+01:00

I'm constantly surprised by questions such as this one. They invariably go along the lines:

I heard that I need to get a Mac to do iPhone development. I want to do iPhone development but do I have to buy a Mac? Is there any other way to develop iPhone software?

If the projected sales for your app don't meet the cost of a new computer, whatever platform you're developing on, it's time to get a different idea for your app. I speak with the smug self-confidence of one who has yet to get his own app within smelling distance of the store.

A rap upon the noggin

2009-08-13T09:20:00.001+01:00

When a patient may be concussed, it's common for parademics to ask simple, topical questions to determine whether the patient is confused. Questions such as "who is the Prime Minister"?

I think somebody may have knocked this poor spammer upside the head (emphasis is mine):

Lloyd's TSB Group plc
25 Gresham Street
London EC2V 7HN

Greetings,

Following the recent announcement by the Chancellor of the Exchequer, Gordon Brown that all assets in accounts that have been

dormant for over 15years be transferred to the Treasury i send this mail to you.

There is a dormant account in my office,with no owner or beneficiaries. It will be in my interest to transfer this assets

worth 20,000,000 British pounds to an offshore country. If you can be a collaborator/partner to this please indicate interest

immediately for us to proceed.

Remember this is absolutely confidential,as i am seeking your assistance to act as the beneficiary of the account, since we

are not allowed to operate a foreign accounts. Your contact phone numbers and name will be necessary for this effect.
I have reposed my confidence in you and hope that you will not disappoint me.

My Regards,
Jim McConville
Lloyd's TSB Group plc

Website relaunch!

2009-07-31T19:52:00.001+01:00

Today I have re-launched Thaes Ofereode to focus on my new role as an independent Mac boffin. I really like the new design, which was created by the ever-delightful Freya.

edit: Gecko doesn't understand the CSS media selector I was using to provide the iPhone CSS. I've therefore reverted the iPhone design until I can find a way to get Firefox to suck less.

The one thing I added to her design was a more iPhone-friendly look. For those of you without iPhones, the screenshots demonstrate how the mobile version will appear. For those of you who are CSS experts, the following will probably be rather dull but for those like me who know enough to be dangerous but no more, here's how it's done.

The three-column layout works really well on the desktop, but the iPhone has a tallscreen-oriented display so not much space for horizontal layout. I therefore chose to put the leftmost, menu column underneath the main content on each page, so iPhone users get to see the heading and then the meat and potatoes. If they are interested enough to get to the end, they'll see the links to the rest of the site.

The links, btw, are just paragraphs with a border, a lot of padding and the magic -webkit-border-radius providing the roundy edges; no messing with JavaScript and funny part-circle images.

So, the third column? Well those impressive-looking widgets can't be displayed on the phone anyway, and would be a bit out of place so they're gone for the moment with the mobile CSS. I may code up some JavaScript replacements soon enough, but I'll need to find somewhere else for them to go. In the meantime, I know you read my blog because you're here, and there are many apps which can help you follow me on Twitter.

Next CocoaHeads Swindon meet!

2009-07-28T23:01:00.001+01:00

So for those of you who didn't manage to enjoy the glories to be found in the town that was the inspiration for one of Legion's more colourful adventures,[*] next Monday, the 3rd of August, offers yet another once-in-a-monthtime opportunity! As ever, the location is in (or just outside) the Glue Pot, a strong man's stone's throw from the Swindon train station. This month's meeting is a recap on QTKit, to allow those who weren't there last time due to the reschedule to catch up on integrating QuickTime into their Cocoa apps.

[*] What am I doing knowing quotes like that? Well, the clue is in the user name. When I was a student my UNIX username was leeg, clearly based on my real name. In short order, I was introduced as "He is Leeg, for he are many" and thus iamleeg.

NSConference videos

2009-07-14T23:20:00.001+01:00

Scotty and the gang have been getting the NSConference videos out to the public lately, and now sessions 7-9 are available including my own session on security. The videos are really high quality, I'm impressed by the postproduction that's gone in and of course each of the sessions I watched at the conference has some great information and has been well-presented. All of the videos are available here.

I've also put the slides for my presentation up over on slideshare.

Refactor your code from the command-line

2009-07-08T04:33:00.001+01:00

While the refactoring support in Xcode 3 has been something of a headline feature for the development environment, in fact there's been a tool for doing Objective-C code refactoring in Mac OS X for a long time. Longer than it's been called Mac OS X.

`tops` of the form

My knowledge of the early days is very sketchy, but I believe that tops was first introduced around the time of OPENSTEP (so 1994). Certainly its first headline use was in converting code which used the old NextStep APIs into the new, shiny OpenStep APIs. Not that this was as straightforward as replacing NX with NS in the class names. The original APIs hadn't had much in the way of foundation classes (the Foundation Kit was part of OpenStep, but had been available on NeXTSTEP for use with EOF), so took char * strings rather than NSStrings, id[]s rather than NSArrays and so on. Also much rationalision and learning-from-mistakes was done in the Application Kit, parts of which were also pushed down into the Foundation Kit.

All of this meant that a simple search-and-replace tool was not going to cut the mustard. Instead, tops needed to be syntax aware, so that individual tokens in the source could be replaced without any (well, alright, without too much) worry that any of the surrounding expressions would be broken, without too much inappropriate substitution, and without needing to pre-empt every developer's layout conventions.

before we continue - a warning

tops performs in-place substitution on your source code. So if you don't like what it did and want to go back to the original… erm, tough. If you're using SCM, there's no problem - you can always revert its changes. If you're not using SCM, then the first thing you absolutely need to do before attempting to try out tops on your real code is to adopt SCM. Xcode project snapshots also work.

replacing deprecated methods

Let's imagine that, for some perverted reason, I've written the following tool. No, scrub that. Let's say that I find myself having to maintain the following tool :-).

#import <Foundation/Foundation.h>

int main(int argc, char **argv, char **envp)
{
	NSAutoreleasePool *arp = [[NSAutoreleasePool alloc] init];
	NSString *firstArg = [NSString stringWithCString: argv[1]];
	NSLog(@"Argument was %s", [firstArg cString]);
	[arp release];
	return 0;
}

Pleasant, non? Actually non. What happens when I compile it?

heimdall:Documents leeg$ cc -o printarg printarg.m -framework Foundation
printarg.m: In function ‘main’:
printarg.m:6: warning: ‘stringWithCString:’ is deprecated (declared at /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:386)
printarg.m:7: warning: ‘cString’ is deprecated (declared at /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:367)

OK so we obviously need to do something about this use of ancient NSString API. For no particular reason, let's start with -cString:

heimdall:Documents leeg$ tops replacemethod cString with UTF8String printarg.m

So what do we have now?

#import <Foundation/Foundation.h>

int main(int argc, char **argv, char **envp)
{
	NSAutoreleasePool *arp = [[NSAutoreleasePool alloc] init];
	NSString *firstArg = [NSString stringWithCString: argv[1]];
	NSLog@"Argument was %s", [firstArg UTF8String], length);
	[arp release];
	return 0;
}

Looking good. But we still need to fix the -stringWithCString:. That could be just as easy, replacemethod stringWithCString: with stringWithUTF8String: would do the trick. However let's be a little
different here. Why don't we use -stringWithCString:encoding:? If we do that, then we're going to need to take a guess at the second argument, because we've got no idea what the encoding should be (that's why -stringWithCString: is deprecated, after all. However if we're happy to assume UTF8 is fine for the output, let's do that for the input. We'd better let everyone know that's what happened, though.

So this rule is starting to look quite complex. It says "replace -stringWithCString: with -stringWithCString:encoding:, keeping the C string argument but adding another argument, which should be NSUTF8StringEncoding. While you're at it, warn the developer that you've had to make that assumption". We also (presumably) want to combine it with the previous rule, so that if we see the original file we'll catch both of the problems. Luckily tops lets us write scripts, which comprise of one or more rule descriptions. Here's a script which encapsulates both our cString rules:

replacemethod "cString" with "UTF8String"
replacemethod "stringWithCString:<cString>" with "stringWithCString:<cString>encoding:<encoding>" {
	replace "<encoding_arg>" with "NSUTF8StringEncoding"
} warning "Assumed input encoding is UTF8"

So why does the <encoding> token become <encoding_arg> in the sub-rule? Well that means "the thing which is passed as the encoding argument". This avoids confusion with <encoding_param>, the parameter as declared in the class interface (yes, you can run tops on headers as well as implementations).

Now if we save this script as cStringNoMore.tops, we can run it against our source file:

heimdall:Documents leeg$ tops -scriptfile cStringNoMore.tops printarg.m

Which results in the following source:

#import <Foundation/Foundation.h>

int main(int argc, char **argv, char **envp)
{
	NSAutoreleasePool *arp = [[NSAutoreleasePool alloc] init];
#warning Assumed input encoding is UTF8
	NSString *firstArg = [NSString stringWithCString:argv[1] encoding:NSUTF8StringEncoding];
	NSLog(@"Argument was %s", [firstArg UTF8String]);
	[arp release];
	return 0;
}

Now, when we compile it, we no longer get told about deprecated API. Cool! But it looks like I need to verify that the use of UTF8 is acceptable:

heimdall:Documents leeg$ cc -o printarg printarg.m -framework Foundation
printarg.m:6:2: warning: #warning Assumed input encoding is UTF8

exercises for the reader, and caveats

There's plenty more to tops than I've managed to cover here. You could (and indeed Apple do) use it to 64-bit-cleanify your sources. Performing security audits is another great use - particularly using constructs such as:

replace strcpy with same error "WTF do you think you're doing?!?"

However, notice that tops is a blunter instrument than the Xcode refactoring capability. Its smallest unit of operation is the source file; refactoring only within particular methods is not quite easily achieved. Also, as I said before, remember to check your source into SCM before running a script! There is a -dont option to make tops output its proposed changes without applying them, too.

Finally tops shouldn't be used fully automated. Always assume that you need to inspect the output carefully, don't just Build and Go.

CocoaHeads Swindon tonight!

2009-07-06T10:47:00.002+01:00

For those of you who've never explored the delights that the fine city of the Hill of Pigs has to offer, tonight offers an unparalleled opportunity. Come and sit in (or outside, weather permitting) a pub only a short distance from the railway station, and listen to Mike Abdullah speaking about WebKit. As always there'll also be general NSDiscussion, and the occasional pint of beer. Maps etc. at our cocoaheads.org page.

Just because Brucie says it...

2009-07-03T23:59:00.001+01:00

Bruce Schneier claims that shoulder-surfing isn't much of a problem these days.

Plenty of people discovered "my password" at NSConference, so I disagree :-) (photo courtesy of stuff mc).

KVO and +initialize

2009-07-01T15:35:00.002+01:00

Got caught by a really hard-to-diagnose issue today, so I decided to write it down in part so that you don't get bitten by it, and partly so that next time I come across the issue, I'll remember what it was.

I had a nasty bug in trying to add support for the AppleScript duplicate command to one of my objects. Now duplicate should, in principle, be simple: just conform to NSCopying and implement -copyWithZone:. The default implementation of NSCloneCommand should deal with everything else. But what I found was that there's a class variable (OK, there isn't, there's a static in the class implementation file with accessors) with which the instances must compare some properties. And this was empty by the time the AppleScript ran. Well, that's odd, thought I, it's only being emptied once, and that's when it's created in +[MyClass initialize]. So what's going on?

Having set a watchpoint on the static, I now know the answer: the +initialize method was being called twice. Erm, OK...why? It's only called whenever a class is first used. It turns out that there were two classes with the same IMP for that method. The first was MyClass, and the second? NSKVONotifying_MyClass. Ah, great, Apple are adding a subclass of one of my classes for me!

It turns out that TFM has a solution:


+ (void)initialize
{
    if (self == [MyClass class])
    {
         //real code
    }
}

and I could use that solution here to fix my problem. But finding out that is the problem was a complete pig.

Going indie!

2009-06-29T19:22:00.001+01:00

This is sort of a message from the past. I wrote it yesterday, but had people I needed to talk to before I could hit the big old publish button. (Including this bit, so I really wrote it "today", but the earliest you can read it means that "today" will be "yesterday". This is one of those uses of the past-perfect-nevertense that blows up lesser recording equipment.)

Today (the real today that this thing was posted), I handed in my notice at Sophos. Six weeks from now, I will be officially an unemployed starving artist. I'm working on lining up a project to take up most of my time for the first few months of the new era, which really looks like it will work out, and of course need to solve the "marketing presence" problem. Although the fact that you're reading this probably means you already know who I am, and something about what I do. If you want a Cocoa or UNIX developer for a contract - especially one with experience in the worlds of security and scientific computing - then please see my LinkedIn profile to find out a bit more of what I've been up to, and drop me a line - here, at @iamleeg or to iamleeg at gmail dot com. I know there are a load of interesting people out there working on a load of interesting projects, one of the great things about WWDC every year is meeting you all and sharing in the excitement. Well hopefully I'll get to work with you on some of that cool software, too!

So, like many people who go self-employed, I've got little idea of what will happen next :-). I've got some ideas for apps which I'll be working on in the (probably too copious) spare time I'll have. But I'm going to focus on contracting and consulting in the short term. This is going to be an exciting time, if somewhat daunting...but you'll be able to check on my daunt levels right here, dear readers.

I promised at the turn of the year that there would be lots of blog posts on various tech things during the first half of the year. Unsurprisingly that didn't quite pan out, and I'm hoping to rectify that over the next couple of months now that I have fewer (perceived) content restrictions on the blog. And this first project I have lined up should certainly be producing some good'uns, assuming it all works out. I'll be the first to admit that if it doesn't, I'm heading for trouble very shortly. Which is why I know that it, or something very like it, will work out :-).

To fellow Sophists who are hearing about this for the first time here, I'm very sorry. I tried to let people know today but there are hundreds of you, one of me and lots of loose ends to tie by mid-August. But don't worry, there will be beer.

Reverse-engineering stringed instruments

2009-06-21T19:47:00.001+01:00

Despite being able to play some instruments, I probably couldn't do a good job of making any of them. I don't have the patience required to boil a horse for long enough to stick a fiddle together, for instance. Luthiers would probably get incredibly bored by the following post but for fellow apart-takers, it'll hopefully be quite interesting.

I once made a stringed synthesiser, when I was at college. The basic principle is that of an electric guitar running in reverse. A metal string is stretched between two bridges, and sits inside a horseshoe magnet. Now rather than plucking the string and letting the magnetic pickup detect the vibrations, we pass an alternating current through the string and use the magnetic field to cause the string to vibrate. Mount the whole shooting match on a soundbox roughly the shape of an appalachian dulcimer, so it makes a decent amount of noise. And there you go!

Well, there bits of you go, anyway. While you can drive the string at any frequency you like, it'll be really quiet on any note which isn't a natural harmonic - it's being forced at one frequency, and trying to vibrate at a bunch of other frequencies, so can't really resonate. Assuming that the materials of the string aren't up for grabs, it's the length and tension which choose the fundamental frequency. What you currently have is capable of playing bugle tunes. Put a few different bugles together and you can play chromatic scales, so putting a few different strings together increases the likelihood that our synthesiser has the ability to play some notes in the tune we want.

In fact, it's still going to have a fairly nasty volume characteristic, because most of the noise doesn't come from the string, it comes from the soundbox. In that regard, violins and pipe organs have quite a lot in common. But they differ in that pipe organs have one soundbox per note - the pipe itself - and violins have a single box. So it'd better be possible to get it to resonate at a whole bunch of interesting frequencies, which is one of the reasons for making them (and acoustic guitars) the shapes that they are. Now what the real acoustic characteristics of a fiddle body are, I'm not entirely sure. But what I do know is that a violin is surprisingly small - the "concert pitch" A pipe in an organ is a little under 40cm and the lowest note a violin usually has (a ninth lower) will therefore be almost a metre long. Even though an enclosed box like a violin needs to be half the length of an organ pipe playing the same note, it will still naturally accentuate the higher frequencies that the strings have on offer because it isn't big enough to do much else. And it's that which gives the instruments their sound. My synth's soundbox was cuboid-ish, so had two characteristic "loud" notes and their harmonics. The z-axis wouldn't have resonated much as the box was on a table which absorbed the momentum.

The remaining interesting point is that the violin is forced to extract the sound from a rubbish part of the string. The bridge is both responsible for translating the motion of the string into the wood and for stopping the string from moving. The string moves most somewhere out toward the middle (it's mainly vibrating at its natural wavelength, which is twice the length of the string) and not at all near the ends. That's why pickups on electric guitars sound "warmer" further away form the bridge. There they pick up more of the lower harmonics, but the nearest pickup (and the bridge) get proportionally more of the higher harmonics.

Beer improves perception of security

2009-06-16T23:58:00.001+01:00

...at least, it provides for a nice analogy to use when discussing basic security concepts. I don't think people necessarily choose better passwords after a skinful, nor do they usually make improved choices of what information to share on social networking sites when returning from the pub. That's probably why Mail Goggles exists.

So, the attendee beer bash at WWDC. There is beer. There is also the regulatory framework of the state of California, which mandates that minors under 21 years of age may not be supplied with beer. There are also student scholarship places to the WWDC, and no theoretical minimum attendee age. There are also loads of people in the vague area of Yerba Buena Gardens who are not attending the WWDC. But only attendees may visit the bash, and only attendees over 21 may drink beer.

I went to the registration desk at Moscone West on the day before Phil Schiller's keynote, and identified myself as Graham Lee. "Hi, my name's Graham Lee" I said to the lady behind the desk. It turns out that's not sufficient. While I did indeed give the name of someone who was indeed registered to attend the conference, there's no reason for the lady to believe the identification I gave her. She wants to be able to authenticate my claim, and chooses to rely on a trusted third party to do so. That third party is the British government (insert your own jokes here), and she is happy to accept my passport as confirmation of my identity.

Now I am given my attendee badge, a token which demonstrates that I have authenticated as Graham Lee, an attendee at WWDC. When I move around the conference centre to get to the sessions and the labs, the security staff merely need to look for the presence of this token. They don't need to go through the business of checking my passport again, because the fact that I have my token satisfies them that I have previously had my identity authenticated to the required level.

The access token would be sufficient to get me in to the attendee beer bash, as it proves that I have authenticated as an attendee. But it does not demonstrate that I am authorised to drink beer. So on the day of the bash I go back to the registration desk and show a different lady my passport again, which indicates that I am over 21 and can therefore be given the authority to drink beer at the bash. I am given the subtle green wristband pictures, which again acts as a token; this time not an identification token but an authorisation token. The bar staff do not care which of the 5200 attendees I am. In fact they do not care about my identity at all, because they know that the security staff have already verified my attendee status at the entrance to the event - therefore they don't need to see my attendee pass. They only care about whether I'm in the group of people permitted to drink beer, and the wristband shows that I am in that group. It shows that I have demonstrated the credentials needed to gain that particular authority.

So, there we have it. A quick beer of an evening with a few thousand colleagues can indeed turn into a fun discussion of the distinction between authentication and authorisation, and how these two tasks can be carried out independently.

WWDC wind-down

2009-06-13T16:01:00.003+01:00

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 :-).

Unit testing Cocoa projects in Xcode

2009-06-10T16:52:00.002+01:00

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?

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

2009-06-03T23:17:00.001+01:00

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.

chord graphics

2009-05-29T19:06:00.001+01:00

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.

Prepping for WWDC

2009-05-28T22:54:00.001+01:00

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

The rokeg blood pie^W^W^Wplot thickens

2009-05-20T00:16:00.001+01:00

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...

Detect the gagh lurking in your system!

2009-05-19T12:53:00.004+01:00

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)

Rootier than root

2009-05-02T13:36:00.005+01:00

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.

On dynamic vs. static polymorphism

2009-04-25T19:44:00.001+01:00

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.

Did you miss my NSConference talk?

2009-04-21T20:40:00.001+01:00

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.

I may have not been correct

2009-04-20T22:22:00.001+01:00

When I said Apple should buy Sun, whether that was a good idea or not, it seems to have failed to occur. Instead, we find that Oracle have done the necessary. Well, there goes my already-outdated SUNW tag. Presumably they'll keep Java (the licensing revenue is actually pretty good), MySQL (I've heard that Oracle make databases), the OS and a subset of the hardware gear. Then they'll become the all-in-one IT industry in a box vendors that Cisco have yet to organise, with (presumably x86) servers running the Solaris-Glassfish-Oracle-Java app stack in some insanely fast fashion. I wonder how many of the recent leftfield hardware projects they'll just jettison, and who will end up running the Santa Clara business unit...

On default keychain settings

2009-04-19T17:00:00.001+01:00

After my presentation at NSConference there was a discussion of default settings for the login keychain. I mentioned that I had previously recommended some keychain configuration changes including using a different password than your login password. Default behaviour is that any application can add a secure item to the keychain, and the app that did the adding is allowed to read and modify the entry without any user interaction. As Mike Lee added, all other apps will trigger a user dialogue when they try to do so - the user doesn't then need to authenticate but does have to approve the action.

That almost - but not quite - solves the issue of a trojan horse attempting to access the secure password. Sure, a trojan application can't get at it without asking the user. What about other trojan code? How about a malicious SIMBL hijack or a bundle loaded with mach_override? It should be possible to mitigate those circumstances by using custom code signing requirements, but that's not exactly well documented, and it's not really good usability for an app to just die on its arse because the developer doesn't like the other software their user has.

There's a similar, related situation - what if the app has a flawed design allowing it to retrieve a keychain item when it doesn't need it? Sounds like something which could be hard to demonstrate and harder to use, until we remember that some applications have "the internet" as their set of input data. Using a web browser as an example, but remembering that I have no reason to believe whether Safari, Camino or any other browser is designed in such a way, imagine that the user has stored an internet password. Now all that the configuration settings on the user's Mac can achieve is to stop other applications from accessing the item. If that browser is itself subject to a "cross-site credentials request" flaw, where an attacking site can trick the browser into believing that a login form (or perhaps an HTTP 401 response, though that would be harder) comes from a victim site, then that attacker will be able to retrieve the victim password from the keychain without setting off any alarms with the user.

If the user had, rather than accepting the default keychain settings, chosen to require a password to unlock the keychain, then the user would at least have the chance to inspect the state of the browser at the time the request is made. OK, it would be better to do the right thing without involving the user, but it is at least a better set of circumstances than the default.

NSConference: the aftermath

2009-04-17T18:16:00.001+01:00

So, that's that then, the first ever NSConference is over. But what a conference! Every session was informative, edumacational and above all enjoyable, including the final session where (and I hate to crow about this) the "American" team, who had a working and well-constructed Core Data based app, were soundly thrashed by the "European" team who had a nob joke and a flashlight app. Seriously, we finally found a reason for doing an iPhone flashlight! Top banana. I met loads of cool people, got to present with some top Cocoa developers (why Scotty got me in from the second division I'll never know, but I'm very grateful) and really did have a good time talking with everyone and learning new Cocoa skills.

It seems that my presentation and my Xcode top tip[*] went down really well, so thanks to all the attendees for being a great audience, asking thoughtful and challenging questions and being really supportive. It's been a couple of years since I've spoken to a sizable conference crowd, and I felt like everyone was on my side and wanted the talk - and indeed the whole conference - to be a success.

So yes, thanks to Scotty and Tim, Dave and Ben, and to all the speakers and attendees for such a fantastic conference. I'm already looking forward to next year's conference, and slightly saddened by having to come back to the real world over the weekend. I'll annotate my Keynote presentation and upload it when I can.

[*] Xcode "Run Shell Script" build phases get stored on one line in the project.pbxproj file, with all the line breaks replaced by \n. That sucks for version control because any changes by two devs result in a conflict over the whole script. So, have your build phase call an external .sh file where you really keep the shell script. Environment variables will still be available, and now you can work with SCM too :-).

Controlling opportunity

2009-04-03T18:12:00.003+01:00

In Code Complete, McConnell outlines the idea of having a change control procedure, to stop the customers from changing the requirements whenever they see fit. In fact one feature of the process is to be heavy enough to dissuade customers from registering changes.

The Rational Unified Process goes for the slightly more neutral term Change Request Management, but the documentation seems to imply the same opinion, that it is the ability to make change requests which must be limited. The issue is that many requests for change in software projects are beneficial, and accepting the change request is not symptomatic of project failure. The most straightforward example is a bug report - this is a change request (please fix this defect) which converts broken software into working software. Similarly, larger changes such as new requirements could convert a broken business case into a working business case; ultimately turning a failed project into a revenue-generator.

In my opinion the various agile methodologies don't address this issue, either assuming that with the customer involved throughout, no large change would ever be necessary, or that the iterations are short enough for changes to be automatically catered for. I'm not convinced; perhaps after the sixth sprint of your content publishing app the customer decides to open a pet store instead.

I humbly suggest that project managers replace the word "control" in their change documentation with "opportunity" - let's accept that we're looking for ways to make better products, not that we need excuses never to edit existing Word files. OMG baseline be damned!

On noodles

2009-03-04T22:52:00.001Z

It's usually considered a good idea to keep a blog focused on exactly one subject. Sod that for a game of soldiers! This one's all about music.

Steph, who is a very good musician and knows what she's talking about, wrote that there are two ways to play a harp, a "get the music right" recitation style and a "get the rhythm right and everything else follows" style more suited to improvisation, noodling or folk playing.

That's not only true of the harp, it seems to hold for many instruments. For instance, in a moment of crazed, um, craziness this weekend I bought what's commonly referred to as a lute. In fact, a lute with much in common with this lute. Now I've been playing it for all of about two hours in total since Saturday, and can barely remember what note each course plays, and do a poor rendition of about four different tunes from a book of trivially simple lute tunes. But today marked an interesting transition, as it was the first day that I could make music up on the instrument without either knowing or concentrating on what I was doing. Only a couple of things (the song "Wooden Heart" made famous by Elvis Presley, and that banging dance-floor filler "Parson's Farewell") but this represented the point where I could make music on the lute - a different skill than remembering where and when to stick fingers on some bits of nylon, steel and wood.

And I think that's where the root of Steph's distinction of playing techniques really comes from; the unprepared style relies on having some music that needs to occur, and the ability for your hands (or nose or whatever your instrument is played with) to move around in some way which causes that music to exist. Whereas the prepared style relies on having some performance in mind that must be repeated, and requires that you think about moving $appendage in such-and-such way to recreate that performance. I find the distinction in conscious application to be an important one when playing the fiddle, an instrument I'm marginally better at than the lute. If I'm reading some music, playing solo or otherwise engaged in trying to play music, then I can only play whatever notes the music contained and in a fairly uninteresting manner. It's only if I'm able to relax and not think about the music that I can harmonise, ornament and otherwise play more interesting things than what was written on the page - even if not necessarily particularly well :-).

Cocoa: Model, View, Chuvmey

2009-02-23T21:45:00.001Z

Chuvmey is a Klingon word meaning "leftovers" - it was the only way I could think of to keep the MVC abbreviation while impressing upon you, my gentle reader, the idea that what is often considered the Controller layer actually becomes a "Stuff" layer. Before explaining this idea, I'll point out that my thought processes were set in motion by listening to the latest Mac Developer Roundtable (iTunes link) podcast on code re-use.

My thesis is that the View layer contains Controller-ey stuff, and so does the Model layer, so the bit in between becomes full of multiple things; the traditional OpenStep-style "glue" or "shuttle" code which is what the NeXT documentation meant by Controller, dynamic aspects of the model which could be part of the Model layer, view customisation which could really be part of the View layer, and anything which either doesn't or we don't notice could fit elsewhere. Let me explain.

The traditional source for the MVC paradigm is Smalltalk, and indeed How to use Model-View-Controller is a somewhat legendary paper in the use of MVC in the Smalltalk environment. What we notice here is that the Controller is defined as:

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate.

We can throw this view out straight away when talking about Cocoa, as keyboard and mouse events are handled by NSResponder, which is the superclass of NSView. That's right, the Smalltalk Controller and View are really wrapped together in the AppKit, both being part of the View. Many NSView subclasses handle events in some reasonable manner, allowing delegates to decorate this at key points in the interaction; some of the handlers are fairly complex like NSText. Often those decorators are written as Controller code (though not always; the Core Animation -animator proxies are really controller decorators, but all of the custom animations are implemented in NSView subclasses). Then there's the target-action mechanism for triggering events; those events typically exist in the Controller. But should they?

Going back to that Smalltalk paper, let's look at the Model:

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

If the behaviour - i.e. the use cases - are implemented in the Model, well where does that leave the Controller? Incidentally, I agree with and try to use this behavior-and-data definition of the Model, unlike paradigms such as Presentation-Abstraction-Control where the Abstraction layer really only deals with entities, with the dynamic behaviour being in services encapsulated in the Control layer. All of the user interaction is in the View, and all of the user workflow is in the Model. So what's left?

There are basically two things left for our application to do, but they're both implementations of the same pattern - Adaptor. On the one hand, there's preparing the Model objects to be suitable for presentation by the View. In Cocoa Bindings, Apple even use the class names - NSObjectController and so on - as a hint as to which layer this belongs in. I include in this "presentation adaptor" part of the Controller all those traditional data preparation schemes such as UITableView data sources. The other is adapting the actions etc. of the View onto the Model - i.e. isolating the Model from the AppKit, UIKit, WebObjects or whatever environment it happens to be running in. Even if you're only writing Mac applications, that can be a useful isolation; let's say I'm writing a Recipe application (for whatever reason - I'm not, BTW, for any managers who read this drivel). Views such as NSButton or NSTextField are suitable for any old Cocoa application, and Models such as GLRecipe are suitable for any old Recipe application. But as soon as they need to know about each other, the classes are restricted to the intersection of that set - Cocoa Recipe applications. The question of whether I write a WebObjects Recipes app in the future depends on business drivers, so I could presumably come up with some likelihood that I'm going to need to cross that bridge (actually, the bridge has been deprecated, chortle). But other environments for the Model to exist in don't need to be new products - the unit test framework counts. And isn't AppleScript really a View which drives the Model through some form of Adaptor? What about Automator…?

So let me finish by re-capping on what I think the Controller layer is. It's definitely an adaptor between Views and Models. But depending on who you ask and what software you're looking at, it could also be a decorator for some custom view behaviour, and maybe a service for managing the dynamic state of some model entities. To what extent that matters depends on whether it gets in the way of effectively writing the software you need to write.

When techs collide

2009-02-09T20:25:00.001Z

If you've ever seen the film Ghostbusters, you'll know that each of the proton packs was, on its own, very powerful and capable of performing its function. Combine two, by crossing the streams, and rather than something twice as powerful you have a potentially Zuul-beating, potentially universe-destroying chaotic mess on your hands.

Such a combination I found today, when I mixed a little bit of Distributed Objects with a soupçon of Cocoa Bindings to create, um, Distributed Bindings (calling it Cocoa Objects would just be rude).

It's actually just as simple as you think it will be, so there's no point in any sample code. You can basically use the answer to the FAQ question on DO. Once you've got the proxy object in the client, use it as the observable controller in -bind:toObject:withKeyPath:options:. And that's it!

Well, not quite it. You'll notice that things are a wee bit crashy, which is why this is somewhat like crossing the streams. Both Bindings and DO use the Proxy pattern to achieve their magic, but because the two systems have no special knowledge of each other the proxy connections are not kept in sync. If your server object mutates after the DO connection disappears, then it tries to send a KVO notification to an object that's no longer there…boom. Having a client-server system where the client can crash the server is of, well, dubious utility. There are some things that you could do to mitigate this, for instance looking for NSConnectionDidDieNotification (in the server) or opening a heartbeat RPC for the client to "check in" with the server. These fixes will work perfectly, if the vended object is updated predictably enough that you can reliably take care of broken connections between KVO notifications. Without that you're SoL, as the server won't reliably get a DO exception - more often than not it'll segfault. But while this may be unstable, it still is damned cool.

A lack of CocoaHeads

2009-02-02T20:19:00.002Z

Apologies to anyone sat in the Glue Pot wondering where the nerds are. Due to a general feeling of bitter colditude we've postponed for a couple of weeks. But never fear, Scotty shall still wax forth on SearchKit on the 16th of the month.

Most favouritest and least favourite Macs

2009-01-24T13:08:00.001Z

The current meme seems to be, given the 25th anniversary of the launch of the Mac (and I'm not going to let it slip by that it's the 20th anniversary of the NEXTSTEP 1.0 launch this year, either) to write an opinion on the best and worst Macs we've ever used. So here's mine.

Obviously my Mac use comes as a result of Mac OS X, so neither of my choices are particularly old machines. My favourite is a definite thing, and it's the first Mac I ever bought myself - a PowerMac G4 Sawtooth. I didn't own it from new; I bought it from a contractor who was writing a WebObjects app for us when I worked at the University. It was a "G4 Server" according to the sticker, which really just meant that it came with a SCSI adaptor fitted standard, and the pièce de resistance: Mac OS X Server 1.2 installed :-). The 1.x series of MOSES (Mac OS Enterprise Server) was a release of Rhapsody, a straight port of OPENSTEP to the PowerPC with a couple of changes. Most noticable were the configuration of startup items, the platinum UI and some changes to the Workspace to make it a little more similar to the Mac OS Finder. The 450MHz G4 I had was blazingly fast in this OS, and none too shabby when it came to more modern OS X too. When I finally sold it on it was running 10.4.

My least favourite is less clear-cut, I have a choice of two. But I think I'm going to give it to the Beige G3 Power Mac I borrowed long-term, I think from the University, when I was a student. This was really a slightly updated Power Mac 8600 with a faster CPU in, but the CPU's capabilities were significantly limited by the architecture (50MHz bus, 5MBPS SCSI) which really belonged to the older 603-alike processors. I seem to remember it having some weird amount of memory, like 208MB, because I'd scrounged different chips from different places, but even with that much RAM it couldn't do more than crawl in OS X 10.0-10.2. As with the G4 I installed Server 1.2, but many of the Java components really were staggeringly slow on this system.

Quote of the year (so far)

2009-01-03T00:15:00.001Z

From David Thornley via StackOverflow:

"Best practices" is the most impressive way to spell "mediocrity" I've ever seen.

I couldn't agree more. Oh, wait, I could. *thud* There it goes.

Tautology of the year (so far)

2009-01-02T23:16:00.001Z

From iDefense, via DarkReading:

A recent wave of fatwas issued by radical Islamic religious leaders in that region authorizing these groups to use cyberattacks to defend Islam has opened the door for these groups to wage cyberattacks, according to iDefense.

In other news, water has been found to be wet. (seriously considering a "my beloved language, you've killed it!" tag)

Quick antispam observation

2009-01-01T11:12:00.001Z

One thing I've been doing recently is removing my membership of a load of websites that I don't seem to have used in a long time. One side effect of not using a website in a long time is that I forget the password I created for the account, so I get to see how the website handles failed login attempts. Often, quite a few times :-(.

Now, some of these sites - and I've been notifying the owners as I go - give you a different failure message if you get your password wrong or your e-mail address. This is, to quote the twitterverse, made of fail. It means these websites can be used to automatically generate lists of the members' e-mail addresses; useful to spammers, phishers (remember that the list is based on being a member of a particular site, so it's easy to target the phish at that site) and even for later trying to compromise accounts on that site. I'd really avoid being a member of any site whose login page worked like that, and try to get them to change their error messages.

What's new in 2009

2009-01-01T02:47:00.001Z

Of course, it's a bit early for a retrospective of 2008, besides which I've already written 73 entries this year, my most prolific year to date on iamleeg. And that doesn't count numerous tweets, stack overflow contributions and of course the occasional piece of source code here or there for some security company. As the noise of fireworks and exploding media players sounds across the world, it's time to pre-emptively ditch 2008 and see what we can expect from 2009. Specifically, what you can expect from me.

It looks to me like the most popular pieces on this blog are the opinions and how-tos regarding Cocoa development, particularly my thoughts on properties and Cocoa memory management round-up. Don't worry, there's definitely more of this coming. As well as preparing for this Mac Developer Network conference talk I've been discussing recently, I've got another exciting - and unfortunately secret - project on the go now which should see plenty of collateral blog posting in the first half of the next year, all about Cocoa development. There'll also be a bit more of an iPhone mix-in; obviously for much of last year the SDK either didn't exist or was under non-disclosure, but now I've got more reasons to be using Cocoa Touch it will also be mentioned on here. I shall also be delving a bit deeper into Darwin and xnu than I have in previous times.

One example of Cocoa-related information is meetup announcements; I'm still involved in the local CocoaHeads chapter and I'll endeavour to post an advance warning for each meeting here. I know many of my readers are in the States but a few of you are local so please do come along! In fact, if you're not local (or "bissen't from rond theez partz", as we say here) then consider going to your nearest CocoaHeads or starting a new one. It's a great way to find out who's working on Mac or iPhone development in your area, share tips and stories and build up that professional contacts network.

Previously I've been concerned that readers here at iamleeg don't seem interesting in commenting on my posts, but these days I'm no longer worried. I can tell how many people are reading, and of those how many are regulars, and I have to say that the blog is doing pretty damn well. Of course, if you do feel inclined to join in the discussion (particularly if I've got something wrong, or missed an important point from a post) then you should feel perfectly at liberty to leave a comment.

Finally, have a happy new year!

Cocoa Memory Management

2008-12-22T12:34:00.001Z

It becomes evident, thanks to the mass centralisation of the neverending september effect that is stackoverflow, that despite the large number of electrons expended on documenting the retain/release/autorelease reference counting mechanism for managing memory in Cocoa, Cocoa Touch, UIKit, AppKit, Foundation, GNUstep, Cocotron and Objective-C code, very few people are reading that. My purpose in this post is not to re-state anything which has already been said. My purpose is to aggregate information I've found on the topic of managing memory in Cocoa, so I can quote this post in answers to questions like these.

In fact, I've already answered this question myself, as How does reference counting work? As mentioned in the FAQ, I actually answered the question "how do I manage object lifecycles in (Cocoa|GNUstep|Cocotron)"? It's actually a very violently distilled discussion, so it's definitely worth checking out the references (sorry) below.

Apple have a very good, and complete, Memory Management Programming Guide for Cocoa. They also provide a Garbage Collection Programming Guide; remember that Objective-C garbage collection is opt-in on 10.5 and above (and unavailable on iPhone OS or earlier versions of Mac OS X). GNUsteppers reading along should remember that the garbage collector available with the GNU objc runtime is entirely unlike the collector documented in Apple's guide. GNUstep documentation contains a similar guide to memory management, as well as going into more depth about memory allocation and zones. Apple will also tell you how objects in NIBs are managed.

The article which gave me my personal eureka moment was Hold Me, Use Me, Free Me by Don Yacktman. Stepwise has another article, very simple rules for memory management in Cocoa by mmalc, which is a good introduction though with one caveat. While the table of memory management methods at the top of the article are indeed accurate, they might give you the impression that keeping track of the retain count is what you're supposed to be doing. It's not :). What you're supposed to be doing is balancing your own use of the methods for any given object, as described in rules 1 and 2 of "Retention Count rules" just below that table.

James Duncan Davidson's book "Learning Cocoa with Objective-C" has not been updated in donkey's years, but its section on memory management is quite good, especially the diagrams and the "rules of thumb" summary. Luckily, that section on memory management is the free sample on O'Reilly's website.

If reading the theoretical stuff is all a bit too dry, the Mac Developer Network have a rather comprehensive memory management training video which is $9.99 for non-MDN members and free for paid-up members.

Finally, Chris Hanson has written a good article on interactions between Cocoa memory management and objc-exceptions; if you're using exceptions this is a good discussion of the caveats you might meet.

Wikipedia == fail

2008-12-22T04:00:00.001Z

On the same day that fark announce the wikipedia irony, I would like to point out a similar situation I saw just today.

This is from the Susie Dent entry discussion page:

IMDb relies on the contributions of the public, so isn't an overly reliable source.

better security, not always more security

2008-12-21T02:45:00.001Z

Today's investigative investigations have taken me to the land of Distributed Objects, that somewhat famous implementation of the Proxy pattern used for intra-process, inter-process and inter-machine communication in Cocoa. Well, by people who measure whether it's a performance hog, rather than those who quote it; as a hint, it was indeed a significant overhead when your CPU was a 25MHz 68030 and your network link a 10BASE-2 coaxial wire. These days we can spend around those problems freely.

Specifically, I wondered whether I should add discussion of the authentication capabilities in PDO to the FAQ entry. Not that it's frequently asked - indeed, it's a NAQ - but because getting mentions of security into a Usenet FAQ is likely to cause newbies to be thinking about security, which is possibly a good thing (for the world, not so much my uniquely employable attributes). But I decided no, though the subject is interesting, it's not because of the technicality, but the philosophy.

Distributed Objects works by sending NSPortMessage messages over NSConnection connections. The connections and message-passing bumph are peer-to-peer, but DO adds some client-server distinction by having servers register their vended connections with name servers and clients look up the interesting vendors in said name servers. By default, anything goes; all connections are honoured and all clients serviced. There are two security features (both implemented as delegate methods) baked into DO, though. The most interesting of the two is the authentication.

The reason that the authentication feature is interesting is that it's implemented in such a way as to make non-security-conscious developers question the security. The end sending the NSPortMessage includes some data based on the constituent parts of the message, and the end receiving the message decides whether to accept it based on knowledge of the constituents and of the data. On the face of it, this looks like shared-secret encryption, with the shared secret being the algorithm used to hash the port message. It also appears to have added no security at all, because the message is still sent in plain text. In fact, what this gives us is more subtle.

All that we know is that given the source information and the sender's authentication data, the receiver gets to decide whether to accept the sender's message. We don't necessarily know the way that the receiver gets to that decision. Perhaps it hashes the information using the same algorithm as the sender. Perhaps it always returns YES. Perhaps it always expects the authentication data to be 42. On the other hand, perhaps it knows the public key of the sender, and the authentication data is a signature derived from the content and the sender's private key. Or perhaps the "authentication data" isn't used at all, but the source material gives the server a chance to filter malicious requests.

Now all of that is very interesting. We've gone from a system which looked to be based on a shared secret, to one which appears to be based on whichever authentication approach we decide is appropriate for the task at hand. Given a presumed-safe inter-process link, we don't need to be as heavyweight about security as to require PKI; whereas if the authentication were provided by a secure tunnel such as DO-over-SSL, we'd have no choice but to accept the cost of the PKI infrastructure. Given the expectation of a safe server talking to hostile clients, the server (or, with some amount of custom codery, a DO proxy server) can even sanitise or reject malicious messages. Or it could both filter requests based on authentication and on content. The DO authentication mechanism has baked in absolutely zero policy about how authentication should proceed, by letting us answer the simple question: should this message be processed? Yes or no? Choose an approach to answering this question based not on what you currently believe could never be circumvented, but on what you currently believe is sufficient for the environment in which your DO processes will live. If a shared secret is sufficient and adds little overhead, then do that, rather than 4096-bit asymmetric encryption.

By the way, the second security feature in DO is the ability to drop a connection when it's requested. This allows a DO server to survive a DoS, even from a concerted multitude of otherwise permissible clients.

Whither the codesign interface?

2008-12-11T23:37:00.001Z

One of the higher-signal-level Apple mailing lists with a manageable amount of traffic is apple-cdsa, the place for discussing the world's most popular Common Data Security Architecture deployment. There's currently an interesting thread about code signatures, which asks the important question: how do I make use of code signatures?

Well, actually, it's not so much about how I can use code signatures, but how the subset of Clapham Omnibus riders who own Macs (a very small subset, as the combination of overheating batteries in the old G4 PowerBooks and combustible bendy-busses means they don't stay around very long) can use code signatures. Unfortunately, the answer seems to currently be "not by much", with little impression of that changing. The code signing process and capability is actually pretty damned cool, and a nice security feature which I'll be talking about at MacDev 09. It's used to good effect in the iPhone, where it and FairPlay DRM are part of that platform's locked-down execution environment.

The only problem is, there's not much a user can do with it. It's pretty hard to find out who signed a particular app, in fact the only thing you can easily do is discover that the same entity signed two versions of the same app. And that's by lack of interface, not by any form of dialogue or confirmation. That means that when faced with the "Foobar app has changed. Are you sure you still want to allow it to [whatever]" prompt, many users will be unaware of the implications of the question. Those who are and (sensibly) want to find out why the change has occurred will quickly become frustrated. Therefore everyone's going to click "allow", which rather reduces the utility of the feature :-(.

Is that a problem yet? Well, I believe it is, even though there are few components yet using the code signature information in the operating system. And it's precisely that allow-happy training which I think is the issue. By the time the user interfaces and access control capabilities of the OS have developed to the point where code signing is a more useful feature (and believe me, I think it's quite a useful one right now), users will be in the habit of clicking 'allow'. You are coming to a sad realisation; allow or deny?

You keep using that word. I do not think it means what you think it means.

2008-12-01T23:45:00.001Z

In doing a little audience research for my spot at MacDev 2009, I've discovered that the word "security" to many developers has a particular meaning. It seems to be consistent with "hacker-proof", and as it could take most of my hour to set the record straight in a presentation context, here instead is my diatribe in written form. Also in condensed form; another benefit of the blog is that I tend to want to wrap things up quickly as the hour approaches midnight.

Security has a much wider scope than keeping bad people out. A system (any system, assume I'm talking software but I could equally be discussing a business process or a building or something) also needs to ensure that the "good" people can use it, and it might need to respond predictably, or to demonstrate or prove that the data are unchanged aside from the known actions of the users. These are all aspects of security that don't fit the usual forbiddance definition.

You may have noticed that these aspects can come into conflict, too. Imagine that with a new version of OS X, your iMac no longer merely takes a username and password to log a user in, but instead requires that an Apple-approved security guard - who, BTW, you're paying for - verifies your identity in an hour-long process before permitting you use of the computer. In the first, "hacker-proof" sense of security, this is a better system, right? We've now set a much higher bar for the bad guys to leap before they can use the computer, so it's More Secure™. Although, actually, it's likely that for most users this behaviour would just get on one's wick really quickly as they discover that checking Twitter becomes a slow, boring and expensive process. So in fact by over-investing in one aspect of security (the access control, also sometimes known as identification and authorisation) my solution reduces the availability of the computer, and therefore the security is actually counter-productive. Whether it's worse than nothing at all is debatable, but it's certainly a suboptimal solution.

And I haven't even begun to consider the extra vulnerabilities that are inherent in this new, ludicrous access control mechanism. It certainly looks to be more rigorous on the face of things, but exactly how does that guard identify the users? Can I impersonate the guard? Can I bribe her? If she's asleep or I attack her, can I use the system anyway? Come to that, if she's asleep then can the user gain access? Can I subvert the approval process at Apple to get my own agent employed as one of the guards? What looked to be a fairly simple case of a straw-man overzealous security solution actually turns out to be a nightmare of potential vulnerabilities and reduced effectiveness.

Now I've clearly shown that having a heavyweight identification and authorisation process with a manned guard post is useless overkill as far as security goes. This would seem like a convincing argument for removing the passport control booths at airports and replacing them with a simple and cheap username-and-password entry system, wouldn't it? Wouldn't it?

What I hope that short discussion shows is that there is no such thing as a "most secure" applications; there are applications which are "secure enough" for the context in which they are used, and there are those which are not. But the same solution presented in different environments or for different uses will push the various trade-offs in desirable or undesirable directions, so that a system or process which is considered "secure" in one context could be entirely ineffective or unusable in another.

Free apps with macdev ticket

2008-12-01T23:10:00.001Z

The Mac Developer network currently have a Special Offer running until christmas eve, get a free copy of Changes and Code Collector Pro with your ticket. Both are useful apps for any developer's arsenal.

Some bloody genius

2008-11-23T18:35:00.001Z

Link to the image, because I know it's too wide for the Blogger template to display properly.

More on MacDev

2008-11-04T13:39:00.002Z

Today is the day I start preparing my talk for MacDev 2009. Over the coming weeks I'll likely write some full posts on the things I decide not to cover in the talk (it's only an hour, after all), and perhaps some teasers on things I will be covering (though the latter are more likely to be tweeted).

I'm already getting excited about the conference, not only because it'll be great to talk to so many fellow Mac developers but due to the wealth of other sessions which are going to be given. All of them look really interesting though I'm particularly looking forward to Bill Dudney's Core Animation talk and Drew McCormack's session on performance techniques. I'm also going to see if I can get the time to come early to the user interface pre-conference workshop run by Mike Lee; talking to everyone else at that workshop and learning from Mike should both be great ways to catch up on the latest thoughts on UI design.

By the way, if you're planning on going to the conference (and you may have guessed that I recommend doing so), register early because the tickets are currently a ton cheaper. Can't argue with that :-).

I'm sorry, I haven't a Clu

2008-11-04T00:31:00.001Z

One of my many "repeat-until-funny" jokes, anyway here is what I have to say on Mr. Cluley's blog regarding iPh0wn.

Solaris iPhone Edition

2008-10-29T23:43:00.001Z

Apple's one new feature in Snow Leopard is support for Exchange, which if not squarely an Enterprise lure is certainly bait for medium businesses. But here we hit Apple's perennial problem; they want to sell more into businesses (because that's where at least 2/3 of all PC money is to be made) but they want to design their systems for home users. When a system is designed to cover every possible potential use for a computer we end up with Windows, which is the kind of "few things to all people" solution that Apple are - rightly - keen to avoid. But as Tim Cook's "state of the Mac" segment in the recent laptop event showed, one of Apple's biggest growth areas is education which is organised along enterprisey lines.

Their solution thus far has been a partial one; we get Mac OS X which is basically a consumer OS, and then we get Mac OS X server which is the same OS with a few configuration changes and extra apps to support being used as a workgroup server. This is less distinct than the changes between Mac OS X and iPhone OS X, but the principle is the same; the same technology is used in different ways, so we get different interfaces to it. Note that these aren't really very divergent products - a UNIX expert could set up an Open Directory Master on a standard Mac OS X box were they so inclined. We get the Mac Pro and the XServe as nods to the existence of more powerful hardware than the iMac. While Apple do have a network of business development managers, enterprise sales people, sales engineers and so on who can support larger customers, their capabilities and freedom are restricted by working on a consumer product in a consumer organisation.

Assuming that Apple aren't going to retreat and consolidate all of their effort on the consumer/prosumer, the logical plan seems to be "the same only more so"; carry on the scheme of applying a common technology base to multiple markets, but with the product interfaces and configurations being specific to the role in which they'll be used. Empower those enterprise sales, support and development teams to make the changes required in both the shared technology base and the domain-specific parts in order to advance their own cause. Allow them to do so in such a way that the consumer focus of the standard products is not diluted. To do all this, what Apple would need is to clearly delineate their Core OS, Consumer OS and Server OS engineering groups, while adding staff, expertise and intellectual property to their Server OS, Server Hardware and Enterprise Support groups.

The bit about "adding staff, expertise and intellectual property to their Server OS, Server Hardware and Enterprise Support groups" can be easily achieved by using the Blue Peter principle. Here's one I prepared earlier. And no, I'm not going mad. Sun have plenty of experience in supporting larger customers and what marketing people like to call vertical markets, and have some good technology: hardware, operating systems software, enterprise services and applications. Their only problem is that they can't make any money on it. On the other hand with Apple it seems that the money is there to be made, and the problem is stepping up to that plate without compromising the consumer products. Consolidating Mac OS X [+ Server] and Solaris 10 would not be trivial but is not beyond the realms of fantasy. NeXTSTEP ran on SPARC hardware, and as we know that Mac OS X runs on PPC, two different Intel architectures and ARM it's likely that the effort to port Mac OS X to SPARC would not be great. But perhaps more useful in the short term is that OpenStep ran on Solaris before, and could do again. Even though Sun have switched Solaris to a SYSV-derived platform, due to Apple's recent push for standardisation with Leopard the two OS are likely more source-code compatible than NeXTSTEP and SunOS 4 ever were. Getting Cocoa up on Solaris would mean that application portability (for the sorts of apps that server admins will want - including Apple's own server admin tools, not for OmniDazzle) becomes viable while the combined company (Snapple?) concentrate on integrating the core tech. They could even get Jonathan Schwartz to do the coding.

Another factor in this proposition is that JAVA is cheap. Apple currently have about $20B in cash and Sun's shares are worth $3.6B, but taking into account that Sun have lost 98% of their dot-com-boom value without slowing their R&D projects, the value for money when you want them for their tech, smarts and goodwill rather than their user base is astounding.

Oh, and speaking of JAVA, what about Java? Java currently represents Sun's main income due to the licensing scheme, but Apple's investment in the platform has declined over time from the Rhapsody days of "everything is Java"; currently the available Java on Mac OS X lags behind Sun's version and isn't ppc64 compatible. The WebObjects team (and hence the Apple store and iTunes) have a heavy Java investment, while other teams have dropped Java (Cocoa) and still others eschew it completely. The iPhone has a very busy developer ecosystem - and absolutely no Java. Where the hypothetical Snapple would leave Java is entirely open, but the option of packaging up the combined company's Java assets and re-selling them would seem unnecessary, unless you thought that even $3.6B was too much to pay.

All you never wanted to know about temporary files and were too ambivalent to ask

2008-10-19T20:12:00.001+01:00

In the beginning, there was mktemp. And it was good.

Actually, that's a load of rubbish, it wasn't good at all. By separating the "give me the name of a temporary file" and "open the file" stages, there's a chance for an attacker to create the temporary file with the name you've chosen between the stages, or create a symlink with the same name.

Next there came mkstemp. And that was better. But not by much. mkstemp opens the file for you as well as choosing a name, so the file was guaranteed to not exist beofre you tried to use it, and will definitely have the ownership and permissions you want.

There is yet another step which the über-paranoid application could take in order to ensure that no other process can see its temporary files, and that is to unlink the file as soon as you get it back. Unfortunately there's no "mkstempr" function (and it might get confused with the equally non-existent mkstemp_r), so this is still a two-stage operation. Unlinking a file which you have open removes it from the directory listing, but doesn't change the fact that you have it open; it's now exclusively yours.

It was asked for: the "features" post

2008-10-15T20:27:00.001+01:00

Someone anonymous once said:
I'm intrigued by your feature comment. Please publish said blog post!
Where said comment was:
The fact that I have stopped using the word 'feature' in many contexts is an entire blog post and a few therapy sessions in itself.
So here, for your delectation, is that entire blog post.

When you're trying to decide what software people want, and indeed how to tell them that they want whatever software they're going to get instead, that's marketing (mainly - it's partly sales, and there's yet another tangential post on why I occasionally deliberately conflate marketing and sales). Marketing works in terms of features, which for the purposes of marketing means "properties or qualities of the software which we think might make people interested in that software".

When you're trying to decide what software to build, or trying to build the software, more specific terms are used. Initially people split requirements into two distinct groups, functional (what the system is capable of) and non-functional (how the system goes about its capabilities), but a more precise organisation is often needed. For instance, a requirement of system security might result in both functional and non-functional aspects of the system being specified.

Of course, some or all of the capabilities are also features, in fact it's generally true that the set of all features, the set of all known requirements and the set of things the customer wants are intersecting subsets of the set of all possible qualities of a software system. Companies without an intersection between any two of these sets tend to go out of business very quickly. But the sets rarely perfectly overlap.

For instance, it's a feature of Windows 7 that it's named differently from Windows Vista, because Microsoft's marketing requires that customers believe that they've put Vista behind them. However, it's also a feature of Windows 7 that it not be very distinct from Vista, because marketing require that application compatibility doesn't get broken. Hence we have the interesting situation that Windows 7 is also Windows 6.1. And if Microsoft think they're being innovative in that version numbering policy, they should try looking up the history of SunOS/Solaris version numbers. BTW, indeed I haven't switched my SUNW tag to JAVA, because I already use the java tag to mean the Java language and the Java platform. Marketing people can be funny sometimes.

Another example, less confusing though more contradictory, is Apple's Snow Leopard collateral. The fact that marketing are telling us there are no new features in Snow Leopard means that "no features" is something they believe we might want to buy, which in turn makes it a feature… confused?

So anyway, I try to avoid using the word "feature" when I'm talking about software, because I'm usually instead talking about a capability or property of a software system, and not about marketing that software system. For instance, in Properties about a year on I described properties as a capability of the Objective-C 2.0 language, which indeed they are. It happens that properties is also a feature of the language (don't believe that programming languages have marketing departments? What else do Apple's tech evangelists do, if it isn't marketing?), but in the case of that post I was talking about what can be done with properties, how properties can be used, and not how they can switch developers to Leopard from Tiger or .NET.

And in other news, it seems that badly-parked tech company founder Mercs are back in fashion.

The view(s) from the hotel

2008-10-05T21:27:00.001+01:00

Which two buildings are across the street from my current location?

and

anyone might think it had been deliberately chosen for comedy purposes…

Properties about a year on

2008-10-04T06:20:00.001+01:00

Leopard has now been out for nearly a year, which means that (publicly) we've had Objective-C 2.0 for the same amount of time. At the release many developers were champing at the bit to talk about the new language capabilities[*], including properties. There were arguments on both sides of the divide, and even a little bit of discussion. But now that we've been using these things for a while, and because I'm ~~bored~~ ~~awake~~ ~~grouchy~~ ~~vocal~~ opinionated, let's have a look back at what they've given us.

There is a broken abstraction in traditional Objective-C, which is the accessor-method-as-property-declaration. Essentially an object can give you two things; work (i.e. it can do stuff) and state information (i.e. it can say stuff about itself and let you change it). In traditional object-oriented languages, because 'saying' and 'changing' are verbs which can be 'done', the two have both been expressed using the same method (heh) as the expression of work. This is not the case in much object-oriented design, for instance in UML a class always has separate "attributes" and "operations".

Properties fix up this abstraction by giving us orthogonal ways to express the two concepts. Work is done in methods; state is got/changed in properties. Now it may be that the state information is actually backed by a method (although it may bang on the ivar directly; more below), but we don't need to know that any more than we need to know in the interface that a property is synthesized or dynamic. All we do need to know is that it is there for us to use, and has certain attributes such as being read-only.

The "on more below" bit is that discussions of KVC-like mechanisms - such as KVC :-) - often involve someone pointing out that they break encapsulation, because it's possible to access an @private ivar with no accessors by retrieving it by key. That's really thinking about the design of a class in terms of the way it's executed rather than its interface contract with the developer, because the @private ought to tell the developer not to touch that particular ivar. Properties neither help nor hinder breakage from the execution side, but from the design side they do provide a stronger distinction between "properties I'm telling you about in the interface" and "things you shouldn't touch". Now we can all get back to using the class's interface to observe how to use it, and that C struct bit at the top to observe how to extend it, as nature intended. It's both a blessing and a curse that Objective-C allows things to appear in source files which don't make it into the executable code, but that doesn't stop such information being useful to the developer in the same way that code comments can be read but not executed.

One of the popular complaints about ObjC properties is the syntax for referring to them in methods (OK, or indeed in functions), where it is argued that myObject.someProperty = 4; doesn't readily tell you whether myObject is an ObjC object, a C struct or a C union. That seems to be at worst a straw man argument to me, and at best a hypothetical issue; in well-designed software it will be rare to mix code at various levels of abstraction except in limited circumstances such as adapter classes. Besides, if the code has been written such that it can be inspected or reviewed (i.e. to some agreed style and standard) and the reviewer is paying attention then it will be easy to distinguish use of the various types. At some conceptual level the C . and Objective-C . operator are doing the same thing anyway; they're both saying "this attribute of that thing".

[*]The fact that I have stopped using the word 'feature' in many contexts is an entire blog post and a few therapy sessions in itself.

MacDev 2009!

2008-09-28T20:27:00.001+01:00

It's a long way off, but now is a good time to start thinking about the MacDev '09 conference, organised by the inimitable Scotty of the Mac Developer Network. This looks like being Europe's closest answer to WWDC, but without all those annoying "we call this Interface Builder, and we call this Xcode" sessions. Oh, and a certain Sophist Mac engineer software will be talking about building a secure Cocoa application.

Rhetoric, smoothly outlined

2008-09-25T23:09:00.002+01:00

Something I did a number of years ago (I could tell you how many, couldn't I? If I could remember; I think it must have been 7) was to study critical analysis. That's the application of linguistics and sociology to, well, basically to refusing to believe anything people say to you ever again. As an example of how it's useful to someone who isn't a professional rhetorician, here's a discussion of the things I read in The iPhone Store Impending Disaster Myth. Mainly because that article is fairly close to the top of my RSS feed reader.

The first thing to note is the use of loaded language in the title - the hyperbolic phrase "impending disaster" and its syzygy with the word "myth" clearly setting the author's stall out. This is reinforced by the first paragraph:

According to the predictable opinion scribes [...]They’re wrong, here’s why.

That first sentence fragment paints the subjects of the author's post as thoughtless machines, churning out page after page of text reinforcing their unchanging opinion. Ironically that is exactly what we are about to read for the next several paragraphs. It's a convenient amalgamation of two rhetorical techniques; most obviously it is an ad hominem (to the man) argument. Attention is diverted away from the discussion of Apple's app store and onto the people with which the author disagrees. This then is the beginning of a straw man which will be constructed toward the end of the piece, sowing the seed in the reader's mind that the author's opponent does not have a relevant argument.

The final sentence, "they're wrong, here's why", is a trademark of this particular author (or maybe that's an example of confirmation bias on my part) and actually renders the rest of the article meaningless for most people. It tells us that the rest of the article is a repudiation (for why it isn't a refutation, read on, but the point of this sentence is some verbal sleight of hand to make you believe that a refutation is to follow) of the position the author has defined for the "predictable opinion scribes", which is either going to make you believe that what's coming up will be an excellent riposte or a boring diatribe, depending on the opinion you've already formed about this author. All that the remaining part of the article needs to do is to fill up past the end of the page so that you believe the riposte/diatribe really exists, and it performs this task with aplomb.

What happens from here is actually rather subtle. The author outlines the position he intends to oppose, followed by "here’s[sic] the facts they’re missing". But the next few sections, from "Developers, Developers, Developers" to "Why Platforms Win" contain an opinionated retrospective on the computing industry, using links to the author's own articles as references. Opinionated? Well, count the number of times the phrase "third rate, old technology" appears. It's actually only four, but it moves from what "IBM, Microsoft, and the PC cloners [Oxford comma sic]" were doing to "the Microsoft strategy". There's enough filler (26 paragraphs and 10 linked articles in the same style by the same author) that it could be easy to forget that segue occurred. A fact which doesn't escape the author:

If you made it this far, you may have forgotten that the first argument against Apple vetoing apps

Too right we might have forgotten. What we haven't forgotten is that we were told "here's why" the app store naysayers were wrong, but have actually been told why Lotus 1-2-3 outsold Visicalc. The author's argument follows the pattern "B follows A. C. Therefore A." Loosely the argument could be described as a "red herring fallacy", although a word I prefer is that the intervening text underwent a process known as "contextomy".

Anyway, before we got here, our author let his façade slip a little:

Now let’s hammer away at the sappy pleading on behalf of developers who want Apple to cater to their whims due to the attractive populist concept of fairness in doing so.

Ooops! Now, do we think that the author is for or against people who disagree with Apple? Anyway, enough backtracking. Why don't we move forward from the end of my previous <q>?

[...] is that its decisions are unpredictable and arbitrary.

Now read the rest of that section. There's a good amount of text to describe why these decisions aren't arbitrary. Whatever happened to unpredictable? Oh, and for bonus points, look for where the final paragraph contradicts the earlier thrust of the section and reinforces the notion that arbitrary rejections have occurred.

The rest of the article carries on in the same vein, and having seen the way in which I automatically parse the earlier part you can probably guess how my cynical mind interprets the rest of the text. Oh, and speaking of cynicism, if you're still wondering why this is a repudiation and not a refutation, then my evil little mind-play trick worked! You've read at least part of every paragraph in the hope to get information I promised at the beginning; if only I'd put some adverts in the post somewhere. So to refute means to prove to be false, whereas to repudiate means to reject. The article we've just looked at is an internally inconsistent expression of the author's opinion, no proof having occurred. It's also an example of the informal fallacy of suppressed correlative. Apple's practices can't be bad, because Microsoft's practices are bad and Apple's are better than Microsoft's.

Well, that was fun! The next time you're talking to your boss (or better, your marketing people), listen out for those rhetorical devices and remember to stay critical :-).

AppleScript, for once

2008-09-24T21:01:00.001+01:00

AppleScript isn't something I write much about, in fact this is the first post I've ever created on the topic. But AppleScript, like the Services menu and Automator, provides that most useful of usability enhancements: the ability to use multiple applications together without fulfilling the marketing requirements of having to look at them all.

As an example, a folder action script might let me combine the Finder with any other application, such as, choosing completely at random, Sophos Anti-Virus:

on adding folder items to this_folder after receiving these_items set theScript to "/usr/bin/sweep -nc" repeat with i from 1 to number of items in these_items set thePath to POSIX path of item i of these_items set theScript to theScript & space & thePath end repeat set theScript to theScript & space & "--quarantine:mode=000" do shell script theScript end adding folder items to

that script then scans any file which appears in a particular folder and locks it if it contains a virus (up to a point). But that's not really the point, the point is that I haven't actually had to use any of the target apps in order to get this combined functionality. It's like I was able to summon the Megazord without having to actually talk to the individual Power Rangers. Erm, or something. And that, really, is how a computer should work; I didn't buy OmniFocus so that I could look at its icon, or a splash screen, I bought it because it can manage my lists of things to do. And I got iCal in order to manage events in time. If I have things to do at specific times, then I ought to be able to combine the two, and the computer can do the work involved. After all, that is why I bought the computer.

Overdoing the risk management

2008-09-15T20:12:00.001+01:00

I own a notebook. In fact, I own several notebooks. One in particular has an interesting feature (where I use "feature" in the "different from the competition, though we don't know whether anyone actually needs it" sense); inside the front cover is space to write your address, and a dollar value reward available to the person who returns the notebook.

Now the notebook itself is probably worth about $20, but on the face of it a used notebook is worth less than a pristine notebook, with a full notebook having no value. Presumably the value of the reward should be related to the value of the notes contained within it, and therefore can't be ascertained until I've filled the notebook up. But then if I were to lose it before filling in the pages, I would not have entered an interim value; and if I had then whenever I made new notes I would need to update the worth of the book.

And who should be footing the bill, anyway? Are my musings of any financial benefit to me, or if my employers get more worth from them should they be contributing to the reward fund? Could I possibly make the same notes again were I to lose this book? Could I pay someone with a lower salary than mine to have thoughts with a similar monetary value? Would someone else who came across my notebook be able to extract the same worth from the contents than me? If so, should I write in an encrypted fashion? How much more would that cost me? Should the reward factor in the costs of decrypting the contents, possibly reverse-engineering the method if I've forgotten it?

Do ideas depreciate? Clearly patentable ideas do, will my ideas be patentable? Will I be able to benefit from the patents? If someone finds the notebook and returns it, are the ideas still patentable? What about non-patentable thoughts, do they all depreciate at a constant rate? Should the reward value be a function of time?

Clearly the only people who can answer all of these questions upfront, and therefore the people who can use this reward feature with confidence, are the people whose ideas can be modelled with a waterfall development process. Take Terry Pratchett; he might know that the content of one notebook equates to roughly 50% of a novel, and that each novel is worth £200k, and therefore the value to him of the notebook is less than £100k. A thought process which eventually results in a cash value for a notebook. For those of us whose ideas are somewhat more iterative (read: chaotic), this seems like a complete misfeature.

Me.com. Your identity, everywhere.

2008-09-08T13:11:00.004+01:00

Title linky goes to a Sophos blog post I wrote about the relative success of MobileMe phishing scams, and the insecurity of MobileMe web access.

Apple 2, iamleeg 0

2008-09-05T20:40:00.001+01:00

So, my few-year-old iPod decided it had had enough, and with pay day having only just passed I thought maybe it would be nice to get a new one. What's happened today? Got the new one home, and it won't work at all (searching for "error 1434" isn't particularly useful, either). However, the one that previously broke, having now been taken apart, started working again. So my 20GB 4G iPod is now humming along nicely (running Podzilla), and my 160GB classic is b0rked :-(.

The twitter sitter hit a bitter critter

2008-09-02T22:39:00.001+01:00

Yup, more on the subject of a home-grown Twitter client. This time, posting and sorting out the UI somewhat have both been achieved:

Posting tweets is amazingly simple - just take the tweet and stuff it into the body of a POST NSURLRequest. The Twitter API even handily returns the posted tweet, so the same code which parses the friends timeline can also insert the new tweet.

So, where to go next? Well, I'm getting bored of typing my password in all the time so Keychain would be nice, @reply buttons and perhaps searching. I'm going to need cache management soon, too.

Mac user Gmail account hack

2008-09-02T19:34:00.001+01:00

I found today in Macintouch reader reports the news that a Mac user found his Gmail account had been taken over. He writes:

I woke up this morning and looked at my gmail and thought, gee that's weird, it won't accept my password. I figured it was a glitch and tried it on my iphone, same thing.

Then I asked for a password reset. When I got back into the account, found a bunch of sent emails from a Nigerian scammer. I also looked at the ip history in gmail and noticed the weird IP, which of course came from Nigeria.

This relates well to a point I've made repeatedly in podcasts and papers; namely that having information worth stealing is not a Windows-only situation. As more data is stored "in the cloud" then the security of the cloud and of the way we use it becomes as important what is going on in our own computers. Having a weak Facebook password compromised will work just as well if you're on Trusted Solaris as Windows.

In other news, yesterday's Twitter client is not really much further along, because a thunderstorm has meant I've unplugged all of my electronics (the laptop isn't plugged in to anything, obviously). I am now very grateful to MarsEdit for having offline editing capability, otherwise I'd have to try and remember all this stuff later ;-)

A better bit o' twitter than the bitter twitter Tommy Titter bought

2008-09-01T22:26:00.001+01:00

Just because everyone these days writes a Twitter client:

This was actually a quick hack project to make up for the fact that I missed CocoaHeads tonight (due to a combination of an uninteresting phone call, and a decision to recover from the phone call by using the rest of my petrol tank). Really just an excuse to play with some APIs (the tweets are grabbed by the controller using NSURLConnection, then some NSXML/XPath extracts the useful information (or not, it is Twitter after all) and puts it into the model), there are many things which need to happen before this is at all a useful Twitter client; the ability to write back, nicer formatting are just the starters. Shiny Core Animation twitting ought to happen.

Still, not bad for two hours I think.

Fuzzing as a security testing tool

2008-09-01T20:56:00.001+01:00

Google have a new browser project, called chrome, and in their introduction they explain perfectly, through the medium of image, how fuzzing works.

Of course, as anyone could tell you, if you take a thousand monkeys and a thousand typewriters and put them all in a room for long enough, you will end up with a thousand broken typewriters, ten fat monkeys and 990 monkey skeletons.

Walking a mile dans ses chausseurs

2008-08-29T22:24:00.003+01:00

The word 'translator' has an interesting history. In the Anglo-Saxon language, 'wealhstod' meant "learned in Welsh" more or less, and described someone who could parlay with the important members of the local British tribes. As is often the case with invasions the British started to use the word, so the Welsh title 'Gwalstawt' means "interpreter of tongues", i.e. the Welsh word for "can speak another language" originally meant "can speak Welsh" (there's another word more closely related to Breton treiñ or Cornish trélya in Welsh, too; trosi).

Anyway, to see what localisation people go through during the l10n process, I decided the best thing to do was to try it myself. To save the time it would have taken to write an internationalised app, I used someone else's; namely TextEdit. Here's the result after about 90 minutes of work:

The first thing to notice is that I haven't actually got much done yet. I've started working on the main menu NIB file (Edit.nib), and I'm about halfway through that. At this rate, it would take me at least a (working) day to finish - granted I'm no expert at the task, so I'm having to make a more heroic effort on otherwise "standard" translations than most localisers would. Although I do have a glossary to help. Even so, TextEdit is a fairly simple app; it's easy to see that even if the translation became a mechanical process, translating a complex program would take a long time.

The other thing you might have noticed is that Mac OS X doesn't actually support Old English, and yet that's the language of my translation. There's a simple trick here; convince Mac OS X that it does support Old English ;-). Type this command in the Terminal:

$ defaults write NSGlobalDomain AppleLanguages '(ang, en, /* other languages */)'

and Robert, as they say, is your father's brother. Apps will now look for localised resources in 'ang.lproj' when they start, so that's where your Old English resources live.

Next CocoaHeads Swindon meeting

2008-08-27T23:48:00.002+01:00

1st September (that's this coming Monday), in the Glue Pot, Swindon. 8:00pm start. Chris Walters will talk about, well, something, and we'll be drinking beer, listening and occasionally chipping in. See you there!

So are Macs uber-pricey?

2008-08-17T03:03:00.001+01:00

No, but Sony Vaios are.

Back from holiday

2008-08-13T17:56:00.001+01:00

I went on holiday to Stockholm this week. Of the ~1.5GB I downloaded from the camera, this was the photo I thought most apt to describe the experience on this blog:

Cocoa#, Mono and Me

2008-07-29T23:40:00.001+01:00

My great application:

Yeah, OK, not so great. But this Inverse Hoffman is the result of a couple of hours hacking in Mono, with Cocoa#. My app's largely based on the Stupid Word Counter tutorial, though it's a from-scratch implementation of the famous Apple/NeXT sample application in C#.

Firstly, a little history. My first encounter with .NET was back in about 2003 at a Microsoft Developer Roadshow in the car park (and later lecture theatre) in Oxford's comlab. I was particularly interested in their discussions of cross-platform capability, Project Rotor (I kept in touch with one of the Rotor developers) and so on, but really didn't see much exciting in .NET. Nonetheless, being a fair man, I took my beta CDs of Windows 2003 and Visual Studio .NET and gave them a whirl. Unfortunately, still not much interesting. Largely due to buggy betas and a lack of beta documentation.

Now accessing Cocoa from non-ObjC languages is nothing new, we've been doing it from Perl, Python, Ruby and Java for ages and partcularly old farts might even remember Objective-Tcl. Why should I care about Cocoa#? Well for a start, there are likely to be a lot Windows developers out there with some (language that boils down to MS IL eventually) skills who are wanting to produce Mac applications, and it'd be interesting to see what we'll end up with when they do. And it's always fun to learn a new language, anyway ;-)

Good points

Real NIB files. No really, that interface is genuinely an IB 3.x NIB based on the Cocoa Application template. The objects inside it are Objective-C objects, and there are good old outlets and actions (I haven't yet investigated whether Cocoa Bindings would work).

macpack. A command-line tool which takes your IL executable and wraps it up in a Cocoa application bundle, ready for drag-deployment.

Good inline bridging information. Unlike, say, PyObjC the language bridge isn't completely dynamic, but unlike the Java bridge or JIGS you don't have to keep a separate manual mapping of real classes onto ObjC shams. For instance, here's the controller from Currency Converter.net, complete with class, ivar and method exports:

namespace info.thaesofereode.CurrencyConverter
{
	[Cocoa.Register("CurrencyConverterController")]
	public partial class CurrencyConverterController : Cocoa.Object
	{
		public CurrencyConverterController(System.IntPtr native_object) : base(native_object) {}

		//Cocoa IBOutlets
		[Cocoa.Connect]
		private Cocoa.TextField inputCurrency;
		[Cocoa.Connect]
		private Cocoa.TextField outputCurrency;
		[Cocoa.Connect]
		private Cocoa.TextField conversionRate;

		//Cocoa IBAction
		[Cocoa.Export("calculate:")]
		public void calculate(Cocoa.Object sender)
		{
			//get the rate from the view
			System.String rate = conversionRate.Value;
			CurrencyConverterModel.Rate = System.Convert.ToDouble(rate);
			//get the currency
			System.String input = inputCurrency.Value;
			System.Double output = CurrencyConverterModel.convert(System.Convert.ToDouble(input));
			//update the UI
			outputCurrency.Value = System.Convert.ToString(output);
		}
	}
}

Bad points

Not very Cocoa-like wrapper classes. I think this is deliberate; they've gone for making the Cocoa shim look like a .NET interface because after all, we're programming from .NET. This is a bit disappointing as I'm more familiar with PyObjC and the Perl-ObjC-Bridge where the APIs are left pointedly alone, but given the target audience of Cocoa# it's unsurprising.

MonoDevelop. Luckily, using it isn't mandated.

So, overall, one more good point than bad (and a tentative two, if you overlook MonoDevelop); a pretty good initial evaluation and I might give this a deeper scrape.

Microblogging

2008-07-22T22:33:00.001+01:00

For a long time, I deliberately avoided microblogs like twitter. I thought that they were simply an acknowledgement that people want to be published more than they want to have something to say. However, it would be rude of me to completely disavow the medium without actually giving it a go.

To that end, I may indeed be iamleeg on twitter, as soon as twitter actually finishes processing the signup form.

I'd like to point out that one problem I'm going to have is brevity - I have spent 650 characters telling you what my username is. Constraining myself to SMS-sized wibblings will indeed be tricksy.

Common sense writ large

2008-07-21T22:04:00.001+01:00

Looking at the bottom of Apple's Q3 results, as indeed with any similar publication from a US publicly-traded company, we see the following text.

This press release contains forward-looking statements including without limitation those about the Company’s estimated revenue and earnings per share. These statements involve risks and uncertainties, and actual results may differ. Risks and uncertainties include without limitation potential litigation from the matters investigated by the special committee of the board of directors and the restatement of the Company’s consolidated financial statements; unfavorable results of other legal proceedings; the effect of competitive and economic factors, and the Company’s reaction to those factors, on consumer and business buying decisions with respect to the Company’s products; war, terrorism, public health issues, and other circumstances that could disrupt supply, delivery, or demand of products; continued competitive pressures in the marketplace; the Company’s reliance on sole service providers for iPhone in certain countries; the continued availability on acceptable terms of certain components and services essential to the Company’s business currently obtained by the Company from sole or limited sources; the ability of the Company to deliver to the marketplace and stimulate customer demand for new programs, products, and technological innovations on a timely basis; the effect that product transitions, changes in product pricing or mix, and/or increases in component costs could have on the Company’s gross margin; the effect that product quality problems could have on the Company’s sales and operating profits; the inventory risk associated with the Company’s need to order or commit to order product components in advance of customer orders; the effect that the Company’s dependency on manufacturing and logistics services provided by third parties may have on the quality, quantity or cost of products manufactured or services rendered; the Company’s dependency on the performance of distributors and other resellers of the Company’s products; the Company’s reliance on the availability of third-party digital content; and the potential impact of a finding that the Company has infringed on the intellectual property rights of others. More information on potential factors that could affect the Company’s financial results is included from time to time in the Company’s public reports filed with the SEC, including the Company’s Form 10-K for the fiscal year ended September 29, 2007; its Forms 10-Q for the quarters ended December 29, 2007 and March 29, 2008; and its Form 10-Q for the quarter ended June 28, 2008, to be filed with the SEC. The Company assumes no obligation to update any forward-looking statements or information, which speak as of their respective dates.

Erm, like, duh. Stuff which we say might happen in the future, might not actually happen. Really? You've got to get out of the financial industry, there's a lucrative career ahead of you in construction.

Designing a secure Cocoa application

2008-07-18T21:56:00.001+01:00

That's the title of next month's CocoaHeads Swindon, and I'll be leading the presentation/discussion. So if you want to learn a little about how to ensuring your Cocoa app doesn't give away the keys to the kingdom, or have some experiences to share with the rest of the group, come along! We'll be at the Glue Pot, which is nice and near the train station as well as reasonably close to a car park. We'll be congregating at 7:00 but will wait for everyone to be settled with a beer in their hand before starting ;-).

Ah, the sweet sound of my own voice

2008-07-14T13:59:00.000+01:00

The title is a linky to the press release regarding the edition of Sophos Podcasts I recorded with Carole, and which has now (clearly) gone live. In it we mainly talk about the data theft and Macs technical paper I've already posted about. This is the first podcast I've ever been involved in, so any feedback you have (apart from telling me that I sound drunk in my first sentence, I'm not sure what that's all about) will be most welcome!

CocoaHeads Swindon

2008-07-08T00:47:00.001+01:00

Just got back from the first meeting of Swindon CocoaHeads, featuring a bunch of people who live nowhere near Swindon, some good beer and the occasional discussion of Cocoa. Special mention to Scott who came all the way from sunny Warsaw to be with us!

Tonight's event was an informal, "what do we want from Swindon CocoaHeads?" event, but it looks like being successful enough that we'll be doing it again. The format will be a presentation or directed conversation, followed by general chit-chat about all things Cocoa. In fact, um, I may have volunteered to give the first presentation at the next meeting. The subject is: well, that would be telling, wouldn't it… ;-). You'll have to find out by coming along to the Glue Pot in Swindon at 8pm on Monday, August 4th. Look out for further announcements and a mailing list over at Scotty's place in the forthcoming month!

Objective-C NAQs

2008-06-24T22:33:00.001+01:00

Never-Asked Questions :-)

In Code Complete 2 §6.5, Steve McConnell presents a list of class-related design issues that "vary significantly depending on the language". So why don't we look at them for Objective-C? Especially as I can't find anyone else who's done so based on a couple of Google searches… N.B. as ever, I'm really considering Cocoa + Objective-C here, as the language itself doesn't provide enough policy for many of the issues to have an answer (only method resolution and the existence of isa are defined by the runtime and the compiler - ignoring details like static string instances, @protocol and so on).

Behaviour of overridden constructors and destructors in an inheritance tree. Constructors are simple. If you can initialise an object, return it. If you can't, return nil. The -[NSObject init] method is documented as simply returning self.

For destructors, we have to split the discussion into twain; half for garbage collection and half for not. In the world of the Apple GC, destruction is best done automatically, but if you need to do any explicit cleanup then your object implements -finalize. The two rules are that you don't know whether other objects have already been finalized or not, and that you must not resurrect your object. In the world of non-GC, an object is sent -dealloc when it has been released enough times not to stick around. The object should then free any memory claimed during its lifetime, and finally call [super dealloc]. Note that this means objects which use the voodoo cohesion of "OK, I'll clean up all my resources in -dealloc" probably aren't going to work too well if the garbage collection switch is flipped.

Behaviour of constructors and destructors under exception-handling conditions. Exceptions are a rarity in Cocoa code (we didn't have language-level exceptions for the first decade, and then there was a feeling that they're too expensive; C++ programmers like the Leopard 64-bit runtime because ObjC exceptions and C++ exceptions are compatible but that's not the case in the NeXT runtime) but obviously a constructor is an atomic operation. You can either initialise an object or you can't; there's no half-object. Therefore if an -init… method catches, the thing to do is unwind the initialisation and return nil. The only thing I can think to say for having exceptions around destruction time is "don't", but maybe a commenter will have better ideas.

Importance of default constructors. All classes implement -init, except those that don't ;-). Usually if there's a parameterised initialiser (-initWithFoo:) then that will be the designated initialiser, and -init will just return [self initWithFoo: someReasonableDefaultValueForFoo];. If there's no reasonable default, then there's no -init. And sometimes you just shouldn't use -init, for instance NSNull or NSWorkspace.

Time at which a destructor or finalizer is called. See How does reference counting work? for a discussion of when objects get dealloced. In the garbage-collected world, an object will be finalized at some time after it is no longer reachable in the object graph. When that is exactly really depends on the implementation of the collector and shouldn't be relied on. Temporal cohesion ("B happens after A, therefore A has been done before B") is usually bad.

Wisdom of overriding the language's built-in operators, including assignment and equality. This is such a brain-damaged idea that the language doesn't even let you do it.

How memory is handled as objects are created and destroyed or as they are declared and go out of scope. How does reference counting work? How do I start using the garbage collector?

WWDC day crosspost

2008-06-17T21:24:00.001+01:00

WWDC summary on SophosLabs blog, written by yours truly. I wonder how many Sophos readers (I should probably avoid the term sophist, shouldn't I?) have an interest in Mac and iPhone stuff (and subequently how many comment via the e-mail address on the Labs blog).

Local KDC on Leopard

2008-06-16T21:28:00.002+01:00

via Nigel Kersten, a great description of the operation of Leopard's built-in local KDC. I think the most exciting thing about the local KDC is the Bonjour support; could we see simple cross-system trust in the near future? Could there be someone in the world who can actually make Kerberos simple?

WWDC day 00000000000000000000000000000101

2008-06-13T20:54:00.005+01:00

Technically day five isn't over yet, but with just one session and a taxi ride remaining I doubt I'm going to get anything prematurely wrong here. In fact, I'm no longer entirely sure that I'll remain awake through the rest of the day so even if something entirely different does happen (still haven't heard anything about IXKit this millennium) I expect I'd miss it.

Planning an east-bound flight is always difficult, because an 11-hour flight through eight time zones "takes" 19 hours. So if I sleep on the plane I'll wake up in the middle of the afternoon UK time, and going back to sleep at newly-local night-time might be complicated. Conversely if I don't sleep on the plane then I won't be going to sleep until at least 9am currently-local time, for a total of about 28 hours uptime. I was just talking to someone who recommended fasting, I'm not sure whether it's worth going through that hardship for an unverified theory (stuff all of that "in the name of science" crap). The other option would be to go into work 3pm-11pm for the beginning of the week, I'm not sure everyone else will appreciate having their meetings moved to the middle of the night and I don't think the canteen's open that late either ;-).

Still, of the three WWDCs I've been to this is definitely in the top ten list of interesting and exciting WWDCs. There definitely still are fellow NeXT fans in the woodwork (actually, *tap* *tap* I think it's gypsum board) who worm their way out during these events, I guess that most have no motivation not to be working on Cocoa. Actually, I don't recall having seen Andrew Stone this week, and I know of a couple of other guys who aren't here, but have definitely managed to gain some traction for the phrase "NeXTSTEP Mobile ;-)

WWDC day four

2008-06-13T06:26:00.002+01:00

Not so many sessions attended today - partly because I've reached the limit of what the human physiology can achieve on a diet of coffee and doughnuts. But also due to ducking out of sessions to meet with ex-NeXT guys, ex-Lighthouse guys and ex-colleagues for most of the afternoon. Of course, this was followed by the beer bash, no longer the campus bash which we all know and fondly remember (or at least we all fondly remember queueing for a couple of hours at each end for the coach) but still a good event. Speaking of ex-Lighthouse guys, Wylie and I spent a bit of time putting Sun's world to rights (essentially, if they were to stop diluting the Java brand, stop pulling themselves in every which way and try to make some money, they might do OK).

So tomorrow is the NeXT meetup at the beginning of lunch, I have a lab appointment at exactly 12 which is a little annoying but I'll try to make it over. If the G4 cube is the right shape, wrong CPU and Real Men's Objects use the NX prefix, then come over to the front of the Moscone West after the second session.

WWDC: afp548 Venn competition

2008-06-12T16:27:00.002+01:00

I, with some help from Ken and the guys, did a better job.

WWDC day three

2008-06-12T16:15:00.000+01:00

Today was not quite a full day, so I managed to spend about an hour or so milling around Yerba Buena park, doing a little gift shopping and generally existing outside of the Mascarpone centre. Also put in another update to the c.l.o-c FAQ (though I didn't update the date! oops…) to better discuss retain/release memory management. There are still situations (GNUstep, Cocotron, and some particular OS X environments) where garbage collection is either unavailable or unsuitable, and it turns out that a lot of questions on either the group or cocoa-dev recently have been about the memory management system.

In the evening, after dinner at Chevy's with the u.c.s.m guys (and yet more discussion of the Sophos feature set), checked in to the Apple Design Awards for the first 30 mins or so. All of the winners (and runners-up) I saw were worthy applications, although it was interesting to note that while most of the "productivity" app winners were from small shops, both of the games (runner-up was Command and Conquer 3, winner was Guitar Hero 3) were from large studios, ports of Windows/console games and in existing long-running series. They're both great games, too, of course. Ian was, of course, rooting for Delicious Library 2, and sadly disappointed ;-).

This was all followed by the AFP548 beer bash over at Thirsty Bear. Yet more "oh, you're from Sophos? Yeah, let me say this one thing…", which I really enjoy because if something's either good or bad enough to be the subject of a beer-fuelled rant in a party, I should probably hear about it. Also submitted a couple of entries to Peter's "Leopard bug Venn diagram" contest; I'm not sure I could do a better job of describing the situation than that but for those who were there, I came up with: \Omega = "Closed/Duplicate" and \Omega = "NeXTSTEP 7.0".

WWDC aside

2008-06-11T21:40:00.001+01:00

None of Perl, Cocoa or some weird XML toolkit came up with the "simple things simple, complex things possible" quote.

WWDC day 2

2008-06-11T06:13:00.002+01:00

Tuesday is typically associated with "starting to learn stuff" at WWDC, and today was definitely spent learning stuff. Learning, for instance, that doughnuts are considered adequate breakfast material, or that if you are prepared to pay the tiny wi-fi fee at Starbucks you can get faster INTARWEBS than all the people on the steps outside the Mascarpone. It was also a day of nice food; I've just got back from dinner with Alex at the Chevy's, having had lunch with Michael at the Ozuma sushi restaurant. More discussing Sophos-for-Mac with customers and potential customers ensued (apparently we've saved some people from the "hell that is Norton", and I point out for legal purposes that that's a direct quote and not my own opinion or words), and I got some pretty good photos of the Bay Bridge and treasure island which I'll upload as soon as I locate the USB cable.

ObjC FAQ update

2008-06-10T15:24:00.002+01:00

Added a question about the ObjC 2.0 garbage collector. Sorry it's been so long in coming! I'll try and add a few more ObjC 2.0 questions over the coming days.

WWDC - day one

2008-06-10T14:49:00.002+01:00

The WWDC keynote is always an odd event to attend. It's put on for the benefit of the investors and the media, with the developers being invited purely to act as braying masses expressing their adulation for His Steveness. It's rare for any technical content to make it into the session, except in unavoidable cases such as the 2005 keynote. The focus of that was the Intel transition, so by necessity there had to be some technical justification of the switch.

With this in mind, it's not hard to see that the keynote can be a somewhat dull affair. Obviously as both an Apple customer and member of the "economic ecosystem" of the Mac, it's always good to be as informed as possible of the company's position and direction. That said, yesterday's keynote (no wi-fi in this hotel, so a late post) contained less of interest to me than usual.

As I mentioned I'm financially dependent on Apple (in an indirect sense of course; I'm paid to write Mac software for Sophos, therefore no Mac = no job at Sophos), though as I'm not an indie dev I have a bit more of a comfort buffer than many people. The enterprise iPhone video Steve showed was basically a backslap in front of the shareholders; look, there are people who really do use this stuff! Then the laundry list of every developer who's downloaded the SDK and managed to get something to compile; interesting to see the wealth of different domains into which the iPhone is entering, but seriously. Two demos, three tops. Not all four thousand of the known apps. Good to see TEH CHEAP being applied to the 3G iPhone, though; I may have to
have a discussion with Orange about a PAC when that's available.

Which left Mobile Me. This is actually a pretty cool reboot of iTools^W.Mac, OK it looks like there might be no more iCards but on the other hand the Mobile Me syncing is really beneficial. I can see that becoming more of a cash cow for Apple, though mainly because they opened it up to the PC; people who have an iPod and Windoze could buy MM to synchronise their contacts, mail and so on, as well as getting webmail access (and webmail access which doesn't suck balls as much as
Exchange's OWA, may I add). That then might make them more amenable to the Halo Effect and the purchase of a Mac down the line.

The rest of the day was interesting but obviously undisclosable, except for the evening I spent in a couple of bars down the financial district (the Golden%Braeburn event at 111 Minna, where I went with Steffi from BNR and a couple of Cocotron committers; then Dave's bar where I met Nigel and most of Apple UK). Conversation ranged from Sophos feature requests to the drinkability of American IPAs; all good stuff!