Fraser Speirs Cocoa and Photos

Media Strategies for a MacBook Air

I recently had some correspondence with Blake Burris, who is himself considering the MacBook Air. Blake was asking about how I’m managing my iTunes and photo libraries on the Air’s limited disk space.

Here’s the substance of what I said, in the hope that it will be useful to others:

I’m a two-machine guy now. I have been for a while, but I’ve always looked on each machine as being equal, but for different purposes. With the Air, I’m moving more towards the Mac Pro being home base, and the Air being something I take with me but don’t depend on. In that sense it’s more like the iPhone: a portable copy of the data, with everything synced up back home.

My photo libraries haven’t fitted on a laptop drive for some time, so that hasn’t been a particular issue. All I use my laptop for is downloading photos into Aperture whilst travelling, which then get moved back to the Mac Pro when I get home. I don’t keep photos on the laptop at all: if I want to show pictures, I’ll pull up a Flickr slideshow.

I have always managed my iTunes on the laptop, though, and my home base/portable version model is slightly different here. I look at iTunes as a mixture of static and dynamic media. All the stuff you paid for (music, movies, TV) is static content that you, in principle, want to keep forever. Podcasts are dynamic content which likely get deleted after one or two listens and which you can always get back for free.

I use my iPhone primarily for video and podcasts and don’t keep music on it at all. I have all my static media on the Mac Pro and the Air’s iTunes library is purely for downloading Podcasts and syncing to the iPhone. I did this because I figured that I wouldn’t want to be away for a couple of days and not be able to move new podcasts to the iPhone. I can wait for the other stuff, although I could equally move a video onto the iPhone from the MacBook Air if I needed to whilst away from home.

To get video onto the iPhone, I connect it to the Mac Pro. The iPhone is set to “manually manage music and videos”, and I can then just drag over what I want. It is slightly annoying to give up the auto-syncing of the ‘newest unwatched’ TV shows, but it’s not a major pain.

If I do want to take my entire library with me, I use my old 80GB 5G iPod. The beauty of this is that you can play music and movies off an iPod on the MacBook Air screen, although I think I have noticed that doing so does not update the “New/Not New” status of TV shows in the iPhone’s internal database. If I ever need to get an audio file off the iPod, well, PodWorks is never far away.

John Redwood MP: Parliament Finally Detaches From Reality

The economics get more depressing every day. The government handling, even more so. As John Redwood MP comments:

Large sums of money were made available to the banks to ease them through the persistent credit crunch and liquidity crisis. The US were tidying up the loose ends of the rescue of America’s fifth largest investment bank. The dollar and the pound were in freefall, bank shares crashed, and the Chinese market fell as the authorities there threatened higher interest rates to combat inflation.

Inside Parliament the government had decided the whole day could be given over to debating climate change again.

MacBook Air Out of the Box

My wife told me that a “small package” was waiting for me at home. That could mean only one thing: the MacBook Air that I ordered on February 28th. I’ve purchased Revision-A Apple products before, but I’ve never, ever had to wait so long to receive one as I’ve waited for this machine.

I got home to find a small, squarish box which was clearly not big enough to contain a laptop of any size. The attached packing slip detailed five items, one of which was the Air, but only four items were in the box. The TNT driver had loaded two boxes at the depot and only delivered one, but the one he kept was the laptop itself! I was about to be really disappointed when my neighbour came over with a box that looked about the right size. Fortunately, the driver had realised his mistake and backtracked to drop off the second box after Carolyn had left. Relief!

My Order

So, what did I get? One custom configured MacBook Air: 1.8GHz with an 80GB hard drive. I also ordered the Ethernet adapter, since I use ethernet a fair bit at work, a second power brick and AppleCare.

Out of the Box

There’s no denying that Apple made the MacBook Air box a lovely thing to open. It’s more like the iPhone box than any previous Mac laptop box. As factory-installed, the Air’s 80GB drive had 17.5GB of material on it, including a full iLife install. For me, that was a bit more than I wanted to devote to the system, so I decided to try a Remote Disc reinstall.

Remote Disc Installation

I thought it was important to try this new technique at least once before actual data was at stake, so I decided to reinstall the Air over USB Ethernet from my Mac Pro. I had been led to expect disastrously long installation times for this, but I was pleasantly surprised. Here’s the timing:

• 1830: Power on
• 1831 (+0h1m): Finds Mac Pro remote install disc
• 1834 (+0h4m): Installer booted
• 1843: Clicked ‘Install’ on a nothing-but-required-printer-drivers (HP) installation.
• 1902 (+0h32m): Green Tick shows up in Installer.

This was with a direct cable connection over the USB Ethernet adapter into a Mac Pro. I’m sure it would be significantly slower over wireless, particularly since I don’t have an 802.11n network.Post-installation, I’ve used 9.39GB of the 80GB disk, a saving of nearly 10GB or exactly 10% of the nominal disk capacity.

App Installation over Wireless

The Air installer discs shipped with 10.5.1, so I had some updating to do. Once that was over, the next step was to install the three packages I can’t download: iLife (just iPhoto), Remote Desktop and Office 2008. The process of using Remote Disc was flawless, once I figured out that I had to enable the “DVD or CD Sharing” service in Sharing preferences on the Mac Pro. I had sort of assumed that would be permanently enabled, having just done a remote OS installation.

Here are some timings over my bog-standard Netgear 802.11b/g wireless:

• iLife (iPhoto only, ~500MB): 5 minutes from ‘Install’ button to green tick.
• Remote Desktop 3 (70MB): 1 minute.
• Aperture 2 (220MB): 3 minutes.
• iWork (full install, ~750MB): 7 minutes whilst also running the big software update in the background.
• Office 2008 (Word, Excel, English proofing tools, Office fonts: 815MB): 6 minutes.

So now, with my core apps loaded but no data, I’m using 12.7GB of disk. I skipped Photoshop CS3 for now, but might add it later if I find I miss it.

It’s also worth noting that, whilst configuring the install, the performance of Installer.app is indistinguishable from a local disc except for a slight UI pause when loading what I guess are the preflight scripts from the package. Cutely, if you press the Eject key on the MacBook Air, it unmounts the Remote Disc.

As far as I can see, Remote Disc is a perfectly adequate technology for the purpose of installing software. It is barely distinguishable from a built-in laptop DVD drive. Partly, I suspect, that’s due to the Mac Pro’s faster optical drive. I find it difficult to believe that many Air purchasers are going to have a need to reinstall such large packages so often that Remote Disc will be an intolerable solution for them. I can’t see a USB Superdrive in my immediate future, despite its pleasing aesthetics. I can, however, see myself getting a spare USB Ethernet adapter for my bag.

Hardware Impressions

It’s light. Really light. But then that’s the part you probably knew already. People have also mentioned the rigidity of the case. I totally agree: it feels more like an iPhone or iPod than a MacBook Pro.

The first two times I tried to boot the MacBook Air, I thought it was dead because it made none of the whizzing-clunking sounds that the MacBook Pro DVD drives make on startup, and the hard drive is silent.

The trackpad is extremely large indeed - far larger than that on the outgoing 17″ MacBook Pro - but the trackpad button is very skinny and isn’t clicky enough for my taste.

I have not been the greatest fan of glossy displays in the past, but the MacBook Air’s screen seems to be a significant improvement on that fitted to early generations of the MacBook. Those first glossy screens had a terribly narrow angle of view in which the colour remained consistent. Slight movements of your head would produce wild and dramatic colour shifts, to the point where it was almost useless for any application that required even mild correctness about colour and shade.

Let’s hear it for LED backlighting. I was initially sceptical about exactly how much better LEDs were for backlights, but I’m a total convert. It’s brighter and whiter than the MacBook Pro’s fluorescent backlight, and it also seems to have a greater range of adjustments. The darkest setting is darker than the Pro’s and the brightest setting is much, much brighter.

Having just hammered the hard drive continuously for two and a half hours, the fans are blowing pretty hard right now. The machine is warm underneath at the back-left corner where the hard drive lives, but the top case is evenly cool to the touch all around. Much cooler than the hard drive area on my MacBook Pro, on which I’ve done nothing but type this post. In the time it took me to write this paragraph, the fans have faded almost to idle.

Multi-Touch and Aperture

The multi-touch trackpad is nice, but I’ll need to try and remember it’s there. I haven’t seen many people comment on this, so I’ll note that pinch-to-zoom and the “wiki wiki wiki like your favourite DJ” gestures do work in Aperture, thusly:

• Pinch: works in the browser to scale the thumbnails up and down. Does not work in the viewer or in fullscreen to switch between fit-to-screen and 100%, sadly.
• Three-finger-swipe: works everywhere the left/right arrows work to move forward and backward through photos.
• Two-finger-rotate: doesn’t work anywhere. It would be lovely, though, if it could be used to control the Straighten adjustment!

So that’s the story of setting up the MacBook Air. Another very, very well-done experience from Apple. Anything else you want to know?

[Update: The Late-Breaking News About Aperture 2 document details all the multi-touch gestures you can use with Aperture 2.  Also, it turns out that you actually can use the rotate gesture for the Straighten adjustment - you just have to add it to the set of adjustments first. Sweet!] 

Aperture 2 In Use

Duncan Davidson posted his impressions of using Aperture 2 in serious production work. I also recently just completed my first shoot since Aperture 2 was released. I’ve been so crazy-busy on FlickrExport 3 and iPhone stuff that I’ve hardly picked up the camera since February.

I was doing some stage photography for our Passion Play and I decided to take my MacBook Pro to download the cards as I went. A friend asked me why I ended up with so many shots (over 1500) from this one evening. The answer is simple: in such low light, you’re working at the very edge of the capabilities of the equipment and the probability of getting it sharp in a single frame is practically zero. I like to shoot stage with little bursts of three to five shots, which usually yields one or two good frames per burst. Even if you get them all sharp, there’s always the chance that someone’s eyes have closed, or a hand has covered someone’s face.

All that said, I am so ready to have a camera that has ISO 6400 or beyond
So, Aperture. My main concern was working fast, since I didn’t have anyone to empty the cards for me. I wanted the machine to ingest the images and move on, so disabled the automatic generation of previews and asked Aperture to use the embedded JPEG preview from the camera (in Preferences > Previews tab). Then I stuck Aperture on Quick Preview mode and got to work.

The process of import went very well. Unfortunately, I managed to screw up at least once, possibly twice by pulling the cards too quickly after asking Aperture to erase them. The result was some images left on the cards, which I accidentally imported again as duplicates. I had forgotten where the “Don’t Import Duplicates” setting was and assumed it was on. I thought it was a preference that I had already set, but it’s actually a checkbox on the import panel. Lesson learned. It was easily enough fixed by creating Smart Albums based on Import Session (thanks to Pat Berry for the idea).

The other slight wrinkle was that it was difficult to tell when Aperture had finished erasing a card. In Aperture 1.5, the project would continue to show the import progress spinner until the card was erased and ejected. As soon as you saw the project shoebox icon, you knew that the card could be yanked. I need to do a little more testing, because now I’m not sure how you know with Aperture 2 - it shows the shoebox icon as soon as it starts erasing the card, not when it finishes. That was really the reason why I ended up with partially-erased cards.

After that, the process was smooth as silk. I did a very quick reject-or-one-star pass just using these previews. I like to shoot using the Monochrome picture style on my 30D. This applies a monochrome conversion to the embedded JPEG preview, which you see on the camera’s LCD. The actual RAW data is still colour, though, so you don’t lose anything. What I found was that, with Aperture using the embedded preview, the image would be initially rendered in colour, then snap to black and white. This was a bit distracting for the rating step. My guess here is that Aperture was first rendering a blow-up of the thumbnail that it generated from the RAW data (in full colour), then almost immediately rendering the image’s embedded B&W preview on top.

The only other problem was that the embedded JPEGs from the camera are fairly low-resolution and don’t look great at full-screen on a 17″ laptop. In particular, for those I shot in colour, there was significant apparent posterisation of the colours due, I suppose, to the compression applied. That’s not unexpected, so the next step was to have Aperture generate proper previews for each non-reject image. That took a while, but made Quick Preview mode even more useful for the finer stages of rating.

Apart from those small wrinkles, Aperture 2 ran brilliantly. Scrolling through all those thumbnails and previews was as smooth as silk.

Featured Comment: InfoWeek’s Response

I thought this one was too important to leave in the comments on my piece about Alexander Wolfe’s cynical and lazy blogging on the iPhone SDK.

David Dugan took the trouble to make a complaint to InfoWeek about the article. The full response is in his comment at the above link, but here’s a little dissection:

Alex actually runs one of the fastest growing Blogs inside InformationWeek, and yes it grows fast based on the juicy headlines, creating some contention and the other things that make a Blog good.

Translation: telling lies about subjects which people care about is good for business.

Comment: This is the downside of the move to ‘free’. When everyone’s competing for advertising eyeballs on content that they used to charge for. It’s difficult to believe that this dynamic has zero impact on the content itself. Look at what Information Week are explicitly saying: our free-content properties are deliberately made more sensational and argumentative than the content that is paid for.

we definitely take more liberty in blogging than we do in a major feature or a news story–there is a difference between these things in our approach.

Translation: accuracy doesn’t matter unless it’s on a slice of dead tree.

Comment: It’s hard to think of a phrase more euphemistic than “take more liberty”. Sentences like “we care less about accuracy in blogging” or “we don’t mind incorrect statements in our blogs” or “any amount of garbage is just fine with us on the blog pages” sounds a whole lot less noble, doesn’t it?

Everyone on this e-mail does not want to lose you as a user of our site, nor do we consider it ‘click whoring’ to write content that gets people riled up–that is the beauty of blogging and that is the beauty of people like you who care enough to send this sort of note.

Translation: We don’t actually know why people read blogs but we read John C. Dvorak once and copied him.

Comment: Is getting people riled up really “the beauty of blogging”? I have a much better definition of the “beauty of blogging”: getting real-world experience from real people who have deep knowledge of their subject and are free to write what they want.

Come to think of it, do tech journalists satisfy any of those four conditions? I’ll grant - in some cases - that they are real people. However, Wolfe’s piece showed that his experience was most certainly not real-world, as he had not even downloaded the SDK. His knowledge on the subject is somewhere between shallow and non-existant, and he is clearly under orders to be sensational in order to grow his readership.

In a world in which Craig Hockenberry can blog about his direct experience in developing for the iPhone, why do I need a journalist to mediate that information for me?

I would like to start a web service like Gravatar where you can state your competencies and those competencies are linked to from every article, post and comment you make on the web. Simply writing under a once-respectable masthead is no longer enough. In fact, today, it’s probably a good indicator that one should lower one’s expectations.

Late Night ImageKit

Bit late on this one, but an episode of Late Night Cocoa was recently published featuring me talking about Image Kit on Leopard.

Bampot of the Week: Alexander Wolfe

John Gruber has his occasional Jackass Of The Week award, for which Rob Enderle seems to be in line for a lifetime achievement award. I needed a more Scottish equivalent, so here is my Bampot¹ of the week: Information Week’s Alexander Wolfe, for his overblown and incorrect piece about the iPhone SDK entitled “iPhone SDK Developers Angry At Apple’s Tight Control”.

Let’s take the piece apart, Gruber-style:

Apple’s mindset is apparent from the get-go. They’ve gone non-disclosure crazy with the iPhone SDK, though admittedly no more nuts than usual. Here, what they’re doing is keeping the all the stuff people want to know under much tighter wraps than they need to. For example, you can download the iPhone SDK for free, but you have to pony up $99 to get at the really good documentation, sample code, and developers’ videos.

This is simply not correct. Firstly, the NDA is a standard thing for pre-release software from Apple and many other companies. The iPhone NDA is little different to others I’ve seen but to discuss the contents of the NDA any further would be to break its terms.

Wolfe makes a factual error in stating that you have to pay $99 to get the documentation and sample code: you get that when you download the SDK. The documentation, samples and videos are available for the price of registering for a free ADC Online developer account. The videos are available via Apple’s ADC on iTunes service.

OK, that’s relatively minor. Pay the $99 and be done with it. I think the bigger problem for developers is going to be death by a thousand cuts. By this, I mean that Apple never seems to put all its cards on the table at once. For example, on Sunday Phonemag reported that the SDK contains a tidbit noting that the iPhone won’t run more than one app at a time, so when users switch applications, whatever is running in the background will get killed.

If Apple “never seems to put all its cards on the table at once”, how come we know about the no-background-threads limitation? If it were a hidden limitation, we would only learn about it when someone tried to write a background app and it failed to work. Documenting limitations isn’t the same thing as hiding them.

From Apple’s standpoint, this is done to maintain decent performance. However, developers are likely to see it as just another screwing.

If Apple had promised me that I would be able to write supported background applications with the SDK then, yes, I would feel screwed. However, to my knowledge, no such promise was made. Having used Windows Mobile devices that do allow process to live on in the background, I can only hope that Apple enforces this limitation as rigidly as possible. Nothing else makes sense for the user in a resource-constrained environment like a phone.

The trick for we developers is to make it look like the app was running all along.

Me, I want to know what’s supposed to happen if you’re in the middle of something important and your iPhone rings. Does your app blow up?

Yes, the only possible explanation for what happens when another app is launched is that the iPhone deliberately crashes the one you’re working in. For “blow up”, let’s substitute “get suspended, saving its data for later resumption” and then we can answer yes.

The same thing will happen to your app when the user hits the Home button. Does Wolfe think that the Home button will be made into a “crash my app” button in iPhone 2.0?

There’s lots of complaining about the fact that all iPhone apps have to be approved by Apple, will be sold by Apple, and Apple will get a 30 percent cut of all sales. On the other hand, John Siracusa at Ars Technica says that “developers see dollar signs” in iPhone apps, so presumably they’ll deal with the restrictions.

Great argumentation: “lots” of unlinked, unattributed ‘complaints’ and the one attributed remark actually refutes the point of the paragraph.

Turns out, though, that developers are limited in what iPhone functions that can tap for the apps they’re building, according to Adam Houghton’s post on his eponymous blog. Houghton characterizes as a “glaring” omission his discovery that developers can’t access calendar appointments, music and videos from the phone’s iPod app, nor phone and SMS functionality.

So there’s missing functionality. The SDK is beta. File an enhancement request.

How is Apple’s rule that only apps it has signed can run on the iPhone going to play when it comes to corporate applications? One commenter on Slashdot …

…and that’s the point at which you have to laugh and close the tab.

This is a lot to digest, and quite frankly most developers will suck it all up because, hey, it’s the iPhone.

I think, right now, “most” developers serious about the iPhone are still reading and reading and writing test apps and figuring things out. Despite it being a lot to digest, that’s apparently no reason for Wolfe to hold off on filing an ill-informed attack piece on an SDK he clearly has not even downloaded and investigated. If he had done so, Wolfe would know that you don’t have to pay $99 to get the documentation, sample code or videos.

Wolfe seems to have totally missed the point about the SDK. He mostly seeks to criticise the no-background limitation, but the majority of unresolved questions in all of this are about the App Store. Here are my questions:

• How do we do a public beta release without charging for it? I never charge users for beta releases.
• Will developers be able to generate coupon codes for free downloads? This is very important for promotional purposes.
• How will the App Store handle discounted upgrades to new versions? Upgrades keep the lights on in year 3.
• How and under what circumstances might Apple revoke an application’s right to run? Does the customer get a refund, and from whom?
• How will it handle demo versions? Trying before buying is important. Seems like this would be easy to do with FairPlay embedded in the applications.

For me, those are the real questions. The technology is great (which, given the NDA, is about as much as any developer should be saying about it right now) and all the known unknowns are about the business deal.

[Update: 1. Bampot (Scotland, slang, pejorative) idiot; an objectionable and foolish person.]

An analogy for RAM and HDD space

I doubt doubt many readers of this blog will struggle with confusing RAM capacity and Hard Disk capacity. Regardless, I offer this analogy that I use to explain the difference to my less-technical friends in the hope that it will help your less-technical friends understand it:

Think of RAM as your physical wooden-or-formica desktop. It has a certain fixed size and, if you want to work on paper documents, you have to have them on your desk. The number of documents and books you can work on at once is limited by the size of your desk. If you want to work on more paper items at once, get a bigger desk. Similarly, if you want to work with more files and applications at the one time, you need more RAM.

Think if your hard disk as your filing cabinet. It can hold many more paper documents than your desk, but you can’t work on a document while it’s hanging in a drawer. If you want to work on something, you have to move it from the filing cabinet to your desktop. That’s the paper equivalent of loading an application or opening a file. If your desktop is already full, you need to put something back in the filing cabinet.

You keep a lot of things in your filing cabinet that you don’t want to work on every day. Those older documents don’t slow down your work at your desk unless you bring them out and put them on the desk. They can happily live in the filing cabinet forever … until you fill the cabinet and then it’s time to throw away the old stuff or get another cabinet. Similarly, the number of files on your hard drive does not seriously impact the performance of your computer, unless the disk is over 90% full.

There you go. Not drastically insightful but I’ve yet to find another explanation that people of all technical abilities (and, literally, none at all) get as quickly as this one.

Xcode: Unit Testing Built Products

Just wanted to share a little trick I recently developed for Xcode. I had a problem with FlickrExport 3: the Info.plist file was not being regenerated correctly when I built the target without cleaning it first. This problem only came to light when I started using preprocessing in the Info.plist to fill in the CFBundleVersion from a build setting defined in a .xcconfig file. The result was that I thought I was building version 3.0.0bX and the final product’s Info.plist was actually 3.0.0b(X-1).

What I wanted to do was to check that everything was copacetic in the built product after the build was finished. My solution was to add a final Shell Script build phase to the target with the following code:

grep -q "${FE_APERTURE_VERSION}" \
        "${CONFIGURATION_BUILD_DIR}/${INFOPLIST_PATH}"
if [ $? -eq 0 ]; then
	echo “Plist check passed.”
else
	echo “Error: out of date plist in built product. Perform a clean build.”
	exit 1
fi

This fragment greps the built Info.plist file for the current value of the FE_APERTURE_VERSION build setting. If they don’t match, the script exits with a non-zero code and Xcode stops the build.

I’ve since expanded this a bit to check that the included frameworks are in their proper locations, are correctly built as Universal Binaries and so on.

ScreenFlow: The iTunes of Screencasting

I come to praise an application that puts a smile on my face every time I use it: ScreenFlow by Vara Software. ScreenFlow is an application for recording video from your computer screen and exporting it as a video file for sharing online.

I’m calling it The iTunes of Screencasting, not because it looks like iTunes or manages a library of your screencasts, but because it does the one thing that I love seeing applications do: it takes a process that formerly involved many small tools that worked together but were poorly integrated and pulls them into one coherent whole.

Kids today don’t remember what we had to go through to listen to music on computers. First you had to rip the CD to AIFF files (being careful not to entirely fill your hard drive!), then use an encoder like Mpegger to convert them to MP3, then add the IDv3 tags in another app, then organise them in files in the Finder (I still can’t believe that people still yearn to do this part), then use Audion to make playlists. Once you’d done all that, you had to go digging for those playlist files in the Finder, open them and play them. And you couldn’t just Spotlight-search for them, or make a Smart Folder. Oh, no.

This is the kind of simplification that Screenflow delivers for screen and audio recording. You launch it, you choose your video sources (screen and/or iSight), you choose your audio sources and you hit the Big Red Button. You do your stuff, and then you tweak it afterwards.

“Tweak it afterwards” makes it sound lightweight. It’s not. In other screen recording software, such as Snapz Pro X, you define a region of the screen to be recorded and if a dialog pops up somewhere you didn’t expect, you start all over again. ScreenFlow does away with all that: you record the entire screen, and zoom in or crop the video later. That alone justifies the application for me. You can also add highlights such as cursor circles, click targets and sounds and keystroke overlays - all automatically and all after the fact.

Put that all together and it means this: focus on recording your demo, forget DJ’ing all your screencast software at the same time and edit with ease. Fantastic application.

[Update: Here's a link to a short video showing you how to sample a hung application: How To Sample An App (4MB Quicktime)]