Remote/Pair-Programming in-the-cloud

[DL Neil]

On 3/08/19 4:02 PM, Terry Reedy wrote:
> On 8/2/2019 4:52 PM, DL Neil wrote:
>> On 3/08/19 8:32 AM, Terry Reedy wrote:
>>> On 8/2/2019 5:10 AM, DL Neil wrote:
>>>> Please recommend a Python-friendly, bandwidth-respectful, (but 
>>>> effective) system for pair-programming; where the 'pair' are 
>>>> geographically separate.
>>> 'geographically separate' could range from in the same room to a 
>>> continent away, as long as two people have separate keyboards and 
>>> screens.
>> True! As long as the tech works...
>> My experience has always been two sharing one PC, ie 
>> taking-it-in-turns to think or to type. Do you do it differently?
> 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"?

What I had in-mind, and others may see it differently (and I will 
happily modify any contribution to whatever an individual PUG attendee 
might need!) is more-or-less the sort of practical question we see on 
the list/one hears in a dev-lab, all the time, eg 'why doesn't 'this' 
work?', or 'how do I...?" but with the advantage of the conversation 
taking-place in real-time. If the answer is trivial, that's it. 
Something more-involved however, may require a detailed look at the 
code, or 'sitting and watching' whilst the other starts to include some 
new 'suggestion' into their code-base. That takes us into the synergies 
offered by pair-programming...

Use case: (possible examples)
(The meeting organiser talked about a project involving Solid ID)
- let's suggest the project hasn't started to-date. Perhaps he would 
download the code and start coding an enquiry against the API. Meantime 
I could be writing some Tests.
- he starts work, but the API doesn't respond in the expected manner. He 
asks me to 'take a look', so I read the code, scroll around, ask 'why' 
or 'why not' questions, and within the conversation we decide an 
alternative approach

The former, strikes me as a possible contribution to the PUG mtg, but 
the latter is more "pair programming" mode.


In the case of Wednesday's PUG meeting, my personal goal is to offer 
encouragement. If that involves 'full' pair-programming I would like to 
be ready - if it involves more simplistic contribution, crest la vie - 
if we can find some new approach which 'shoots for the moon' then all my 
dreams will come true...


>>> IDLE is Python-friendly, free, and FOSS.  I wonder how hard it would 
>>> be to pair programming connectivity as an extension.
> 
> This was an initially pie-in-the-sky idea that cannot solve your 
> immediate problem.  But I think now that something useful could be 
> feasible sometime.

(with all due apologies)
I haven't touched Idle in years (probably v2.n - and n<5 at that). Can't 
remember if I did something which impacted the Idle environment, or if 
it was because I was doing a lot of web-work. Regardless, even after a 
quick scan of the v3.7 PSL docs, I don't know what I'm talking about!
(as if that's anything new)


>>> 1. Do the systems you have considered operate as an editor + 
>>> satellite terminal or as synchronized peer editors.
>>
>> Always the former, the local devices are merely 'repeaters' (through a 
>> web browser) of what is happening on the server. This at both edit and 
> 
> 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.


> IDLE already intercepts keypresses to do syntax coloring and smart 
> indentation (after \n).  It should not be too hard to also send through 
> a socket anything sent to a tkinter/tk text widget.  Making a text 
> read-only is trivial.

Sounds like the sorts of things Linux's X-server does/did.


> With a real editor as satellite, the locally configured font face, font 
> size, and syntax highlight colors can be used.  Transmitting 
> highlighting as text would require the invention of a protocol to 
> differentiate text from such meta information.
> 
>> run/test stages.

Yes, important to remember that the editor is only one tool, and that 
pair-programming may involve kicking-off a 'run' from the cmdLN or 
browsing a page from the web server (etc).


> Running code locally would
> 1. Save bandwidth.
> 2. Allow two users to do different things occasionally.
> 3. Reveal OS dependencies if on different systems.  When patching IDLE, 
> I would love to have my Macbook set as a satellite to check that code 
> works on Mac as well as Windows.

Good idea! Websites frequently use services which show how different 
browsers (and versions) will display the same web page.


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


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


Some of the cloud services I've reviewed present a screen very similar 
to a GUI editor one might use on a (local) PC. Others offer a BASH cmdLN 
and thus the Python REP. (I haven't tried calling for Idle, and maybe I 
should - some have listed VI[m], EMACS, or even Nano. Thus, it may be 
that a GUI-based service suits some coders, whereas others would prefer 
the more character-oriented approach...


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...
-- 
Regards =dn