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.

I’ve started a new project (ha! as if I needed another): I’m trying to write an HTTP server in ruby using just the HTTP/1.1 RFC (RFC 2616) and the ruby docs. It’s called Perchance, just because I’m feeling rather serendipitous. It’s been mildly successful so far. I’ve gotten it to connect to respond to a basic GET request, which means that the socket stuff is working good. Now I just have to worry about the proper formatting of the protocol. It’s really just a matter of coming up with cleaver ways to read and respond to the requests, because right now it’s pretty crude.

I’m doing this because I think it’ll be useful to be able to create an application from only an RFC. These things are pretty dry, and to be able to read through them and extract the requirements and create a program that adheres to them is probably a pretty useful skill, especially since all the documentation on cool stuff like SIP and NAT-Transversal tend to be hidden away inside RFCs.

Also, learning the ruby socket stuff is fun. It feels useful already.

I don’t know if it’s something I’ll ever release (something tells me the world could go without another httpd) but it’s definitely an interesting project for the time being. I’ll update the status on it around the new year. Hopefully I’ll have most of the spec done by then.

fortune spat out something funny and relevant today:

“Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing.”
— Dick Brandon

UPDATE 3/08/07: Bart has updated SSH Keychain to 0.8 and made it a UB. Thanks Bart!

The development of SSHKeychain, my favourite little SSH key manager seems to have stalled for some reason or another. Unfortunately, their last release is a PPC build, meaning it has to run under Rosetta on all the fancy new Intel machines Apple is shipping these days. This is a pain, since it’s actually the last app wasn’t running natively one my Macbook Pro.

I’ve noticed that they actually updated the source in svn to build as a universal binary (way back in February), but never bothered rebuilding and distributing it. Luckily, since open source is really great, I checked out a fresh copy and built such a universal binary for myself. I thought I’d share the results, to make it easy for those who don’t want to install Xcode tools and build it themselves:

Download SSHKeychain r95 - Universal Binary Don’t use this! See Update!

You should really checkout and build yourself if you want to make sure it’s secure and everything, but if you trust me, this is much easier.

Thanks a ton to the SSHKeychain guys for doing their thing. I highly appreciate this piece of software.

Thanks to ThisService, I’ve turned the previously mentioned ROT13 ruby script into a system-wide Mac OS X service. Simply select the text you want encrypted/decrypted, hit CMD-Shift-R or select ROT13 from the service menu, and your text will be ROT13-ified.

Thanks, Jesper!

Dowload it here: ROT13service.zip

I’ve been asked to lead a Ruby session at my school for a small group of students interested in learning the language. As such, I’ve been brushing up on it lately, and I came up with a fun little script I thought I’d share.

Our topic is cryptography, and in the spirit of fun I thought I would show how easy it is to write a ROT13 cipher in Ruby. Here it is:

def uppercase_swap(byte)
  if /[A-M]/ === byte.chr then byte += 13
  else byte -= 13 end
end

def lowercase_swap(byte)
  if /[a-m]/ === byte.chr then byte += 13
  else byte -= 13 end
end

ARGV.shift.each_byte do |byte|
  byte = uppercase_swap byte if /[A-Z]/ =~ byte.chr
  byte = lowercase_swap byte if /[a-z]/ =~ byte.chr
  print byte.chr.to_s
end
print "\n"

As you can see, it’s not very big. Ignoring the 2 function definitions at the top momentarily, all we are doing is taking the first argument (ARGV.shift), and iterating through each byte –each character of the string. With each byte, we are checking to see if it is an upper or lowercase letter and calling the appropriate function to swap it with a different letter if it is.

Simple. Nice.

If anyone has any input on how to improve this code, please let me know. UPDATE: I made it better, here’s how:

def swapLetter(byte)
  if /[A-M]|[a-m]/ === byte.chr then byte += 13
  else byte -= 13 end
end

ARGV.shift.each_byte do |byte|
  byte = swapLetter(byte) if /[A-Z]|[a-z]/ =~ byte.chr
  print byte.chr.to_s
end
print "\n"

Merging functions is goood.