Remote/Pair-Programming in-the-cloud

[Terry Reedy]

On 8/3/2019 1:50 AM, Chris Angelico wrote:
> On Sat, Aug 3, 2019 at 3:36 PM DL Neil <PythonList at danceswithmice.info> wrote:
>>
>> On 3/08/19 4:02 PM, Terry Reedy wrote:
>>> I currently work on my home machine, so my recent 'pair programming' has
>>> been limited to comments and now diff suggestions on Github PRs.  So I
>>> need the comments on real use cases from you and Chris to even think
>>> about something for IDLE.
>>
>> Is that really "p-p" or more "code review"?

The latter.  The quotes here mean "the closest I currently come to pair 
programming".  I have often *wished* for live interaction instead.

> I'd say that, no, commenting on GitHub PRs is not "pair programming".
> It's a different form of collaboration. Pair programming specifically
> refers to two people working in realtime on one project.
> 
>>> Good.  Master-satellite would be much easier.  We added line numbers to
>>> IDLE's editor last week, so verbal feedback from satellite to master
>>> should be sufficient for many purposes.
>>
>> Elsewhere in the thread there is much discussion of this. Regardless of
>> the "we are all adults here" philosophy, my feeling (stuck-in-the-mud
>> though it might be) is that one person/system has to have 'control', and
>> the other, the 'pair' (or the 'tutor') is invited to see/do 'whatever'.
>> However, r/o would be a show-stopping limitation.
> 
> When pair programming involves training (tutor and student, or senior
> and junior programmer), forcing the more experienced person to stay
> hands-off is a very good thing; it forces the less experienced person
> to actually keyboard every change, and thus is more likely to
> understand what's going on. But when it's two peers, you'll often want
> to switch out who's in control. Depending on the architecture, this
> might be a simple matter of flipping a switch and changing who's
> master and who's on a read-only clone.

Since master and clone are copies of the same program, switching roles 
should be simple, and easier than trading seats.

>>> 4. Require encryption of some sort if over the public internet.  Just
>>> because people download code from strangers over http is not a reason to
>>> encourage carelessness.  I am pretty ignorant on what this would mean.
>>
>> TLS?
>>
> 
> TLS doesn't really solve this problem. If you have a single central
> server, TLS just tells you that you're talking to that server, without
> proving anything about who's on the other end. Even if you directly
> connect the two nodes, TLS wouldn't prove who that is, unless you get
> a dedicated certificate. What it *can* prove is that your data stream
> hasn't been tampered with en route, but the problem of receiving code
> from strangers is still an issue. Ultimately, pair programming depends
> on a measure of trust - you have to be confident that the person
> you're pairing with isn't going to be maliciously messing with your
> system.
> 
> However, I think it would be an extremely useful feature if the output
> from running the program could also be replicated to the other client.
> Let's say you're developing a Python script that connects to a
> database (eg psycopg2 + PostgreSQL). To run that locally, you'd need
> your own replica of the database, and that often means having your own
> credentials (ie having the script able to choose which set of
> credentials to use), replicating the database schema, and possibly
> even getting a duplicate of the current table contents. Way WAY easier
> to just run it on one computer and copy the output.

I did not think of this scenario because I don't currently program with 
external libraries and DBs.  Sending output seems to be a must, with 
running delivered code an option depending on trust and code review.  It 
does, however, require a control message to switch incoming text from 
editor to shell.

>>>>> 2. Do two systems connect directly peer-to-peer or through a server?
>>>> Exclusively the latter (thus far in the investigation).
>>>
>>> The former would be the only option until someone (else) set up and
>>> supported a server.
>>
>> Except that when you think about it, were I viewing your screen, your
>> m/c would indeed be a "server"! We could lose potential by arguing
>> semantics (not my intention). In fact, we dealt with this point, above.
> 
> There's a difference between the conceptual and the technical here.
> The NAT issue may mean that, for technical reasons, a broker is
> needed.

I believe bittorrent somehow deals with the issue, but I don't know how 
much a broker is used after the initial seeding.  I believe some 
player-hosted multiplayer games run peer-to-peer after the initial 
introduction, but I don't know for sure.

Restriction to local networks might have some use.  There have been 
programming classes where a teacher uses IDLE projected on an overhead 
screen.  In at least some cases, a large type size (25-40) is needed. 
It might be nicer to deliver to each students computer.

>> I'm thrilled at your interest, but am ignorant/uncertain that
>> pair-programming and Idle go together. To which you may say that perhaps
>> they should... In which case, I'd recommend taking a look at some of the
>> services (listed at the beginning of this thread) to first establish
>> 'virtue' and yes, I'll try to do a better job at roughing-out some
>> use-cases with you...
> 
> I think Idle could be a very useful pair programming tool, but that
> doesn't mean it'd be the best option available. IMO it could be an
> extremely light-weight one, though.

-- 
Terry Jan Reedy