osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Remote/Pair-Programming in-the-cloud


On Mon, Aug 5, 2019 at 8:54 PM DL Neil <PythonList at danceswithmice.info> wrote:
>
> 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...

Sometimes there can be magical firewall penetration tricks that allow
the traffic to go peer-to-peer after an initial handshake with some
central server, but this has its own problems. On any network that I
control, such tricks are disabled; if you want to listen to
connections from the outside world, you get my explicit permission and
an actual line in the firewall configs.

> 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")

No, that's not pair programming. That's collaboration on a project,
but it's not the sort of thing where you need to see the other
person's screen.

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

That's fine if one end is a dedicated server.

> I assume a level of trust. Why would you pair-program with someone
> untrustworthy? Either you're a team or not!

What about poisoning the channel externally, though? If you can't
directly connect a TCP socket between the two peers, the traffic will
have to go out on the internet.

> 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!)

At my work, we instruct students on how to set up one particular tech
stack, including an editor, linter, source control, etc, etc. We're
clear with them that these are not the only options, but for the sake
of bootcamp time pressures, we aren't going to show them any others.

Depending on what you're trying to do, it MAY be acceptable to teach
just the language. But that won't make someone employable on its own.

Like everything, "it depends" :)

ChrisA