Remote/Pair-Programming in-the-cloud

[DL Neil]

On 3/08/19 8:44 AM, Chris Angelico wrote:
> On Sat, Aug 3, 2019 at 6:34 AM Terry Reedy <tjreedy at udel.edu> wrote:
>> On 8/2/2019 5:10 AM, DL Neil wrote:
>>> Please recommend a Python-friendly, bandwidth-respectful, (but
>>> effective) system for pair-programming; where the 'pair' are
>>> geographically separate.
>>
>> 'geographically separate' could range from in the same room to a
>> continent away, as long as two people have separate keyboards and screens.
> 
> Though there may be differences between LAN-optimized tools and
> internet-optimized ones.

Correct! Koding (on my ToDo list for today) no longer offers a web-based 
service but offers a download for Docker or Kubernetes (or ???). The 
communications lag has been my biggest concern since we opened the 
investigation...


> Not the OP, but weighing in from personal experience: I've often pair

I'm hoping for more responses recounting personal experience, especially 
if it involves a stern warning for my sanity!
(oops, too late!)


> programmed using just a video call service (with screen share). The

TeamViewer, and similar?
I didn't mention this earlier, perhaps being carried-away by my 
enthusiasm for 'there must be a better way'...


> biggest downside is that it has to share the full image of the screen,
> which means it has to aggressively compress the video in order to
> handle home-grade internet connections. (OTOH, that does mean that
> it's IDE-independent, and can showcase literally anything.) If IDLE
> were to grow a peer-to-peer pair programming feature, I could imagine
> it being a text-only connection with a single master and any number of
> slaves, where the slaves are showing a replica of the master's screen.
> IMO the slaves should not need any way to directly manipulate
> anything, though it may be of value to be able to highlight a block of
> text and have the master see that highlight (independently of the

I have used VNC-type software to slave screens, either in pairs 
(tutorial - mine following a trainee's work) or in a 'class set' (using 
my screen as a 'projector'). It seemed both finicky and fragile and 
whilst working well on-the-LAN (ie in-class), was too slow and 'block-y' 
updating the screens when we used it for remote tutorials. (of course 
such [also] reveals that we didn't have very high-speed connections)

During such, the VNC profiles were set so that trainees' I/O devices 
were 'locked' to prevent clashes. However, that need doesn't apply here 
and is actually contrary to the objectives...


> master's own text selection). Having everyone able to edit
> simultaneously creates technological problems, and then a social

One of the encouraging features of many options (on list in earlier 
post) is the facility of "multiple cursors".

At first this confused me, because many text editors allow one to 
declare "multiple cursors" in order to perform the same action at 
multiple locations throughout the same source-file. In the 
pair-programming context, "multiple cursors" means exactly what you say: 
each contributor is able to work (relatively) independently of the 
other, and the system keeps track of who-is-doing-what! ("IDE-independent"?)


> problem (when you start trampling over each other's code by mistake),
> and the solution to the social problem usually amounts to a semaphore
> system "okay, you go ahead and take over"; baking that semaphore into
> the technology (by having only a single master) would keep things way
> simpler.

Which is why I assumed the need for Zoom or similar audio connection 
(A/V 'on top' likely to overwhelm a wi-fi link)? None seem to offer 
that, however some do provide a "chat" window.

Yes, the "semaphore" is going to be my biggest concern on the night. 
When done in-person, a lot can be communicated non-verbally (and, 
perhaps particularly in this country: rather informally, eg even a nudge 
of the elbow = 'move out of the way and let me in/I got this').

I'm thinking that such will require a greater degree of formality and 
courtesy. Radio operators are used to the discipline of letting the 
other person finish talking...

Contrarily, that might be handled by agreed rôles and 'separation of 
concerns':- Many of these services store the source code (etc) 'in the 
cloud', plus each contributor can share or have his/her own editor 
screen (your "IDE-independent", above). So, it would also be possible 
for one to be designing tests concurrently with the other writing code. 
However, perhaps we're getting away from 'traditional' pair programming, 
and into the area of 'just because the technology enables us do it, 
doesn't mean it's a good idea'! OTOH the whole point of this 
investigation is to see what's 'out there' and be open to whatever if 
might enable us to do...


Thanks for your wisdom.
-- 
Regards =dn