A CoViD-19 story about an approach for teaching in quarantaine (2)
Start of the C Programming Course
After the first online sessions using the default Python 3 kernel, which proved the usefulness and stability of the Jupyterhub there came the next step. Introduction to C programming as a part of the Systems Software module in the IFI programme at Bremen UAS.
Users were added as already described in part 1 of this series. Logins all worked (except one incorrect password) and the students started writing their first tiny C programm. The VPS host used contained 4 virtual CPU’s and 8 GB RAM, running several lxc containers of different purposes (websites, cloud services, communication services, …). Running almost 80 Jupyter Notebooks, partly Python, partly C in parallel didn’t slow down the system at all, no swap space was used during all the activity.
To sum up matters: the system worked like a charm. That’s indeed all that has to be said. Even fooling around with fork()/exec() and different other Linux system functions, filesystem access and so on just worked as if it were a locally run system. Also the use of additional libraries proved straight foreward by simply adding the appropriate linker directives in the notebook.
Benefits for Teaching
First and foremost, the fact that all students have the exactly identical working environment for their lessons is a huge benefit, compared to possible other scenarios. Too many times I remember finding myself fixing weird PC setup problems with lab (or, even worse, the students' own) computers. Precious time that better had been used for learning and teaching than fixing setups. In a F2F lab setup this might just be a (yet sensible) nuisance, in a distance learning setting, it simply is a no go. It must probably be said that in this case I was dealing (in part) with engineering students that had no further ICT background, matters would hopefully be different with dedicated ICT students - they should be able to manage their programming environments.
The inner workings of Jupyter (real compilers/interpreters running natively upon the OS, no simulated/emulated environment) make it easy for the students to solve real-world problems as if they were working in their own local programming environment. Additional benefit: as it is still the case that particularly engineering students, but to quite some extent even ICT students have little to no experience in administrating Linux environments which easily wastes a noteworthy amount of teaching time (by helping each and every student to set up a simple programming environment - editor, compiler and explaining over and over again file system layout or even the simplest CLI commands), using the Jupyterhub freed me from these tedious duties. And no - moving to another OS as the basic environment wouldn’t really make matters better, you unfortunately soon realize it’s not the one or the other OS they cannot handle. They’re simply lost whenever they have to leave the comfort zone of swiping their cellphone screens. This might sound harsh, but in my experience the so-called digital natives are IMHO often more the sort of digital ignorants (but that’s probably a topic for a future post).
Yet another benefit is the possibility to export the notebooks as a whole which makes it easy to collect not just the code the students wrote but to also have them answer related questions and to explain their approach directly within the notebook, without having to resort to massive amounts of comments within the code. In other words: have them comment just as you would want someone to comment code inline and still get the additional answers (e.g. for grading) directly with the program code. And testing the students' code is just a matter of opening the Jupyter notebook on your local machine.
Shortcomings
Little. A ready-made Debian package including some common kernels would be nice (maybe something I might work on in the future), easy addition of kernels (a common way of installing them) is something I really missed. True, I had little to no time for digging deeper into documentation (which might or not have helped me setting up the environment), but that’s a common situation, isn’t it?
One could probaly complain about missing separation of individual students' programming environments (i.e. notebooks), true, if things go completely wrong (Murphy, where are thou'?) this might crash the whole setup. But at first sight this is the way things are, let’s face it. What I did miss sadly was an easy way of culling (i.e. stopping after some time of user’s/owner’s inactivity) individual running notebooks to free ressources (as it would have been already inculded in The Littlest Jupyter Hub), documentation for adding this feature to one’s hub setup are online, but from what I remember it was not 100% trivial to deploy (maybe I’m wrong and it was just the mere lack of time that led me to this conclusion - only future will tell, see below).
Conclusions and Outlook
What was originally meant to be a quick and dirty hack due to restrictions in place after the SARS CoV-2 virus had hit large part of the world, simply to enable ongoing teaching turned out to be a more than just viable solution particularly (but not solely) for blended learning settings. It will from now on be a cornerstone in my teaching, be it F2F or online.
As soon as I find the time to do so, I will make some changes in my setup: Add LDAP for user management (probably try to hook up to our university’s AD), add some more kernels (Go, Rust) and add a culling mechanism.
