One of the issues of working in distance education is providing individual support to individual students. In a traditional computer teaching lab environment, students encoutering an issue might be able to ask for help from teaching assistants in the lab; in a physical university, students might be able to get help in a face to face supervisory setting. In distance education, we have spatial separation and potentially temporal separation, which means we need to be able to offer remote and asynchronous support in the general case, although remote, synchronous support may be possible at certain times.
Related to this, I just spotted preview of a Docker workflow thing, Docker dev environments, for sharing work in progress:
The key idea seems to be that you can be working inside a container on your machine, grab a snapshot of the whole thing, shove it on to dockerhub (we really need an internal image hub….) and let someone else download it and check it out. (I guess you could always do this in part but you maybe lost anything in mounted volumes ,which this presumably takes care of.)
This would let a student push a problem and let their tutor work inside that environment and then return the fixes. (Hmm… ideally, if I shared an image with you, ideally you’d fix that, update the same image, and I’d pull it back???? I maybe need to watch the video again and find some docs!)
One thing that might be an issue is permissions – limiting who can access the pushed image. But that would presumably be easier if we ran our own image hub/registry server? I note that Gitlab lets you host images as part of a project ( Gitlab container registry ) which maybe adds another reason as to why we should at least be exploring potential for an internal Gitlab server to support teaching and learning activities?
(By the by, I note that Docker and Microsoft are doing a lot of shared development, eg around using Docker in the VS Code context, hooks into Azure / ACI (Azure Container Instances) etc.)
In passing, here are various other strategies we might explore for providing “live”, or at least asynchronous, shared coding support.
One way is to gain access to a student’s machine to perform remote operations on it, but that’s risky for various reasons (we might break something, we might see something we shouldn’t etc etc); it also requires student and tutor to be available at the same time.
Another way is via a collaborative environment where live shared access is supported. For example, using VS Code Live Share or the new collaborative notebook model in JupyterLab (see also this discussion regarding the development of the user experience around that feature). Or the myriad various commercial notebook hosting platforms that offer their own collaborative workspaces. Again, note that these offer a synchronous experience.
A third approach is to support better sharing of notebooks so that a student can share a notebook with a tutor or support forum and get feedback / comment / support on it. Within a containerised environment, where we can be reasonably sure of the same environment being used by each party, the effective sharing of notebooks allows a student to share a notebook with a tutor, who might annotate it and return it. This supports an asynchronous exchange. There are various extensions around to support sharing in a simple JupyterHub environment (eg https://github.com/lydian/jupyterlab_hubshare or potentially https://github.com/yuvipanda/jupyterhub-shared-volumes ), or sharing could be achieved via a notebook previewing site, perhaps with access controls (for example, Open Design Studio has a crude notebook sharing facility is available to, but not really used, by our TM351 Data Management and Analysis students, and there are codebases out there for notebook sharing that could potentially by reused internally behind auth (eg https://github.com/notebook-sharing-space/ipynb.pub )).
A fourth approach is now the aforementioned Docker container dev sharing workflow.
OUseful.Info, the blog... 