GitHub presents Field Day—a one-day unconference for leaders of technical student communities. Students will share how they build communities, learn from each other’s successes and mistakes, and explore how they can collaborate in the future. We’ll spend the day focusing on how our summer internships in the San Francisco Bay Area can benefit our respective communities at home.
Field Day is a flexibly structured, student-run event. Attendees drive most of the content, and you’ll find students giving lightning talks and leading discussions on their experiences.
If you run a student tech club or if you’re actively involved in your school’s tech scene, and also happen to be in the Bay Area this summer, we’d love to welcome you at GitHub HQ on July 29th.
Professor Chris Lupo has taught at California Polytechnic State University for eight years and recently revamped his upper-level Architecture course using GitHub Classroom. In this post, he shares his workflow for deeper insight into student work, efficient debugging, and community support. </strong>_________________
At California Polytechnic State University, the motto is “learn by doing”, so it follows that students learn with real-world tools, rather than with board work and problem sets.
In group work, we do a lot with Raspberry Pi and students get into the habit of making sure they push to get it on their other systems, or so their partners can download changes. The flow encourages strong development habits. Push early, push often—that kind of thing.
Chris uses Classroom to distribute starter code and create individual and group assignments.
Chris uses Classroom, GitHub’s collaboration features, and Raspberry Pi to work with students when they get stuck. Here’s a quick overview of his workflow:
Quickly access a student repository. Assignments set up through Classroom automatically add Chris as a collaborator, and the dashboard clearly presents a list of student work.
As soon as students click an “invitation link” from Chris, Classroom creates a new repository for them. Here’s the output from GitHub Classroom in Chris’s course.
Clone and comment in-context. Students can see where changes need to be made and leaves comments directly in their code.
Test the fix on his own Raspberry Pi.
Push the code back to the student’s repository, with fixes and comments.
This workflow solves the cumbersome task of transferring files. Both instructor and student can work from their own environments, instead of switching between computers.
I can clone their work, connect to the Raspberry Pi that I have access to, and run their code. From there I can work with them directly on their code base to show them what steps to take and how to move beyond their current problem. After we work together, I can push the code back to them when we’re done.
I have access to everybody’s code all the time. I’ve not had that capability prior to using GitHub Classroom.
When Chris has questions about Git or best practices, he reaches out to the GitHub Education Community for advice from other teachers.
I’ve also found the community really helpful for support. For example, I learned about a script named orgclone that was really useful for me in repository management.
Even though Git and GitHub take some time to get students up to speed, Chris says students are happy with the experience now that he’s implemented GitHub.
Feedback has been very good. There is a little bit of a learning curve for people who have never used Git before, but they all said it was worth it.
Adapt Professor Lupo’s assignments:
Use Raspberry Pi assignments for a university setting:
School may be (almost) out for summer, but we’re still adding to the Student Developer Pack. Sentry is now offering error reporting to new and existing pack members—send up to 500,000 errors per month and enjoy unlimited projects and members.
Sentry provides real-time error tracking and crash reports for your web apps, mobile apps, games, and more. With Sentry, you get all the information you need to identify, reproduce, fix, and prevent bugs—from the full stack trace and the contextual details of the exception to a trail of events that led to the issue and release and commit data—so you can set priorities, triage proactively, and make sure errors don’t affect your user’s experience.
Our Student Developer Pack gives students free access to the best developer tools from different technology companies like DigitalOcean, Datadog, Stripe, Travis CI, Sentry, and more. Oh yeah, and all students get free unlimited private repositories—perfect for summer projects.
Feedback is essential to the learning process. Input from an expert at the right time can make all the difference in a software project.
In past programming classes, Professor John David N. Dionisio’s printed out student assignments and commented on their code by hand, directly on the paper. Students said it was easier to understand feedback when it was in context.
When he started using GitHub’s interface to communicate with his students, he found he could introduce version control even earlier in his courses. As a result, Dionisio’s students have the opportunity to use industry tools from day one of their studies.
The web app has made development more accessible sooner, letting freshmen get in on it without having to learn everything about version control. The comment threads and the ability to comment line by line tightens the feedback loop. Now printing is not really necessary because you can just look at the diffs and make comments about it.
Working with a live repository, he knows students will see it exactly as he does. And GitHub Classroom’s dashboard lets him share a link to the full assignment and view who has accepted it.
For students it’s easy to get started. With Classroom, I can now basically deliver a complete package, including the instructions. Instead of things being sort of scattered, and having the student accumulate it together. Documentation is there, sample code is there, and configuration files for continuous integration are there.
Every student picks it up, and if they’re off and running. They can commit, and you can look at their histories. Students have their own private repo that they would build their files on.
Until he started using Jenkins to flag formatting issues, Dionisio had to provide his students with a flood of stylistic comments.
Now, instead of focusing on bad indentations and incorrect spacing, Dionisio can give more qualitative feedback on redundancies and best practices. His comments have evolved into more of a conversation.
I frequently give feedback in terms of design and structure, like “I would’ve instead written this line this way.” And since GitHub comments are in Markdown, they’re easy to read and very clear.
You can really format the code and convey your ideas. The display thread helps the student respond. It allows very context-sensitive, context-aware discussions for finer points of code.
A before and after of Dionisio’s feedback—from manual markup to precise and contextual feedback using GitHub’s review process.
A few additional examples of John’s feedback to students.
In industry, developers almost never start from scratch. To be successful, they need to be able to ask questions about code, to understand what’s going on, and recognize the strategies of other developers. In the classroom, pull requests work to build those skills:
Pull requests with Markdown support are a great place to have a consistent thread of feedback. And this clear signal of, “I now accept your work”—like building a relationship of submitting your work for someone to look at, and after we workshop it for a little bit, I now accept your work.
Anything that helps me simulate tools and practices they will encounter later is always of help.
This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms.
Mikaela Marciales, a junior at Lowell High School in San Francisco and member of the JROTC, reflects on her projects in AP computer science as equal parts expression and fun—in large part thanks to a creative AP computer science approach developed by her teacher, Art Simon.
When I’m feeling all optimistic and happy, I’ll make a really colorful, explosive program. If I’m more calm, I’ll make a more minimalistic type program.
Years ago, Art remembered that a student brought in some code he ripped out of a magazine. After they ran the code together, the student’s eyes lit up.
From there on out, Art has designed assignments for students to make work theirs, put personal touch on projects, and build things that are meaningful.
Programming is about making the computer do what you want it to do. So personalize your projects. Make them fun. Make them unique. When students can make it theirs, you tap into another kind of creative design and drive.
Recursion is a critical programming concept, but it can be pretty abstract. In Mikaela’s words, her first introduction to recursion was, “Wow, this must be super complicated.”
But Art showed students fractals and prompted students to create their own. With a touch of Algebra and looking at a few lines of sample code, Mikaela jumped in to make her own Sierpinski Triangle.
Now Mikaela is even looking at nature differently.
Whenever I think of recursion, now I think of nature and tree rings, Mr. Simon showed us this picture of a leaf that is a leaf inside of a leaf inside of a leaf type thing. I think I’ve seen it in a lot of plants now that I think about it.
Art encourages his students to look at similar projects on GitHub for inspiration and to ask other students for input.
Mikaela reflects on this blend of studio feedback and peer learning:
Having people that I talk to is really nice because, you can just say, “Oh, that would be really cool in your program.” And someone will tell me, “Oh yeah that would be cool in your program, too.”
Mikaela built on what she’d learned in Java programming for her future assignment Asteroids.
He structures the assignments in terms of milestones, layering in a different element or feature of the project at each turn.
In Mikaela’s Asteroids game, we’re using object oriented programming techniques that build up and adds features. We get the ship working first. That’s milestone number one. We get the asteroids on the screen. That’s milestone number two. We get the ability to remove asteroids and look for collisions. That’d be milestone number three. Then we add bullets, and you got a working game.
Since everyone’s project is unique, Art isn’t concerned about dishonesty—as long as students can explain what is going on in the program, they’ve mastered the material.
People are going to create objects that explode differently and encounter collision detection differently.
Mikaela has run out of computer science courses to take at Lowell, but she participates in an after-school program called Mission Bit and plans to continue with an engineering internship this summer. And Mr. Simon’s approach to teaching has made all the difference:
I have to compliment Mr. Simon because I was a complete beginner in all of this stuff when I came into it, and he taught me everything, which is pretty cool because now I know so much.
This is a post in our “Teacher Spotlight” series, where we share ways teachers use GitHub in their classrooms.