At first glance, Apple seems to have set an impressive record compared to previous years:

• 2008 – 2 months
• 2009 – 1 month
• 2010 – 8 days
• 2011 – 10 hours
• 2012 – 2 hours
• 2013 – 2 minutes

What's different this year, however, is that availability was announced 24 hours in advance. Everybody knew exactly when to be at their computers with their fingers poised over their keyboards. The moment tickets went on sale, many thousands of people around the world hit Apple's web site at the same time — many more than the number of available tickets.

This means the two-minute sellout time tells us nothing about customer interest or demand. It only tells us how fast Apple's servers were at taking orders. And even that's not quite true; it's not clear how many, but Apple had to call some people on the phone to complete orders that the servers had messed up. You could argue that WWDC didn't really sell out until every one of those people got their ticket — and again, that revised time interval wouldn't reflect on the level of demand, only on the efficiency of the order-taking mechanism.

How fast would WWDC have sold out if the servers had worked flawlessly? Not only don't we know; we shouldn't care. We're beyond bragging rights about who can put up the "sold out" sign faster, or whether we were faster this year than last. Everybody knows that WWDC, like Google I/O, has way more demand than supply, and it doesn't seem that'll change soon.

There have been suggestions to prioritize customers by some measure of merit, like old-timers first or newcomers first, but I don't agree. Or rather, I mostly don't. John Siracusa writes about a time when rushing to buy a ticket actually made a difference:

I wanted to preserve at least some aspect of the process that rewarded the most enthusiastic Apple fans: the people who are willing to be roused from bed at 2 a.m. and rush to their computers to buy tickets; the crazy ones; the people who just want it more.

I too would love to see this aspect preserved; I am, after all, one of the crazy ones. But Siracusa goes on to say that we're beyond that now, and I agree with that.

Things being as they are, I think every interested customer should get an equal chance at a ticket. I agree with Siracusa that a lottery, which would slow down the ticket-buying process, is the best way to accomplish this. What Apple should focus on is not speed, but selling its limited number of tickets in an orderly, reliable way with a minimum of stress for its customers.

As a basic sign of respect for Lu Lingzi, the BU student killed in last week's bombing, can the NPR folks at least take five seconds to learn how to pronounce her name correctly?

I've wished before for a class that would teach how to pronounce various languages. The idea is similar to those crash courses for tourists visiting foreign countries, but the focus would be on pronunciation, with vocabulary only as a happy side effect.

It could be done a lot of ways. It could be taught in grade school; it could be an adult education thing; it could be an app or family of apps; it could be a blog or tweet stream or a daily column in the newspaper or a YouTube channel.

It might help to have multiple teachers who specialize in different languages. Teaching could focus on just Romanized forms or, for the ambitious, it could include how to read non-Roman alphabets like Cyrillic and Korean.

I would benefit from such a class. At Thai and Vietnamese restaurants I'm sometimes uncomfortable ordering things from the menu that I'm not sure how to pronounce. One of these days I should put in the effort to learn.

Mandarin romanizes in a pretty straightforward way that I'm sure most people could learn, especially if we set aside the tones. It would help if reporters would pronounce things right, which they could do on a case-by-case basis with just a minute of coaching. For starters, they could pronounce "Beijing" with the "j" in "jingle bells" rather than the "zh" in "Doctor Zhivago".

Come to think of it, I'm not positive I pronounce "Zhivago" correctly.

I would love to see a switch statement we could use for objects, testing equality with each case: statement. @switch would work nicely as the name, and I envision it working like this:

@switch(myString) { case @"hello world": // Do something break; case @"another one": break; }

This would be equivalent to writing the code using if statements and sending -isEqual: messages, but with a much more readable control flow.

The blocks approach

One suggested approach was to use a dictionary to map each "case" value to a block that should be executed when the "case" value matches the "switch" value. Jeff Biggus posted this solution mainly as an academic exercise, but I think it's about as tidy as the blocks-based approach gets:

typedef void (^voidBlock)(void);
 
#define swoosh( test_var__, action_dictionary__... ) \
        ((voidBlock)action_dictionary__[test_var__])();
 
[...]
 
NSString *test = @"that";
swoosh( test, @{
        @"this" : ^{ NSLog( @"found this" ); },
        @"that" : ^{ NSLog( @"found that" ); },
});

Nicolas Bouilleaud posted an alternative solution using +resolveInstanceMethod: that allows you to write:

[[@"foo" switch]
 case:@"bar" :^{ success = NO; }
 case:@"baz" :^{ success = NO; }
 case:@"foo" :^{ success = YES; }
 ];

I'm not crazy about using blocks for a few reasons:

• You have to think about whether you need to use __block variables.
• You can't put break, continue, or return statements in the blocks and have them work as they would in an analogous switch statement; often their very presence would be a syntax error.
• If you use a dictionary of blocks, the "case" objects have to conform to NSCopying so that they can be dictionary keys. Also, as Nicolas points out, if you use a dictionary, you can't specify the order in which the cases are tested. So, no dictionaries; but you can imagine a similar approach using an array.
• Xcode's auto-indenting of blocks looks really, really horrible. In theory, the typographical quirks of an IDE have nothing to do with the soundness of a technical approach, but Xcode is so bad about this that I can't ignore it. For example, if I put the first NSLog above on its own line, Xcode does this:

swoosh( test, @{
       @"this" : ^{
    NSLog( @"found this" );
},
       @"that" : ^{ NSLog( @"found that" ); },
       });

objswitch, objcase, endswitch

I don't know how original this is, but by using a few macros and a small class used behind the scenes, I came up with a different approach that is essentially syntactic sugar around nested else-if statements. Here's an example of how it looks, as formatted by Xcode:

objswitch(someObject)
objcase(@"one")
{
    // Nesting works.
    objswitch(@"b")
    objcase(@"a") printf("one/a");
    objcase(@"b") printf("one/b");
    endswitch
 
    // Any code can go here, including break/continue/return.
    // Xcode will indent it nicely.
}
objcase(@"two") printf("It's TWO.");  // Can omit braces.
objcase(@"three",  // Can have multiple values in one case.
        @"tres",
        @"trois") { printf("It's a THREE."); }
defaultcase printf("None of the above.");  // Default case is optional.
endswitch

I would argue this is even a tiny bit nicer than switch/case syntax, because you don't need unsightly break statements to keep the cases from bleeding into each other.

If someObject is @"one", the output is

oneb

If someObject is @"tres", the output is

It's a THREE.

In this example all the "case" values are strings, but they can be any object.

The "keywords" objswitch, objcase, objkind, and endswitch are actually macros. There is a simple class called ObjectMatcher that is instantiated by objswitch. You can see the code on GitHub.

objkind

Some people mentioned wanting similar syntax for testing the class of the object rather than its value. Testing an object's class is often a sign of suboptimal design (see here for a brief discussion, here for my thoughts on the matter), but for those occasions when you decide it's the right approach, you can use my objkind macro:

objswitch(someObject)
objkind(NSNumber) { printf("It's a NUMBER."); }
objkind(NSString) { printf("It's a STRING."); }
objkind([NSArray class],
        [NSDictionary class],
        [NSSet class]) printf("It's a collection.");
endswitch

Note that if you're only passing one class name to objkind, you can just give the class name:

objkind(NSNumber)

But if you pass multiple classes, you have to say [MyClass class] or [MyClass self] (or, if you prefer, MyClass.class or MyClass.self) for every item after the first one. This is a limitation of __VA_ARGS__ macros. I prefer all the items to look the same — hence:

objkind([NSArray class],
        [NSDictionary class],
        [NSSet class])

Like objcase, objkind is just a wrapper around a nested else-if statement, so you can freely mix objcase and objkind within the same objswitch.

selswitch, selcase

One place I might like a similar construct is for doing a switch statement on a selector. I have validateUserInterfaceItem: methods all over the place with lots of nested if-statements like this:

SEL itemAction = [anItem action];
 
if (itemAction == @selector(selectSuperclass:))
{
    // ...
}
else if (itemAction == @selector(selectAncestorClass:))
{
    // ...
}
else if ((itemAction == @selector(selectFormalProtocolsTopic:))
         || (itemAction == @selector(selectInformalProtocolsTopic:))
         || (itemAction == @selector(selectFunctionsTopic:)))
{
    // ...
}

I created selswitch and selcase macros that let you do this:

selswitch([anItem action])
selcase(@selector(selectSuperclass:))
{
    // ...
}
selcase(@selector(selectAncestorClass:))
{
    // ...
}
selcase(@selector(selectFormalProtocolsTopic:),
        @selector(selectInformalProtocolsTopic:),
        @selector(selectFunctionsTopic:))
{
    // ...
}
endswitch

I haven't decided whether the improvement is big enough that I'd use this rather than plain old nested ifs, especially since validateUserInterfaceItem: is called very frequently and should be as fast as possible.

[UPDATE: I've made several edits since I first published this post, ranging from fixing typos to inserting a sentence or two. I was originally flagging each change, but to reduce clutter I decided just to add this mention at the bottom.]

The first way: a regular .app

Your Cocoa application can provide services that appear in the Services menu. Apple's "Services Implementation Guide" explains how to do this. Basically:

• Create a class (or use an existing class) with one method for each service. Each service receives input and optionally returns output by way of NSPasteboard.
• Add an "NSServices" key to Info.plist with info about each service.
• At some point during application startup, call NSRegisterServicesProvider().

Put the application in /Applications, or a subfolder thereof, to get the system to detect the new service(s).

When an application service is invoked, the application becomes active. There seems to be no way to avoid this. At best you can immediately hide the application, but there will still be a flicker as windows appear and disappear.

UPDATE: Mark Munz offered this tip on the cocoa-dev mailing list:

[T]he solution I used to prevent Services from bringing the app forward is to have a background (LSUIElement) helper app that acts as the NSServices provider. Depending on what you need to do, you could either support the service directly in the helper app or use it to talk to the parent app to perform the necessary work (without requiring it to activate). I use the second approach.

The second way: a .service bundle

If you want a service that is purely a background operation, you can create a standalone service that has no UI. It's very simple once you know how, but I haven't found a lot of help online, although some books discuss it and you can find examples on GitHub by searching for NSRegisterServicesProvider.

I expected a "System Service" template in Xcode, but there is none. Instead, you use a "Cocoa Application" project and code it just like a regular application with services except:

• Change the target's wrapper extension from "app" to "service": Project > Target > Build Settings > Wrapper Extension.
• Make it a background application by adding to Info.plist: LSUIElement = YES. (This is the "Application is background only" item in the popup menu that appears in Xcode's plist editor.)
• Remove resources you won't need, like MainMenu.xib, AppDelegate, and Credits.rtf.
• Edit main.m to instantiate the service-provider object and enter a run loop. Here's an example.

Build the project and copy YourService.service to ~/Library/Services. You may have to relaunch apps to get them to see the service.

Tips

• Instead of editing Info.plist to add the NSServices entries, you might prefer to use Xcode's UI. I don't know when this was added to Xcode, but you can go to Project > Target > Info and there's a "Services" area at the bottom. It's easy to miss if you don't know it's there.

• To uninstall the service, remove YourService.service from ~/Library/Services. You won't be able to delete it if the service has a running process, so you might have to kill the process first.

• If the service doesn't appear in the Services menu, you may have to force the menu to be reconstructed. Unfortunately there's no command you can call from the command line. It's trival to write one though — all it has to do is call NSUpdateDynamicServices().

See also

As I mentioned, Apple's "Services Implementation Guide" has plenty of detail on writing application services, but as far as I can tell the only help it gives on standalone services is this one line:

> To build a standalone service, use the extension .service and store it in Library/Services.

The breakthrough that got me going was when I found example code on the Timac blog. I already had implemented a service in an application. By looking at Timac's code and doing monkey-see-monkey-do, I got my first standalone service working.

I then realized I could find plenty more examples by searching GitHub for "NSRegisterServicesProvider".

Here's the service I wrote. It copies method names to the clipboard so you can paste them in emails, code comments, docs, and so forth.

I am wondering, what is the difference between testing if an instance responds to a method, and checking the kind of class it is?

I mean, I understand that if you had 10 classes that all have a method, and one that doesn't, it's easier to just do [myClass respondsToSelector:@selector(foo)], rather than doing [myClass isKindOfClass:[Thing1ThatHasMethod class]] || [myClass isKindOfClass:[Thing2ThatHasMethod class]] || …etc

But, I have a situation where an NSDictionary is holding an object that is either an NSNumber or an NSArray of NSNumbers.. And I wondered which of these is the best way to go?

if ([item isKindOfClass:[NSArray class]])

vs.

if ([item respondsToSelector@selector(objectAtIndex:)])

?

Here's my personal roundup of how I use the approaches that were discussed in response to Patrick's question.

isKindOfClass:

I would use isKindOfClass: for the situation Patrick (the OP) described. You already have specific expectations that the dictionary entry will be either a number or an array (assuming your data isn't corrupted). You want to know which it is, so you ask it. To me, this maps most closely to my mental model of the situation.

One scenario where I've used isKindOfClass: is when getting values from NSUserDefaults. I may have changed the app from allowing just one value for a user preference to multiple values, so I could reasonably expect to get either an NSNumber or an NSArray.

respondsToSelector:

I typically use respondsToSelector: in these scenarios:

1. I'm deciding whether to send a particular delegate message to my delegate, and there's no hint in the declaration of the delegate that lets me assume it implements the method. For example, the delegate might be declared as a plain id, so I have no idea at all what it implements. Or it might be declared as conforming to a delegate protocol, but that particular method might be @optional. Note that I'm in this scenario when I'm creating the class that does the delegating — that's the class that has to decide whether to send the message.

2. Occasionally in an action method I'll sanity-check the "sender" argument. I may be expecting the sender to respond to -representedObject (and not caring whether it's because it's an NSMenuItem or an NSButtonCell or whatever), so I check for that.

3. Occasionally I do something similar to the responder chain where I look for an object on some chain that responds to the message, and if I find one, I send the message.

In all these scenarios the question is "I have this message I might want to send, and I want to know whether and to what object I should send it."

conformsToProtocol:

I don't think I've ever used conformsToProtocol:. I don't have a cogent explanation for why not. It's just never seemed to be the real question I wanted to ask.

Category methods

By adding category methods, you can let the inheritance mechanism do the "if this kind of object, then do that", which is after all what it's designed for. Ondra Čada gave an example:

@interface NSObject (MySum)
-(int)mySum;
@end
...
@implementation NSNumber (MySum)
-(int)mySum { return self.intValue; }
@end
@implementation NSObject (MySum)
-(int)mySum { int s=0; for (id o in self.objectEnumerator) s+=[o mySum]; return s; }
@end

Mike Ash gave a variation which is the logical equivalent of isKindOfClass: in this special case:

@interface NSObject (FooChecking)
- (BOOL)ma_isFoo; // prefixed to avoid conflict
@end
 
@implementation NSObject (FooChecking)
- (BOOL)ma_isFoo { return NO; }
@end
@implementation Foo (FooChecking)
- (BOOL)ma_isFoo { return YES; }
@end

Smalltalk takes a similar approach with methods like isNumber and isSymbol, which every Smalltalk object responds to.

I like the category approach and have used it on occasion, especially where (a) I'm doing the check in a lot of places, and/or (b) I feel it expresses my question better. I am lazy enough that I'll just do an isKindOfClass: if it's only in one place.

Even with the isFoo approach you'll probably be casting to Foo* at some point, so you're still "cheating" in that you're using knowledge of an object's specific class.

Here's the text of the poem:

石室诗士施氏，嗜食狮，誓食十狮。适施氏时时适市视狮。十时，适十狮适市。是时，适施氏适市。氏视是十狮，恃矢势，使是十狮逝世。氏拾是十狮尸，适石室。石室湿，氏使侍拭石室。石室拭，氏始试食是十狮尸。食时，始识是十狮尸，实十石狮尸。试释是事。

I selected this text and told my Mac to "Start Speaking". For some reason in my System Preferences I had the "Kyoko" voice selected at the slowest speed, so it came out sounding like a drunk Japanese woman.

I changed to the "Ting-Ting" voice at normal speed and heard it in mainland Chinese as intended. Fun!

In Cantonese (the "Sin-Ji" voice) the words are not only different from Mandarin but much more different from each other than in Mandarin. In Cantonese most of the syllables are "see", a few are "sik", quite a few are different altogether. This did not surprise me.

What did surprise me was how it came out in the Taiwanese voice ("Ya-Ling"). I had thought mainland and Taiwanese Mandarin were pronounced the same word for word, with the only difference being a matter of accent, the way Minnesotans pronounce harder R's than Californians. But it turns out there are some words that are pronounced completely differently.

Wang gives a translation of the poem in his blog post. Rather than copy it here, I suggest you visit his blog at the link I gave. I like what Google Translate returns, especially the phrase "relies on the vector potential":

The sarcophagus poetry Guests Amur, addicted to food lion, oath eat ten lions. Suitable Amur always suitable for the city, as the lion.Ten o'clock, fitness, fitness ten lions. Yes, the appropriate Amur appropriate city. 's Depending on those ten lions, relies on the vector potential, so that the death of ten lions. S pick the ten lions corpse, fitness sarcophagus. Shishi wet, that's so paternity swab sarcophagus. The sarcophagus the swab,'s start tasting is ten lions corpse. Food before consensus is ten lions corpse, the real ten lions corpse. Interpreting things.

I used the Mac's "say -o" command to generate the above audio files. The output was in AIFF format, which I converted to MP3 using an app called "Music Converter".

UPDATE 1: Edited to mention Jian Shuo Wang by name, and to mention that he offers his own translation of the poem.

UPDATE 2: It occurred to me that a person claiming to be a native Mandarin speaker could be tested by being made to read this poem aloud. In theory a real native speaker would have less trouble getting the tones right than a faker, making this poem — dare I say — a sort of "shi-bboleth".

[1] Actually Byron linked to an article on Shanghaiist.com, but I'm linking here to the original article which it links to.

[2] Note that "shi" is not pronounced "shee" as you might think. It's more like the English word "shirr". It amuses me that the word "是" by itself, which means "Yes" or "Okay," sounds like "Sure." It's an affirmative answer in two languages.

The text fragment used by the Cantonese Sin-Ji voice still contains the name "Sin-Ji" in Romanized form, but somehow when it's pronounced it sounds more like Cantonese than before.

Here's the text fragment that gets spoken:

$ plutil -convert xml1 /System/Library/Speech/Voices/Sin-Ji.SpeechVoice/Contents/Info.plist  -o - | grep -A 1 VoiceDemoText
 
<key>VoiceDemoText</key>
<string>您好，我叫 Sin-Ji。我講廣東話。</string>

Here's how it used to sound:

Here's how it now sounds:

I wonder how it does that — how the text-to-speech engine can possibly know the right tones to use for "Sin-Ji", or even that it's a Chinese name. Regardless, I wish they'd use the Chinese characters for the name because I'd like to know what they are.

The text fragment used by the Taiwanese Ya-Ling voice does what I want. It has replaced the Romanized "Ya-Ling" with Chinese characters.

Here's the new text fragment ("Ya-Ling" has been replaced with "雅玲"):

$ plutil -convert xml1 /System/Library/Speech/Voices/Ya-Ling.SpeechVoice/Contents/Info.plist  -o - | grep -A 1 VoiceDemoText
 
<key>VoiceDemoText</key>
<string>您好，我叫 雅玲。我說國語。</string>

Here's how it used to sound — pretty disastrous:

Here's how it now sounds — note how different the "Ya-Ling" is:

You can hear these voices yourself by going to System Preferences > Dictation & Speech > Text to Speech. If you don't already have the voices for these languages installed, it'll take a while to download them.

I'm on 10.8.2. I don't know when Apple made these changes.

Here are two huge snakes they had:

[Credit: kittyfisher on Flickr]

[Credit: dotpolka on Flickr]

Coiled up like this, they were each about the size of an automobile tire.

There are more great photos on the store's web site and Facebook page.

There was something intimate about viewing these creatures this way that I liked better in some ways than any zoo or aquarium.

Thanks to Google Maps, you can look around inside the store without being there.

View Larger Map

It looks like the brokers who do this often deal in fairly pricey apartments, so it seems silly, not to mention spammish, to try to grab the attention of people seeking cheap rents.

This morning I realized it's easy to avoid those listings: just set the minimum rent to $2 instead of leaving it blank. Sure, it's obvious now, but this wouldn't be the first time I was slow on the uptake.

Speaking of slow uptakes: when I first started searching for apartments on Craigslist, it took me a while to figure out why there is a minimum-rent field at all. Who wouldn't want to pay as little as possible?

One reason is that you might figure you get what you pay for, and you don't want your search results cluttered with the cheap stuff.

Another reason is so that you can omit listings you've already looked at. For example, if you don't like any of the apartments under $1000 and might consider bumping your budget up to $1100, you'd search on the range $1000-$1100, because you don't need to see the under-$1000 listings again. (I picked $1000 because it's a nice round number, not because it'd get more than a broom closet in NYC.)

And now I see a third reason: to avoid seeing the bogus $1 listings.

One complaint I've seen a few times goes something like: "I'm tired of people posting about their kids." I can see how people might feel that way, but I happen to feel the opposite, at least on Facebook. I love my friends' kid photos and kid stories. Many times I've chuckled out loud as if the kids were my own nieces and nephews.

Maybe I'm just lucky to have friends who have great kids and also post plenty of non-kid stuff that I also like, so I never feel overwhelmed with updates on Little Johnny or Little Janey.