Portable, Shareable Application Development Environments | Glenn Gillen

Portable, Shareable Application Development Environments

Jan 07, 2014

The emphemeralization of my possessions

I remember a time when managing, securing, and protecting all my possessions seemed laborious. There was a pile of cassettes, CDs (and later DVDs) that had to be boxed up and moved whenever I moved house. The music had long been ripped to CD, but it still spanned multiple external drives and I needed to keep the CDs incase something ever went wrong with one of the drives. Then there were the photos: some 8x9 prints that had been scanned, and an ever growing directory of digital only ones. That again needed to back backed up onto external drives. And of course there was meant to be an offsite copy of those, incase there was a house fire. But whatever offsite copy I had was rarely up to date.

Little by little that’s changed. iTunes and an iPod replaced much of the physical clutter I had for music, later the iPod was replaced by a phone and Spotify. As for the photos the relationship flipped, my “offsite” copy was where I kept the whole library (S3 to begin with) and only a small working set was ever on my computer at a time. Even the hassle of keeping copies of software lying around on CDs with serial numbers disappeared thanks to some scripts to install all my free open source software and the Mac App Store.

It wasn’t until a couple of years ago, while talking to a friend about the risk of crime and property theft in San Francisco, that I appreciated the magnitude of what had happened. 10 years ago someone breaking into my house didn’t just carry a huge emotional impact, but it significant upfront and on-going financial ones too. TVs, home theatre systems, computers. Thousands of dollars of equipment and potentially months of effort to acquire replacements and set everything up again. Not to mention the sentimental things like photos that could never be replaced. But today the financial impact is $999 to replace a Macbook Air and 30mins-60mins to set it up. All the “irreplaceable” music, photos, and software is back exactly as it was in the time it takes to eat lunch.

Taking something that seemed to have a high negative impact, and making it near negligible has been liberating. And so I’m constantly looking at how to take it further.

Outsourcing your development environment

I’ve been playing with Nitrous.io on and off for about a year now and I really love the approach they’re taking. As quick as it is to setup my local machine the biggest and most variable time sink is getting it to a fully working dev environment. Installing XCode to compile binaries has historically been a pain, and making sure any C-based dependencies compile when jumping to a new OS hasn’t always been reliable. And I never actually ship code OSX based so doing all my development on a Mac OS is breaking one of the tenets of the 13-factor app methodology: dev/prod parity.

Wouldn’t it be great to not have to install GBs of software just so you can write code? Wouldn’t it be great to be able to instantly access your familiar dev environment, from any computer, within minutes? And wouldn’t it be amazing to be able to share that environment with a colleague so you could work on a problem together, even if you weren’t in the same room?

Some of you might be agreeing but thinking that none of this is new and people have been doing it for years. And you’d be right. What Nitrous.io is doing differently is that they’re running it for me. It’s the difference between me paying to have a server in a rack to store all my photos, and then monitoring it’s uptime and managing backups, and working out how to fail over or just storing them all on Dropbox or S3. Running my own instance to host my dev environment is just moving the problem, I want to remove it.

It’s not all rainbows

There’s been a couple of things that have held me back from going all-in in Nitrous.io though:

  • Having to keep my vim scripts synced: It’s a minor thing, and it’s largely scripted, but it just feels like a hassle. If/when I’ve got all my development happening there it’s probably not an issue, but right now I’ve got a local environment configured to my liking that I want to be able to use. They had a Mac App to help address that, but it doesn’t work with Mavericks :(

  • Collaborating via the web IDE: Partly an extension of my previous issue, I like the setup I’ve got and I want to use it. Editing in a browser still doesn’t feel right to me, pairing can be challenging enough without productivity impacts.

  • Shared vim/emacs config: religious wars have started over less. At previous places I’ve worked we’ve converged on a single configuration so everyone’s computer felt familiar while pairing. Given part of my goal here is to share a remote service, everyone will be on their own computers, so converging on a config seems like it’s a needless constraint.

Once I stated the problems, it was easier to reason about a solution. All I needed was:

  • The ability to edit files like they were on my local machine.

  • To make sure file changes were synced to Nitrous.io, and that other users would receive those changes.

Part of the experience of pairing is watching live what your pair is doing. That can happen via screen sharing, but I wanted to see if I can remove the screen sharing and instead have my own terminal open and watch the changes live. That means there’s an explicit contract that both users need to uphold.

Editing files like they’re local

Well I cheated. I’m actually editing local files, and then using unison to push the changes to Nitrous.io over SSH. To make make sure whoever I’m pairing with can see my changes I need to make files are saved in near-realtime. Enter the vim-auto-save plugin.

Detecting remote changes

Unison is set to run repeatedly every 1 sec (I originally had fswatch setup to run it only when local files changed) so changes will be propagated in both directions. The other part of the contract each user needs to uphold is to ensure they detect and display any changes to files within their editor. For vim that required some hacks to my .vimrc.

Packaging it up

To make it easy to move this setup onto a new machine, I’ve consolidated all of config changes into a single repo at https://github.com/glenngillen/nitrious.io-pairing-setup.

Hi, I'm Glenn! 👋 I've spent most of my career working with or at startups. I'm currently the Director of Product @ Ockam where I'm helping developers build applications and systems that are secure-by-design. It's time we started securely connecting apps, not networks.

Previously I led the Terraform product team @ HashiCorp, where we launched Terraform Cloud and set the stage for a successful IPO. Prior to that I was part of the Startup Team @ AWS, and earlier still an early employee @ Heroku. I've also invested in a couple of dozen early stage startups.