Some people call me "the remote pairing guy"...

I’ve been remote pairing with folks for a couple of years now. However, it’s only the past few months that I decided that heavyweight application-based solutions just weren’t working for me.

Expectatons

I expect my remote pairing experience to be as close to in person as possible. To that extent, what I desire is:

Responsive

When I, or my pair, types, I expect to see it on screen in near real-time. Even a one second delay is potentially too much.

Low bandwidth requirement

I often pair with people on the opposite side of the country. Higher bandwidth solutions tend to suffer more due to lack of bandwidth

Audio and Video

I need to be able to both hear and see my pair when pairing whenever possible. Without video, body language can’t be communicated.

For instance, ever noticed how you will often gesticulate when you’re on the phone. Feels stupid, right? It’s human, it’s communication, and so it matters to pairing.

I need my video of my pair, and vice versa, whenever I can get it.

FYI, I tend to place the video of my pair just beneath the camera on my screen. I also work to keep the video o my pair visible at all times. More on that in a bit.

Modular

The above two reasons mean that I need to be able to pick and choose which features of my pairing environment I’ll use based on internet weather. All-in-one solutions dont lend themselves well to this.

Cost

I don’t want my pairs to have to pay for extra products or services to pair with me.

Learning curve

I want to use well-known and usable tools so that my pairs aren’t wasting time fighting the tools when they should be pairing with me.

I’ve tried

  • VNC
  • Teamviewer
  • Mac OS X Screensharing
  • Skype Screensharing
  • Google Plus Screensharing & Hangouts
  • Tmux
  • Screen

All of these have let me down.

VNC (and Mac Screensharing)

VNC and Mac Screensharing (allegedly VNC under the hood) are both bandwidth intensive, typically proving too unresponsive for sustained pairing. On-screen updates often lag one to several seconds.

Teamviewer

Teamviewer is generally responsive.

But it’s way too expensive! A single license runs ~$700! Sure, it’s for life. But then my pair has to have it as well. Granted, Teamviewer is free for non-commercial use.

I also had it crash a pair’s Linux machine! This did not give me good vibes. Your mileage may vary.

Skype

Ah, Skype. How I love to hate you.

The laundry list:

  • Screensharing is unidirectional: My pair can see my desktop but they can’t effect changes
  • Frequent dropped connections
  • Screensharing frequently hangs while audio continues to operate as normal. This can only be corrected by dropping and restarting the call! FAIL!
  • Frequent compatibility issues with older versions of Skype
  • Video may be the most bandwidth intensive of the tools I’ve tried that provide video
  • Skype 5 has one of the least usable interfaces ever conceived in the 21st century

Just don’t use it. Really. Don’t.

Google Plus Screensharing & Hangouts

G+ is a different beast from Skype, though it has some similar features.

G+ screensharing is also a strange beast. It’s a feature within G+ Hangouts, a group video chat provided by G+. Like Skype, it’s unidirectional. I know, bummer, right? But it’s extremely responsive compared to Skype. Alas, again, it’s unidirectional. That won’t work.

But G+’s audio and video in Hangout is simply amazing. And it’s cross-platorm. The only sad part is that it uses Flash; it’s pretty CPU intensive. For example, it would peg both cores on my 11” Core 2 Duo Macbook Air.

Let me provided emphasis here: I strongly prefer G+ Hangouts for my A/V while pairing.

Tmux/Screen

Tmux and GNU Screen are basically two different takes on the same idea.

They’re session multiplexeres.

English, please?

They let you open multiple shells within a single terminal shell. You can also share the Screen/Tmux session via a socket with other users on the same machine.

Again, for emphasis, I use tmux whenever possible when pairing. I have my pairs SSH into a machine under my control, fire up tmux, and off we go to the races! My impression is that it’s more a matter of taste; I’ve seen Screen work as well.

Delving into the details of SSH is a bit of scope for this article but you can read more about the basics here.

Tmux (and screen) is:

  • Open source and easily acquired
  • Extremely low bandwidth over SSH
  • Most responsive option of the bunch
  • Tmux has a shallow learning curve: it’s easy to become productive with it quickly. I’ve seen numerous developers learn enough Tmux to be productive in it within a minute or two of explaining how to navigate between terminal sessions.

Nut’s n’ Bolts

As I mentioned above, the high level of my pairing stack is…

  • G+ Hangouts
  • Tmux
  • SSH

… but there are few more parts to the equation.

I typically pair with people on a machine behind a router

I use a DD-WRT router. DD-WRT is an open source router firmware that works on a whole range of off-the-shelf routers. Among other awesome features, it has a nice built-in feature to keep DynDNS current with the router’s internet-facing IP address. Because, like many people, I lack a static internet IP address (they’re just a tad finite, you know?), I use:

  • A free DynDNS account
  • Keep DynDNS updated through DD-WRT

Finally, because I control the router, I port forward SSH from the router to my internal machine of choice. Advice here: don’t keep your SSH on the well known port 22 for security reasons.

I use a Mac

While I can do a passing job of faking it as a Linux sys admin, I prefer not to. Sorry, Linux peeps.

That said, OS X has this handy little checkbox in the Sharing -> Remote Login preferences to help you secure your SSH:

Working with SSH on a Mac

I also need to be able to easily add and remove users based on their SSH public keys. Most importantly, I need to be able to tell OSX that these newly created users should be allowed to connect to my machine via SSH. This took a little bit of research and, frankly, is OS X arcana. As such, I wrote a pair of quick-and-dirty scripts that automate the chore for me.

Recap

My whole stack amounts to:

  • G+ for audio-video chat while pairing
  • A shared Tmux session running on a Mac under my control made accessible via a DynDNS address hidden behind a DD-WRT router port forwarding SSH to the Mac with users provisioned/removed via a couple of scripts on an as-needed basis.

And, so, I bid you happy remote pairing!

Posted by evan on Monday, October 17, 2011

blog comments powered by Disqus