Remote/Pair-Programming in-the-cloud

[Chris Angelico]

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"?

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.

> > 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.

> >>> 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'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.

ChrisA