DAVID MALAN: Hello, world. My name is David Malan, and I'm here in Sanders Theatre at Harvard University where I teach CS50, Harvard's introduction to the intellectual enterprises of computer science and the arts of programming, an introductory course for majors and non majors alike. CS50 is among Harvard's largest courses, and indeed in healthier times, the seats behind me would look a little something like this. But the course is also freely available as OpenCourseWare as CS50x via platforms like YouTube, and edX, and beyond. And the course is additionally available to teachers in the high schools and middle schools as CS50 AP, a curriculum that they can adopt or adapt for their own classroom. 

Students meanwhile can take both before and after CS50 itself, a whole suite of courses nowadays by CS50's team, including courses on artificial intelligence, game development, web programming, and more. All of these courses meanwhile are available at edx.org/cs50 for free. Now, over the years have we had to provide students with quite a bit of infrastructure in order to make this and now other courses possible, particularly toward an end to onboarding them to the world of programming without having to configure and install software on their own Macs and PCs, invariably then having technical support difficulties as opposed to focusing on the course's actual curriculum and the principles of programming itself at term starts. 

And in fact, if we roll back to 2007 at the time with students here only on campus being provided with shell accounts on a Unix, later, Linux cluster on campus for which they had a username and password. They had a home directory as well as access to commands like GCC and GDB because indeed the course introduces students to programming initially by way of C, followed by Python and other languages as well. 

But in 2008, we began to experiment with the cloud, which was in its earliest form. And by using AWS EC2 and other services did we replicate that same topology in the cloud so as to actually have more administrative and educational control over that same environment for just our students in the course itself. In 2012 meanwhile, just a few years later, did we begin to experiment with downloadable virtual machines, in our cases, dubbed the CS50 Appliance, a Fedora and later Ubuntu image that students could download on their own Macs and PCs. They could download something like VirtualBox or VMware in order to run their own CS50 environment on their own computer. 

Particularly enabling was this for the OpenCourseWare audience who, to date, could watch content, could read PDFs and the like, but they couldn't necessarily do the course's programming assignments or problem sets not having access of course to Harvard's shell accounts here on campus. But with the Appliance were they able to work not only on their own computers but even offline, engaging actively in the course's OpenCourseWare. 

But a few years later in 2015 did we begin to explore web-based alternatives as well to just get away from the process of needing students to install anything on their Macs or PCs, particularly in the context of schools, where teachers might themselves not have administrative access over the school's own labs. And so we began to experiment with an open source tool at the time, now AWS Cloud9, on top of which we developed a suite of pedagogical plug-ins so that students could use just a browser to access still a text editor, and a terminal window, and all of those same tools but this time requiring only a browser. 

And most recently now in 2021 have we begun to experiment as well with Visual Studio Code and its suite of extensions replicating that same environment. But we're also now aspiring to provide students with an offboarding experience as well, whereby students at terms end will now be able to download-- once they are comfortable and have their footing in programming itself-- VS Code and any requisite extensions in order to have their own independent programming environment. Because indeed if CS50 is the only proper programming class they ultimately take, they can at least continue developing even without any of the course's infrastructure thereafter. 

So in order to achieve all of these tools, we were motivated by trying to solve just these three problems-- enabling students to write code, enabling students to submit code, and enable teachers like ourselves to review that same code. And underlying then all of those problems were a number of problems already solved, for instance, authentication, authorization, code reviews, container orchestration, testing, version control, and more. And even though we have had for years, myself included, this tendency to try to create solutions ourselves and implement our own homegrown solutions so as to get these tools just right, that's of course intention with using something off the shelf, which, while already developed, might not do exactly what you want. 

But we've over time tried to find the sweet spot, whereby we use as much open source software or SaaS type tools as we can and then stitch them together using our own extensions, and plug-ins, and the like to create, ultimately, the UX that we want our students to have. And so in the case of these primitives, for instance, have we in recent years leverage GitHub itself for all of these and more. 

For authentication, we have students log in via OAuth with their own GitHub usernames and passwords. For authorization, we've leveraged GitHub support for teams so that TAs and students can have read and/or write access to the same repos. For code reviews, we've leveraged the web UI's interface for pull requests or commits on which you can type per line comments. Container orchestration now comes in the form of code spaces online, testing via GitHub actions, version control via Git itself, and more. 

And so within each of these environments over the years have we also developed a suite of command line tools and later web tools as well that leverage these primitives to solve more problems for students in order to uplift them in the experience of writing code on their own. Submit50, for instance, was one of the earliest of these tools, a command line tool that, at the end of the day, just let students submit their code using Git underneath the hood but without having to understand or wrestle with any of the mechanics of Git itself in that first week of the class, where they're still just learning, hello, world, in C or some other language. 

But for the backend then of submit50 are students really, at the end of the day, pushing to a repo in our own GitHub organization. And they reference it by way of a path, like owner/repo/branch/path that submit50 then uses to infer to where to push the code for students. In that repo meanwhile is there just a simple configuration file that flags that path as a valid submission path that students can use. And within that YAML file might there be the equivalent in YAML of something like a gitignore that prescribes exactly what files we do and don't want them to submit. 

Now, underneath the hood all submit50 is doing is essentially git add, git commit, git push, and the like. And even for resubmitting do we even avoid merge conflicts or the potential thereof altogether by doing a bit of trickery as well so that, again, for students early on these get completely abstracted away. But towards terms end, particularly when they start to collaborate potentially on final projects, can we begin to take away some of these training wheels and have them use the native tools themselves. 

Meanwhile, to distribute students own repositories and within it starter code, have we been using GitHub Classroom most recently, whereby students accept an assignment which has the result of copying a template repository for them into our own org that they and perhaps their TA then have read and/or write access to. Underneath the hood meanwhile do we then leverage web hooks or the equivalent thereof to use GitHub actions, whereby we export a prescribed format for GitHub Classroom in the form of an autograding.json file that actually automates the process of running a suite of correctness tests, which, in our case, happen to use our own command line tool but could really be any unit testing tool or the like. 

And for more qualitative feedback do we leverage the web UI to provide line by line comments as might be the case with a teaching assistant working more closely with their own student. And now in our case for those automated tests do we use our own tool, check50, which essentially just wraps a unit testing suite for C, and Python, and the like. But that too ultimately is backed by a GitHub repo. So a student would run a command like check50 owner/repo/branch/path that simply indicates where in the web to go get those correctness tests from in order to run them locally on the student's own code. 

Now, in the graphical context, we also have provided students and built on top of these primitives something we call see CS50 Lab, which essentially embeds a text editor and terminal window alongside a rendered markdown file, thereby enabling us and any teacher online to create in their own GitHub repository a learning experience for students. That might have some starter code, might have some correctness, and might also have a narrative alongside it that ultimately lives in a repository indicated by, again, owner/repo/branch/path inside of which too might be a YAML file for some minimal configuration, the readme file itself, and the starter code. And within that YAML file would just be a bunch of key value pairs that tell our tool how to configure the web environment exactly as that teacher wants for their own students. 

Also, graphically as well within these most recent web tools, like the IDE and now VS Code, have we wrapped the process of just starting the graphical debugger by a tool called debug50 so that when students compile and then run their code through debug50 does it trigger essentially a launch.json file in VS Code to get dynamically generated and configured so that the debugger is right there up and running without students manually configuring anything themselves. If you're familiar with rubber duck debugging, the process of talking through your logical problems in hopes of hearing any illogic with a rubber duck or an inanimate object, similarly, have we built a VS Code extension that allows students to talk via chat with a virtual rubber duck giving them hopefully a bit of prompt for finding their problems. 

And then underlying all of these tools is not only Docker but now a devcontainer.json file, which allows us to specify a whole suite of configurations for students, like the extensions to preinstall, the Docker image to use, and the settings that can customize the graphical user interface they're ultimately using. Behind the scenes, meanwhile, do we use a suite of REST APIs in order to automate a lot of the processes, especially with regard to authorization. But ultimately, these and more tools are all freely available to students and teachers alike and documented at cs50.readthedocs.io. The course's themselves are all freely available at edx.org/cs50. And indeed, this was CS50.