On 8/3/2019 1:50 AM, Chris Angelico wrote:
On Sat, Aug 3, 2019 at 3:36 PM DL Neil <pythonl...@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
--
https://mail.python.org/mailman/listinfo/python-list
