At Zimpler, we like to program in pairs. When everyone is working in the same office, that’s pretty easy: we just share a computer, and use whatever text editor the owner of the computer has (in our case Emacs, Vim or Sublime Text 2).
But things get complicated when one of the developper decides to move abroad for a couple of months…
First attempt: No Pair Programming
Well, the easiest solution is simply to stop pair programming and simply review each other’s code. But we observed that it’s really more difficult to solve problems in a simple and elegant way while programming on your own. One is also more reluctant to fix broken windows on code that is already written.
So I guess that’s not a viable solution. Pair programming is great, and passing on it simply because we are not in the same place is just too sad.
- Trivial to setup
- Makes me a sad panda
Second attempt: Screen Sharing
The simple approach is to simply run some sort of screen sharing application. We have been using Screen Hero, which is really awesome. Each user that joins a Screen Hero session gets his own cursor with his name on it. In addition to that, we run google hangouts or Skype to talk to each other.
This works great, except that there is some lag for the users that are not hosting the session, and the quality of the video is not perfect. Spending most of the day writting code with an image full of compression artifact, even minors, is pretty painfull.
Also, since we recently migrated to JRuby, some of us still use a not so powerful MacBook Air, running Skype + Screen Hero + Spork + Nailgun + Chrome made our computers really, REALLY slow.
So that didn’t work for us, but if you have access to a really good internet connection and powerfull computers, this might be the best solution.
- Easy to setup
- Fancy cursors for everyone
- Compression artifacts
Third attempt: AWS + SSH + tmux + Emacs
Inspired by other remote-working companies like Relevance, we decided to try a combination of SSH, tmux and Emacs. To make things easier, we decided to setup all that on a High CPU Amazon EC2 instance.
I order to work with git, we simply need to active Agent Forwarding
when we ssh in to the instance. It’s also interesting to setup some
port forwarding when we want to run
To do that automatically, we just configured a host in our local
~/.ssh/config that look something like that:
1 2 3 4 5 6 7
And then we just have to
ssh pp to access the instance.
We met some problem when running Emacs from the terminal, since the
meta key (the
cmd button on mac) is not properly interpreted. Also,
C-<right> were not properly recognized.
iTerm 2 solved the first
problem. In the preference panel, under Profiles/Keys, select “Left
otion key acts as +Esc”. Now we can use the
alt key as the meta key.
We solved the second problem within emacs, by mapping the ASCII escape
sequence received from
C-<direction>. That’s what
we added to our
1 2 3 4
This solution is pretty nice, but it restricts us to Emacs, vim, or
editors that can be run in a terminal. It also requires a lot of
effort to setup. We also get the super annoying scrolling with tmux
C-b [, is there a better way?).
It might have been easier to setup tmux with vim instead, but we have a much more efficient workflow with emacs at the moment.
Though a nice side-effect of developping on the exact same type of instance that we deploy our application to is that we find bugs that we might have missed while developping on our local machines. We found a bunch of timezone-related bugs for instance.
The plus side is that once everything is in place, it’s really comfortable to program. We share the same cursor, the same window, there is not compression artifacts, and all is super fast.
This is clearly the best solution we have found so far. Plus it’s a really geeky one, and we get to learn tmux along the way.
- A lot of configuration
- No support for sublime text 2
- Weird scrolling with tmux
We’re still kind of green in the field of remote pair programming, but we found a pretty good solution for now. There is clearly room for improvement, but remote pair programming feels pretty much like local pair programming (even arguably better).