How many students can help solve urgent problems within weeks of writing their first lines of code?
In Taichi Furuhashi’s “Introduction to Spatial Information Systems I” at Aoyama Gakuin University in Japan, students collaborate with organizations like the American Red Cross, the World Bank, the United Nations and the Japan International Cooperation Agency.
For Furuhashi, President of CrisisMappers Japan, student engagement and active learning are his primary design principles. The relatively new program helps students work together to make new tools that solve big problems.
Furuhashi’s courses have been dedicated to alleviating disasters, and his students work on different aspects of providing accurate and up-to-the-minute data to aid in relief to NGOs and industry partners.
Design principles behind the School of Global Studies and Collaboration.
In July of 2017 the Asakura City region of Japan was hit with heavy rains and flooding. Whole sections of southern Japan were impassible, and residents urgently needed resources like water and food.
Organizations like the Red Cross used the Humanitarian OpenStreetMap Team’s tasking manager (called HOT for short) to post requests for analysis of affected regions.
Students in Taichi’s class accept a request for mapping help from the Humanitarian Open Street Map tasking manager (a.k.a. HOT).
Photos of the affected regions come in via probe drone, satellite, or panoramic camera. Students draw polygons on maps that match up with these photos to show affected regions, like mudslides, downed forests, or collapsed bridges. Then they export the GeoJSON data to a GitHub Gist file (like this one) and send the analysis back to organizations the Red Cross via HOT.
This map captures the heavy rain caused by Typhoon No. 3 on June 30, 2007. It’s based on images taken by helicopter by the Ministry of Land, Infrastructure and Transport. The polygons and lines indicate potentially impassable roads due to mudslide and the general reach of the flood.
The contributions that students make—their polygons and data analysis—can help authorities decide where to send resources and find flood and landslide victims. By helping local crises, the work of the class is always relevant and urgent.
As the Director of OpenStreetMap Foundation Japan, Furuhashi involves students directly in the open source communities he’s a part of. This means mastering the GitHub flow, using GitHub Pages to make portfolio sites, and participating in open source communities.
He produced a slide deck to help onboard students to the world of GitHub and introduce them to the world of open source. The slides are, naturally, under an open license: CC BY-SA 4.0.
If you’re looking for a real-world approach to computer science education in Germany, you can find it at the Hasso Plattner Institute (HPI) in Potsdam, which offers a practical and engineering-oriented alternative to conventional computer science programs.
In one of HPI’s undergraduate software engineering courses, researchers Arian Treffer and Christoph Matthies encourage their students to make mistakes, assess where they get stuck, and reflect on their software development process. This way students learn how to deliver the best possible results when working together.
The final year undergraduate course “Software Engineering II” features a real-world software development challenge: 20-30 participants jointly develop a single system. Students form small development teams and coordinate within as well as with the other student’s teams. Tutoring, lectures and an introductory exercise are offered alongside the project. All code is published on GitHub under an open source license. Christoph says:
When you leave here, you should have an idea of how to develop software in a team. It’s likely that you’ll work with others on some outdated legacy system in your later work life. As long as people have the ability to reflect on how their process, they are more likely to succeed in whatever they want to do.
Arian adds, “If you don’t practice good communication and you work in a setting with multiple teams, frustration is inevitable. The first time your code is thrown away because someone else has already completed your ticket is an important learning experience.”
Focusing on communication and self-organization shapes how students start coding: commit often, write clear commit messages, and learn from your mistakes. But first, students learn the basic tools and processes needed in an introductory exercise. However, managing these exercises for many students—and checking them manually—can get tedious.
Professor CI introduces students to technical tools using GitHub’s continuous integration services.
Participants work on their own repositories in Github and receive feedback and new challenges from the CI server when they push their code.
Arian is quick to note that using CI to help students fix their problems isn’t completely novel. The innovation, he says, is in how they use Professor CI with GitHub.
What is novel is using GitHub issues to motivate people and basically get them into the habit of tackling issues, writing tests and fixing bugs. If an Issue is done, you’re automatically sent another one that progresses the exercise—this is the new part. Prof. CI simulates a customer requesting new features, changes and bugfixes.
Summary of time from acceptance to completion of student tasks via Professor CI. For more details on the design and implementation, see the corresponding paper.
With Professor CI, students can work on their local machines, using their local development tools, and get the benefit of quick feedback from instructors. In turn, instructors have insight into students’ processes and code.
Christoph adds, “Automation is great for standardized exercises, but in the actual development project that follows, we rely heavily on human interaction.”
Building software in teams requires talking to real humans, so the next step in the course is gathering clear and concrete requirements from a stakeholder. As anyone who builds software knows, that’s easier said than done.
Instead of giving students clear requirements for their final project, Treffer and Matthies assign a co-worker the role of the customer, whose primary job is to—well—be a customer.
He throws ridiculous requirements at the students, and changes his mind constantly. Then the students have to get out of the customer what to build. They don’t get requirements. And the development process and all of its artifacts, they have to manage on their own.
This approach ensures that budding engineers get the close-to-real-world experience that the HPI hopes to instill. They develop real skills in listening, negotiating, and communicating that will help them code solid products and reduce wasted effort, wherever their degree takes them.
Treffer notes that students often think that development is chugging along better than it is, because they don’t yet have the experience required to identify problems as they arise. Milestones serve as natural points of reflection at which the group can work together to make processes better. They also closely monitor students, both with tutors and using GitHub tools to make sure they don’t deviate too much from development best practices.
Treffer and Matthies use a variety of exercises that help students find out what worked, what didn’t, and how to make next time better. The Sailboat is an exercise that students use to reflect on the development process.
In this exercise, the sun is what went right and the wind is what pushed the team in the right direction. The anchor represents what slowed the team down, and the rocks, of course, are potential future problems. Marking each feature of the boat scene allows the group to candidly diagnose how they work together.
Reflection exercises allow the students to get closer to one another and their professors to more intimately understand their students. Being able to collectively analyze and discuss what went right and what went wrong allows for some resolution to what might have been a rough sail. It also helps students learn how to collectively develop a process that will, ultimately, create better software and more efficient development time with minimal waste.
Basically, the most important aspect of our lecture is that students learn to apply what they’re doing to identifying problems with their development process and learn how to improve the process. It’s about figuring out which process works best for your team and context.
Applications are open for summer internships at GitHub. As an intern at GitHub’s San Francisco headquarters you’ll spend ten weeks from June to August working with a team in engineering, product, security, sales, marketing, or design.
Every GitHub intern has the opportunity to make an impact by working on real projects with mentorship from experienced GitHub employees. Interns have worked on projects ranging from adding embedded code snippits to deadlines and rosters for GitHub Classroom and The state of the Octoverse.
To help give you a better idea of what to expect from interning at GitHub, the class of 2017 has written a letter to future GitHub interns:
If you’re reading this letter, you’ve made the first step towards gaining the professional experience of a lifetime—at a place that values you—your ideas, creativity, life experiences, and individuality.
The GitHub internship program is open to all students enrolled in a university, community college, associate, or graduate school program. You can apply directly on our website for any of the following 2018 summer internship positions:
Bard College is not a technical research university. In fact, when students arrive on campus, most say they’ve had no experience with computer science.
Professors Keith O’Hara and Sven Anderson aim to change this during students’ first week on campus. Every student starts their liberal arts experience with the Language and Thinking program in which O’Hara asks them to think, express ideas, and create an artifact with code.
Anderson and O’Hara’s novel pedagogy makes programming accessible and appealing to philosophy majors and poets. Here are three of their methods to try with your nontechnical students.
“The mathematician, like the poet, works only slightly removed from pure thought-stuff. He builds his museums in the atmosphere, from atmosphere, creating by toil of the imagination.”—Fred Brooks, mathematician
Keith introduces his class to the world of code by using JS Bin to remix HTML pages. Then students build confidence by seeing the direct output of their changes as they work. First they change a link, then the stylesheet, then work up to adding their own graphics. In the first workshops, they also learn how to use GitHub to host media files from fellow students.
We can use code to speak to machines, to each other, and to the world around us. To prime students to think about these complex relationships, O’Hara points to the first chatterbot ELIZA, a parody of a psychotherapist as a human-machine communication system. Humans input their thoughts and feelings, the machine responds to their input, and the relationship blooms out of the design of the software.
In a second workshop, students write algorithms to generate poetry, make a robot sing and dance, or create virtual fish for a group fish tank.
In these workshops, Keith provides clear and functional code for students to customize and enhance.
In these coding studios, students were exposed to how computing can be the ultimate medium—the meta-medium—allowing us to express ourselves in new ways with motion, sound, graphics, and text.
In the first assignment, Keith asks students to collect and share URLs from a free-write. To help them understand how link structures work, he gives students balls of yarn. Then they toss yarn around the room to show connections between their sites.
Later, they exchange wooden nickels to explore the algorithm that powers Google Search, sharing their “money” with those the sites they link to and an instructor who further divvies up the pot.
The wooden nickels act as currency for power or authority; the exchange of these nickels simulated how power is distributed ad accumulated in the network.
What is the impact of these creative assignments? And why would Bard implement a computing element in their orientation?
Keith’s answer: to change attitudes towards computer science. To make significant strides in the diversity of computing, we need to connect computing to other disciplines, like art and biology.
First impressions are critical, and we expect that this brief exposure to computer science will have its most signicant impact on students when they make decisions about whether to engage computing in courses and employment opportunities. An increased familiarity with computing may allow them to entertain it as part of a viable pathway for their future.
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.