Upgrading from iPhoto '11 to Aperture 3

Apple's iPhoto has a great feature set -- simple and sufficient for day-to-day needs -- but performance comes to a crawl after you've used it for about a year or two. It almost feels like iPhoto is actually Aperture Lite and its supposed to lead you towards that $80 pay wall after one or two years of trial usage.

Anyway, migrating your iPhoto library to Aperture is no simple feat, especially if you're upgrading because your library has outgrown iPhoto's limits (think 100K photos in 3-5K events). Here's what I've learned from my experience:

About the process:

1. I chose to import from my iPhoto library by leaving the image files in their current location. Im not sure if doing otherwise will make things faster or slower. Something tells me its the latter.
2. It could literally take up to one day to finish the entire process.
3. There are three phases: 1) Import, 2) Saving Aperture library, 3) Processing. The first two needs to be done without shutting down Aperture.
4. The import stage could take up half a day, the CPU may spike in temperature at times, and disk I/O will be pretty busy; so be prepared. 
5. The import is not resumable. You cannot interrupt or cancel the import. If you do, you have to start over (i.e. by deleting the Aperture library file before starting the app again). Otherwise, Aperture will just create a duplicate entry in your Aperture library if you try the import again -- duplicate library entries are not detected.
6. Once the import is done, you are not. Closing Aperture will cause it to save its library. This won't take as long as the import, but it can take a couple of hours.

About speed:

1. If you didn't close aperture or when you open it again, it will be busy processing all the photos it has just imported. This will likely take the longest time, but you can close Aperture at any time. So if aperture is slow after its done with the import, its probably because its still processing all the images.
2. Having a speedy HDD (7200rpm or solid-state) will make a huge difference
3. I've read that turning off face detection and automatic preview generation makes a difference -- made no difference to me
4. You can monitor the whole progress by opening Aperture's Activity window. Deselect any current selection on the main window's side bar and minimize the main window -- this seems to help responsiveness

It seems odd to me that Apple made little effort to make the transition from iPhoto to Aperture easier or at least enable us to do the migration in parts over a few sessions. Who are their target users if not upgrading iPhoto users?

After 1 Aperture crash, 3 failed attempts, I'm... still at the processing stage.

How Rails 2.x and 3.x handles time zones with mysql

Very good post on how rails handles time zones with mysql

Mode 2: Automatic time zone conversion is enabled

• This is the default when you create a new Rails 3 application, but not when you create a Rails 2 application.

• In this mode Rails keeps all Time object in the configured zone, but stores them in MySQL as UTC times (regardless of the time zone you chose).

Working with LaTeX and Preview in OS X 10.7.2 Lion

In the past, compiling and previewing my LaTeX document from vim was as simple as running make and open as external commands:

:!make clean all; open document.pdf

open is a handy command line program that opens the file with the default Mac application for its file type.

I end up having multiple windows open for document.pdf but that was fine for me.

In OS X 10.7.2, this process broke because Preview would hang for 1-2 minutes when the LaTeX compiler is still building the pdf. A naive approach would be to make an AppleScript to close Preview's window of document.pdf before running make.

However, I found a nice trick that makes use of the way Lion handles process termination. From the Ars Technica review:

"Lion reserves the right to keep an application's process around just in case the user decides to relaunch it. Upon relaunch, the application appears to start up instantly—because it was never actually terminated, but was simply removed from all parts of the GUI normally occupied by running applications."

So we can just do:

:!make clean all; killall Preview; open document.pdf

By terminating Preview, we skip its lag in figuring out the changing document and at the same time, we get no duplicate windows for document.pdf in Preview.

That's a win-win! :)

Segmentation Fault Running Vim on OS X 10.7.2 Lion

So after upgrading to OS X 10.7.2, vim has been terminating with a segmentation fault whenever I run an external shell command from inside vim.

Aside from normal shell commands, I frequently run fmt from inside vim to format my text to 78 / 80 characters wide.

To solve this, simply compile vim from source:

1. Download the latest source, e.g. ver 7.3:
   curl ftp://ftp.vim.org/pub/vim/unix/vim-7.3.tar.bz2 -O
2. Untar:
   tar -xvjf vim-7.3.tar.bz2
3. Configure to build without GUI:
   ./configure --enable-gui=no
4. make
5. make install
6. Edit your .bash_profile to make sure running vim will run the recently build vim at /usr/local/bin/vim instead of the default at /usr/bin/vim:
   PATH=/usr/local/bin/:$PATH; export PATH
7. All Done!