Remote/Pair-Programming in-the-cloud

[DL Neil]

On 3/08/19 5:50 PM, 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:
>>> 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