Category: Mac

I was going to take a shot at ripping apart this Leander Kahney article in Wired magazine on how Apple is the anti-Google and therefore evil, but I figured if I waited long enough that John Gruber at Daring Fireball would do it for me. Gruber didn’t disappoint, noting that “by Kahney’s logic, any company that is different from Google – and clearly most companies are far more different from Google than Apple is – is evil. I can’t tell if Kahney is being willfully obtuse or is simply a shithead.” Heh.

The accompanying list of 5 ways that Apple “breaks the rules” makes me wish that Gruber had gone after it as well. Software should be decoupled from hardware, huh? So it can run on just any phone or computer? We have a name for that kind of application. It’s called a web application. You know, the kind of application that Apple encouraged people to develop for the iPhone, and that all the pundits said wasn’t sufficient. Now Kahney slams Apple for encouraging people to build apps that run on the iPhone natively. What does he really want? Maybe Kahney is really asking for the iPhone OS to run on any old phone hardware platform. I can tell you that I can think of no surer way to ruin the user experience, and the brand, than to cram the iPhone software onto a piece of crap like the Sony Ericsson phone I just got rid of, or even onto my wife’s Blackberry Pearl.

The third point, that every Mac is preloaded with Apple software, makes me laugh. You think PC users like having a bunch of crap applications preloaded on their machines? Windows Media Player, which is preloaded on Windows everywhere but the EU, is an OK media player and it’s the default, unless the OEM changes it. But that has nothing to do with the OEM’s concern for the end user’s experience, and everything to do with the revenue they get from the partner from whom they are bundling the software. To be fair, Apple chooses not to bundle competing products, but they have bundled third party software, notably Quickbooks and trials from the Omni group. On both Windows and the Mac, the user can change the default music player (or any other default program) very easily. Would Kahney prefer that Apple shipped with no default player and made the user download one?

And the whole point about the iTunes/iPod closed loop is such a piece of crap. One word: MP3. Available on every platform. You can rip your CDs to MP3s, using iTunes, and put the MP3s on your iPod. One point in favor of this argument: iTunes for Windows doesn’t support syncing to non-iPod players, but there’s a free plugin to fix that.

The fourth point, love your customers, sounds like a page from the Good Product Manager blog. How to be a bad product manager: give your customers whatever they want and ask for in your product, regardless of the cost of support and regardless of whether the resulting product actually does what your customer wants it to do. How else to explain Kahney’s inexplicably picking on the “no floppy drive in an iMac” decision, which in retrospect was not only one of the smartest things that Apple ever did but also created the market for USB thumb drive storage? And the MacBook Air “no optical drive” situation has been covered over and over again. It’s called making intelligent trade offs. It’s what every product manager does.

I enjoyed the Fake Steve Jobs smack-down on Kahney, and wish that he had gone farther. There’s a lot of good lessons to learn in the article for a product manager with half a brain; you just need to dig in and question every assumption that Kahney makes.

I’ve been fighting it, but now it seems the cold, or rather miscellaneous bug of the week, is upon me. Too bad, too, because it’s a nice day and I can see the future of my iPhone getting much brighter.

There is an article to be written about the effectiveness of Apple’s product management—introducing the iPhone as a purely consumer device, then creating a massive developer ecosystem in a single announcement yesterday—but I kind of like Fake Steve Jobs’s take on the announcements even better.

I came into Gizmodo’s liveblog of the iPhone SDK announcement a little late, but the good stuff has already started, beginning with the announcement of native Exchange support for the iPhone. If I just worked in a Mac world I wouldn’d care so much about this, but with one too many IT administrators who don’t care to open up MAPI on their Exchange servers—plus the need to get access to calendars and address books—I’m thrilled that this is coming.

The internals of the SDK are really interesting, too. Of course the hacker community has known about this stuff for a long time, but seeing the full list of what is supported on the phone—certificates, Bonjour (aka ZeroConf networking), the Keychain, SQLite, the address book, threading support, location management, audio mixing and recording, video playback, 2D Quartz, plus a touch-optimized version of Cocoa.

And the development tools stack looks great too, including a true iPhone Simulator. Question: What about test automation? It’s been a long time since I looked at Xcode; does it include a test automation framework?

And I would never have expected a heavy emphasis on games on the first demo of the SDK, but all of a sudden it makes sense. The iPhone is not just a Windows Mobile killer, it could also be a PSP killer.

Now. What I’m waiting for is guidance for IT administrators so I can go have a conversation with my IT guy. And, of course, for the first iPhone apps to show up.

Update: SalesForce.com client!

An interesting article on using GTD with the iPhone led me to a web based task management service called Remember The Milk. It features a clean iPhone interface, email and Quicksilver integration, location based tasks, and all sorts of other goodness.

Which begs the question, I suppose, of how many features a task management service really needs.

I’ll try to work with it and see how things go.

My current employer is built around a couple of concepts: certain kinds of needs are better served on demand than by buying a tool, and certain kinds of software testing (in our case, application security testing) can be automated. There are other concepts that come into our business model, but those are kind of at the core of what we do.

Like so many other things in the world, our concepts aren’t new (though we do have some unique tricks that make them uniquely valuable). Automated testing, in particular, has a long lineage. I didn’t realize how long, however, until I came across a reference to MonkeyDA on Andy Hertzfeld’s Folklore.org, a collection of stories about the creation of the Macintosh.

MonkeyDA was a Desk Accessory, a tiny program that could be run without forcing another program to quit. (Desk accessories were a response to the lack of multitasking in the early Mac OS, and the many use cases of working with a modern graphical computer that essentially demanded having two programs open at once. They ran on top of the currently running program in a different memory space.) But it was a “special” DA. It simulated user interactions with the Mac, by feeding a random stream of events to the OS resulting in the cursor moving on the screen, text being typed, menu items being selected, etc. It was kind of designed to see if it could break the Mac OS or its applications by subjecting it to all sorts of abuse—just like a monkey banging away at the keyboard and mouse would. If the program crashed, it meant the Monkey had found a condition that a user might eventually find. The Monkey is no substitute for human testing based on test cases, but it’s an important complement.

The punch line, of course, is the size of the Monkey program. Written back in October 1983, its binhex is only 2791 characters long. That’s less than 3K of compressed code. That you could create that much mayhem with that small a program is a reminder that code has power, and that you never know what someone else’s code is going to do.

Nice article by MacOSXHints’s Rob Griffiths on Macworld about how to unlock some of the hidden functionality in the Screen Sharing application in Mac OS X 10.5. I particularly like the Quality slider.

My first-generation MacBook Pro (1.83 GHz Core Duo model) is now running with a maxed-out complement of 2 GB of RAM. It wasn’t easy.

The MacBook shipped with a gig of memory, which I thought would be plenty since my G4 had been reasonbly OK with 1 GB. But I hadn’t reckoned on two things: the enormous hunger of iPhoto, and Leopard. Both combined to make the move to a maximum memory profile (2 GB) seem advisable.

So I ordered a 2 GB upgrade kit (a pair of 1 GB DIMMs) from Other World Computing. I’ve done business with this company since 1995, when I bought my PowerMac 7200/90 and a reconditioned Radius monitor from them. I last bought a memory upgrade from them for my mother-in-law’s iMac, and that process went extremely easily.

Upgrading the memory in the MacBook Pro, on the other hand, gave me heart failure. The process of getting at the memory was easy enough, theoretically: remove the battery, and remove the cover from the battery compartment, then swap the DIMMs. But first, I had to find a P0 Phillips screwdriver—not easy, even with a full toolbench. Then I had to unseat and reseat the new DIMMs about three or four times before the machine would boot.

But, now that it has, it’s slick, slick, slick. The Finder is more responsive; iPhoto feels snappy. Leopard loves some RAM. And at $50 for the upgrade, I wish I had done it about six months sooner.

A few quick impressions of the iPhone over the last few days:

1. I spent most of the first night I had the phone cleaning up the address book. My old Sony Ericsson had made a mess of my addresses because it didn’t support separate first and last name fields, and synced a bunch of duplicate contacts back with a blank first name and the full last name. I was finally able to clean that up on the new phone.
2. Walking the dogs outside our house takes on a whole new aspect with a pocket Web browser. In related news, our WiFi hub is reachable down to the corner and across the street.
3. Interestingly, the iPhone doesn’t sync the playcount of tracks that were played on it back to iTunes. This could be an advantage or disadvantage.
4. The unit gets very warm when it’s doing data operations over the AT&T EDGE network. I used it to delete 30 or 40 email messages yesterday and it was quite warm to the touch.
5. It worked with my Monster iPod car FM transmitter, though it warned me that there might be some noise and offered to switch it into airplane mode. I ignored the warning and heard no noise. It also behaved very nicely when a call came in, fading down the volume in about a second and resuming iPod playback immediately upon hanging up. It would have been cool if the sound came through the car speakers and not the iPhone speaker, though.

And yes, it is a very very cool phone.

Interesting report (via Fake Steve Jobs, of course) that the iPhone has a higher market share (as measured through browser usage) than Windows Mobile. Of course there are lots of caveats with such a study, such as whether browser usage is the right metric to measure smartphone penetration (hint: how often do you browse the web on your phone?). But it’s still broadly suggestive of one thing: Apple got the mobile browser experience right.

And starting tonight, I will be doing my part to grow that market share. I picked up my iPhone this morning and will be activating it tonight (when I get to my home computer). It’s very cool, even turned off .

Apparently, as of Mac OS X 10.5, Apple’s Mail client provides a new URL protocol: message:. Good article at Daring Fireball that explains the message: protocol and how to get the information from it. What use is it? Well, any third party app that wants to index and point into the mail store can simply use a URL, which really opens up the types of development environments you can write those things in and the portability of the data.

Bottom line: the format is message:%3cmessage-id%3e, where %3c and %3e are the encoded values of < and > respectively, and the message-id is gotten from the Message-ID header and can be viewed by dragging the mail message to TextPad or another drag-compatible client, or by using AppleScript.

Cool stuff.

Via Daring Fireball, an easy solution to the stack icon problem. What stack icon problem? The one where the stack, when collapsed into the dock, takes on the icon of the first item in the folder so you have no stable reference point for what it actually is—that stack icon problem.

Looks nice in my Dock:

Forget the hack that I posted earlier. A quick review of various threads about Tiger on the 800MHz iMac seems to indicate that the video card in that model has problems keeping up with demand, and that iChat in particular may have some real problems in the upgraded system. Since iChat is the main reason that my inlaws use their Mac (along with Mail), I think we’ll hold off.

Details: MacOSXHints on experiences with hacked Tiger installs; sleep problems; sleep problems 2.

On the way down to Jim Heaney’s wedding, we stopped overnight at my inlaws’ place in Lakewood, NJ. They own one of the four Macs in the family, an 800 MHz G4 iMac (one of the Luxo Jr models). I had bought Leopard as a family pack with the intention of upgrading everyone, but I hit a surprising snag: Apple’s Leopard Installer actually enforces the 867 MHz minimum clock speed cited on the box specs! So for lack of 67 MHz, the disk won’t install.

Fortunately, there are a few workarounds. One is, if you happen to have another Mac handy, to boot the iMac in target disk mode and install the OS that way. The problem is that I don’t have my MacBook Pro with me, and I’m not sure if the iMac even supports booting into target disk mode.

The second, which I’m doing now, is to make a patched copy of the install DVD that disables the speed check. The linked article helpfully explains how to do the patch (and provides an example file) and even provides screenshots to show the process. I am currently making a read-write disk image from the install DVD and once I get a double-layer DVD to burn it to we’ll be able to move forward.

What are the risks? Well, I think the biggest risk is that some of the new Core Animation features will tax the processor and slow things down. So we’ll have to watch that. But being able to remote into my inlaws’ computer and help them will be worth it, as will the putatively improved iChat experience. And a quick check of comments of people who have done this hack suggests that any degradation of performance on an 800 MHz machine will be minimal, so in this case I think the risks are outweighed by the rewards.

Wired: First Look: Delicious Library 2.0 Burns With Animated Cool. Looks like the 2.0 version (currently under development) of Delicious Library should address a lot of my criticisms of the program, as well as a lot of Core Animation goodness. Favorite features: publishing to templates, iTunes integration, export formats, library sharing, and smart bookshelves.

For comparison, here’s my Delicious Library feature request list from 2004. So far, it looks like they’re addressing #s 1, 2, and 5. I’d still like to see #6.

I have been running Leopard for about two hours now, having picked up the Family Pack this afternoon and backed up the MacBook Pro (first full backup since I bought the thing, frighteningly enough). Notes so far: seems snappier. I thought I’d hate the changed handling of folders in the dock (stacks?) but I actually really dig it. If you only have one mouse button and don’t want to do the two-handed right click, it’s a much easier way to work with the contents of folders in the dock, and a much better application of Fitts’ Law.

I ran into a minor Keychain issue that seems to be responsible for this update after the installation, but that’s the only glitch so far.

I did notice one interesting thing. Software updates, even those that required restarts, used to download and install before signalling for a restart. Now the restart signal occurs and the installs happen after the user desktop disappears. Cuts into the user’s productive time, but perhaps safer and easier for the update installer to handle…

(Title reference here… only much less violent.)