Remote/Pair-Programming in-the-cloud
DL Neil
PythonList at DancesWithMice.info
Fri Aug 2 17:28:30 EDT 2019
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
More information about the Python-list
mailing list