Two years ago, I wrote a post called The Warhawk Flies that summarized my email server migration from Microsoft’s Exchange Server 2003 to the open source combination of Postfix and Cyrus IMAP. The move was both liberating and educational.

The experience with Debian, BIND DNS, MTAs and the IMAP protocol were well worth it and the server has been performing admirably ever since installation. Of course, hosting your own email server from your house isn’t without its drawbacks.

First is the actual server itself. Although the server is housed in a Mini-ATX case, it still takes up room and power. Then there is the noise. It’s much quieter than what I had before, by a measure of ten-fold, but it still gives off some noise. Most of the time I don’t care but sometimes I’d rather not have my home office sound like a mini server room.

Second is the maintenance. Backup routines, making sure that software and security updates are installed, and gawd forbid that there is an actual hardware failure. Most of these can be automated, but I’d rather spend my time doing something else.

Lastly, my notion of how email should work has changed. Although I was constantly squirreling away email in their own separate folders, I never actually found any old email by traversing the folder hierarchy; I simply searched for it. Google’s implementation of labels allow me to categorize and archive email without having to create a complex archival folder structure. At first I found this backwards, but the more that I used it at work the more I started to see the merits of adopting such a system.

With those drawbacks in mind, I started thinking about potentially moving my email and my email domain to GMail. After some deliberation and some clarification of what GMail’s service could and couldn’t do via our sysadmin (@demonbane) I decided to take the jump.

I signed up for the pro account ($50 a year per mailbox) so that I could use their IMAP4 import tools. You can cancel this after the free trial is over and I’ll probably do that because there is no compelling reason to keep my GMail account at the pro level.

Importing two mail boxes (my girlfriend’s and mine) took approximately 2 and a half hours. During that time, I changed all of my MX records to point to Google so that I would be up and running by the time the import was done.

Since I now have 3 GMail accounts that I’m checking (work, home and another domain that I manage), I decided to pick up a copy of Mailplane, which is basically an OS X application that wraps GMail, and allows you to switch accounts with a click of a button (probably the primary reason I chose to install Mailplane).

After the import was done, I tested inbound and outbound email and it worked flawlessly. No one on the outside could tell that my mail was now being routed and hosted at Google. Ultimately, I’m quite happy with hosting my email through Google.

I bought my first generation iPhone 6 months after it had debuted in the market. It’s the first mobile device that I’ve actually bought myself. All of the previous mobile devices that I have had (including the terrible Windows Mobile Phone) have been owned by the company that I used to work for.

From the minute that I got it, I’ve loved it. Simplicity and elegance, Internet access from anywhere (where there was an EDGE connection), a full web browser and more.

As an Apple enthusiast, when the 3G iPhone version was released, I wanted to pick up the new model but there was little reason to upgrade (with the exception of the 3G speed boost). With very little motivation to upgrade, I stuck it out with my 1st generation iPhone.

A year after 3G model was released, I was completely frustrated with the speed of the EDGE connection. It reminded me of the old modem days. Anytime that I wanted information quickly the connection sputtered; traffic, email, weather, maps, directions, you name it. It reminded me of the old modem days and that’s something that I would rather forget.

When Apple released their new iPhone 3GS model, I knew that I was going to upgrade. In my mind, the main reason for upgrading was the 3G speed increase, everything else would be extra toppings.

I have to say that this is one of the best upgrades I’ve ever done (on any device; computer or electronic device). I came for the 3G connection, but everything about this new phone is better. Here is my list of reasons to upgrade from earlier versions of the iPhone:

• 3G speed (Obviously the 1st gen 3G iPhone already had this)
• GPS (The 1st gen 3G iPhone already had this)
• Device specs upgrade (although Apple doesn’t publish the new specs the CPU increase and memory bump are noticeable)
• Oleophobic screen (my 1st gen iPhone was a magnet for the oils that your skin secretes. This one has a new coating that keeps it to a minimum)
• Better camera (new 3 mega pixel camera with auto focus)
• All new video camera (VGA recording up to 30 fps with audio. Takes surprisingly good video for a phone (even in low light))
• Better built in speakers (I believe the 1st gen 3G iPhone had the new speakers. I can finally hear my phone ring inside of my messenger bag)
• Voice control (for voice calling and controlling iPod)

If you have a 1st gen iPhone and can afford it, I think that this upgrade is a no brainer. Even if you have a regular 3G iPhone, I think that this upgrade is still worth it (unless you rarely use the camera).

I live in Vancouver, Washington but I commute to Portland for work every week day. For my commute, I usually take I-5 and therefore have to traverse Interstate Bridge to cross over into Oregon. The bridge allows for marine traffic on the Columbia River to pass underneath by lifting the spans and thus closing traffic off until it is clear. Naturally, because of the traffic implications, this is an event that occurs rather infrequently, but it still occurs nonetheless.

There have been times when I’ve been unfortunate enough to be stuck in traffic while a bridge lift was happening. Judging by the amount of other commuters and freight vehicles stuck beside me, I’m guessing that information about spans lifting isn’t being distributed efficiently.

The last time this happened, I tweeted the message: “Does anyone know if ODOT or WADOT make notifications (of any kind – web other otherwise) before they raise the I5 Interstate Bridge?” I was curious about this because I wanted to make a simple web app that tells you if the span is up or down.

A few days later, a response came from the OregonDOT’s twitter account, "Yes, we send traffic alert to Portland area traffic reporters before a bridge lift. @pdxcommute usually tweets about them. They shared a number for me to call for more information and while I have not yet called to get the details my mind started wondering how they would be able to distribute this information in a timely manner to multiple sources. I put the idea out of my head until I read Ilya Grigorik’s post titled HTTP PubSub: Webhooks & PubSubHubbub.

Using that as a springboard, I’ve come up with a conceptual system that addresses these questions.

Let’s say that you operate a web application that distributes traffic information to subscribers via IM, Email, SMS or Twitter. You’ll want to get that information from a reliable source and in Oregon that would be ODOT.

ODOT will surely have more than one service asking for traffic update data, so a polling mechanism on the client end is very inefficient for both the server and the client. Here, PubSubHubbub makes perfect sense. Images below are adapted from this Google Document (PubSubHubbub Subscription Flow Draft 0.1):

In step 1, you can see that my fictional web application (Subscriber) asks the ODOT Publisher to subscribe to traffic data. The Publisher sends information to the subscriber telling it where it can receive that data.

In step 2, our web application subscribes to the data feed and tells the Hub to send updates to a specific URL.

In step 3, there is some security checking from the Hub back to the Subscriber. The Hub sends the data to the URL that the Subscriber specified in step 2.

In step 4, Someone at ODOT has posted a new traffic update and therefore the Publisher updates the specified Hub.

In step 5, the Hub POSTs the update to the endpoint URL that the Subscriber specified in Step 2. Although the diagram below shows the interaction between the Hub and one Subscriber, in theory a Hub can update multiple Subscribers at once.

In the final step, the Subscriber can then re-post the data via IM, Twitter, Email, or SMS or simply display it on their website. Once a Subscriber gets a hold of that data, then it’s up to them what they do with it.

This conceptual method for delivering data is much more efficient. Besides the initial setup, the only data that’s being transferred is actual data and there is no useless polling going on. Although PubSubHubbub is one solution to the polling problem, it’s not the only one. Others are using the IM standard, XMPP, to also distribute information to Subscribers.

If you’re interested in PubSubHubbub, I strongly suggest that you read the documentation at Google’s Code page.