This is the third installment on writing code in a post-PC environment. In Part 1, I talked about my hardware of choice. Part 2 reviewed the software used to run on that hardware. This post discusses the cloud-based services I use to keep my app development in sync. The two services I link into the most when developing with a little help from the cloud are Dropbox and a variety of virtual machines.

A Drop in the Box

Dropbox is one of the few cloud storage providers that got it mostly right. Their platform-agnostic approach allows their simple service API to be easily incorporated into PC and post-PC platforms, making it a default storage service for a number of Windows, Mac, Linux, Android, and iOS applications.

Despite its weak security model and questionable privacy practices, I use the free DropBox service mainly as a "junk" repository. Code snippets, TODO's, configuration files (my favorite emacs and vim settings), preliminary mind maps, and anything else that wouldn't be a confidentiality breach should my account be compromised.

I am also hesitant to rely too much on Dropbox as their business model strikes me as one that is waiting for the right business partner (one willing to spend billions, à la Microsoft buying Skype) to be acquired by, the same way Ruby on Rails PaaS provider Heroku become a part of Salesforce.com. It's also surprising to me that a platform-agnostic company like Google hasn't come up with a competing solution of their own. Perhaps Google will be the one that acquires Dropbox. Either way, I'll wait until the dust settles a bit before comfortably putting my coding eggs into that storage basket.

Multiple VMs

For my more serious projects, I use multiple VMs, each partitioned for a different tasks: ideas, in process, testing, production. The ideas VM is a free-form machine that can be blown away at any time with a new Linux distro, loaded with an alpha release of a new Rails build, or a playground for a new utility or library that I've read about on Dr. Dobb's and other programming websites. I use an in-process VM for the applications that I have a formal roadmap and architectural design plan for building, and keep things nice and tidy by not introducing any foreign bodies that might impact the development trajectory in any way. The testing VM is used to push my development snapshots to a continuous testing system that can also be accessed by customers interested in seeing the latest work in progress. And of course, the production VM is is the sacrosanct machine that hosts the working application.

Depending on the type of project and customer, these VMs can be housed behind a firewall accessible only via VPN or they are on the Internet and hosted on a variety of providers. If I need something rock stable with developer-friendly access and reporting capabilities, companies like Linode and Rackspace are on the top of my list. For the scratch VMs where uptime isn't as important as rapid VM teardown/build-up and low-cost is paramount, a number of VPS providers have begun to fill that space, some offering their services for as low as five bucks a month.

Cloud-Centric Workflow

A typical coding session on my iPad follows these steps — fire up iAWriter and sync with Dropbox to see what's on my synchronized task list. If it's a confidential project, that task list is on a VM that I secure sync using Goodreader or Textastic. I also use Goodreader if I just want to review the code. If I'm writing code, I use the Textastic + TextExpander combination I talked about in Part 2. If it's a code project for which I need live compiles and testing, I will use iSSH, though only if I know I'm on a solid network connection (typically when I'm at home or linked into a secure, trusted WiFi hotspot). The tools, combined with the connected cloud backends and a good Bluetooth keyboard, provide almost everything I need to leave my PC behind. A year from now, that PC will be a relic from the past, like IBM Selectric Typewriters and CRT monitors.

One More Time

Check back for the series conclusion where I discuss what doesn't work in the post-PC developer-oriented environment I've described, along with possible ways to resolve these hurdles to code flow. Until then, post your comments to the blog or send me an email letting me know what you think the optimal post-PC development environment should look like.