How does Harvard’s largest course, an Introduction to Computer Science, use GitHub to achieve its learning goals?
Professor David J. Malan, Gordon McKay Professor of the Practice of Computer Science at Harvard University, is dedicated to offering his students a robust learning experience. This post outlines how he uses GitHub and his own custom tools to build hands-on assignments for CS50 students.
With over 700 students, 80 staffers, and 2,200 participants in their end-of-term CS50 Fairs, CS50 has a reputation for rigor, real-life application, and engaging material.
At the same time, says Professor Malan, about half of CS50’s students typically treat the course as “terminal”— as their one and only course in computer science. So the projects touch on applications in a variety of fields, from social sciences and humanities to medicine and finance.
Malan says of the learning goals of CS50: “We want to provide students with a solid foundation in computer science so that they are well prepared for any field. And also bring to bear some practical skills to that world. So that is actually tied in with our adoption of GitHub this past year.”
The mental model for cloning, branching, opening pull requests, or pushing can be tricky for newbies just starting out. As a way to onboard students, Malan wrote a command-line tool that wraps a sequence of Git commands called
submit50. They developed
submit50 to not “reinvent the wheel” with a new submission system, but to create space for students to grow into comprehensive GitHub use as their learning evolves beyond CS50. Says Malan:
One goal was to have students graduate, so to speak, from the class actually having a GitHub account. And even though they don’t keep their work in public portfolios for the course, the hope is that they’ll have at least enough understanding of GitHub that they can use it after the term ends for personal projects.
CS50 uses the structure of one branch per problem, and students engage Git and GitHub from the command line.
First, they run a command in their directory on a Linux system with a folder they wish to submit to CS50’s servers. The student then runs
submit50 foo where
foo is the unique identifier for that assignment.
submit50 models how Git and GitHub work while abstracting away some of the complexity:
Behind the scenes we show them the command so that through a bit of osmosis, they can infer what’s actually going on.
We clone their repo, which lives in our
submit50organization. So we have full administrative rights, and students have push and pull privileges only.
submit50script clones that repo into a temporary directory. We do the equivalent of
rm -rfto blow away whatever is currently in there, and then
git-addthe entire contents of their current working directory into that repo, and then tag it with a tag that corresponds to the problem’s name, and then push it to the server.
An example assignment is “C$50 Finance” where students build an application to simulate stock trades using Python with Flask, HTML, CSS and SQL.
Students create tables with user accounts, who can then buy and sell stocks. The application queries Yahoo Finance for stock quotes, almost in real time.
Malan is delighted to see the different personal touches students add to their projects, both functional and aesthetic.
It’s a fun opportunity to introduce students to even the aesthetics of web design. Invariably the first thing students do is customize the aesthetics of the site, and then certainly there are differences in features, and we’re fine with that. The assignment requires ultimately that they add a personal touch, so any feature that’s not been enumerated by us they’re welcome to do so long as it’s of reasonable scope. So we’ll get different outputs from that as well.
All students exhibit their final projects an end-of-semester “CS50 Fair.” About 2,200 people attend to see the student demos.
Malan designs the event as a kind of celebration, a capstone ritual where students can show people what they’ve made:
It’s a fun way to delight in how much you’ve finished, particularly if new to programming just months prior. And it perhaps creates a bit of social pressure too. You know you’re going to be showing this not just to your Teaching Fellow, but to your classmates, and you want to be proud of it. And so, hopefully, that incentivizes all the more of a strong finish.
Pushing beyond the boundaries of the traditional classroom, Malan connects the course materials with the news in a kind of “Daily Show” for technology, called “CS50 Live.”
Malan and the crew of Teaching Fellows take up current events, like Apple’s implementation of OpenSSL with a bug in it, and dig into the code on the show.
This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms. Check out the other posts:
Join this week’s discussion in the community forum: How to automatically gather or collect assignments?
Google provides some guidance on how to effectively run a Google Summer of Code project but it’s not tailored specifically to GitHub’s workflow. To set clear expectations for mentors and students here’s our ideas on how to successfully participate in Google Summer of Code as a mentor or organization administrator.
Make a dedicated file or repository for documenting project ideas and discuss them in issues. The ideas should be things that are going to be useful to your project, would take a maintainer a week or two to complete and you think should take a student between a month and a month and a half to complete. You can populate these from
help wanted-labeled issues in your repository. They should be brief enough to stimulate discussion on their implementation but not detailed enough for students to be able to copy-paste any part into their proposal.
For example, the Homebrew project has a repository for these ideas (updated for GSoC 2017).
Strongly encourage students to adopt one of your ideas rather than their own. You have a much better idea than they do on what will be useful, achievable, and mergeable.
Rather than angsting over student technical interviews or their proposals documents you should make your decision primarily on which students (if any) to accept based on a trial of the work you expect from them in the summer: a pull request to your project’s repository. Google expects students to get involved in communities so requiring e.g. a one line change in a pull request is more time efficient than any other metric.
In general any established GitHub open source repository should have an easy way for new, aspiring contributors to submit a useful pull request. In Homebrew’s case they have a
brew audit linting tool where some lints are deliberately left unfixed to give newcomers an opportunity for an easy first pull request.
For example, the Homebrew project’s process is documented in their README.
You should not help students any more than any new contributor or provide any more guidance than what’s already documented in your project. If they ask for help, point them to the instructions (and consider improving them). If they cannot figure out what other contributors can: they are unfortunately not good candidates for GSoC which requires them to be self-motivated, driven and able to learn independently over the summer.
Provide regular review to student pull requests before the application deadline. Make it clear to the student that the pull request must go through the review process and get merged before you can accept their application. They’re in a rush, but you shouldn’t be. In respect of time, students shouldn’t rush last minute to hit a deadline.
This is a good principle in general but not the typical mindset for students who typically do work for a single output that’s handed in. Encourage them to split their work up into multiple, regular pull requests over the summer so their pull requests can be more easily reviewed and merged.
For example, see @AnastasiaSulyagina’s pull request to remove some duplicated exceptions as part of Homebrew’s 2016 GSoC. This was a small change review and a merge followed quickly.
Most of your interactions with your student should look like your interactions with other maintainers and contributors on your project. For example, if you talk with other maintainers on Slack, invite your student and encourage them to ask questions when they have them. If you can talk about things in issue comments and pull request reviews: do that instead of video calls or other private methods of communication so that other maintainers can help provide review and feedback.
Have a meeting that you both stick to every week (that neither of you are on vacation) on text (i.e. IM), audio or video chat. Defer to the student’s preferences on IM vs. audio/video as they may feel more comfortable communicating over text if English isn’t their first language. This should be your chance to see what progress there has been if there’s been no public activity. That said, a week with no commits, issue comments, or PR comments is a sign of major concern that you should raise with the student.
As mentioned previously: you should not accept students who have not made a trivial pull-request to your project. Similarly, the focus of the summer should be around pull-requests too. If the student does not have a significant, non-trivial pull request opened by their mid-term: they should fail. If the student does not have a significant, non-trivial pull request merged by the end of the program: they should fail. Again, splitting the work up into multiple pull requests over the summer is vastly preferable to opening pull requests at the last minute.
Like many things in life: strict, no-compromise boundaries may sound harsh but end up being kinder to the student. You can communicate these expectations at the beginning of the program and then they don’t need to worry about whether they will pass or fail. This is also a life lesson: many deadlines after graduation are not negotiable and it’s better to fail at GSoC than many other things in life.
It does, yes. The requirements above may mean that you’re not able to get any students who are good enough for your project or that you need to fail students. This is unfortunate but it’s ultimately better for students and much better than having a bad GSoC experience.
For point of comparison while following the above system for the last two years the Homebrew project has always had more good students than mentors available for them, never failed any students, had the majority of students ship major features our users have been happy with and, best of all, had a minority of students become and stay Homebrew maintainers.
Now that you know how to effectively run a Google Summer of Code project on GitHub consider applying as a GSoC organisation before the February 9, 2017 at 17:00 (GMT) deadline and have a great summer!
We released GitHub Classroom in fall of 2015 to make it easier for teachers to distribute code and collect assignments on GitHub. In the last year, we’ve seen it enter the classrooms of thousands of teachers. We’re delighted that it’s helping students learn STEM subjects and even more excited to share the processes, tips, and tricks educators have built around it.
To kick off a series about educators and classroom practices, we’d like to introduce you to Geoff Schmit, a former engineer for National Instruments. In his tenth year of teaching at Naperville North High School, Geoff seeks to prepare students with the mindset of a creative, ethical engineer who uses real-world tools:
I had a background in source control which I brought with me from my life as a software engineer. I think students should learn about source control before they leave this class. They should have written unit tests before they leave this class. And they should read articles about technology in society and ethics before they leave this class.
He kickstarts his semester with pre-filled repositories—sample code and libraries in GitHub Classroom. Students dive straight in, without the tool getting in the way:
On the first days of school I want them doing turtle graphics in BlueJ. I don’t want to worry about setting up the environment and everything. So I’m able to pre-package everything, so they can double-click on it and type some code in, and we’ll work.
This is his first year using GitHub Classroom to organize his assignments and gently introduces students to GitHub.
Using Classroom, students click on a single link to create and manage their repositories:
So rather than them having to worry about forking, cloning, and that stuff, they just click on the link to accept the assignment.
With Github Classroom things are so much smoother because it copies the whole assignment into a private repository, which is nice.
To submit their assignment, students commit to the master branch of their own repositories, then pass that link to Geoff’s Learning Management System (LMS), Canvas.
To grade their the project, Geoff downloads the code through the GitHub desktop client, runs it, and assesses the lab.
I have the link right there to GitHub, and I click on it, and I download it, go through all their code, run it, whatever, and just go right on to the next one. So it’s super fast to take a look at their code and run it, which is great. It’s been really easy. It’s worked really well.
Dr. Mitchell Resnick, creator and educator of Scratch, refers to learning experiences with “low floors, wide walls:” activities that are easy to begin, but enable a creative flow that keeps learners engaged past the requirements.
Geoff’s labs aim to spark this kind of engagement in his students. The Cityscape Lab, one of four over the semester, offers few concrete specifications: create three classes and animate your Cityscape in some way.
So, that’s the low floor and for some students, that’s going to be a stretch and they’re going to work really hard to do that.
But then for others, it’s like, “Well, you could do more.” We haven’t done loops or anything yet so I say, can you figure out how to do windows, other than having to draw all 100 of them by hand? or *can you figure out basic looping structures?
And I’ve had submissions like a student who downloaded constellation star data so the stars in the sky actually matched reality. I’m sure she spent hours and hours outside of class working on that but she was really excited about it, whereas other students just got their buildings done, and that’s fine.
What I have been surprised about, because I was worried about it at first, is that when students meet the requirements they don’t stop.
Geoff has several AP Computer Science courses a day. When he’s demonstrating to his class and projecting code snippets or examples, he uses one branch per class period.
So when Period Four starts on Tuesday, Geoff picks up from yesterday’s branch:
Every day I update Canvas with a link to the branch of each class period. If a student is absent, they know where to find everything we did together as a class yesterday. And that’s been really great.
Geoff only grades exams and a summative lab at the end four units. All the other projects, daily hands-on activities, and everything else, is all practice.
By putting projects front-and-center instead of grades, Geoff says students are more open to learning experiences that might put them in more vulnerable positions, like sharing work and pair programming.
Students say to themselves, “I can take risks. I’m not being graded on this. I’m not worried about my partner not doing as well as me, because we’re just practicing.” That trust goes a long way towards helping them accept different kinds of activities.
This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms. Check out the other posts:
CARTO is the newest addition to the GitHub Student Developer Pack.
CARTO is a powerful open platform for discovering and predicting key insights underlying the world’s location data. It’s a suite of geospatial tools, services, and APIs for discovering and predicting the key insights from your location data in your applications. You’ll be able to do powerful analysis of your data.
With CARTO you get:
Members of the pack get:
The Student Developer Pack gives students free access to the best developer tools from different technology companies like Datadog, GitKraken, Travis CI, and Unreal Engine.
Students, get mapping now with your pack.
The Community-Powered Bootcamp is a self-paced subscription program for beginners. You’ll learn online using the same course of study as the Web Developer Program—a comprehensive curriculum tailored to job seekers. In a month, you can pick up a few in-demand skills and work with a community of other learners to start reaching your goals, whether they are technical literacy, a new programming language, or a new career.
After one month, you can sign up for a monthly subscription of $149 USD.
The Student Developer Pack gives students free access to the best developer tools from different technology companies like Datadog, GitKraken, Travis CI, and Unreal Engine. Sign up for the pack, and start learning.