Remote/Pair-Programming in-the-cloud
Terry Reedy
tjreedy at udel.edu
Sat Aug 3 14:44:56 EDT 2019
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
More information about the Python-list
mailing list