With today’s deploy, we added some console sharing and file system features to make helping other people easier, whether it’s in a group setting, or a more in-depth one-on-one session.
It’s been great to see more and more initiatives to teach Python, over the last few years, but it’s never as easy as it should be. Personally, we have definitely experienced the struggle of our friends who are new to programming, from general commandline stuff and installing modules, to understanding different error messages and trace backs etc. We want to see if there’s more we can to do help make the mentoring process as easy and painless as possible.
tl;dr: go mentor someone today and tell us how to make the sharing features even better for you!
New Sharing Features
- We added the ability to share your console read-only, so that your sharee cannot type into or resize your view window (which can get super annoying when your mentee does not realize resizing their window has an effect on you!)
- For the education beta specific stuff, we also added these two features in response to popular requests:
- An extra option for teachers to share a console with all their students in one click
- Mount the student’s home directories so that the teacher can see them (ie. teachers can now access /home/student1 in addition to /home/teacher)
Cool Infrastructure Stuff
We also continued on our epic quest towards zero downtime by stupidifying the file server. Previously, our file server shared the same code base as our web/console servers, and used the django code to do tasks such as updating user storage quotas (eg: after an account upgrade). It was a good idea at the time because it meant that we could handle a quota update request, grab what a user’s storage quota changed to, and then apply the new quota- all very easily from within django.
However, this violates the concept of keeping things modular and meant that we had an extra dependency to manage properly. Whenever we updated the source code and wanted to push it out to production, this meant that we needed to do it to the file server as well. This then meant that we needed to make sure nobody was writing to the file server during that time and that all the changes were flushed to disk. This is one reason why we needed downtime when deploying (to ensure data consistency etc).
Anyway, now all the fileserver has on it is a minimal flask microservice independent of our main django code, so the hope is that we can cut out this particular source of downtime. Yay!