SIGCSE 2017 - a path to github part 1

Both at and prior to SIGCSE 2017, I promised to write up the steps I take to introduce and use revision control systems in my classes.

This series is not meant to be a git or GitHub tutorial. There are plenty of those already (two of which I've linked to below). This is about the process I use with my students to get them up to speed.

As with any new tool, there will be some resistance but once git saves them once, they get religion. There will also be some bumps in the road but at the end of the day, the students will be using a valuable and necessary tool.

I was also surprised at the ancillary benefits I got as a teacher by using GitHub in particular. I'll talk about that at the end of the series.

Here's part one.

I'm doing this with git and GitHub but there's no reason why other systems and hosts can't be used. I'd also recommend that any educator or student sign up for the assorted discounts offered by GitHub.

I've followed this basic idea multiple times and done it over the course of a single semester, a year, and even two years. Regardless of time frame, the idea is the same. Make each step simple and relevant and introduce complexity and roadblocks a piece at a time.

Step 1 - code distribution

To start, I don't even talk about version control. We start with code distribution. For years, I've looked for efficient ways of sharing code with my classes. Both code developed in class and code for assignments.

I've tried things like NFS, Dropbox, online code repositories like the files section of systems like Moodle or Blackboard.

At Stuy, we've always had efficiency problems with NFS and Dropbox has multiple problems ranging from students not being able to install the client on school machines to the problems of the network hit when a room full of kids are syncing at the same time.

Uploading to a CMS system was also problematic - I'm a command line wonk and hate going through slow web page menus to navigate a filesystem and upload files. I also had to remember to get the files off of whatever machine I was working on in class and then transfer them to the CMS when I had a free moment.

Enter git. Now, of course, if you're going to use git in the classroom you have to know it. There are plenty of resources out there. Online courses, articles, videos, and tutorials. Here are a couple:

I also want to point out that I just use raw command line git along with native GitHub. GitHub has rolled out GitHub Classroom which adds a layer of support for educators. I don't use it because, as I said, I'm an old school command line wonk and also because I figured out a sequence that worked for me and my students before GitHub Classroom existed. Were I starting now, I'd take some time to look at their current offerings before jumping in.

Set up

Before starting, make sure you register your ssh keys. This help page has more information. You'll want to register an ssh key from every machine you use - home, work, laptop.

Now go over to GitHub and make a new repository. I usually name it classcode. BEGINNER NOTE: when creating the repo, make sure to check the "initialize this repository with a README" box. If you don't you'll be given a set of instructions on how to set things up once you click Create repository but it's easier and easier to follow if you start with an initialized repo with a README.

I make the repo public – it's code I'm distributing – nothing to hide here. If you aren't comfortable with that, just make the repo private. If you've registered as a teacher with GitHub, you can set up an organization and you'll be able to set up free private repos within it. The other downside here is that you'll have to individually give each student access to the repo. That's a mild annoyance but it only has to be done once.

Teacher use

Next, clone out the repo. BEGINNER NOTE: Make sure you check out the ssh version not the https version. Just make sure that when you click the clone button, it says "Clone with SSH." If not, just click the "Use SSH" link in the same box. Students will clone the using https.

From the teacher point of view, you can just start using the repo. My work flow is typically:

  1. git pull at the start of class
  2. write code throughout class
  3. git add, git commit, and git push at the end of class

I use a similar flow when I want to add files in my office or at home.

Student use

From the student point of view, assuming a public repo, they just have to clone the repo and at the beginning of every class or work session, do a git pull. That's all there is to it.

Thoughts

That's it. The kids are now using GitHub – they're probably looking at and poking around on the web site as well as pulling files to their machines. You can also, in class, show things like git status, git log, and git diff to set the stage for step 2 of this process and beyond.

Since the students aren't adding, committing or pushing, you probably won't get any errors.

The only problem that could reasonably occur is if a student places a file in their local copy of the repo with the same name as something they haven't pulled yet. This is pretty easy to address and provides a nice stepping stone lesson to again, set the stage for more complex operations.

I'm happy with this as a first step towards git using GitHub. It provides a nice way of sharing class code while gently introducing the students to the tool.

The next step is having the students add files to a repo. That's the next post in this series.

SIGCSE 2017 - Recap

As a high school teacher, I was never able to attend SIGCSE, the conference of the ACM's Special Interest Group on Computer Science Education. Between the number of instructional days I would lose and the cost, I could never justify going. Instead I looked over the proceedings and read many of the papers.

Now that I'm at Hunter, I was finally able to attend. This year in Seattle, the conference ran from Wednesday through Saturday. I was part of a panel on "Tools we can't live without." Over the next few weeks, I hope to blog about a number of things I thought and talked with people about over the conference including:

  • The path I use to teach git and why GitHub a good teaching tool (my talk).
  • The relationship of different CS Ed stakeholders - teachers, researchers, organizations, etc.
  • Teaching at the high school level vs college - perceptions and reality.
  • The challenges of tech tool adoption in schools.
  • What's going on in K12 CS Certification.
  • Maybe some other stuff.

Today, some overall thoughts.

The good

As with many conferences, the "hallway track" along with receptions sponsored by the CS4All consurtium, TEALS, Code.org were terrific. I was able to finally meet in person many people who I've only known virtually and got to know many more as well. I left the conference with a much larger address book and a long list of follow up items. Being in Seattle, I also enjoyed being able to spend time with people from TEALS and Code.org, two of the CS Ed groups working hard to do some real good (yes - I do like and support these guys even though I call them out on things I disagree with, but that's the subject of another post).

I attended sessions on CS certification, teacher preparation, assessments, POGIL based instruction to name a few. They ranged from valuable to interesting and to be honest, a couple of "what were they thinking" but the overall experience was very much worth the trip. I also got to speak to a number of wonderful students at the poster sessions.

The keynotes are also well worth a read (sorry if you don't have ACM digital library access). Jeannette Wing talked about the importance of probability and statistics in CS Ed, and aspects of Gail Chapman's talk "Inspire, Innovate, and Improve…" keynote and Mitch Resnick's "Fulfilling Papert's Dream" both spoke to the educator inside me.

The bad

The biggest downside to me was that I found very little value added in a number of the paper sessions over just reading the papers. Part of this is probably because of my own over-inflated expectations given the number of years I've waited to attend. Part of it though, was the fact that sessions were so tightly packed that I didn't have time to follow up with presenters before having to run to the next thing. Unfortunately, in some cases, it was because the presenter merely "read" the paper much as a professor sometimes just reads the slides or the book to his class.

Other thoughts

One paper presentation I very much liked was Exam Wrappers: Not a Silver Bullet presented by Michelle Craig and Ben Stephenson. I actually came in late since I was hustling over from the Code.org lunch. The result was that I didn't actually know what "Exam Wrappers" were until well after the talk when I ran into Jim Huggins. Exam wrappers, in short, are merely when you require the students fill out something for some credit when picking up their exams. The funny thing is that it's a strategy that high school teachers have used for years without a special name and we already knew the good and bad of it without the research but that's not what I want to get at here. What I loved about the talk, besides the fact that Ben and Michelle are clearly strong presenters is that this was a negative result that was being presented. I also loved the fact that they didn't present their research as gospel but rather pointed out the strengths and weaknesses of their approach - they made a case to what and why we should pay attention to and what should be taken with a grain of salt.

This was a major breath of fresh air after being exposed to so much education 'research' over the course of my life that the author or presenter felt was just as strong as a mathematical proof rather than an indication based on a specific experience or small set of experiences.

I also felt a little weird at times during the week when west coast people seemed to know me. I know I'm a loud mouthed curmudgeon and I go on my periodic ed rants but given the dearth of comments on this blog I was really surprised to get as many as "great to meet you in person after reading your blog" or "we know you and your work" all week. It was weird and somewhat humbling.

Finally, another highlight f`or me was that I got to catch up with some of family.

sigcse-seattle.jpg

Already planning to submit something to present at SIGCSE 2018 in Baltimore.




Enter your email address:

Delivered by FeedBurner

Google Analytics Alternative