Neil Mix

Last year’s WWDC was a pretty quiet but busy affair for me — I was learning as much as possible while also heads-down trying to get Pandora for iPhone ready in time for the App Store launch. This year I’m hoping to be a bit more sane, breathing between sessions and socializing here and there. Except for when I’m not busy going to and from Pandora HQ. And visiting coworkers and friends after work. Oh hell, this year’s WWDC is going to be *way* busier for me than last year.

Oh well. If you’re also in town for the event and want to hook up, drop me a line.

Some lackey recently wrote a quick post for Mobile Orchard discussing the combination of retain/release and protocol inheritance in Objective-C. If such things float your boat, check it out.

One of the inventors on SSL was interviewed on CNET recently and threw out this gem of a quote:

We had this fight early on in the Internet days: What do we tell the user to do when there is an expired certificate? Security professionals always struggle with the general public because usability always wins. When you get an expired certificate, the site owner or organization would always prefer to allow the user to do things rather than disallow. This is just an unfortunate fact.

Ok, look, this problem has nothing to do with user interface and what you call “usability.” Security and usability are not mutually opposed as long as the security has a reasonable signal-to-noise ratio.

Consider this: what percentage of web sites with bad certs are in fact malicious? Now, what percentage of sites with good certs turn out to be malicious? As it turns out, the trustworthiness of a site has almost nothing to do with the validity of it’s SSL cert! That’s your usability problem. I want software that tells me something is a security risk, not that it could be a security risk.

Objective-C has a neat little thing called nil, which represents the absence of an object. It’s like null in Java or JavaScript, or NULL in C, but with one important difference: you can call methods on it.

“Bwah?” you say, wondering why that would be a feature rather than a bug. Yes, that was my first reaction too. But after much use, I have decided that it is indeed a feature.

Send a message (i.e. call a method) — any message — to nil, and the response is always 0, i.e. nil. It’s counter-intuitive that nil is a good thing, because it seems like it would be a good way to mask errors.

And it can mask errors, but not usually. More importantly, effective use of nil cleans up tons of code that would otherwise be filled with if (foo == nil) checks.

Consider: object X holds a delegate “foo” which is notified about various events that happen to X. This delegate foo is connected to X by code external to both X and foo.

Now, this foo thingy isn’t really essential to the proper functioning of X. X doesn’t care about foo, foo cares about X. So why in the world should X be responsible for figuring out whether foo has been set or not?

Enter nil. X doesn’t need to know whether it’s delegate foo has been set or not, it just sends messages. If there’s no foo there, the messages disappear into the ether. Meanwhile X’s code is easier to read, because it doesn’t jump through hoops to guarantee that foo present.

I like nil. A lot.

(Update: some commenters have expressed concern about the effect of nil within arithmetic operations. It’s an understandable concern, but not relevant to Objective-C. Nil is an object type, not a primitive type. And as those of you familiar with C and Objective-C already know, primitive types don’t coerce to objects, and there’s no operator overloading. So nil doesn’t ever participate in arithmetic operations.)

Go to download.com and look for software to buy for your computer. What’s the average price point? Probably around $30 to $50 for low-end software. Now go to the iPhone App Store — what’s the average price point there? Much lower, probably less than $10.

Why the difference?

The App Store demonstrates what happens when you simplify technology. Buying software for the desktop is a pain — you have to know which websites to visit, you have to know how to install the software, and you have to know what you’re getting into so you don’t end up with spyware. It’s not simple, it’s a huge time vacuum, and not many people do it.

For the iPhone, software is a consumer good. I mean consumers in the broadest sense — people who buy stuff from grocery stores, who shop at malls, who watch regular TV. You know, people who buy music on iTunes — those consumers.

How did Apple bridge the gap from power user to average consumer? Prominent access point, clean browsing, simplified and uniform installation, integrated billing, and quality control. And clean developer APIs that simplify development. The end-to-end cost of launching apps for iPhone is lower, so the price of apps is lower, and thus the risk of trying out new software is lower. The pool of software buyers expands, the pool of developers expands, and the ecosystem shifts. All this, and there’s not even a try-before-you-buy option.

It all seems obvious in retrospect. The question I ask now is: why doesn’t an “App Store” exist for desktop applications? Someone could make a killing.

Our lates version of Pandora for iPhone is available in the appstore. Progress bar, artist bios, Cover Flow song history, bookmark song samples, genre stations, and a few other nice things. Check it out!

The end of the year brings awards season, and I’ve seen two whoppers come my way already. Earlier this month Apple named Pandora top free app for 2008. And just now Time magazine named Pandora the number one iPhone app for 2008.

Holy cow!

I’ve been silently here lately — building the Pandora iPhone app is a big reason why — but I’m hoping to write more in the coming year about developing Pandora for iPhone.

I was interviewed by the Mobile Orchard folks recently, discussing a range of interesting stuff about developing the Pandora iPhone app. There’s a few good tidbits about iPhone dev and a some other tidbits about UI design/development. Take a listen if you’d like to hear my cheery voice.

My good friend Dan Grigsby has a new blog: Mobile Orchard. It’s all about iPhone development. He’s started up a podcast series kicking things off with Hampton Catlin, creator of the iPedia app. Check it out, it’s good stuff. Dan has a keen eye for what developers like and need. I’m looking forward to seeing what Mobile Orchard holds in store.

When I was at The Ajax Experience this past week, a couple different people asked my opinion on ES-Harmony (and the demise of ES4). And then I remembered that my poor blog has been quite lonely lately.

So here’s my thoughts, pretty straightforward: I’m glad to see everyone moving in the same direction. I think ultimately it was the right decision, but I feel a bit disappointed too. My understanding of what happened is that some of the core foundation of the design — namespacing and program units — proved unworkable under extended scrutiny. And without them it was thought that a clean slate with lessons learned would be best. This was a “good” reason for ES4 to fail, and there’s a subtle point in this: the design process worked as intended! Unlike some have claimed, there was no intent to “rush” ES4 to standardization. Instead, there was steady, iterative work using a reference implementation and real-world implementations to gather experience. And in time it was discovered that certain features came at too great a cost. Better to find that out now than later — which is how it’s supposed to work, isn’t it?

I look forward to what ES-Harmony will bring, and ES-3.1 can’t get here soon enough. (As in, the design for it *should* have already been completed. *cough*) I sense some “hardliner” stances may be unfolding with regard to ES-Harmony, which would certainly prove to be a bad thing. I hope I’m mistaken about this.