Remote Pairing: SOCKS Proxy

I’m a big fan of remote pair programming. The problem I often run into is the need to share a web browser. In the past I have always jumped strait to a screen sharing tool like or TeamViewer. The problem here is these technologies tend to use quite a bit of bandwidth.

The solution recently I have found is to use a SOCKS proxy to the hosting machine.

The proxy allows us to tunnel our traffic through that person’s machine and therefore allowing you to access things local to them like a VM which may not be publicly accessible.

This solution also has the added benefit of the remote pair not needing to do anything but have an ssh server running.

To start a tunnel we’ll need to use the following command but with some substitutions:

$ ssh -p pairing_server_ssh_port -N -D 9999 ssh_user@pairing_server

Let’s explore this ssh connection string!

First the -p flag followed by the port your pair is running their SSH server on. This flag is optional if your pair is using the standard port 22.

Next we include the -N flag which which tells ssh client to not execute remotely which keeps the process running in our shell allowing us to close the tunnel with a ‘Control+c’.

After that another flag is the -D which actually is the SOCKS proxy flag. This flag takes a port number as an argument. This port number needs to be open on your machine. It is the port that your browser will connect to to tunnel traffic to your pair’s machine.

Then we’ll need to finish filling out the username and server information.

Once you have the command filled out hit enter to start the tunnel running.

After our tunnel is running we just need to configure our browser to use the SOCKS proxy.

The easiest browser to setup for a SOCKS proxy is Firefox so we’ll need that installed on our machine.

Next we’ll need to open Firefox preferences and navigate to the ‘Advanced’ section (1). Once there we’ll want to go to the ‘Network’ preferences (2) and choose the ‘Connection’ settings (3).

Now we’ll specify the Manual proxy and host for the SOCKS server as seen below:

After clicking OK and closing all the preference windows you’ll be able to use Firefox to browse the web through your pair’s internet connection. Like always when remote pairing, etiquette is key and make sure you are using this browser for activities that you need to and not for internet searching, email, etc. All of your traffic for this browser will be going over this tunnel and through your pair’s machine.

Using this tool in-conjunction with Joe Kutner’s Remote Pairing: Collaborative Tools for Distributed Development tmux pairing setup will give you a very low bandwidth solution to web development remote pairing.

TCCC12 – Pair Programming recap

I recently I had the opportunity to share a passion of mine at Twin Cities Code Camp 12.  I gave a presentation, “Pair Programming Techniques”, where I shared my experiences of pair programing including things I found to great and things that are not so grate. This presentation was one of my favorites as it had a great amount of audience participation. I will attempt to share this information in a series of blog posts.

Pair programming is the act of working on a focused task with someone.  I’ve seen it be a productivity booster, we’ve all had times where we just hit the preverbal wall while working on something.  I always found that explaining my situation to someone else would help me get over this block and get back to work.  Imagine having that person right there working on the task with you. Sure I’ve been in situations where both of us in a pair got stuck but that is a rarity.

While pairing I tend to notice that I am getting a real time review of the code I am writing.  I like being able to discuss code while it is written, giving me a chance to learn and teach all while getting things done.

Pair programming is not the silver bullet, it’s not going to solve all your problems or make your team’s velocity jump a hundred and twenty percent.  It’s not just for twenty something hot shot developers, working at the latest startup.  Even though you have two eyes working on the codebase doesn’t mean bugs are going to get through. Pair programming is like the old saying “measure twice and cut once”, which doesn’t mean you are going to cut every board perfect but it it limits your possibility of a defect.

In todays work place it is common to have people in the office along with remote employees.  Just because someone works remotely doesn’t mean that they can’t pair and have to work alone.  There are advantages and disadvantages to both situations.

Pairing locally has many advantages, most of which have to do with being in a physical environment. When you are working locally you have the ability to better read your pairs body language, you can grab some paper and sketch out some ideas.

Sometimes pairing locally can have some distinct disadvantages too.  There are big things like sickness, working in a very close environment makes it easy to pass things to each other.

Working remotely solves the sickness issue and allows both people to pair and not worry when they have a simple cold.  I have found myself enjoying remote pairing in this situation.  While you don’t have some of the physical amenities that you would in a normal office setting, video chat and screen sharing comes pretty close. I have spent time working remotely at previous jobs and have found that human interaction is something that I need. Pairing remotely gives you someone to talk with, share your ideas and get feedback from.

While pairing remotely is great during the height of flu season, and with video chat and screen sharing you can almost see everything there is still a great deal of communication that needs to take place for the pair to be effective. Bandwidth is a major downfall of remote pairing, I live in a location with a slower DSL connection and I have to prioritize the tools I use when remote pairing.

Look for follow up blog posts about different styles and tools for paring locally and remotely.  I’ll cover some of the techniques I have learned and developed since I started pairing.

Pair Programming with Tmux

This morning I decided to try out a new pairing setup.  What I did was setup a machine that can be accessed by both developers and installed tmux.

Tmux works like screen where it creates sessions that you can attach multiple users to.  It also allows you have a few open buffers so you can do things like have one buffer open for Vim and another to run your Rails Server.

So we have taken advantage of the ability to attach multiple users to a session and then had each developer attach via ssh from their local machine.  We haven’t configured tmux beyond the basic install but it seems to be working good.

One nice thing is each developer can SSH back into their local box from a separate buffer and have access to files on their local machine if need be.