Keeping Context With Tmux and Digital Ocean

- 5 minutes read - 1049 words
@sgharms reply about tracking process

In a recent disscussion the developer community “The Practical Dev” asked how we, as developers, keep track of what we’re working on so we remember where to start next time. Many of the respondents had advice about time tracking or to-do lists. I read the question as a question about technology and less about process.

My answer was that:

Tmux + doing my work on my @digitalocean droplet creates great continuity in process for me. I rarely break the context (~years).

I’ve been working in this development “style” for many years now and I thought refresh some of the core ideas. Most of them haven’t changed, which, in many ways, is exactly how I know I’m doing the right thing. This is the context setup that I have used / am using for:

  • Blogging Platform
  • Lisp programming
  • Algorithms Work
  • A Rails app
  • Sysadmin work on my Digital Ocean droplet

So it’s my belief that this is a robust solution.

My Development Computer is a Digital Ocean Droplet

From my perspective, I rent computer cycles in the form of a droplet from Digital Ocean. I go for the plan that’s one above the cheapest (because I’m worth it). I’ve only been hamstrung by memory limits once, but that was an unusual case (I was doing rebases of massively large repos). To use these “rented” cycles, I connect via SSH to the server and use it in a style that would seem entirely familiar to someone used to working with mainframes in the late 70’s.

Obviously, this setup won’t work for anyone doing Unity or VR programming. But for anyone in the CLI or CLI + Browser style of programming, you’re going to have all the horsepower you need.

So, for roughly 140 dollars a year I rent a computer that can’t be stolen, that has full backups, and that I can connect to whenever I want. I can access it when I’m at a friend’s house or while idling at an Apple store.

Unlike a “real” laptop, my upgrade was easy. I upgraded droplets this year because the Ubuntu LTS release I was on expired. The process was to spin up a new droplet, rsync my home directory, export a few server rules and I was done. I’ve initialized dozens of laptops, I’ve never had it easier than this.

Also, I pay for the server-side backup. I don’t have to worry about backup disks or Time Machine or fire or any of that noise. If there’s an outage, I’ll use my backup tape from DO. While this might represent an unacceptable risk for some, it’s never been a problem for me. Also, I have another server which I use to host a git server so I have some redundancy, if needed.

Lastly, by doing my work on a machine that is not owned by my employer, I’m ensuring that any software I create is not caught in an IP contest.

My Laptop is a Near-Disposable Dumb Terminal

I’m currently using a 2014 MacBook pro. The tools I need this thing to run for development are:

  • iTerm
  • Browsers
  • Tunnelblick (for VPN sockets)

I have a PC laptop as well. When I want to use it, I do. When I travel light, I use a [Chromebook][cb]. Ultimately I don’t have to care about these machines' performance specs because the machine that does the work is my droplet.

The PC I bought for $300 second hand from a computer repair store near Penn Station. The $2200 laptop that I tried in the Dell store 9 months ago is now at that same spot for $300. Effectively I can “lease” top of the line hardware (nice clicky keys, pretty screen) for $300 a year which I pair with a $100 investment in reliability. For me this is a no-brainer setup.

My Work is “Contextualized” by tmux

When starting work on my droplet, I use tmux to create a virtual context. I give it a name for a task “blog” or “lisp” or “java.” I then open several “windows” (that can be tiled, split horizontally, split vertically, etc.) that create a work “environment.” While this could be tedious, tmux allows scripting so I have written a script to create a new environment. Here’s my script for setting up my blogging environment:

#!/bin/sh

SESSION_NAME="blog"
WORK_DIRECTORY="$HOME/git_checkouts/repo-dir/"

tmux has-session -t ${SESSION_NAME}

if [ $? != 0 ]
then
  echo "Starting tmux ${SESSION_NAME} in ${WORK_DIRECTORY}"

  # Correct directory
  cd ${WORK_DIRECTORY}

  tmux new -s ${SESSION_NAME} -n vim -d

  # Start vim
  tmux send-keys -t $SESSION_NAME 'vim' C-m

  # Launch a terminal space
  tmux new-window -t ${SESSION_NAME} -n 'shell'

  # Launch a server space
  tmux new-window -t ${SESSION_NAME} -n 'Local Server'
  tmux send-keys -t ${SESSION_NAME}:2 'bundle exec jekyll s --host local-host-name'  C-m

  tmux select-window -t ${SESSION_NAME}:=0

  # Pick it back up again
  tmux attach -t ${SESSION_NAME}
fi

Aside: Most of my scripts look like this, feel free to take it as a template

I rarely have to re-launch a context. My droplet stays up in durations measured as months, so it’s rare to have to restart this context, but I have the code in a git repo so, were I to have a virgin droplet, I would clone the repo and have my scripts and be able to get back to work in but a few minutes.

So, on cheap hardware, I can create and instantly reengage with my work contexts. What does that feel like day-to-day? I’ll tell you.

Context Preservation

Since my contexts stay up for months at a time and that I’ve broken the “my computer / my work” bond. Closing the lid doesn’t mean losing the “flow” of the workspace.

Also, when I return to an idea that I’ve had to leave off for days, weeks, heck months, I don’t have to remember which files in which directory were being edited. My windows in the session patiently wait for me to come back and when I do I’m on the exact line and column I was on when I left. This can further be augmented with vim’s mksession capability, but I don’t find myself using that.

So that’s how I stay productive and focused when I have to leave a context. The secret is: don’t lose your context if you don’t have to; you don’t have to.