REAL WORLD SCENARIO (blinking lights)
Mr. Tom Dev wants to remote pair program with Mr. Todd Programmer. Tom is in New York, Todd is in San Francisco. They’re working on yet another blog written in Ruby. Tom fires up Rubymine, Todd fires up TextMate.
Todd’s editor quickly alerts him that he is connected with Tom and that their projects are out of sync. The plugin gives them each the option of using Tom’s file versions, Todd’s files, or performing a git pull request. They both do a git pull and are back in sync.
Todd quickly opens the User model in Rubymine with cmd-shift-N and Todd quickly sees that same file opened in Textmate. Todd then highlights a method that has been failing a test and Tom sees that highlight. Todd makes the change to the file, clicks cmd-s, and that file change is synced over to Tom.
Tom thought there was a secondary change needed in the Profile model, so he hits cmd-T, opens the Profile model and Todd sees that file opened in Rubymine. Todd tells Tom that he’s smoking catnip, that the bug he was referring to was closed weeks ago.
Todd wants to show Tom what the blog looks like so far. Todd is running a local Rails instance. Luckily Todd’s Github plugin is signed in to the Github tunneling service, so Tom simply visits http://coolblog.github.com:3000/users/index and he’s able to view Todd’s local Rails instance. Todd and Tom tweak CSS all night long. Tech ecstasy.
Remote pair programming is difficult. Screen sharing applications are laggy. TMux with vim are challenging to setup and confine the user to utilize a strip down editor.
Github is at the forefront of social programming and has a chance to take remote pair programming to the next level. I propose the following features:
1) A intermediary service that sends and receives high level actions from common development editor environments and sends/receives them between two connected developers.
2) Develop a series of plugins for the most common development editors; Eclipse, Netbeans, Rubymine, vim, Textmate, etc, that observe the programmer’s actions within the editor and sends/receives those actions with the service outlined in item #1.
2a) The plugin scans the opened project and sends the directory structure to the other remote developer so that inconsistencies in project files can be accounted for (e.g. the remote dev hasn’t done a git pull so his checksums are different relative to the other remote developer).
3) The plugin recognizes local file changes and automatically syncs them with the other remote developer.
4) Provide a tunneling mechanism that allows for easy, local sharing of remote webserver instances (similar to http://progrium.com/localtunnel/).
ADVANTAGES :
- Developers get to use their favorite environment with their favorite key-bindings.
- Speed; just sending file open/closes/switches would be much faster than sending entire screen updates.
- The tunneling interface would provide a simple way for both developers to see either person’s work.
DISADVANTAGES :
- This setup is primarily geared towards web developers.
This is exactly the kind f thing I dream about. Squinting at the compressed JPG screen share is obnoxious and I spend more time checked out and doing something else then actually pairing. I like VIM and my partners like Textmate. So my driving is slower than 🐶 💩 rolling up hill in February.
If there's any headway on finding a technology stack that helps reach the epitome pairing experience you described please offer some links / insight. Thanks.