Don't change your RSS feed

Stuff changes on the internet. I get that. Your site has been redesigned with a totally new and completely elegant URL structure. Great! However, unless you're me, you probably actually have readers that subscribe to your site via RSS. Make sure that whatever changes you make, you don't break that feed.

For years I've been reading a web comic called theWAREHOUSE. It's a great comic, especially if you like puns (they have some real elaborate ones on occasion). However, back in July it went through some site change that ended up breaking the RSS feed that I was using. Shocking thing is, I didn't notice it broke until now. That's right, it took me four months to realize that I wasn't seeing posts from them anymore, and they were one of my favorite web comics.

Going back into the archives in Google Reader, one of the last entries on the old feed mentioned that they would be moving the site. There was no mention in that article that the move would break anything, though. From this post it sounds as though he switched from manually editing PHP & XML files to Wordpress, but I suspect he completely neglected to think about how the transition would affect the people that were subscribing to those XML files.

Anyway, moral of the story is that if you, as a site owner, break your RSS feed, don't expect that people will notice and resubscribe. It's far, far more likely that the vast majority of them won't notice and will completely forget about you.


The 13" Retina MacBook Pro

I reviewed my new 13" Retina MacBook Pro on the Ask Different Blog. Conclusion: it's awesome!


Where the iPhone 5 sample pictures were taken

Following up on my post from last year where I made a map depicting where the sample photos for the iPhone 4S were taken, I have done the same thing with the sample photos from the iPhone 5. Of the six photos posted, four have GPS tagging (the two photos of the ocean do not):

In general, it seems that this time the photographers stuck “closer to home” and didn’t really go too far away from the San Francisco Bay area. Maybe it’s a good sign for the quality of the iPhone 5’s camera that they didn’t need to.


Beware using Camera Connection Kit across time zones

Last week I went on a fantastic vacation; a road trip loop starting and ending in Las Vegas and passing through the Hoover Dam, the Grand Canyon, Bryce Canyon, and Zion National Park. Since my laptop was still awaiting my RMA from OCZ (another story) I decided to buy a Camera Connection Kit for my iPad and use that to load pictures off my SD cards and onto my iPad so we could view them and free up space on the cards.

This process worked okay; not flawlessly (again, another story), but well enough — or so I thought.

However, when I got back home and imported all my photos into iPhoto, I noticed that the times were wrong on nearly all of them. And they weren’t all wrong by the same amount - some were correct, others were two hours ahead, and others three hours ahead. What happened?

It turns out that when a camera stores the time a photo was taken in EXIF, it stores that information textually for whatever time the camera is set to without any time zone information. When importing the photo in iPhoto or on the iPad, the software looks at the EXIF timestamp and interprets that as the time the photo was taken in the time zone on the device.

That works all well and good if the time zone on the camera and the time zone on the device importing the photos is the same. It’s also only a minor annoyance if they always differ by a constant value, like if the time on the camera is set incorrectly.

However, in my case I had my camera set to EDT the entire time; the problem I had was that my iPad, in an effort to be helpful, kept changing its own time. Under all other circumstances this is very useful, but this meant that the timestamp my iPad put on the photos was dependent on which time zone I imported them in. Very annoying. Fortunately, the correct data was still retained in the EXIF - I just needed to delete all the photos from iPhoto and reimport them, and iPhoto correctly reread the times.

Unfortunately, there doesn’t seem to be an easy solution to this. Ideally, EXIF should be updated to provide an absolute time, but that doesn’t seem very likely if they haven’t already, and it also wouldn’t fix the millions of cameras that already exist. The best pragmatic solution, in my opinion, would be to have an option when importing photos on the iPad to specify the time the camera is set to, but again I don’t see this as likely because it would appear to complicate the process. Alternatively, have iPhoto on the Mac reread the EXIF data of everything it imports or receives through Photo Stream and reinterpret it in the time zone that the Mac is set to.

However, until there is a fix (which very likely could be never) what should users of the Camera Connection Kit do? My suggestion would be to go into the settings of the iPad and override the current time zone and set it to the time zone of the camera before importing. Then set it back to change automatically when done. It’s a hack, but it does work.


Taming a Linux dev environment with Vagrant

Last November I wrote a small rant on this blog about the frustrations that I’ve had with Linux. Specifically, I outlined what my usual solution is if I can’t get something working after about 15 minutes:

I’m tempted just to toss my VM, get the latest Ubuntu ISO and reinstall from a known-good state. But again, you can only do this so many times before it becomes tiresome.

So, enter Vagrant. Vagrant takes this annoying, manual process that I’d resigned myself to doing from time to time and provides a way to automate it (and, in doing so, mostly replaces the need to). Now, instead of messing around with package managers and permissions, I just specify how I want the server configured in a Vagrantfile and Vagrant goes and creates it for me. And if something gets messed up for whatever reason, the process of blowing the VM away and starting over is fast and painless:

$ vagrant destroy
$ vagrant up

And you’re back in business.

Of course, automated installation of packages is all well and good, but the real power of Vagrant comes as part of a development workflow. When Vagrant starts up the VM, it mounts the directory with the Vagrantfile onto the /vagrant path on your virtual machine, allowing you to make changes to your project files locally with a native editor and have them immediately available on the VM. Gone are the days where you’d have to fire up an editor on the VM or have to constantly copy over the project files - it all just works now.

Having a single point on the VM where everything’s stored also makes it possible to specify things like VirtualHost configurations for Apache. So, when the VM boots, in addition to loading all the required packages, it can also configure the installed servers with the necessary parameters for your project. The scope of this sort of configuration is outside that of the Vagrantfile, but Vagrant has built-in support for Chef and Puppet that you can use to do the job.

Finally, if you commit the Vagrantfile (and whatever associated Chef or Puppet files you might have) to your version control system, you can share that development environment with all the members of your team. If you need to add or upgrade a package, just commit the change, have all members of the team pull and vagrant reload and boom - everyone’s development environment now contains that new change. And in the future when you want to pull up the code from the past, you’ll not only be able to see the code but instantly boot up the development environment as it existed and run it.

The Vagrant team has put together a great Getting Started walkthrough to give you an idea of the power and flexibility Vagrant provides. Personally, I now find Linux a lot more manageable now that I don’t have to worry about stuff getting messed up on my development VMs.