Remote/Pair-Programming in-the-cloud

[Chris Angelico]

On Sun, Aug 4, 2019 at 4:46 AM Terry Reedy <tjreedy at udel.edu> wrote:
>
> On 8/3/2019 1:50 AM, Chris Angelico wrote:
> > 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.

Should be indeed, though having accidentally painted myself into a
corner on many occasions, I would say it's worth writing this down as
a goal all the same :)

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

Rather than having such a control message, perhaps it could be
possible to have any number of "target window" channels? So you could
have two editor windows and a shell, or even multiple shells, if Idle
can do that in one process. I'm not sure how Idle's architecture is;
in my experimentation, I was only able to get a single execution
window.

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

Hmm, bittorrent's broker is just for finding peers - it doesn't
actually transfer any content. I'm pretty sure two behind-NAT torrent
clients are unable to communicate unless one of them has a port
forwarded to it.

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

The easiest way would be to have the main Idle engine able to listen
on a socket OR connect to one, and then "restricting to LAN" is simply
a matter of managing it in your firewall (or, in the case of many NAT
networks, simply a matter of doing nothing).

The broker would be a basic echo server, and if desired, it could
handle encryption (TLS). Since there would potentially be many
concurrent Idle replications happening, there'd need to be some sort
of "room name" or something, but it could still be very simplistic.

This would be a very cool feature, especially since it could bring
ultra low latency pair programming even to people on mobile
connections.

ChrisA