Announcing the Google Code-in 2016 Winners!

Drum roll please! We are very proud to announce the 2016 Google Code-in (GCI) Grand Prize Winners and Finalists. Each year we see the number of student participants increase, and 2016 was no exception: 1,340 students from 62 countries completed an impressive 6,418 tasks. Winners and Finalists were chosen by the 17 open source organizations and are listed alphabetically below.

First is a list of our Grand Prize winners. These 34 teens completed an astounding 842 total tasks. Each Grand Prize winner will be flown to the Google campus for four days this summer to meet with Google engineers and enjoy the Bay Area.

GRAND PRIZE WINNERS

Name	Organization	Country
Matthew Marting	Apertium	United States
Shardul Chiplunkar	Apertium	United States
Michal Hanus	BRL-CAD	Czech Republic
Sudhanshu Agarwal	BRL-CAD	India
Alexandru Bratosin	CCExtractor Development	Romania
Evgeny Shulgin	CCExtractor Development	Russian Federation
Joshua Pan	Copyleft Games Group	United States
Shriank Kanaparti	Copyleft Games Group	India
Dhanat Satta-awalo	Drupal	Thailand
Utkarsh Dixit	Drupal	India
Kaisar Arkhan	FOSSASIA	Indonesia
Oana Roşca	FOSSASIA	Romania
Raefaldhi Amartya Junior	Haiku	Indonesia
Vanisha Kesswani	Haiku	India
Ilya Bizyaev	KDE	Russian Federation
Sergey Popov	KDE	Russian Federation
Anshuman Agarwal	MetaBrainz	India
Daniel Hsing	MetaBrainz	Hong Kong
Dhruv Shrivastava	Mifos	India
Sawan Kumar	Mifos	India
Ong Jia Wei, Isaac	Moving Blocks	Singapore
Scott Moses Sunarto	Moving Blocks	Indonesia
Mira Yang	OpenMRS	United States
Nji Collins	OpenMRS	Cameroon
Cristian García	Sugar Labs	Uruguay
Tymon Radzik	Sugar Labs	Poland
August van de Ven	SCoRe	Netherlands
Deniz Karakay	SCoRe	Turkey
Jacqueline Bronger	Systers	Germany
Soham Sen	Systers	India
Filip Grzywok	Wikimedia	Poland
Justin Du	Wikimedia	United States
Sampriti Panda	Zulip	India
Tommy Ip	Zulip	United Kingdom

And below are the Finalists. Each of these 51 students will receive a digital certificate of completion, a GCI t-shirt and hooded sweatshirt.

FINALISTS

Name	Organization
Bror Hultberg	Apertium
Kamil Bujel	Apertium
Ngadou Sylvestre	Apertium
Apratim Ranjan Chakrabarty	BRL-CAD
Tianyue Gao	BRL-CAD
Trung Nguyen Hoang	BRL-CAD
Danila Fedorin	CCExtractor Development
Manveer Basra	CCExtractor Development
Matej Plavevski	CCExtractor Development
Daniel Wee Soong Lim	Copyleft Games Group
Jonathan Pan	Copyleft Games Group
Oscar Belletti	Copyleft Games Group
Ashmith Kifah Sheik Meeran	Drupal
Heervesh Lallbahadur	Drupal
Neeraj Pandey	Drupal
Adarsh Kumar	FOSSASIA
Ridhwanul Haque	FOSSASIA
Sanchit Mishra	FOSSASIA
Dmytro Shynkevych	Haiku
Stephanie Fu	Haiku
Tudor Nazarie	Haiku
Harpreet Singh	KDE
Sangeetha S	KDE
Spencer Brown	KDE
Daniel Theis	MetaBrainz
Divya Prakash Mittal	MetaBrainz
Tigran Kostandyan	MetaBrainz
Illia Andrieiev	Mifos
Justin Du	Mifos
Tan Gemicioglu	Mifos
J Young Kim	Moving Blocks
Maxim Borsch	Moving Blocks
Quinn Roberts	Moving Blocks
Shivani Thaker	OpenMRS
Tenzin Zomkyi	OpenMRS
Yusuf Karim	OpenMRS
Emily Ong Hui Qi	Sugar Labs
Euan Ong	Sugar Labs
Pablo Salomón Ortega Quintana	Sugar Labs
Basil Najjar	SCoRe
Jupinder Parmar	SCoRe
Thuận Nguyễn	SCoRe
Muaaz Kasker	Systers
Muhammed Shamil K	Systers
Phoebe Fletcher	Systers
David Siedtmann	Wikimedia
Nikita Volobuev	Wikimedia
Yurii Shnitkovskyi	Wikimedia
Cynthia Lin	Zulip
Rafid Aslam	Zulip
Robert Hönig	Zulip

The Google Open Source Programs Office is proud to run this contest each year. The quality of work from our participating students is incredible, and each year we look forward to meeting our Grand Prize winners in person. It’s exciting to see the next generation of coders emerge! We also owe a huge debt of gratitude to all of the mentors who helped guide each of the participants through their tasks. Without their tireless work over the past 7 weeks, GCI would not be possible.

Stay tuned to the open source blog - we’ll regularly post Google Code-in 2016 stories in the upcoming months including a full breakdown of contest statistics, wrap-up posts from the organizations, student highlights and more.

By Mary Radomile, Open Source Programs Office

Join the POSSE Workshop on Student Involvement in Humanitarian Free and Open Source Software

Are you a university or college instructor interested in providing students with experience in real-world projects? Are you interested in supporting participation in humanitarian free and open source software (HFOSS)? If so, join the Professor's Open Source Software Experience (POSSE) workshop being held at Google’s San Francisco Office, April 20-22, 2017.

Over 100 faculty members have attended past workshops and there is a growing community of faculty members helping students learn within HFOSS projects. This three-stage faculty workshop will prepare you to support student participation in open source projects. In the workshop, you will:

• Become part of the community of educators which involves students in HFOSS
• Learn how to support student learning within real-world project environments
• Motivate students and raise their appreciation of computing for social good
• Meet and collaborate with instructors who have similar interests and goals

Workshop Format

Stage 1: Starts February 23, 2017 with online activities. These activities will take 2-3 hours per week and include interaction among workshop instructors and participants.

Stage 2: The face-to-face workshop will be held at the Google San Francisco office, April 20-22, 2017. Participants include the workshop organizers, POSSE alumni and members of the open source community.

Stage 3: Comprises online activities and interactions among small groups. Participants will have support while involving students in an HFOSS project in the classroom.

Please click here to learn more about the POSSE workshop in April.

How to Apply

To apply, please complete and submit the application by February 13th. Prior work with FOSS projects is not required. The POSSE workshop committee will send you a confirmation email to notify you of the status of your application by February 23rd, 2017.

Participant Support

POSSE is supported by the National Science Foundation (NSF) and Google. NSF funding will provide two nights lodging and meals during the workshop. Travel costs will be covered up to $500. At this time,we can only support US-based faculty members. However, if you can support your own travel, please do submit an application!

Why is Google participating?

Google is participating in order to help educators overcome challenges identified in the POSSE workshop held last June, and to better support FOSS education in academia. We are very happy to host the first POSSE workshop located on the west coast of the United States.

See you in San Francisco this April!

By Helen Hu, Open Source Programs Office

Google Summer of Code 2016 wrap-up: Orange

This post is part of our ongoing series of guest posts from the students, mentors and organization administrators who participated in Google Summer of Code (GSoC). GSoC is a program that pairs university students with mentors for a summer where they apply their computer science skills to building open source software.

Orange Data Mining is a data mining suite with visual programming and interactive data analysis at its core. Orange was developed at Bioinformatics Lab at University of Ljubljana, Slovenia, it is written mainly in Python, and you can find it hosted on GitHub.

This was our third Google Summer of Code and we were given five slots and decided to select students based on two criteria: their proposal joined with their coding skills and the importance of the project to our organization.

Great work was done over the summer and we are proud to present our students’ projects!

Recommender Systems add-on by Salva Carrion

Salva independently implemented a new Orange3 add-on for recommender systems. He developed a scripting library for collaborative filtering for the core of the add-on, which includes a number of published matrix factorization algorithms. The scripting library is then further extended to include GUI-based widgets for visual programming.

Educational add-on by Primož Godec

Primož took on a task of developing a series of educational widgets for Orange3. The end result was a full Orange3-Educational add-on with four widgets that can be used to demonstrate key data mining and machine learning procedures in the classroom. These widgets are useful for helping beginners understand the inner workings of key algorithms in data mining, and for teachers to be able to visually explain the various methods. They include interactive and step-by-step visualizations of k-means, polynomial classification, and gradient descent.

Text add-on by Aliaxey Sukharevich

Orange3-Text add-on was already an active project before GSoC, but Aliaxey took it to another level. Twitter and Wikipedia public RESTful services were introduced as widgets to allow acquisition of data from new sources. Many widgets were boosted with new functionalities and methods (e.g. HDP, LDA and LSP methods in Topic Modelling widget). Preprocessing was redesigned and reimplemented such that it now handles n-grams and POS Tagging.

CN2 Rule Induction by Matevž Kren

The goal of this project was to implement a CN2 rule induction algorithm, and Orange widgets for learning and exploration of inferred classification rules. At the heart of the project is an implementation of a scripting library, which can be easily extended with additional divide and conquer algorithms or its components.

Porting Orange codebase to Pandas by Sašo Stanovnik

This was a gargantuan task and Sašo handled it beautifully. The goal was to consolidate Orange data structures and management routines to support data from Pandas. Sašo redesigned Orange data management core, did a massive amount of refactoring and improvements and removed legacy and unused code. The biggest challenge was of course preserving as much compatibility with the existing Orange interaction as possible while providing full Pandas flexibility. The result is a functional Pandas-based core Orange.

All contributions were committed on GitHub (Orange3, Orange3-Text, Orange3-Recommendation and Orange3-Educational repositories) and most of them are already pip-installable. The only contribution that has not yet been merged is the migration to Pandas, which will require adaptation and careful compatibility checking of other components of the system.

We are extremely grateful to be given the chance to participate in Google Summer of Code and to have had such amazing students at our lab. We can’t wait to apply again next year!

By Ajda Pretnar, Organization Administrator for Orange

Google Summer of Code 2016 wrap-up: QEMU

This post is part of a series of guest posts from students, mentors and organization administrators reflecting on Google Summer of Code (GSoC) 2016.

QEMU is a machine emulator and virtualizer. It can run operating systems and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC).  It is also used by hypervisors like KVM and Xen to virtualize x86, ARM, POWER and other architectures so virtual machines can run at near-native performance.

This year was QEMU's sixth time participating in Google Summer of Code and we had 6 students from around the world. Here are highlights from GSoC 2016:

Pranith Kumar worked on Multi-threaded TCG, a larger effort to make QEMU's just-in-time compiler multi-core friendly. He studied the memory ordering CPU instructions for many architectures supported by QEMU and devised a TCG opcode that can represent the memory ordering semantics. His patches allow TCG to correctly translate memory ordering instructions (previously they were ignored!). This is one piece of the puzzle to support multi-threaded translation and will help emulation scale to many cores. Pranith also contributed to testing and debugging multi-threaded TCG issues that he encountered while contributing to this cutting-edge part of QEMU.

Gerard Garcia worked on packet capture support for AF_VSOCK in Linux, tcpdump and Wireshark. QEMU recently gained support for the virtio-vsock device that allows socket communication between guest and host. The AF_VSOCK address family didn't support packet capture yet, making it hard to debug and observe communication between applications. Gerard’s patches implement the kernel interfaces and tcpdump/Wireshark functionality needed to monitor traffic over AF_VSOCK. This project was challenging because it required getting code merged in multiple open source projects. Gerard pulled it off with great skill!

Every year QEMU applies to participate in GSoC and we’re delighted for the opportunity to mentor students interested in systems programming, emulation, compilers and low-level code like firmware. You are welcome to get in touch on IRC or our mailing lists any time of the year to find out about contributing to QEMU. We also have a wiki page with small tasks you can get started on as your first step in QEMU programming.

By Stefan Hajnoczi, Organization Administrator for QEMU

Now accepting organization applications for Google Summer of Code 2017

We’re heading into the 13th year of Google Summer of Code (GSoC) and are now accepting applications for open source organizations. GSoC is a global program that gets student developers involved as open source contributors. Students spend three months working under the guidance of mentors on projects to expand and improve open source software.

Last year we had 178 open source organizations and 1,200 students participate. Open source organizations include open source projects and the umbrella organizations that often serve as their fiscal sponsors.



Do you represent a free or open source software organization? Are you seeking new contributors? (Of course!) Do you love the challenge and reward of mentoring new developers in your community? Apply to be a mentor organization for Google Summer of Code! Starting today we are accepting applications from open source projects who would like to serve as mentor organizations for enthusiastic student developers.

The deadline to apply is February 9 at 16:00 UTC. Organizations chosen for GSoC 2017 will be posted on February 27.

Please visit the program site for more information on how to apply, a detailed timeline of important deadlines and general program information. We also encourage you to check out the Mentor Manual and join the discussion group. You can also learn more by exploring our series of guest posts written by mentor organizations who participated in GSoC 2016.

Best of luck to all of the applicants!

By Josh Simmons, Open Source Programs Office

Google Summer of Code 2016 wrap-up: GitHub

Every year open source organizations, mentors, and university students come together to build and improve open source software through Google Summer of Code (GSoC). This guest post is part of a series of blog posts from people who participated in GSoC 2016.

Open source maintainers at GitHub mentored 5 students in Google Summer of Code last year. The students did great work that we’d like to highlight and congratulate them on:

Updates to GitHub Classroom 

GitHub Classroom helps teachers automate their work and interact with students in issues and pull requests. Last summer two students took on projects to help teachers work more efficiently and with greater insight into their classrooms.

Classroom Project #1 

Cheng-Yu Hsu is a student who worked to implement new features suggested by teachers using GitHub Classroom, including due dates for assignment submissions and visualizations of classroom activities. In reflecting on the project, Cheng-Yu said:

"Having a great community is one of the most important factors of a successful open source project, so participating [in] the community is also a huge part of this project. It is great to have chances responding to user feedback, helping people resolve issues and brainstorming new features with them."

Classroom Project #2

Shawn Ding worked on student identifiers and team management for GitHub Classroom. This means that teachers using GitHub Classroom can use things such as student emails to identify their assignments. Teachers can also now manage their students and teams of students using GitHub Classroom via drag and drop in the settings page which then updates the data on GitHub.

Front-end controls for Jekyll

Jekyll Admin is a Jekyll plugin that provides users with a traditional CMS-like graphical interface to author content and administer Jekyll sites from the comfort of their browser. GSoC student Mert Kahyaoğlu has been using Facebook’s React framework to create the front-end that will allow you to write a new post, edit existing pages or add new files. And it will all work with GitHub Pages.

Best of all, Mert's plugin allows people to author content and administer Jekyll sites without knowledge of command line or installing an external text editor like Atom. Once installed, Jekyll users start their site as they would normally and simply append “/admin” to their site's URL to launch the WordPress-like administrative interface. Jekyll Admin's initial release is ready for use on your own site.

Octokit.net 

Alexander Efremov added support to Octokit.net for interacting with the GitHub API using a repository ID, alongside the existing support for providing the owner and repository name. This means integrators do not have to update their systems when a repository changes ownership. The changes to support these APIs were rolled out incrementally over a number of pull requests, and 0.21 release of Octokit.net made these new APIs available to the public.

We had a great time mentoring these students on their projects last year!

By Carol Smith, John Britton and Brandon Keepers, Organization Administrators for GitHub

Google Code-in 2016: another record breaking year

Today we celebrate the closing of the 7th annual Google Code-in (GCI) which, like last year, was bigger and better than ever. Mentors from each of the 17 organizations are busy reviewing the last of the work submitted by student participants.

Each organization will pick two Grand Prize Winners who will receive a trip to Google’s Northern California headquarters this summer where they will meet Google engineers, see exciting demos and presentations and enjoy a day of adventure in San Francisco. You can learn about the experiences of the 2015 Grand Prize Winners in our short series of wrap-up blog posts. We’ll announce the new Grand Prize Winners and the Finalists here on January 30.

We would like to congratulate all of the new and returning students who participated this year. We’re thrilled with the turnout: over the last seven weeks, 1,374* students from 62 countries completed 6,397* tasks in the contest.

And a HUGE thanks to the people who are the heart of our program: the mentors and organization administrators. These volunteers spend countless hours creating and reviewing hundreds of tasks. They teach the young students who participate in GCI about the many facets of open source development, from community standards and communicating across time zones to version control and testing. We couldn’t run this program without you!

By Josh Simmons, Open Source Programs Office

* These numbers will increase over the coming days as mentors review the final work submitted by students.

Introducing Draco: compression for 3D graphics

3D graphics are a fundamental part of many applications, including gaming, design and data visualization. As graphics processors and creation tools continue to improve, larger and more complex 3D models will become commonplace and help fuel new applications in immersive virtual reality (VR) and augmented reality (AR).  Because of this increased model complexity, storage and bandwidth requirements are forced to keep pace with the explosion of 3D data.

The Chrome Media team has created Draco, an open source compression library to improve the storage and transmission of 3D graphics. Draco can be used to compress meshes and point-cloud data. It also supports compressing points, connectivity information, texture coordinates, color information, normals and any other generic attributes associated with geometry.

With Draco, applications using 3D graphics can be significantly smaller without compromising visual fidelity. For users this means apps can now be downloaded faster, 3D graphics in the browser can load quicker, and VR and AR scenes can now be transmitted with a fraction of the bandwidth, rendered quickly and look fantastic.

Sample Draco compression ratios and encode/decode performance*

Transmitting 3D graphics for web-based applications is significantly faster using Draco’s JavaScript decoder, which can be tied to a 3D web viewer. The following video shows how efficient transmitting and decoding 3D objects in the browser can be - even over poor network connections.


Public domain Discobolus model from SMK National Gallery of Denmark.

Video and audio compression have shaped the internet over the past 10 years with streaming video and music on demand. With the emergence of VR and AR, on the web and on mobile (and the increasing proliferation of sensors like LIDAR) we will soon be swimming in a sea of geometric data. Compression technologies, like Draco, will play a critical role in ensuring these experiences are fast and accessible to anyone with an internet connection. More exciting developments are in store for Draco, including support for creating multiple levels of detail from a single model to further improve the speed of loading meshes.

We look forward to seeing what people do with Draco now that it's open source. Check out the code on GitHub and let us know what you think. Also available is a JavaScript decoder with examples on how to incorporate Draco into the three.js 3D viewer.

By Jamieson Brettle and Frank Galligan, Chrome Media Team

* Specifications: Tests ran with textures and positions quantized at 14-bit precision, normal vectors at 7-bit precision. Ran on a single-core of a 2013 MacBook Pro.  JavaScript decoded using Chrome 54 on Mac OS X.

JanusGraph connects the past and future of Titan

We are thrilled to collaborate with a group of individuals and companies, including Expero, GRAKN.AI, Hortonworks and IBM, in launching a new project — JanusGraph — under The Linux Foundation to advance the state-of-the-art in distributed graph computation.

JanusGraph is a fork of the popular open source project Titan, originally released in 2012 by Aurelius, and subsequently acquired by DataStax. Titan has been widely adopted for large-scale distributed graph computation and many users have contributed to its ongoing development, which has slowed down as of late: there have been no Titan releases since the 1.0 release in September 2015, and the repository has seen no updates since June 2016.

This new project will reinvigorate development of the distributed graph system to add new functionality, improve performance and scalability, and maintain a variety of storage backends.

The name "Janus" comes from the name of a Roman god who looks simultaneously into the past to the Titans (divine beings from Greek mythology) as well as into the future.

All are welcome to participate in the JanusGraph project, whether by contributing features or bug fixes, filing feature requests and bugs, improving the documentation or helping shape the product roadmap through feature requests and use cases.

Get involved by taking a look at our website and browse the code on GitHub.

We look forward to hearing from you!

By Misha Brukman, Google Cloud Platform

Apache Beam graduates to a top-level project

Please join me in extending a hearty digital “Huzzah!” to the Apache Beam community: as announced today, Apache Beam is an official graduate of the Apache Incubator and is now a full-fledged, top-level Apache project. This achievement is a direct reflection of the hard work the community has invested in transforming Beam into an open, professional and community-driven project.

11 months ago, Google and a number of partners donated a giant pile of code to the Apache Software Foundation, thus forming the incubating Beam project. The bulk of this code composed the Google Cloud Dataflow SDK: the libraries that developers used to write streaming and batch pipelines that ran on any supported execution engine. At the time, the main supported engine was Google’s Cloud Dataflow service with support for Apache Spark and Apache Flink in development); as of today there are five officially supported runners. Though there were many motivations behind the creation of Apache Beam, the one at the heart of everything was a desire to build an open and thriving community and ecosystem around this powerful model for data processing that so many of us at Google spent years refining. But taking a project with over a decade of engineering momentum behind it from within a single company and opening it to the world is no small feat. That’s why I feel today’s announcement is so meaningful.

With that context in mind, let’s look at some statistics squirreled away in the graduation maturity model assessment:

• Out of the ~22 large modules in the codebase, at least 10 modules have been developed from scratch by the community, with little to no contribution from Google.
• Since September, no single organization has had more than ~50% of the unique contributors per month.
• The majority of new committers added during incubation came from outside Google.

And for good measure, here’s a quote from the Vice President of the Apache Incubator, lifted from the public Apache incubator general discussions list where Beam’s graduation was first proposed:

“In my day job as well as part of my work at Apache, I have been very impressed at the way that Google really understands how to work with open source communities like Apache. The Apache Beam project is a great example of this and is a great example of how to build a community." -- Ted Dunning, Vice President of Apache Incubator

The point I’m trying to make here is this: while Google’s commitment to Apache Beam remains as strong as it always has been, everyone involved (both within Google and without) has done an excellent job of building an open source project that’s truly open in the best sense of the word.

This is what makes open source software amazing: people coming together to build great, practical systems for everyone to use because the work is exciting, useful and relevant. This is the core reason I was so excited about us creating Apache Beam in the first place, the reason I’m proud to have played some small part in that journey, and the reason I’m so grateful for all the work the community has invested in making the project a reality.

Naturally, graduation is only one milestone in the lifetime of the project, and we have many more ahead of us, but becoming top-level project is an indication that Apache Beam now has a development community that is ready for prime time.

That means we’re ready to continue pushing forward the state of the art in stream and batch processing. We’re ready to bring the promise of portability to programmatic data processing, much in the way SQL has done so for declarative data analysis. We’re ready to build the things that never would have gotten built had this project stayed confined within the walls of Google. And last but perhaps not least, we’re ready to recoup the vast quantities of text space previously consumed by the mandatory “(incubating)” moniker accompanying all of our initial mentions of Apache Beam!

But seriously, whatever your motivation, please consider joining us along the way. We have an exciting road ahead.

By Tyler Akidau, Apache Beam PMC and Staff Software Engineer at Google

Google Summer of Code 2016 wrap-up: Oppia

Google Summer of Code (GSoC) is an annual program that encourages university students to become open source contributors. This guest post is part of a series of blog posts from the open source projects and organizations that participated in GSoC 2016.

The Oppia project makes it easy for anyone to create lightweight, interactive online lessons that simulate personal tutoring. These activities, called “explorations,” can be shared with others around the world as standalone tutorials (such as Programming with Carla and Quadratic Equations), or embedded in websites to supplement an existing course (such as “Take Your Medicine” on edX and Computational Thinking for Educators).

2016 was Oppia’s first year participating in GSoC and it was a blast! More students flocked to our ideas page than we had expected, and our Gitter channel was full of people saying hello and looking for starter projects. Over the course of the summer, with the help of two capable and enthusiastic students, we were able to bring the following new features to the Oppia codebase:

A new creator dashboard -- Avijit Gupta


An important principle of Oppia is that lessons can be easily improved over time -- it’s hard to figure out all the possible ways a student can go wrong at the outset, but it’s much easier to respond appropriately to a new misconception that arises.

Each creator on Oppia has a “creator dashboard” which allows them to see the lessons they’ve created, as well as the feedback they’ve received from learners. Avijit completed a full revamp of this page, updating its design (for both desktop and mobile) and finding ways to display all the necessary information in an intuitive way so that creators can easily improve their lessons while getting feedback on their teaching.

The new creator dashboard.

In addition, Avijit added functionality allowing creators to view student misconceptions that were not well-addressed, to make it easier for them to improve the feedback for those answers. He has continued to help out with the Oppia open source project as a maintainer and reviewer, even after GSoC, and is mentoring other contributors who are working on further improvements to the creator dashboard. You can read more about the project in his GSoC writeup!

Speed improvements -- Vishal Gupta


In order to improve the accessibility of lessons for students with poor internet connectivity, Vishal’s project aimed to make Oppia speedier and less bandwidth-intensive. He started by implementing a performance testing framework to benchmark his efforts, and also integrated it with our continuous integration system in order to protect against performance regressions. He then turned his efforts to caching as many static resources as possible, implementing a cache slug system that causes new files to be downloaded only after a new release is made.

In addition, Vishal removed JavaScript code that was inlined in the main templates, and refactored it out into an external script which could then be cached for better performance. You can read more about this project in his post on the Oppia blog.

We’d like to extend our grateful thanks not only to Avijit and Vishal, but also to our many willing and enthusiastic mentors, and to Google for supporting our open source work with GSoC.

Join us in helping improve educational opportunities for students around the world. If you’d like to subscribe to news and updates about Oppia’s participation in GSoC, you can sign up to the oppia-gsoc-announce mailing list -- or, if you’re already feeling enthusiastic, you can start helping out with the project right away!

By Ben Henning and Sean Lip, Organization Administrators for Oppia

Grumpy: Go running Python!

Google runs millions of lines of Python code. The front-end server that drives youtube.com and YouTube’s APIs is primarily written in Python, and it serves millions of requests per second! YouTube’s front-end runs on CPython 2.7, so we’ve put a ton of work into improving the runtime and adapting our application to work optimally within it. These efforts have borne a lot of fruit over the years, but we always run up against the same issue: it's very difficult to make concurrent workloads perform well on CPython.

To solve this problem, we investigated a number of other Python runtimes. Each had trade-offs and none solved the concurrency problem without introducing other issues.

So we asked ourselves a crazy question: What if we were to implement an alternative runtime optimized for real-time serving? Once we started going down the rabbit hole, Go seemed like an obvious choice of platform since its operational characteristics align well with our use case (e.g. lightweight threads). We wanted first class language interoperability and Go’s powerful runtime type reflection system made this straightforward. Python in Go felt very natural, and so Grumpy was born.

Grumpy is an experimental Python runtime for Go. It translates Python code into Go programs, and those transpiled programs run seamlessly within the Go runtime. We needed to support a large existing Python codebase, so it was important to have a high degree of compatibility with CPython (quirks and all). The goal is for Grumpy to be a drop-in replacement runtime for any pure-Python project.

Two design choices we made had big consequences. First, we decided to forgo support for C extension modules. This means that Grumpy cannot leverage the wealth of existing Python C extensions but it gave us a lot of flexibility to design an API and object representation that scales for parallel workloads. In particular, Grumpy has no global interpreter lock, and it leverages Go’s garbage collection for object lifetime management instead of counting references. We think Grumpy has the potential to scale more gracefully than CPython for many real world workloads. Results from Grumpy’s synthetic Fibonacci benchmark demonstrate some of this potential:



Second, Grumpy is not an interpreter. Grumpy programs are compiled and linked just like any other Go program. The downside is less development and deployment flexibility, but it offers several advantages. For one, it creates optimization opportunities at compile time via static program analysis. But the biggest advantage is that interoperability with Go code becomes very powerful and straightforward: Grumpy programs can import Go packages just like Python modules! For example, the Python snippet below uses Go’s standard net/http package to start a simple server:

from __go__.net.http import ListenAndServe, RedirectHandler

handler = RedirectHandler('http://github.com/google/grumpy', 303)
ListenAndServe('127.0.0.1:8080', handler)

We’re excited about the prospects for Grumpy. Although it’s still alpha software, most of the language constructs and many core built-in types work like you’d expect. There are still holes to fill — many built-in types are missing methods and attributes, built-in functions are absent and the standard library is virtually empty. If you find things that you wish were working, file an issue so we know what to prioritize. Or better yet, submit a pull request.

Stay Grumpy!

By Dylan Trotter, YouTube Engineering

Rails Girls Summer of Code: Changing the face of tech

This is a guest post from Laura Gaetano who organizes Rails Girls Summer of Code, a global fellowship program inspired by Google Summer of Code.

Have you seen that picture of Margaret Hamilton, the NASA engineer who worked on the computer systems for the Apollo 11 launch? She’s standing next to the human-sized pile of listings of the Apollo Guidance Computer source code that she worked on. Do you know about Ada Lovelace, often cited as the very first computer programmer?

From World War II until the 1980s, women engineers and women computer operators were fairly common. There was a steady rise in women entering STEM fields, and young girls had role models and strong women to look up to. We're well acquainted with the drop in female engineering graduates worldwide after this time period, and the subsequent drop in the percentage of women entering the world of tech. We're here to help change that, and reverse the trend.

Rails Girls Summer of Code (RGSoC) aims to bring more diversity into the world of tech — specifically, into the world of open source software, where women make up a mere 11% of the community. The global program offers 3-month scholarships to teams of women to allow them to work full-time on an open source project of their choice – aided by local coaches and guided by the project maintainer (or a core contributor). The scholarships are funded through the support of the community as well as our sponsors, via a crowdfunding campaign.

Local vs. Global
We all cherish our local community and understand how strong of a support network it can be, especially for newcomers. The Rails Girls chapters worldwide emphasize that need: most coaches and organisers are local, and many alums go on to create their own study groups, or become coaches or organisers themselves. RGSoC also relies strongly on a global network of user groups — both Rails Girls chapters and similar organisations such as PyLadies or DjangoGirls.

Thanks to our connections with these different groups, we are able to reach people in remote or unlikely locations, and build the most diverse group of applicants possible. This is very important to us. Since the beginning, the program has provided the opportunity to bring together women with different experiences, backgrounds, locales and age groups to come together and be part of the same global initiative.

Our Structure
Last year, we received over 90 team applications. When applying, each two-person team chooses from a list of pre-selected projects. These projects are maintained by people we either personally know, or who have reached out to us prior to the application period. We look for projects with patient, open-minded contributors who are active in their community, and projects that provide a lot of learning opportunities for applicants.

Project maintainers (also called mentors) are in touch with students in order to adapt the roadmap throughout the summer to the students' needs and check up on their progress. On a daily basis, students spend the majority of their time with coaches. The coaches help, support, and teach the students throughout the summer. Each team is also appointed a supervisor, who supports students on the organisational side of things. They are the glue that keeps the whole team together, and a way for the core RGSoC team to keep track of how every team is doing.

Our Stats
Our program started in 2013 with 18 teams, 10 of which were sponsored and 8 of which were volunteer teams. The following year, 16 teams participated with 10 sponsored spots. The real breakthrough came in 2015 when we were able to fund 16 sponsored teams, a substantial increase from the previous years. Not only did this enable us to have more impact — with a potential 12 more women entering the tech world and STEM workforce than the previous years — but it also shows the community’s trust in the program.

In 2016, the Ruby community awarded us with a Ruby Hero Award, and we managed to collect enough money to sponsor 16 teams from five continents with another 4 teams joining as volunteers. This year was also the first time we had teams based in Uganda, Egypt, Singapore and the Czech Republic.

Our stats from 2016 (Image: Laura Gaetano/RGSoC)

In 2015, we contacted our alums from 2013 and 2014 to find out what they were doing after the program. The responses were impressive: out of 64 graduates, over 90% are now currently working in the tech field. A fair number of graduates have even founded their own startup. Not only that some of these women have found their calling, but we might have made a small difference in the community of open source, and are on the right track to really shake things up.

Where do we go from here
On the first of July last year, we kicked off our program with over 130 people participating — including coaches, supervisors, designers, helpdesk coaches and project mentors. We were incredibly excited to have 20 teams in 16 cities and 11 different countries, spanning time zones, from UTC+10 to UTC-7.

Our 2016 sponsored and volunteer teams! (Image: Ana Sofia Pinho/RGSoC)

We’ve seen in the past just how much of an impact we’ve had in our participants’ lives, and are hoping that this trend will continue to rise. We hope that some of our previous editions' teams graduated with the skills and confidence to become NASA engineers, web developers, or anything else they want to be. Hopefully someday they will become a young woman’s role model, and realise the important role they served in changing the future of engineering and of open source software.

By Laura Gaetano, Organizer of Rails Girls Summer of Code