Remote Pairing Setups (Architectures) Complete with Diagrams, Requirements, Software, etc.

[ChrisMcNabbSoftwareDeveloper]

I'd like to see a section of this "ppwm" repo with layout of various Remote Pair Programming Setups...including Diagrams, Requirements, Software, etc. ...with details on what's required and "how to" install and configure everything for that particular setup. It would be simple, clean and informative.

Purpose: The purpose of this would be when you find a remote pair partner and the two of you have now decided to pair on something, you now have to decided on HOW you are going to pair. In other words WHAT is your setup for the actual pairing session. If there's a place we could go to and quickly determine from the setups demonstrated on the section of this repo which setup to use, then the two pairing partners could agree on "SETUP #3", for example. Then, each pairing partner could make sure they both are setup and configured for SETUP #3, BEFORE the pairing session starts. Or, if they agree SETUP #5 would be easier for each of them, then they would settle on SETUP #5. They could do this initial conversation via email, or even twitter, for example. That way, when the time comes to start paring, all the "setup/configuration/keys/etc" would have already been done in advance and they are ready to have an effective pairing session.

For example, I started this diagram just to roll the marble around and see what popped out. This the kind of think I'm thinking about. This first setup could be named "Westley"...just for ease of referring to this setup by name. (I like using the names of the characters from Princess Bride.)

This pairing setup is the one I've been using for the last year now and it has worked out very well! I work from home and I pair everyday.

Notice from the picture I have sections on: tools, steps, pros, & cons. These were just my initial thoughts.

Thoughts? Feedback? Hate it? Love it? I'd love to hear what you have to say. Let's all jump in and have a discussion. Thank you!

[avdi]

I love this idea, and I especially love the idea of giving the different setups memorable names. It's like the beginnings of a pattern language of remote pairing. After @ChrisMcNabbSoftwareDeveloper ran it by me I asked him to file this issue for discussion.

I'd like to get a conversation started and maybe start identifying some of these setups.

@joemoore, @elight, @geeksam - I'm pinging you in particular. Thoughts?

Feel free to loop in anyone else I'm missing who has extensive remote pairing experience and might have something to add.

[steveklabnik]

This'd be super useful.

I've been doing a lot of #pairwithme, and it's been two ways:

1. ssh into a server and tmux/vim. vanilla.
2. one person shares the screen over google hangout, and the roles don't switch.

[elight]

3) Port forward from your router to a computer on your LAN, give the other developer remote access via public key, they SSH in, and tmux.

Though lately I've been doing a lot of number 1 (heh).

Yes, I believe this could be very useful to those who are unsure how to get started.

Better still: given the patterns, add recipes (even literal recipes as in "chief") to help people DIY.

[elight]

That is, I like that there are web apps trying to fill this space. But this same capability could made available freely via OSS tools that enable people to DIY. But I digress.

[geeksam]

Coincidentally, I'm scheduled to give a talk in June about remote pairing, and was thinking of covering different setups and the pros/cons of each. (Also coincidentally, I did an [internal-only] screencast using "Humperdinck" and "Buttercup" as names.)

A large part of why we set up ls-pair was just to establish a standard setup so that we could walk new people through "clone the repo, run the script, install this Hamachi thing, and type this command" in five minutes. Then, if needed, ten minutes of tmux orientation and another 10-15 of vim orientation, and you're good to go. Otherwise one spends way too much time on initial setup, which can be frustrating.

So, yes, I think this is a fantastic idea. I'll try to find some time to diagram the ls-pair setup and, if nothing else, add it to the docs there. (=

[chrishunt]

This is one way to get pairing with Avdi on either of the two setups mentioned.

Me:

$ su - pair
$ gh-auth add avdi
$ curl http://remote-ip.herokuapp.com
98.146.126.33

Avdi:

$ ssh pair@98.146.126.33

We're both in the same tmux session automatically because of .zshrc:

# Always work in a tmux session if tmux is installed
if which tmux 2>&1 >/dev/null; then
  if [ $TERM != "screen-256color" ] && [  $TERM != "screen" ]; then
    tmux attach -t pair || tmux new -s pair; exit
  fi
fi

[elight]

If we're talking about patterns, let's not forget the tried and true "2 people figure out where to meet then work in front of the same computer" ;-)

[geeksam]

@elight Funny you should mention. I've found that remote pairing tools also make in-person pairing feasible in a wider range of physical configurations. See slides #45-51 at: http://timestream.net/gschool_talk/slg-gschool-slides-with-notes-2013-02-08.pdf

[ChrisMcNabbSoftwareDeveloper]

Thank you so much everyone for your comments and your feedback, so far. This is great. geeksam - I'll be happy to draw up the diagram for you....no problem...I just need some details about the setup.....

[geeksam]

@ChrisMcNabbSoftwareDeveloper: two laptops, no cloud box. Host, in their own account, runs 'wemux start', which sets up a tmux server named 'wemux'. Guest connects to host laptop via SSH to a separate account and types 'wemux pair', which connects to the tmux server named 'wemux'. There are a few more steps detailed in the "preflight checklists" at https://github.com/livingsocial/ls-pair

[avdi]

Would it be fair to call this a variant of general self-hosted tmux/ssh workflow?

On Fri, Apr 26, 2013 at 2:20 PM, Sam Livingston-Gray < notifications@github.com> wrote:

@ChrisMcNabbSoftwareDeveloperhttps://github.com/ChrisMcNabbSoftwareDeveloper: two laptops, no cloud box. Host, in their own account, runs 'wemux start', which sets up a tmux server named 'wemux'. Guest connects to host laptop via SSH to a separate account and types 'wemux pair', which connects to the tmux server named 'wemux'. There are a few more steps detailed in the "preflight checklists" at https://github.com/livingsocial/ls-pair

— Reply to this email directly or view it on GitHubhttps://github.com/avdi/ppwm/issues/20#issuecomment-17091107 .

Avdi Grimm http://avdi.org

I only check email twice a day. to reach me sooner, go to http://awayfind.com/avdi

[rwjblue]

@pwelch, @rondale-sc, and I have been working on remote_pair_chef as a way to quickly get an EC2 instance running and configured with weemux, vim, rvm, ruby 1.9.3.

Once setup and run it will automatically add the ssh public keys from github (like gh-auth) for both the 'host' and 'pair', and setup the authorized_keys file to force either user into a shared wemux session upon connect.

We are also planning to support a local wemux/tmux connection tunneled through the remote EC2 instance (to avoid having to poke holes in your local firewall/router on the host side).

So I guess the two main setups that we are seeing/dealing with are:

1) tmux + (vim | emacs) on a remote system. 2) tmux + (vim | emacs) on a local system (using ssh tunnels to avoid firewall issues).

[elight]

This is a lot like how I was working except behind a firewall. Wemux is great.

On Fri, Apr 26, 2013 at 2:20 PM, Sam Livingston-Gray < notifications@github.com> wrote:

@ChrisMcNabbSoftwareDeveloperhttps://github.com/ChrisMcNabbSoftwareDeveloper: two laptops, no cloud box. Host, in their own account, runs 'wemux start', which sets up a tmux server named 'wemux'. Guest connects to host laptop via SSH to a separate account and types 'wemux pair', which connects to the tmux server named 'wemux'. There are a few more steps detailed in the "preflight checklists" at https://github.com/livingsocial/ls-pair

— Reply to this email directly or view it on GitHubhttps://github.com/avdi/ppwm/issues/20#issuecomment-17091107 .

Evan Light http://evan.tiggerpalace.com @elight

[elight]

Avdi: Sounds like a reasonable mouthful of a name. Simplicity is hard.

On Fri, Apr 26, 2013 at 2:32 PM, Avdi Grimm notifications@github.comwrote:

Would it be fair to call this a variant of general self-hosted tmux/ssh workflow?

On Fri, Apr 26, 2013 at 2:20 PM, Sam Livingston-Gray < notifications@github.com> wrote:

@ChrisMcNabbSoftwareDeveloper< https://github.com/ChrisMcNabbSoftwareDeveloper>: two laptops, no cloud box. Host, in their own account, runs 'wemux start', which sets up a tmux server named 'wemux'. Guest connects to host laptop via SSH to a separate account and types 'wemux pair', which connects to the tmux server named 'wemux'. There are a few more steps detailed in the "preflight checklists" at https://github.com/livingsocial/ls-pair

— Reply to this email directly or view it on GitHub< https://github.com/avdi/ppwm/issues/20#issuecomment-17091107> .

Avdi Grimm http://avdi.org

I only check email twice a day. to reach me sooner, go to http://awayfind.com/avdi

— Reply to this email directly or view it on GitHubhttps://github.com/avdi/ppwm/issues/20#issuecomment-17092048 .

Evan Light http://evan.tiggerpalace.com @elight

[elight]

@rjackson: :+1:

[geeksam]

Sounds about right. The main differentiator is that it doesn't grant pair partners unsupervised access to your login. (At least, assuming you disable wemux's "rogue mode".) -Sam

On Fri, Apr 26, 2013 at 11:32 AM, Avdi Grimm notifications@github.comwrote:

Would it be fair to call this a variant of general self-hosted tmux/ssh workflow?

On Fri, Apr 26, 2013 at 2:20 PM, Sam Livingston-Gray < notifications@github.com> wrote:

@ChrisMcNabbSoftwareDeveloper< https://github.com/ChrisMcNabbSoftwareDeveloper>: two laptops, no cloud box. Host, in their own account, runs 'wemux start', which sets up a tmux server named 'wemux'. Guest connects to host laptop via SSH to a separate account and types 'wemux pair', which connects to the tmux server named 'wemux'. There are a few more steps detailed in the "preflight checklists" at https://github.com/livingsocial/ls-pair

— Reply to this email directly or view it on GitHub< https://github.com/avdi/ppwm/issues/20#issuecomment-17091107> .

Avdi Grimm http://avdi.org

I only check email twice a day. to reach me sooner, go to http://awayfind.com/avdi

— Reply to this email directly or view it on GitHubhttps://github.com/avdi/ppwm/issues/20#issuecomment-17092048 .

[geeksam]

Right, firewall. I generally use Hamachi to get around those. :D

On Fri, Apr 26, 2013 at 1:27 PM, Evan David Light notifications@github.comwrote:

This is a lot like how I was working except behind a firewall. Wemux is great.

On Fri, Apr 26, 2013 at 2:20 PM, Sam Livingston-Gray < notifications@github.com> wrote:

@ChrisMcNabbSoftwareDeveloper< https://github.com/ChrisMcNabbSoftwareDeveloper>: two laptops, no cloud box. Host, in their own account, runs 'wemux start', which sets up a tmux server named 'wemux'. Guest connects to host laptop via SSH to a separate account and types 'wemux pair', which connects to the tmux server named 'wemux'. There are a few more steps detailed in the "preflight checklists" at https://github.com/livingsocial/ls-pair

— Reply to this email directly or view it on GitHub< https://github.com/avdi/ppwm/issues/20#issuecomment-17091107> .

Evan Light http://evan.tiggerpalace.com @elight

— Reply to this email directly or view it on GitHubhttps://github.com/avdi/ppwm/issues/20#issuecomment-17098158 .

[rking]

I think we're ready to start consolidating knowledge into.

Anyone have a preference for where this should go? Some options (and their benfits) include:

http://c2.com/cgi/wiki?RemotePairing

• Old school wiki has lots to teach us.
• RailsConf is in Portland, so we can kick it off with authenticity

FedWiki

• The future school has a lot to teach us, and we have a lot to teach it
• Also, Portland authenticity

This wiki on this repo which isn't enabled yet

• Handy, familiar to GitHubbers, ready to feed data elsewhere (git clone https://github.com/avdi/ppwm.wiki.git (or use as a submodule))
• Keeps it Avdi-branded, which is good because he's at the forefront of this discussion, and the credit for the result is largely his to hold or relinquish.

Documents in this Repo

• Tighter control
• Could be DRY'd more aggressively, for example it could be documentation that has a manifestation from a CLI tool's --help interaction, and the same content could be rendered on the Web with full graphics, etc.

Anyone has feedback on these or other ideas?

[joemoore]

Thanks for the invite -- sorry I'm late to the party.

I agree that the visual aids + memorable name will make it much clearer how different remote pairing setups work.

I'll post a few pattern here in a few more posts in lue of a wiki.

[avdi]

Agree that a wiki is the right way to work on these. Using the built-in one on this project seems logical to me. It looks to me like the wiki is already enabled; just to test I started a new page:

https://github.com/avdi/ppwm/wiki/PairingSetups

[rking]

@ChrisMcNabbSoftwareDeveloper - 1) Are you OK if we (or you, if you want) put the above into the Wiki somewhere? 2) What tools did you use? We should homogenize that a bit so we can get a nice, updateable look.

[ChrisMcNabbSoftwareDeveloper]

Sure. It can live in the ppwm repo wiki....that's fine with me. I'll get started moving over what I have so far and start adding the pieces mentioned do far. Everyone feel free to end me what you have and I'll consolidate it and draw the diagrams.

Chris McNabb Sent from my iPhone

On Apr 29, 2013, at 6:56 PM, ☈king notifications@github.com wrote:

@ChrisMcNabbSoftwareDeveloper - 1) Are you OK if we (or you, if you want) put the above into the Wiki somewhere? 2) What tools did you use? We should homogenize that a bit so we can get a nice, updateable look.

— Reply to this email directly or view it on GitHub.

[bf4]

bump? any output of this? wiki pages https://github.com/avdi/ppwm/wiki/_pages

[avdi]

Closing cuz stale