#remote pairing

[remotepairprogramming]

From the book's page on Prag Prog:

You’ve heard about pair programming’s benefits: fewer bugs, improved skills, and faster delivery. But what happens when you want to pair with someone in another city, country, or even hemisphere? With the right tools, you won’t have to relocate to refactor. In this book, you’ll learn techniques used by the most productive remote programmers in the industry to pair with anyone on the globe on any kind of project. You’ll use collaborative editors, screen sharing, secure networking, and virtualization to create a remote pairing environment that feels as if your partner is sitting right next to you.

I am very impressed with the level of detail and research in the book. The majority of the book describes the technical nuts-and-bolts of remote pairing in different scenarios, focusing on remote pairing on open source projects; I think he does an extremely good job.

Author Joe Kutner conducted a lengthy interview with me, and I tried to convey my remote pairing experiences as accurately as possible. I also had the privilege of reviewing an advanced copy of the book. I'm flattered to be featured in the excerpt along with Jay Haynes of Big Nerd Ranch.

I'm most encouraged by the book's promotion of pair programming in general. Thank you everyone who has ever paired with me, both remotely and in person. I tried to distill the best of our experiences and patterns in my small contribution to Kutner's book.

Required disclaimer: all opinions expressed in the Kutner's book are my own and do not represent those of Pivotal Labs, Go Pivotal, EMC, etc. etc.

[samuelgoodwin-blog]

How to get started with remote pairing quickly

Remote Pair Programming is a thing now that people do. Basically, it enables you to learn from and work with anyone anywhere, ever. You can do that thing we love to do (write code) with a diverse range of people.

So let's say you've decided you like this idea of getting out of the bubble of programmers you know well and you can't to go see how the rest of the world lives. I'll show you how to setup your Mac to do just that:

1. Install the tools you'll need.

You'll need a few things here, easiest way to install them all is with Homebrew.

brew install tmux

Tmux lets multiple people use the same terminal session. This is way faster than relying on any screen sharing application and works even on less-than-epic internet. It also lets you do a bunch of fancy things (4 minute video) to manage multiple windows and split-screens in your terminal session.

brew install vim

Technically your OS X install comes with this already, but the version we get is not the latest version of Vim. They have fixed bugs and made improvements in performance and such since the version that ships on OS X. Also, you might find that some plugin decide to use just won't work on the older version. Might as well install it while we're here.

You'll also want to grab a copy of ngrok. This is a convenient way to give people access to your laptop without needing to do all kinds of router configurations (which you maybe can't do if you're forced to use your ISP's router, bleh). It also gives you some monitoring abilities, lets you track usage and keep up with who is using the connection.

2. Let your partner onto your system.

Now I personally wouldn't even give my password to my wife (if I had one), so here we'll use ssh keys. Tell your pairing partner to send you their public key. If they use github already, you can find their keys by adding the extension ".keys" onto their profile url. For example, you can turn my profile url https://github.com/sgoodwin into https://github.com/sgoodwin.keys and see all of the public keys I've added. If they don't have one already, github provides excellent documentation to explain how.

Once you have their key, you'll want to add it to your ~/ssh/authorized_keys file. If you don't already have this file, feel free to create it. You'll want to add an entry (just a new line) in the file that looks something like this:

command="tmux attach" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC3iQgxhX0Ozb6oy9eORGIY3HowlDtUfKpWNJCwiU2F1aRA9alsxeSvjJpOxqKip3Z7//ynPUK151r/ZU9aBmv43n3RITSUQqM1BAYoXPTCrQeehBJIzEE4wXFm8NUkSwTiF7xHdCDo7rnluz58qUWDpHxcb/XwZFt17zGO/PPuJcFkuy79la37xvol2fb9No2TON54ZBbx8Xi2IzEbxbWTmMc6K+vwwxZPIAQz5EL3vBRrtyT8RHjhF3G5Z1KmD6YkX9BaYnUbX+3WYVhzo19QRgiRgE9I5IP6KNSKJuxKBb4SaYdPJbn/cUPgvZmMj1oaoTUW2236FXglIjAaDoEx [email protected]

The first bit there supplies a terminal command which should be executed as soon as they login. I chose the command "tmux attach" which puts them directly into my tmux session so we can get started. Whatever command you put here, the ssh connection will close as soon as the command finishes. If you put ls for example, it would print the contents of your home directory and then close the ssh connection. Now when they ssh into your machine, they'll be tossed right into your terminal session and you two can get to coding.

Once ssh is configured, turn on ngrok and let them in with the command:

./ngrok -authtoken <YOUR AUTH TOKEN GOES HERE> -proto=tcp 22

This will open the gates to your machine and display the url your partner can use to find your machine with ssh. Once they do get ssh to connect, you'll be looking at the exact same terminal session and you can get the party started.

3. Connect with some audio

Now that you can both type, it's helpful if you can both speak. Skype does an ok job with this (audio only, video and screen sharing are slow and mostly bad). You could also use something like FaceTime Audio which has excellent audio quality in my experience. Whatever you two want to use is cool. Use your cell phones even.

Some warnings

I don't know these Ngrok people very well, for all I know they're recording all of my traffic to report to the NSA. Probably shouldn't use it for your terrorist plots or for coding sessions where security of the code you're looking at is super important. You're working over ssh, so your work is encrypted, but you know, sometimes you need to be paranoid.

If you start to feel uncomfortable about the person you're going to pair with or even during the pairing session, pull the plug (just quit ngrok) and delete their key.

Even with these caveats, there are some advantages to setting things up this way:

No need to manage your configs on a different system. I'm not a fan of maintaining configurations on more than one machine, so this is a big win for me.

Dtrace. Another option you have is to share some server and work there instead of your own machine, but linux machines don't get dtrace, your Mac does though!

It will take you maybe 30 minutes to set this up. Your dev environment is already setup on your computer, all you have to add is the bits to share it with someone.

Now that you're equipped to pair with people, you can go here to find more info about pairing and places you can go to find potential pairing partners. This is one of the ways we can get around not having enough more-senior developers near us. Go learn things!

[remotepairprogramming]

Remote Pair Programming Presentation

On 07/06/2011 I was honored to give a presentation at the Atlanta Software Craftsmanship meetup. here are the slides. I'm going narrate a screencast with these slides soon.

[remotepairprogramming]

Remote Pair Programming Presentation Video

Here is a video screencast of my Remote Pair Programming presentation.

[remotepairprogramming]

My Remote Pair Programming video from Pivotal Labs

Visit http://pivotallabs.com/talks/143-remote-pair-programming-people-and-technology to see a video recording of my Remote Pair Programming presentation.

[remotepairprogramming]

Debugging an Android Phone by Remote Pair Programming

We sometimes have to get creative when remote pair programming. For example, how do I help debug a problematic Android phone when I'm 2,500 miles away from it? The answer: my pair holds it up to the camera for me to see!

[remotepairprogramming]

Remote Pairing with External Mic and Speakers

Using external mic and speakers has made remote pairing much nicer for me. I work in a home office where the noise does not bother other people. The biggest benefit for me is just a more natural feeling, less "tethered" if you will. I have never had feedback or echo issues and my pairs usually can't tell the difference in sound quality vs. when I wear a headset. 

The mic is a Blue Snowball and the speakers are a Bose SoundDock, but I don't really recommend that unit -- it works, but it's too bass-heavy. Thus I don't have   specific speakers to recommend, other than to say choose speakers that have a balanced sound; that probably means spending more than $10.

Notice in the video that my pair isn't wearing headphones, either. He also has a Snowball mic and good speakers and you can hear him just fine without too much background noise. Though he is working in a crowded office environment he can still use external speakers because, when they are not crappy internal computer speakers, my speech sounds like any other person talking and not a "annoying computer voice." 

[remotepairprogramming]

Remote Pair Programming with tmux and Vim: the first 14 days

For the past two weeks I’ve been remote pairing using Vim and tmux, a terminal multiplexer, allowing multiple users to share multiple terminal windows. Vim is… Vim. You know — Vim. If you don’t know what Vim is, fire up Internet Explorer and use the Bing Bar to search for “Vim.”

TL;DR – tmux works well for terminal-based technologies

tmux is working pretty well for us as remote pair programming screen sharing technology for our terminal-based development tools. We gave up some MacVim functionality and had to learn (and keep remembering) a few new commands when using tmux + Vim. tmux is of no help for GUI-based tools, such as robust IDEs and web browsers, for which we still use Screen Sharing.app, if a bit awkwardly. For certain teams, tmux + Vim + Screen Sharing.app is a viable development setup, though with more overhead than pure Screen Sharing.app.

Pros

Negligible network lag for remote the developer.

No special firewall setup as long as you have ssh access to the host.

Cross platform between Unix, Linux, and OS X based systems.

MacVim users will find Vim very familiar.

Cons

Have to learn and use the tmux commands for screen navigation, scrolling, and more.

Does not help with GUI tools, such as browsers and IDEs.

Vim not as customizable as MacVim — MacVim users take note.

Likely higher overall overhead and impact to the pair.

Still using Screen Sharing.app for some tasks, but awkwardly.

Keep reading for more details.

Switching Offices: Hello Lag!

As a remote developer I work with one of our physical offices on software projects. Often, my “base” office changes when I switch projects. I switched offices once again for my current project, where elusive network gremlins have taken up residence. The upshot: my preferred screen sharing solution, Screen Sharing.app, is too laggy for maximum productivity.

Enter tmux + Vim

My new project adopted Vim (well, MacVim) as the code editor of choice. Other remote developers on our team had already established tmux + Vim as the remote pairing tech for this project for terminal-based tasks, such as coding, managing servers, and running tests, and Screen Sharing.app for GUI-based tasks. I jumped on the bandwagon.

tmux + Vim: The first 14 days

Here are my initial thoughts on the tmux + Vim remote pair coding combo. I’m planning on posting follow up articles as time goes on.

What Lag?

The first thing I noticed is that there is very low network lag when using tmux. Low network lag is tmux’s #1 win for the remote developer. Network lag using Screen Sharing.app + MacVim was very frustrating.

MacVim is Vim

MacVim is Vim. Switching from MacVim to Vim was an easy transition… mostly.

MacVim is not Vim

MacVim isn’t Vim. We have tweaked our .vimrc to use the ⌘ (Command) key, which doesn’t work for tmux + Vim because ⌘ is handled by OS X instead of Vim running in the terminal. We added additional key mappings that mimicked MacVim’s ⌘+[whatever] to <leader>+[whatever]. We had also set up MacVim to have different background colors for insert vs. navigation mode; we lost that, too.

tmux Overhead

tmux lets you share multiple terminal windows, but with that that comes with some additional overhead. You have to enter a special tmux-command-mode to manage tmux, such as creating, switching, and closing shared tmux windows. There aren’t too many commands to remember (or reference) — print out the excellent “$ cheat tmux” cheat sheet.

Scrolling Sucks

It really does. tmux’s scrolling buffer is not the same as your terminal’s scrolling buffer. You have to enter tmux’s goofy “copy” mode and use the movement keys to scroll around. Control+c exits this mode, which is counter-intuitive, especially if you are scrolling through the output of a foreground-running program which you would also exit using Control+c.

Impacting my In-Office Pair

I’m particularly sensitive to my impact on my in-office pair. Maybe that’s the Idaho in me — don’t be a burden. Ideally my pair has to make minimal changes to accommodate remote pairing: Skype and a headset. This is one of the reasons why I like Screen Sharing.app. As you can see from the list above, MacVim users switching to tmux + Vim have to make quite a few adjustments, albeit small adjustments.

Using GUI Tools

Coding isn’t everything. My pair and I tweak and reload our site dozens of times per hour, do research, look at design mockups, check Pivotal Tracker, and perform countless other non-terminal tasks throughout our day. tmux doesn’t help those tasks.

The Secondary Monitor

I still use Screen Sharing.app to perform GUI tasks on my pair’s computer, though in a somewhat awkward way. Our workstations have two monitors: one used for the main coding windows, the second for everything else. I use Screen Sharing.app to view my pair’s secondary monitor, which has the web browser loaded with our ever-changing site under development, Tracker, and other stuff. The problem is that I cannot see the OS X Dock, or see the application-switcher when I press ⌘+tab, a key-press I use habitually. In other words, it’s hard for me to switch apps on that secondary monitor.

Here’s another frustration: When I switch to Screen Sharing.app and see my pair’s browser, I automatically press ⌘+r to refresh the browser’s page. The problem is that the browser is not actually my pair’s foreground application — Terminal or iTerm is, since he’s been coding in Vim with me. ⌘+r messes up my pair’s Terminal/iTerm screen every time. I’m forcing myself to always use the “reload” browser button instead.

I’ll post a follow-up in a few weeks outlining the tmux + Vim learning curve and any changes we’ve made to our process.

Resources and Links

tmux

vim

cheat gem – command line cheat sheets

tmux cheat sheet

Other developer’s blog posts about tmux + Vim or screen + Vim:

Remote Pair Programming with Screen and Vim – haruska.com

Remote pair programming with GNU Screen — blog.bigsmoke.us

Remote pairing with GNU Screen and Vim – tooky.github.com

Love, hate, & tmux – robots.thoughtbot.com

Remote pair programming – jpmelos.com