On 3/08/19 5:50 PM, 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:
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 this thread others, have been looking at NAT and broker
arrangements. It has been v.interesting to read.
If it is a corporation's project, then this is an option. The business
of choosing ports and opening firewalls is a (?mere) matter of
standardisation and coordination. (cough, cough, mumble, mumble)
However, if we are talking about a public product, eg TeamViewer; then
ease of operation comes to the fore. (much though I disagree with what
amounts to an abuse of port-80 - specialists trying to 'manage' Internet
traffic must really have things to say about such)
The reason I mentioned "TeamViewer" (and A.N.Other mentioned BitTorrent)
is that client-server is so much easier to implement - even if (using
this example) the two (pair-programming) start as clients to some
central server, but later comms are 'delegated'/re-directed to become
peer-to-peer or go-direct. In the case of TV, which I use in (unpaid,
much put-upon, family - you know this song!) 'technical support' mode,
both the one seeking help and my own computer have to separately log-in
to the TV system, the second asking to connect to the first...
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.
I can't see the r/o version in pair-programming - although 'elsewhere'
people have mentioned programmer interviews, so maybe that's it.
In pair-programming both have a contribution to make. The key, requiring
both technical and social/inter-personal considerations (see discussion,
elsewhere), is to understand one's current rôle, and to have a clear
'break' when 'swapping seats' - in radio, that is the reason for
finishing with "over" (cue Leslie Nielsen sketch), and on a ship's
bridge there is a clear announcement, eg "Fred has the conn", so that
'everyone' knows who's in-charge 'now'!
To me, that is mostly an inter-personal communications issue. I don't
really want 'some computer' deciding when and what I might do. Others
might prefer the opposite.
Also, there are scenarios when both (of the pair) might be contributing
by 'coding' concurrently, eg one writing tests and the other code, or
one writing one class and the other a second. (but you can debate if
that is "pair-programming")
Python's philosophy already covers this with: "we're all adults here"...
(see also 'trust', below)
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.
As above, using a client-server relationship, thus TLS/SSH are
relatively natural, and certainly common, components of the whole.
OT: the world of certificates has been revolutionised by LetsEncrypt.org
and their free services.
I assume a level of trust. Why would you pair-program with someone
untrustworthy? Either you're a team or not!
That said, and thinking back to the different scenarios (above), I can
see the r/o option being useful in such a case. For example, some of my
stats clients like to run through the code. It's a form of
checking/testing, so I don't mind - they read (the math of) code far
better than they can write/structure it! However, I definitely don't
want them modifying anything, even if an error is found or a change
requested. I want to be in-charge!
(stamps foot...)
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.
+1
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.
I've debated this issue (in fact wrote a paper on the subject) from a
pedagogical perspective (but in my own training area, not Python):-
Is it acceptable to train folk to code (in a particular language)
without also covering the likely tools they will (also) use?
So with Python, during the first lesson we could jump straight into a
one-line print( "hello world" ) program using the REPL. However, an
editor will be employed as soon as we want our code to persist. So
should we (immediately) promote the use of a professional editor/IDE, eg
PyCharm, Sublime Text, Codium, Eclipse; or a 'traditional' character
editing tool, eg Vi, emacs?
(please no 'religious wars' just because I mentioned both in the same
sentence!)
The problem is that the trainee wants to learn Python (or whatever) and
a full-fat editor has a steep learning curve. Learning the editor, which
should be secondary to learning the language, either starts to 'take
over' or is an huge distraction from the primary learning-objectives!
What about Thonny* then? A simple editor. Some nice debug features. Some
useful 'illustrations' to show what's happening under-the-hood. An
excellent product! Trouble is, who uses it 'in real life'?
So, are we thus contemplating jumping from the REPL to 'a simple editor'
(to ameliorate "cognitive load"), but later have a professional
responsibility to our trainees (and their eventual employers) to move to
'something real'...
* I deliberately avoided mentioning Idle (a) I don't want Terry to think
of himself as a 'target', and (b) I don't know Idle to be competent to
comment!
OTOH remember that this thread started with a PUG Code Evening as the
single use-case. It has broadened since (per above). One aspect that
many of the 'solutions' listed in the original post, seemed to be aiming
to cover was 'education' or 'classes'. Perhaps Idle is aiming at that
use-case?
Certainly I'd agree that more-and-more of our training should be enabled
via Internet - but then (heavy disclaimer!) I would say that! However, I
fear that the needs of pair-programming do not match particularly well
the needs of a class 'broadcast' use-case - and this shows clearly
amongst (my) rejects!
Another use-case (for Idle) which may not be sufficiently
thought-through, is that evidenced by many of the questions which appear
on this list: 'Fred' has written some code, it fails in some crucial
aspect, he can't see why, and requests 'more eyes'. How often is the
code attached (and then stripped by the mail-reflector)? How often does
someone put the code into their msg but then refer to a lineNR? (and, of
course) do I need to mention "indentation"? How about a version of Idle
which allows such supplicants to 'post' their code, and for list
contributors to be able to run/test/amend same? Might this be a valid
extension of an "editor" in this geographically dispersed and
asynchronously operating world? (see also JSfiddle (etc) in the
JavaScript world) I suggest that there is a lot of scope for re-thinking
just how training, and more importantly/relevant to this list,
"learning", can take place in this ?brave, new, world...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
