I get a lot of requests to add date-shifting support for iPhoto 08 to my iPhoto AppleScripts. But in most cases, the scripts would be completely unnecessary, iPhoto finally built this feature into the application. Here’s how to use it.

Select one or more photos you’d like to adjust, then choose “Adjust Date and Time…” from the Photos menu:

You then change the Adjusted date to the correct time and all the other photos will be shifted to match.

Using this native tool is substantially faster than anything I could do with AppleScript. I’m just kind of sad I never finished up the auto-date difference calculator I was working on.

I’m surprised at how emotional I was this morning. My older daughter was born 6 months and 8 days after September 11th. Today she and her younger sister are both in school. I think this is the first year I’ve been alone for the entire morning.

Walking my younger daughter to preschool this morning, we stopped as the firemen of Engine 5 pulled the truck out of the station a little and stood silently to commemorate Flight 11 at 8:45. I tried to explain to her why we were waiting for them — with them — but I had no voice. Those men and women dwarf me, every day they’re a reminder of what true heroism looks like. I feel lucky that my window looks out on their station.

There was a bagpiper at the station, as the firefighters stood in remembrance of the South Tower falling at 10:05 am, the bagpiper played Amazing Grace. At 10:28 am he started with Amazing Grace and switched into America The Beautiful.

Previous 9/11s: 2001, 2002, 2003, 2004, 2005, 2006. I don’t know why I didn’t post anything last year.

Three weeks ago my mother was diagnosed with breast cancer.

Last week, she became a survivor.

In honor of my mom, this Sunday, September 14th, I will be running in my first race, the Komen Foundation’s NYC Race For The Cure. Please consider making a donation, no amount is too small.

Update: The race was an amazing event, possibly the biggest crowd I’ve ever been a part of. It was also incredibly emotional and inspiring.

Thanks to everyone who donated, we raised over $1,600 in less than a week!

(regularly updated)

Installing Git on a shared hosting account is simple, the installation is fast and like most things Git, it just works.

This is a basic install without documentation. My main goal is to be able to push changes from remote repositories into the hosted repository, which also serves as the source directory of the live website. Like this.

Prerequisites

The only two things you absolutely must have are shell access to the account and permission to use GCC on the server. Check both with the following command:

$ ssh joe@webserver 'gcc --version'
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50)
[...]

If GCC replies with a version number, you should be able to install Git. SSH into your server and let’s get started!

If you see something like /usr/bin/gcc: Permission denied you don’t have access to the GCC compiler and will not be able to build the Git binaries from source. Find another hosting company.

Update your $PATH

None of this will work if you don’t update the $PATH environment variable. In most cases, this is set in .bashrc. Using .bashrc instead of .bash_profile updates $PATH for interactive and non-interactive sessions–which is necessary for remote Git commands. Edit .bashrc and add the following line:

export PATH=$HOME/bin:$PATH

Be sure ‘~/bin’ is at the beginning since $PATH is searched from left to right; to execute local binaries first, their location has to appear first. Depending on your server’s configuration there could be a lot of other stuff in there, including duplicates.

Double-check this by sourcing the file and echoing $PATH:

$ source ~/.bashrc
$ echo $PATH
/home/joe/bin:/usr/local/bin:/bin:/usr/bin

Verify that the remote path was updated by sending a remote command like this (from another connection):

$ ssh joe@webserver 'echo $PATH'
/home/joe/bin:/usr/local/bin:/bin:/usr/bin

Note: Previous iterations of this page installed into the ~/opt directory. Following current Git conventions, I’m now installing into the default ~/bin.

Installing Git

SSH into your webserver. I created a source directory to hold the files and make cleanup easier:

$ cd 
$ mkdir src
$ cd src

Grab the most recent source tarball from Github. When this post was updated, the current Git release was version 1.7.10.1:

$ curl -LO https://github.com/git/git/tarball/v1.7.10.1

Untar the archive and cd into the new directory:

$ tar -xzvf v1.7.10.1
$ cd git-git-9dfad1a

By default, Git installs into ~/bin which is perfect for shared hosting. Earlier versions required adding a prefix to the configure script (like this), but none of that is necessary anymore. If you do need to change the install location of Git, just specify a prefix to the Make command as described in Git’s INSTALL file.

With all that taken care of, installation is simple:

$ make
$ make install
[lots of words...]

That should be it, check your installed version like this:

$ git --version
git version 1.7.10.1

It’s now safe to delete the src folder containing the downloaded tarball and source files.

My preferred shared hosting providers are A2 Hosting and WebFaction.

Due to excessive downtime and API rate limiting by Twitter, I’ve been experimenting a bit with using Fluid to run Twitter in a Site Specific Browser (SSB). While I’d much rather be using Twitterific or Hahlo, this works pretty well, except I had no luck with any Twitter auto-reloading UserScripts I found. So, as usual, I wrote my own.

The script was uploaded to UserScripts.org, you can install it and view source over there: Twitter Reloaded on UserScripts.org

The script does a few things differently from other scripts I found:

• Reloading is postponed if there is any text in the status field
• A visual countdown is inserted into the top of the page
• Twitter pages are reloaded every two minutes, that’s probably still gratuitous, but every minute seemed like overkill.

I resisted Git for a long time. It seemed a cultish thing with devout vocal followers and frequent mentions on Digg. I figured it would probably be a passing fad. I was wrong.

I drank the Kool-Aid and damn, it was tasty.

The first important thing to realize, especially when starting out and considering switching, is that Git works with existing Subversion repositories. That means the transition can be as simple as learning a few new commands, your repositories and servers don’t need to changing. Other team members don’t need to switch. If I had any other team members, this would be huge.

Of course, once you start using Git and see its potential, you’ll probably switch everything, convert your repositories and feel superior whenever you have to work with a Subversion hosted project.

Ultimately, Git is a revision control system and is fundamentally about preserving and protecting your working history. So feel free to experiment, it’s really hard to mess up.

It took me an afternoon to grasp the basic concepts of Git, or at least enough to use it in dumb-SVN mode. After about a week, I started to feel fairly comfortable.

I read a small mountain of weblog posts, documentation and the like, here are the ones I found most valuable:

• A tour of git: the basics
  Carl Worth’s port of Bryan O’Sullivan’s Mercurial book
• Learning git-svn in 5min
• HowTo: Use git for personal development when everyone else is using Subversion Part 1 and Part 2
• Using Git with Google Code Hosting
  A good overview for working with any Subversion repository.
• Bluish Coder: How to publish a Git repository Some good ideas about publishing repositories
• Git Quick Reference
• Fraser Speirs wrote this while considering switching from SVN to Git
• Git will eat Subversion’s Lunch by Bill Bumgarner

And definitely watch Linus Torvalds’ Google talk about Git. It won’t tell you how to use Git, but he’s funny and the talk worth seeing.

Getting Git

• Mac OS X Installation Binaries (other OS’s too)
• And of course, TextMate support: Git Bundle

While Git itself is easy to compile from source, getting the documentation manpages built on Mac OS X Leopard is a pain in the butt. I futzed around with it a little, but gave up halfway through installing a seemingly endless line of dependencies. The Mac binary installer works perfectly well and is kept up to date. I’d rather spend my time using Git than installing it.

Using Git

I was blown away by some of the stuff Git can do.

In the Google talk Linus pointed out how all SCM packages could do branching and branching wasn’t a problem. Merging was. Merging branches with Git is leprechauns and unicorns. It’s almost too easy. After a few days I found myself branching all over the place, constantly creating new branches to test any idea I was having. Folding those branches back in was almost always quick and painless.

Interactive line-by-line commits mean it’s possible to commit single lines from a file instead of the whole thing. This is great if you happen to go off on a bender and change a zillion different things between commits.

Cherry-picking is also great, and saved my butt when I created a pretzel of branch history. Using git-cherry-pick I was able to straighten out my history completely within Git using Git’s tools with no loss of work.

Conclusion

I started writing this post at the end of May, it’s now early July and I’ve been using Git for a few months with no regrets. The only time I hold my breath is when I’m pushing changes back to SVN, though it hasn’t glitched on me since early June. The speed and flexibility of Git are a constant pleasure to work with. The pain of merging branches, which used to take entire afternoons with SVN, has almost become an afterthought.

WWDC 08 was incredible. While the iPhone gold rush euphoria contributed, everything just seemed especially good this year.

I’ve been quietly disappointed in Leopard since it shipped. It just seemed too rough around the edges and somewhat rushed, especially compared to the polish demonstrated by the iPhoneOS. Because of that, I’m probably more excited about Snow Leopard than I was about Leopard. Besides the promise of generally improving the overall experience, the under-the-hood OpenCL and “Grand Central” additions are truly revolutionary advances for desktop OSs. The idea behind OpenCL being able to utilize the largely untapped parallel processing power of the GPU has the potential to radically reorganize the entire idea of computing, moving things distinctly towards a brain-like collection of specialized processing units. I’ve been joking this is OS X SP1 but that’s just not true, Apple is mainlining some serious innovation into the backend of Snow Leopard and this should be a very, very good release.

My plan for this year worked very well. I managed to set aside the week prior to essentially cram on Cocoa and Objective-C. While that was originally supposed to be three weeks, the time I eeked out still helped a great deal. I also maintained a very disciplined focus about which sessions I went to. In the past I’ve flitted around trying to get a taste of every subject that interested me — which is almost everything. This year’s deliberate focus and pre-study nearly eliminated the blank-stare drift I’d experienced in the past and left me feeling more confident than ever about building stuff with Cocoa, writing FXPlugs and making things for iPhone.

But far and away the best thing about this year was the people. Twitter made a lot of this possible by starting conversations beforehand. I think I probably met half my twitterstream in person, which was awesome and kind of funny. The social dynamic of first meeting twitterers is sort of one where everyone treats everyone else like a celebrity. It ended up being this wonderful abstracted feeling of recognition which wasn’t nearly as creepy as it sounds like it would be. My only regret is not meeting the handful of people I knew were there but never crossed paths with.

There are just too many people to call out, but I was blown away by just about everyone I met.