inessential by Brent Simmons

December 2008

On the App Store and Free Markets

Some of the response Paul’s and Daniel’s recent writing about the App Store has gone something like this: It’s a free market — deal with it.

Here’s the thing, though: it’s not a free market.

It’s owned and operated by Apple, and there is no alternative. (No alternative without jail-breaking, that is, which only a very small minority of iPhone users will ever do. Or even hear about.)

I’m not saying that Apple owning the market itself is a bad thing. I like having a single App Store: I like that it makes it totally easy for iPhone users to get software, which means it’s more likely they’ll get my software. (My software is free, by the way.)

I’ll be unequivocal: I love the App Store.

But let’s set aside Apple’s ownership — it’s still not a free market. It’s a market that has a certain shape (with hot-lists but no demo versions), and that shape rewards very cheap apps over higher-quality, more expensive apps. It’s a guided market.

There are plenty of exceptions, yes — and it is, as always, up to developers to market their applications.

iPhone apps can compete on price, coolness of screen shots and name and icon, but they can’t compete on quality. They can compete on quality only second-hand — that is, you can hear from other people (via user ratings or other means) but you can’t try an app yourself before buying.

It’s self-evident, I would hope, that a free market in software allows you to try before you buy.

This is how it works pretty much everywhere. This is the overwhelming consensus that software developers, vendors, and users have reached.

Will Apple add the ability to deliver demo versions? I have no idea — but I hope so, because I as an iPhone user would rather shop in a free software market than be guided toward cheaper but (often) less-good apps.

My guess is that Apple would want the same thing, and that this is on their roadmap. I’d also guess that it’s a difficult thing to do.

(For one thing, think about supporting demo versions — it will get difficult when users who have never bought software for their computers before don’t understand the difference between demo and free, and they complain to Apple when an app stops working and starts asking for money.)

Nevertheless, I have no inside knowledge that would lead me to be optimistic — but I am optimistic anyway.

Joe on Snow

Joe Heck on Snow days in Seattle: “Our 50 plows are out doing the main roads, but we just never have quite enough to deal with snow that actually sticks around (normally the temp goes back above freezing and we lose almost all the ice and snow within 24-48 hours). Not sure that’ll happen this time — with more expected snow coming in tomorrow.”

File creation date in Ruby on Macs

I couldn’t find a way to get the creation date of a file, using Ruby on a Mac. For the benefit of anyone searching for this same thing, here’s the solution I’m using. (Seems to work so far.)

Where f is the path to the file:

Time.parse(`mdls -name kMDItemContentCreationDate -raw #{f}`)

Uses the awesome mdls. (Do a man mdls in Terminal to learn more.)

(Note: File.atime, File.ctime, and File.mtime return the last access, change, and modification dates, respectively — but there’s no File method for the creation date. Also note that there may be a better way to do this that I just don’t know about.)

Update 3:39 p.m.: Ben Tucker posted a better version that’s not open to shell injection.

1981

St. Mary's 198101

Space Invaders T-shirt! (Me in 1981, age 13. Already programming Apple computers by that age.)

Binary

Switching to binary for unread counts, so us geeks no longer have to translate from decimal to binary in our heads.

NetNewsWire icon showing 10011 unread

Browser CPU usage

One thing that bugs me — some pages use an abnormal amount of the CPU even when they’re not apparently doing anything.

For instance, open this page on Mashable. (Not to pick on them: I like Mashable a ton and subscribe to their feed.)

Once the Flash thing has loaded, run top or Activity Monitor and watch Safari’s CPU usage. On my laptop, it goes up and down, but it’s around 13%. Even though nothing is going on.

Then close the page — Safari’s CPU usage immediately backs down.

It’s not just Flash causing the problem.

- I disabled plug-ins and reloaded the page, and CPU usage was around 7% in this case.

- Then I disabled JavaScript and reloaded the page. CPU usage went down to around 3%.

- Then I turned off image display and reloaded the page. Ah, now we’re down to 0%.

The thing is, web developers should test their pages for CPU usage the same as app developers do. And anytime a page is idle, CPU usage should be at 0%. Same as with any other app.

2008 pop tunes

I saw the iTunes and Last.fm top 2008 lists on Mashable and took a couple minutes to listen to excerpts.

And I can only conclude that most people are terribly depressed most of the time. The first world is in danger of a mass extinction event. Suicide by songs.

As an antidote to this maudlin syrup, allow me to recommend an oldie: Dreaming by Blondie. You may think you remember the song — but listen again, paying special attention to the drums.

Just a reminder: human achievement is possible; the air around you need not be so bleak.

In other words, listen: buck up, weirdos.

Tip: use Property List Editor to view data structures

Sometimes when I’m working with nested arrays and dictionaries — as a result of parsing some XML, for instance — I don’t even try to keep a map of the structure in my head.

Instead I write the dictionary or array out to a file...

[someObject writeToFile:@"/Users/brent/Desktop/foo.plist" atomically:YES];

...and open it with Property List Editor, so I can actually see the structure. (This also lets me know that the structure I created is the structure I intended.)

Property List Editor screenshot

Bonus tip: valueForKeyPath can be super-handy for getting data out of nested structures.