Distributed Pair Programming in distance education

Question

We've done pair programming for years with the rule of two kids, one screen, and the kids sitting next to each other. We have found this to be a tremendously valuable process.

Now that all instruction is distance learning due to COVID-19, are there virtual solutions that would allow our students to simulate something like this?

Answer 1

My suggestion would be to utilize seprate tools for elements of the process rather than try to find a packaged solution, or modify an existing tool which is 'not quite right' for the task.

Quick summary is:

• use Discord for communications, text and/or audio
  • Restricted channels for each pair to utilize while coding
  • Open channel for students to contact the instructor
• use the GoLive feature of Discord for the "driver" to stream their active IDE to the "navigator" (GoLive will stream a "terminal" window, it does not have to be a game.)
• use git to "lock in" the code between role switches with commits
• use GPG keys for signing of commits and to authenticate the SSH pushes
• use GitLab as the remote repository

Use Discord for communications

As the instructor:

1. Create a Discord server
2. Create a public text channel for the students to reach you in
3. Create a public text channel for the students to share in (you can monitor, but don't communicate here)
4. Create a role for each assigned student pair
5. Create a private text channel for each role above
6. Create a private audio channel for each role above
7. Enable each role to send/read messages, or connect and use GoLive, in the role-specific text and voice channels
8. As students join, however you get them to connect, assign them to the role which matches the assigned pairings

As the owner of the server the instructor will be able to read the chat in all text channels, hear the conversation in any audio channel, and view any of the windows being streamed. Instructor preference and style take priority, but my suggestion is to limit any messages sent by the instructor to the designated channel. Moderator type actions can, and of course should, be taken in any channel. Going remote still leave "classroom discipline" in the instructor's hands.

As the school term progresses, it's likely that pairs are reassigned frequently. Perhaps as often as each new project. Once a project is graded, the associated text channel could be reset, or removed.

Use git

While git may not be The one true source control system, it is a popular one. The command line use of it can be quite complicated, especially for advanced purposes. The basics of it, however, are quite manageable for students. GUI tools also exist, though I'm reluctant to endorse any one, or even recommend their use. With students learning to use git it is probably better for them to learn the CLI commands, which will work on any OS, and on any system with git installed. The GUI they learn might not work on the system they have to use later, for work or for advanced classes. The GUI probably won't work if they have to use SSH for any reason as well.

Using git, as long as both students have access to the repo, allows for one to make changes, commit the results, and pass control to the other when they switch roles. As an extra benefit, since the current "navigator" will have the last committed version locally, they can scan through the file(s) to review other parts while directing the "driver". Ensuring that identifier names and parameters are used correctly, for example, without disturbing the "driver" with those details, allowing the driver to concentrate on the section of code being changed.

As a benefit to the students, they'll have the ability to unroll changes that were leading down a dead-end. As a benefit to the instructor, each commit will be blamed to the student driving. Additionally, by following the diffs, it's likely that when the team gets lost in the weeds, the instructor can see what thinking started the problem, and help them to see the way out.

Use GPG keys

The "remote" aspect of this is challenging for instructors to "watch" the students work. Having to worry about who is doing the work and who is not only adds to the work load. Requiring that the students GPG-sign their commits can help with that some. Not only will the repository assign the updates to the user, it will also verify that the user claiming the updates is the same one who signed them. There is no encryption involved, just a signing of the commit to prove who made it. Using it, however, might require the students to install GnuPG on their systems. Encouraging them to do so shouldn't cause any issue, and it can be a good habit to develop for later as well.

The process of setting up a key for use with the git program, and for connecting to the remote repository is fairly simple. Even from the command line.

1. Generate the key pair to use. The key pair needs to have both singing and authorization capabilities.

gypsy@spellweaver:~> gpg --quick-generate-key "Student Name <[email protected]>" future-default auth,sign
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key A822359C643A77A4 marked as ultimately trusted
gpg: revocation certificate stored as '/home/gypsy/.gnupg/openpgp-revocs.d/11716FF672B9DD368C174F26A822359C643A77A4.rev'
public and secret key created and signed.

pub   ed25519/A822359C643A77A4 2020-03-19 [SCA] [expires: 2022-03-19]
    Key fingerprint = 1171 6FF6 72B9 DD36 8C17  4F26 A822 359C 643A 77A4
    Keygrip = 92F62A329D3CBBBE64BFA8DABC6F4348623AB256
uid                            Student Name <[email protected]>

2. The ASCII version of the public key will be needed when setting up the repository. This block will be copy-pasted to the repository within the user's account settings.

gypsy@spellweaver:~> gpg --armor --export A822359C643A77A4
-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEXnMHZxYJKwYBBAHaRw8BAQdAjh6qOGnp5b0GTNZEHL4wIrIljwxLlxfU8/F5
l8TZVNC0KVN0dWRlbnQgTmFtZSA8ZW1haWwubmFtZUBzb21lLXNjaG9vbC5lZHU+
iJ0EExYKAEUWIQQRcW/2crndNowXTyaoIjWcZDp3pAUCXnMHZwIbIwUJA8JnAAsL
CQ0IDAcLCgMBBAYVCgkICwMFFgMBAgACHgECF4AACgkQqCI1nGQ6d6RXEAD/Rdhz
kh+gNvnO367JYqdoIwFiIsW4a2mq3d4nqNE6migBAM3m8cMO2Ww2u5+O7l8P4GuI
EMTlK2WWckAEJUGS1pMO
=6LSb
-----END PGP PUBLIC KEY BLOCK-----

3. The public key needs to be saved in SSH format.

gypsy@spellweaver:~> gpg --output id_ed25519.pub --export-ssh-key [email protected]

4. The public key will be needed when setting up the repository on GitLab. The last line is what will be copy-pasted in the settings of the repository for the SSH key.

gypsy@spellweaver:~> cat id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAII4eqjhp6eW9BkzWRBy+MCKyJY8MS5cX1PPxeZfE2VTQ openpgp:0x643A77A4

5. the git program needs to be set to always gpg-sign commits and told which key to use

git config --global commit.gpgsign "true"
git config --global user.signingkey "A822359C643A77A4"

Use GitLab as the remote repository

Usually GitHub vs GitLab is more about personal preference than any project-based requirements. The granularity of permissions in GitLab is better than GitHub, allowing the instructor to grant access to the assignment repos on a per-user basis. GitLab allows for unlimited private repositories without having to create a paid account. Let's face it, as a rule educators don't have the spare funds to support enterprise level tooling. GitLabs give for free what GitHub will charge for. As it is student work, private repos seems more appropriate on two grounds. First, normally student assignments are not available to the general public. Even more so when dealing with under-age students. Second, by having private repos, with only the pair of students working on it being granted access, the ability to copy one team's work by another team is greatly reduced.

Three additional factors available from GitLab which might be useful are: 1) Discord Notifications, 2) their Continuous Integration (CI) pipeline, and 3) the ability to install a local, or self-hosted, GitLab for greater security. Depending on the language being use, the CI pipeline might help in keeping variations in build environments between student systems, or between their system and the instructor's system, from hiding or creating errors.

Tidbits and Notes

One possible downside to Discord is that it can also be used for video calls. That, however, is a something which is available through the "friends" section rather than in the "server" you would be responsible for, so it shouldn't count against you, or the application.

A bonus for Discord is that the odds are high that most of the students already have it installed, and know how to use it. They probably know how to use it better than the instructor would.

For the current crisis (COVID-19) Discord has increased the size of GoLive streams to 50. That shouldn't matter unless it's decided to us the GoLive feature for the instructor to do demonstrations, which is also a possibility.

If the students have an assigned email account from the school, it is probably a good idea to require that such email be the one associated with the GPG keys and the accounts on GitLab. Official required communications should be done by email using that address as well. Assignment instructions, due dates, grades, etc., rather in the untracked space of Discord.

To "invite" the students to the Discord server, create short-lived, single-use invites for each student, and send that in an email to them rather than a general invited for the class.

For most Linux systems, git is a simple install, directly from the default software repositories. For Windows it takes a bit more work. A guide, which seems to be pretty good, is How to install and use Git on Windows.

An advantage, and possible disadvantage of using the GoLive option is that each student can have their own version of the IDE, customized to their preferences. It's even possible they could use a different IDE than they would in class, and different from what their partner is using.

The potential problem with this is that they could become lost in the IDE and the instructor, having never used that one might not be able to help.

An unplanned benefit could be that new insights into student preferences, including IDE choices, can be obtained by noticing which IDE students gravitate towards, and how they use them. Once classroom instruction is able to resume, a change of IDE for in-class use might be in order.

The 24/7 availability of the tools can get the students into the habit of "calling" the instructor an anytime, without thinking that there are other things to do, or classes to work with. Setting a time for "class" where you will be available on the server for direct contact, perhaps during the same time-span as class was held when it could be held. To avoid the appearance of always being available it might be worth creating a different server for each class, keeping your "office hours" on each server in turn.

Answer 2

I've been experimenting with AWS Cloud9 with a view to remote pair-programming (at the professional level). Also, as a means of (vocational level) coaching of young professionals currently working-from-home. Might it meet your needs?

Also, Amazon have various educational tie-ups, which your school/system might investigate.

Disclaimers: AWS is subject to US 'export controls'; some don't like using such service-providers in principle; I have no link to AWS other than as a user.

Regards =dn

Answer 3

In the past I've successfully used XPairtise for Eclipse. The Eclipse marketplace shows this and a couple of others: https://marketplace.eclipse.org/category/free-tagging/pair-programming

A separate voice or text channel might be good to use with it.

But you want something with a fast and seamless switch between driver and navigator and also integration with the testing system. Eclipse with a plugin gives you that. The switch of roles should be as quick as passing the keyboard from one person to the other in co-located programming. Here it might be "click a button to switch roles."

Note that XPairtise hasn't been updated for a while and the others listed are newer. I haven't tried them.

A web search for "distributed pair programming" will probably give more information.

Answer 4

Keep it simple and integrate into tools that your school is already using as much as possible.

For example, my university is using MS Teams (which may currently be free for everyone). To do pair programming, each pair of students sets up a call with each other and one person shares their IDE window (we use Thonny). The other one then requests control, so either person can play either role (driver or navigator).

(Edits welcome for corresponding info about Zoom.)