words by patrick

When I’m not doing one of the many things I usually do, I sometimes do other things. One of these things is photography. I’ve been doing it for several years now, and consider myself to be a decent amateur photographer. With a photo library of almost 10,000 6MP+ photos, and plans on it becoming larger, I have outgrown the usefulness of iPhoto. I’ve played with Adobe Lightroom quite a bit, and while I do rather like it, I decided that Aperture suited my needs much better, and was actually a purchasable product. I won’t go into a comparison of Lightroom and Aperture here, there are plenty of other people who already have, so I’ll let them tell you why Aperture is better. I want to show how you can do something I thought would have been slightly more straightforward when I began using Aperture, but wasn’t.

This is a quick guide to using Aperture most effectively on a laptop with a relatively small internal hard drive and a nice big fast external hard drive.

First off, let me explain why you would want to do this:

• Since your internal drive is small, you typically want to save it for things you need all the time. For me, that’s my apps, my music, a few movies, and a ridiculous amount of development tools, source, and code. Like everyone, keeping as much space free as possible is a high priority – a virtue, if you will.
• Internal laptop drives are slow. Unless you’ve sprung for a smaller drive, chance are you’re running at 5400rpm. This isn’t terrible, but it’s nothing compared to the 7200rpm or 10,000rpm desktop drives available today. With eSATA or Firewire 800 connections becoming avaliable, it may be much faster to work on an external drive than an internal one.
• Desktop drives are freakin’ huge. This comes in handy when you start dropping 2GB worth of photos at every shoot.
• Aperture allows you to take image previews (basically large thumbnails) of all your offline media with you, so you can still show off or look at photos that you don’t have with you, you just can’t edit or export them. This is awesome, because it means you can have a 30GB photo library you can carry with you anywhere for only about 6GB of hard drive space [tweakable]. (This was one of the big selling point of Aperture for me.)

With this in mind, let me explain the basic workflow:

1. Images are taken in the field and immediately imported into Aperture for organization and editing.
2. Upon getting back to the studio/office/whatever, images in Aperture are re-located to the external storage drive where more editing or organization can take place. This frees up space on the laptop for more images next time, but keeps preview of the images like all the others.
3. The photo library is backed-up to a separate “vault” drive for backup purposes.

Simple? Great. The problem is that doing this in Aperture isn’t immediately obvious, at least it wasn’t to me, so here’s how you do it.

1. Create a folder on your external drive where you want to store all your photos. I called mine “Photo Library”.
2. In Aperture, select File -> Import… -> Import iPhoto Library. Choose your iPhoto Library folder, and then select “Choose…” under the “Store Files:” pop-up. Navigate to the folder to just created and hit Open. Ensure “Move Files” is selected. Under the “Subfolders” popup, choose how you would like your the folder hierarchy of your library to be built. You will probably never be interacting with the files manually, and it is important that the naming scheme be kept consistent because you will be using it every time you unload files from the laptop to the external drive. Although Aperture won’t particularly care, this has the potential to create a very messy folder hierarchy if you don’t stick to your chosen naming scheme. I chose Image Year/Month/Day since it was the same way iPhoto did it and it just Makes Sense™. You can also change the version filename if you like, but I always just leave it as is.

   Click “Choose”. Depending on the size of your iPhoto library and resolution of the images, this will take a long time. Like I said, my photo library is about 10,000 images large and I think it took about 5 hours. Aperture is doing a lot: It’s moving a ton of files to an external drive, as well as creating image previews for each file. Let it do it’s thing.

3. Organize your photos to your heart’s content. I recommend creating projects for all the different albums, because Aperture seems to slow down the larger the project is, and by default the iPhoto import dumps all images into a single project with multiple albums.
4. Unplug your drive. You’ll see that all your images are still there, still viewable, but marked as offline. Hooray!
5. When you’re “out in the field” or whatever, you can import your images into a new project and under the “Store Files:” popup, select “In the Aperture Library”. This will keep the files on your laptop for now.
6. When you get back to the office/studio, select the project you worked on out in the field. Select File -> Relocate Masters for Project…, then navigate to the folder you made in step 1. For consistency, you should use the same subfolder naming scheme you used in step 2. While you don’t necessarily have to, the folder will quickly start looking like spaghetti if you don’t, then when you have to access it manually it will be a nightmare.
7. The masters will be moved off your internal drive, but the previews will stay. Hooray!

All it takes is the proper know-how and single command to do, so I guess in retrospect this isn’t really that complicated. Here are some things I tried that you should NOT do:

• Don’t move your Aperture Library file (~/Pictures/Aperture Library.aplibrary) to your external drive. The next time you launch Aperture, it will just create a new empty library, and even if you do relocate the file in the Aperture preferences, you won’t be able to use any of the cool fun offline image features that make Aperture so sweet. There is no way to use Aperture with two separate Library files or something. I found this out the hard way.
• Don’t create an alias/symbolic link from ~/Pictures/Aperture Library.aplibrary to /Volumes/ExternalDrive/Photos/Aperture Library.aplibrary (or where ever you have it). This was a great trick to use to keep the iPhoto Library on an external hard drive while keeping the other iLife apps happy, but I can’t imagine it works all that well with Aperture.

One last word about the image previews: If you go to Aperture -> Preferences… and look under the Previews heading, you can see that you can adjust the image preview quality to a certain size if you are limited on space, or prefer large-as-possible images.

So there you have it. Aperture rocks.

So I’m working on a little Core Data based application that you will hear more about in the future. In it, I have an NSTableView whose coulmn headers are bound to an NSArrayController, which in turn is bound to the managedObjectContext to get all my spiffy data.

Problem #1: Core Data doesn’t do sorting. Every time the app is launched, the data in the table appears randomly. Having it appear sorted on launch was actually really simple. Here’s the solution:

1. Implement a KVC NSArray object in your controller or delegate object, and have it return an NSArray with the default sortDescriptor (here I am sorting by a ‘date’ property):

- (NSArray *)sortDescriptor
{
	if(sortDescriptor == nil){
		sortDescriptor = [NSArray arrayWithObject:[[NSSortDescriptor alloc] initWithKey:@"date" ascending:NO]];
		}

	return sortDescriptor;
}

- (void)setSortDescriptor:(NSArray *)newSortDescriptor
{
	sortDescriptor = newSortDescriptor;
}

2. In Interface Builder, bind the sortDescriptors Controller Content Parameter to your controller or delegate object, and set the Model Key Path to whatever you called your NSArray of sort descriptors (in my case, sortDescriptor).

That’s it! It wasn’t as intuitive as I originally thought, but it certainly seems pretty clean to me.

BUT WAIT! We have a new problem now.

Problem #2: Objects that are inserted or changed in the table aren’t sorted properly. Fixing this problem was a little trickier, but I found a solution to it at CocoaDev’s RearrangeObjects page. Here’s my little implementation of it (although original credit should go to JediKnil):

1. Register to hear the NSManagedObjectContextObjectsDidChangeNotification, preferably somewhere in your app controller’s awakeFromNib method.

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(objectsDidChange:) name:NSManagedObjectContextObjectsDidChangeNotification object:[self managedObjectContext]];

2. Next, we implement the objectsDidChange: method:

- (void)objectsDidChange:(NSNotification *)note
{
       [myArrayController rearrangeObjects];
}

This forces the table to check it’s arrangement every time any object is changed, added, or deleted. Depending on your purposes, you may want to use JediKnil’s method which checks for certain properties changes, and avoids rearranging if unneeded.

That’s it! It took me a while to figure this out and I saw others were having the same problems else where and never really got answers, so hopefully this is useful to someone. Good luck!

There’s a few tutorials floating around on the internet on how to use ssh keys to login to your servers without having to type your password each time. It’s a very useful thing to do but sadly none of these tutorials are Mac OS X specific. Therefore, I thought I’d help out my Mac OS X native friends (Hi James!) and provide one that leverages the value of SSH keys using SSHKeychain.

The whole process is pretty simple: You create your SSH keys using ssh-keygen on your home computer, then upload your public key to the servers you wish you use passwordlessly, set up SSHKeychain, and you are golden. Let’s get to it.

To create your SSH keys use the following command and follow the on screen instructions, although you can leave the file name blank, since the defaults are fine:

ssh-keygen -t dsa

I can’t recommend using a blank password, because hey, it just seems dodgy. After you do that, two new files have been created in ~/.ssh/, id_dsa and id_dsa.pub. As you probably guessed, id_dsa.pub is your public key. Upload it to the servers you want to access it using scp, and place it in ~.ssh/authorized_keys2:

scp ~/.ssh/id_dsa.pub yourserver.com:.ssh/authorized_keys2

Since this is probably your first time setting up ssh keys, that file most likely won’t already exist, although it would probably be worthwhile to check if it does, and simply append your id_dsa.pub file to it if necessary.

Special note: My awesome web host, nearlyfreespeech.net, has a different method of handling public SSH keys. I needed to send them my public key in a service request for it to be added to their private database, which was no problem, but different than usual. If your having trouble logging in without a password, try asking your server guys what’s up first.

Now usually what we would have to do is start ssh-agent (which handles our key exchanges for us), tell it to add our new keys, and then use the shell it provides us with. Although this could be added to your shell login file, there is a much easier and more convienent way in Mac OS X.

Enter SSHKeychain. This app basically loads ssh-agent for you all the time, so you don’t have to worry about it, as well as other nice little things. And it’s free. Go OSS! Install this app (download, mount, copy, trash the dmg, you know the drill), set up the prefs (I have it appear only in the menubar for dock cleanliness), and go into the environmental tab and turn on “Manage global environment variables”. Log out and log back in, and you should now be able to ssh into your without being prompted for a password! Just keep that id_dsa file nice and secure, eh?

Next up, I’m going to cover how to use SSHKeychain to setup and use SSH tunnels.

This is my first tutorial (or even real article) on this blog, so if you have any comments, suggestions, or corrections, please feel free to email me at patrick @ this domain.