Google Data

Google Code-in is our annual contest that gives students age 13 to 17 experience in computer science through contributions to open source projects. This blog post is the third installment in our series reflecting on the experiences of Google Code-in 2015 grand prize winners. Be sure to check out the first and second posts in the series, too.

In this post we look at the stories of three more Google Code-in (GCI) grand prize winners. Our grand prize winners come from a pool of 980 students from 65 countries who, all told, completed 4,776 tasks for 14 open source projects.

We were lucky enough to host many of these extraordinary young coders at Google HQ for a few days this summer. Over that time, we learned more about where they came from, what they gained by participating in GCI and what they plan to do as new members of the open source community.

Google Code-in 2015 Grand Prize Winners explore the SF Bay Area in this immersive Google Street View display with fellow open source program managers Stephanie Taylor and Cat Allman who run GCI.

Our first story today is that of Břetislav Hájek from the Czech Republic, who chose to work with the OpenMRS project because he sees their work as important. OpenMRS is an open source medical record system that improves healthcare delivery in resource-constrained regions.

Břetislav got into computer science through web development, so he started by working on tasks related to HTML and CSS. This gave him confidence to take on more challenging tasks. His favorite task was creating a web application for searching through patients. While he didn’t find it hard, he learned a lot and was proud to have made something useful. Reflecting on Google Code-in, Břetislav said: “That’s the thing I like about GCI. I always treat tasks as opportunities to learn something new. And the learning is more entertaining since I work on real problems.”

IRC communication proved to be an important part of Břetislav’s success. Other students were there and tried to help each other out as best they could, and there were always mentors available to help guide them. He enjoyed the friendly environment. The community motivated him to work harder and try new things. In the end, Břetislav was glad to have participated and is motivated to continue his work.

Next we have Vicente Bermudez from Uruguay who discovered Google Code-in through a story in the local news celebrating a Uruguayan grand prize winner from a previous year. Like Břetislav, Vicente chose to work on the OpenMRS project because the cause spoke to him.

He got into programming through his love of video games and his desire to create his own. He hadn’t heard about programming before but initial research piqued his interest. Following his curiosity, he learned Java and expanded his knowledge from there. Conveniently, much of OpenMRS is built with Java!

The task-based structure worked well for Vicente. He was unsure of some tasks, recognizing that he didn’t know much about what they required. For instance, he hesitated to take on one that involved creating a Windows Phone app because he had never created a mobile app. But he persisted and, five days later, he had completed it and learned a lot about mobile development.

It surprised Vicente how much he learned in such a short time span. He had this to say: “During the contest I gained knowledge in a variety of fields such as programming, testing, video editing, and graphic design. The mentors encouraged us to think about quality instead of quantity, and I learned a lot from that.”

Vicente loved his Google Code-in experience and plans to continue contributing to open source projects, especially OpenMRS.

The last student story we’ll share today is that of Anesu Mafuvadze, a student from the US who worked with the Sustainable Computing Research Group (SCoRe). His introduction to computer science came through robotics in one of his high school classes which used a language similar to C++.

Anesu was thrilled by the experience of bringing the robots to life with code. He described his introduction this way: “The more I programmed the more captivated I became; I loved how easily I could convert my wildest ideas into fully functioning programs; I loved the thrill of working in an environment that demands minute precision; above all, I loved creating programs that other people found useful.”

Online documentation and YouTube tutorials fueled Anesu’s education for several years as he picked up multiple languages and began participating in programming contests. But he knew something was missing, Anesu lacked real world coding experience and had never collaborated with others. As such, he didn’t pay much attention to the readability of his code, wasn’t aware of version control, didn’t write extensive tests and had never built something for the common good.

Enter Google Code-in. Working with mentors helped Anesu deliver quality and building open source software required him to learn collaboration tools and value readability. The contest also gave him an opportunity to build on skills that he hadn’t developed, such as web development. Anesu says the experience made him a better programmer and that the introduction to open source has motivated him to use his skills on projects that benefit society.

Thank you to Břetislav, Vicente and Anesu for their hard work contributing to open source projects and for sharing their stories with us. We have one more blog post coming with more student stories so stay tuned!

By Josh Simmons, Open Source Programs Office

Science Journal is an app that turns your Android phone into a mobile science tool, allowing you to use the sensors in your phone to explore the world around you. The Making & Science team launched Science Journal a few months ago at Bay Area Maker Faire 2016 and have been excited to see different projects people have done with it all over the world!

Today we are happy to announce that we are releasing Science Journal 1.1 on the Google Play Store and also publishing the core source for the app. Open source software and hardware has been hugely beneficial to the science education ecosystem. By open sourcing, we’ll be able to improve the app faster and also to provide the community with an example of a modern Android app built with Material Design principles.

One important feature in Science Journal is the ability to connect to external devices over Bluetooth LE. We have open source firmware which runs on several Arduino microcontrollers already. In the near future, we will provide alternate ways to get your sensor data into Science Journal: stay tuned (or follow along with our commits)!

We believe that anyone can be a scientist anywhere. Science doesn’t just happen in the classroom or lab. Tools like Science Journal let you see how the world works with just your phone and now you can explore how Science Journal itself works, too. Give it a try and let us know what you think!

By Justin Koh, Software Engineer

Originally posted on the Google Developers Blog

By Sam Thorogood, Developer Programs Engineer


Today, we’re announcing that the open source version of Google’s Santa Tracker has been updated with the Android and web experiences that ran in December 2015. We extended, enhanced and upgraded our code, and you can see how we used our developer products – including Firebase and Polymer – to build a fun, educational and engaging experience.

To get started, you can check out the code on GitHub at google/santa-tracker-weband google/santa-tracker-android. Both repositories include instructions so you can build your own version.
Santa Tracker isn’t just about watching Santa’s progress as he delivers presents on December 24. Visitors can also have fun with the winter-inspired experiences, games and educational content by exploring Santa’s Village while Santa prepares for his big journey throughout the holidays.
Below is a summary of what we’ve released as open source.

Android app

• The Santa Tracker Android app is a single APK, supporting all devices, such as phones, tablets and TVs, running Ice Cream Sandwich (4.0) and up. The source code for the app can be found here.
• Santa Tracker leverages Firebase features, including Remote Config API, App Invites to invite your friends to play along, and Firebase Analytics to help our elves better understand users of the app.
• Santa’s Village is a launcher for videos, games and the tracker that responds well to multiple devices such as phones and tablets. There’s even an alternative launcher based on the Leanback user interface for Android TVs.

• Games on Santa Tracker Android are built using many technologies such as JBox2D (gumball game), Android view hierarchy (memory match game) and OpenGL with special rendering engine (jetpack game). We’ve also included a holiday-themed variation of Pie Noon, a fun game that works on Android TV, your phone, and inside Google Cardboard’s VR.

Android Wear

• The custom watch faces on Android Wear provide a personalized touch. Having Santa or one of his friendly elves tell the time brings a smile to all. Building custom watch faces is a lot of fun but providing a performant, battery friendly watch face requires certain considerations. The watch face source code can be found here.
• Santa Tracker uses notifications to let users know when Santa has started his journey. The notifications are further enhanced to provide a great experience on wearables using custom backgrounds and actions that deep link into the app.

On the web

• Santa Tracker is mobile-first: this year’s experience was built for the mobile web, including an amazing brand new, interactive – yet fully responsive, village: with three breakpoints, touch gesture support and support for the Web App Manifest.
• To help us develop Santa at scale, we’ve upgraded to Polymer 1.0+. Santa Tracker’s use of Polymer demonstrates how easy it is to package code into reusable components. Every housein Santa’s Village is a custom element, only loaded when needed, minimizing the startup cost of Santa Tracker.

• Many of the amazing new games (like Present Bounce) were built with the latest JavaScript standards (ES6) and are compiled to support older browsers via the Google Closure Compiler.
• Santa Tracker’s interactive and fun experience is enhanced using the Web Animations API, a standardized JavaScript APIfor unifying animated content.
• We simplified the Chromecast support this year, focusing on a great screensaver that would countdown to the big event on December 24th – and occasionally autoplay some of the great video content from around Santa’s Village.

We hope that this update inspires you to make your own magical experiences based on all the interesting and exciting components that came together to make Santa Tracker!

This guest post is a part of a short series about Guy Yachdav, Tatyana Goldberg and Christian Dallago and the journey that was inspired by their participation as Google Summer of Code mentors for the BioJS project. Don’t miss the first post in the series. Heads up, this post contains spoilers for Game of Thrones seasons 5 and 6!

We built on the Google Summer of Code (GSoC) philosophy and the lessons we learned from participating in 2014 by starting a JavaScript Technology class at the Technical University of Munich (TUM).

We began with two dozen students who worked on expanding the BioJS visualization library. Our class became popular quickly and the number of applicants doubled each semester (nearly 180 applicants for 40 seats in the 2016 summer term).

In 2016 our team grew to include Christian Dallago, who had joined as a GSoC mentor. Together we decided to break with tradition of our course’s previous semesters. Instead of focusing on data visualization, we wanted to introduce students to data science with JavaScript. To get our students fully engaged, we decided the project would center on data from the hit TV show, Game of Thrones.

Our aim was to create an online portal for Game of Thrones fans which would:

1. Provide the most comprehensive, structured and open data set about the Game of Thrones world accessible via API.
2. Present an interactive map based on JavaScript.
3. Listen to what people are saying on Twitter about each of the show’s characters.
4. Use machine learning algorithms to predict the likelihood of each character’s death.

Our plan worked — the students were engaged. It was a beautiful sight to see: GitHub repos humming with activity as each dev team delved deeper into their projects. As a project manager, you know you’ve got something good when issues are being opened and closed at 4:00 AM!

The results were mind blowing. In 50 days of programming, 36 students opened over 1,200 issues and pull requests, pushed 3,300 commits, released four apps to NPM, and, of course, produced one absolutely amazing website.

The website amasses data from 2,028 characters. Our map shows 240 landmarks and the paths traveled by 28 characters. Our Twitter sentiment analysis tool analyzed over 3 million tweets. And we launched the first ever machine learning-based prediction algorithm that predicts the likelihood of dying for the 1,451 characters in the show that are still alive.

Visualization of Twitter sentiment analysis data for Jon Snow during season 5 of Game of Thrones. The X axis shows the timeline and the Y axis shows the number of positive (green) and negative (red) tweets. Each tweet is analyzed by an algorithm using a neural network to determine whether the tweet’s writer has a positive, negative or neutral attitude toward the character.

Since launch, the site’s popularity has skyrocketed. Following our press release, we were covered by over 1,500 media outlets, most notably Time, The Guardian, Rolling Stone, Daily Mail, BBC, Reuters, The Telegraph, CNET and many more. HowStuffWorks, The Vulture and others produced videos about the site and Chris Hardwick’s Comedy Central show did a segment about us. We’ve also given countless interviews to TV, radio and newspapers.

	Google Analytics for the website. Left chart shows the number of visitors to the website during the first week after launch, reaching over 73K visitors on April 25th. Right chart shows the number of visitors at a given time point during the same week.

The most exciting part of the project was predicting the likelihood that any given character would die using machine learning. Machine learning algorithms find rules and patterns in the data, things that humans cannot obviously and simply detect. Once the rules and patterns are identified, we apply machine learning to make inferences or predictions from novel, previously unseen, data sets.

Warning: The next paragraphs contain spoilers for seasons 5 and 6 of Game of Thrones!

In order to predict the likelihood of a character’s death, we collected information about all of the characters that appeared in books 1 to 5 and analyzed over 30 features, including age, gender, marital status and others. Then we used a support vector machine (SVM) to statistically compare the features of characters, both dead and alive, to predict who would get the axe next. Our prediction was correct for 74% of all cases and surprised us by placing a number of characters thought to be relatively safe in grave danger.

According to our predictions, Jon Snow, who was seemingly betrayed and murdered by fellow members of the Night’s Watch at the end of season 5, had only an 11% chance of dying. Indeed, Jon has risen from the dead in the second episode of season 6! We also predicted that the rulers of Dorn (Doran and Trystane) Martell are at a high likelihood of death and, as predicted, they were taken out in the first episode of the new season.

Of course, as is always the case with predictions, there were also misses. We didn’t expect Roose Bolton to be killed off nor did we see Hodor’s departure coming.

This experience was an amazing ride for our team and it all started with Google Summer of Code! In the next post we’ll share what followed and where we see ourselves heading in the future.

By Guy Yachdav, Tatyana Goldberg and Christian Dallago, BioJS

Several years ago a science journalist asked me which languages could pack the most information into a 140-character Tweet. Because Twitter defines a character roughly as a single Unicode code point, this turns out to be an easy question to answer. Chinese almost certainly rates as the most “compact” language from that point of view because a single Chinese character represents a whole morpheme (in linguist terminology, a minimal unit of meaning) whereas an English letter only represents a part of a morpheme. The Chinese equivalent of I don’t eat meat, which in English takes 16 characters including spaces is 我不吃肉, which takes just four.

But this question relates to a broader question that as a linguist I have often been asked: which languages are the most “efficient” at conveying information? Or, which languages can convey the same information in the smallest amount of space? Untethered by the idiosyncrasies of Twitter, this question becomes quite difficult to answer. What do you mean by “space”? Number of characters? Number of bytes? Number of syllables? Each of these has its own problems. And perhaps more crucially, what do you mean by “information”? The Shannon notion of information does not straightforwardly apply here.

A group of us at Google set out to answer this question, or at least to provide the form that an answer would have to take. We had the resources and experience needed to annotate data in multiple languages, and we were able to divert some of those resources to this task. The results were published in a paper presented at the 2014 International Conference on Language Resources and Evaluation in Reykjavík, Iceland.

We are now releasing the data on GitHub. The data consist of 85 sentences typical of the kinds of sentences generated by Google Now, translated into eight typologically diverse languages: English, French, Italian, German, Russian, Arabic, Korean, Chinese, which include some highly inflected and uninflected languages, and various types of morphology including inflectional and agglutinative. The data were annotated by one to three annotators depending on the language, with morphological information, counts of the marked features and other information. The main data file is in HTML, color coded by language, which makes it easy to browse but also easy to extract into other formats.

Since the basic information conveyed by each sentence can be assumed to be the same across languages, the main focus of the research was on the additional information that each language marks, and cannot avoid marking. For example, the English sentence:

has the French translation:

The verb ending -ez, in boldface above marks “addressee respect”, a bit of information that is missing from the English original.  One could have used a different ending on the French verb, but then that would not avoid this bit of information—it would be choosing to mark lack of respect, or familiarity with the addressee.

In the paper we tried various ways of measuring the differing information content of the languages relative to various definitions of “space”. Considering all the factors together, we concluded that the languages that conveyed the most information in a given amount of space were highly inflected languages like Russian, with uninflected languages like Chinese actually being the “least efficient” at conveying information.

We don’t expect this to be the final answer, which is why we are releasing the data as open source in the hopes that others will find it useful and maybe can even extend it to more sentences or a wider variety of languages. Ultimately though, any answer to the question of which languages convey the most information in the smallest amount of space must seriously address what is meant by “information”, and must pay heed to the famous maxim by the Russian linguist Roman Jakobson (1959) that “languages differ essentially in what they must convey and not in what they may convey.”

By Richard Sproat, Research Scientist

One of the many open source efforts at Google is the Google Cloud Platform (GCP) native libraries for our most popular languages. One of these libraries is the gcloud-ruby project on GitHub which is released as the gcloud gem on rubygems.org. There are several gems for accessing Google Cloud Platform resources from Ruby but this gem is different. It is hand coded by Rubyists for Rubyists and that has some distinct advantages.

Many of us have had experience working with libraries that are clearly ported from another language. I usually talk about them as Ruby with a Java accent or Python with a Perl accent. Generally they work just fine but you can run into some low level friction — sometimes things just don’t feel right. Native gems written by members of the community solve this problem. In the case of gcloud-ruby there are some really concrete examples.

First, gcloud-ruby uses syntax that is similar to other popular Ruby libraries. For example, the syntax for specifying a table schema in BigQuery (Google Cloud Platform’s very large scale data warehouse) looks like this:

table = dataset.create_table "baby_names" do |schema|
  schema.string "name"
  schema.string "sex"
  schema.integer "number"
end

Creating the same table in popular Ruby on Rails looks like this:

create_table "baby_names" do |schema|
  schema.string "name"
  schema.string "sex"
  schema.integer "number
end

Google Code-in is our annual contest that gives students age 13 to 17 experience in computer science through contributions to open source projects. This blog post is the second installment in our series reflecting on the experiences of Google Code-in 2015 grand prize winners. Be sure to check out the first post in the series.

This week we profile three more grand prize winners from Google Code-in 2015. These students came from all around the world to celebrate with us in June after successfully completing 692 tasks that resulted in significant contributions to the participating open source projects.

Google Code-in 2015 Grand Prize Winners and Mentors were treated to a cruise around San Francisco Bay.

Google Code-in is our annual contest to help pre-university students gain real-world computer science experience by taking on tasks of varying difficulty levels with the help of volunteer mentors. These tasks are created by open source projects so while learning, the students are contributing to the software many of us use on a daily basis.

The finalists and winners for our 2015/2016 season were announced in February and, in June, the grand prize winners joined us for four days of learning and celebration. Students and their guardians came from all around the world. One of my favorite things, as one of the Googler hosts, was seeing the light bulbs go on above parents’ heads as they came to understand open source and why it’s so important. These parents and guardians were even more proud of the students as they learned how much their teenager has contributed to the world through participating in Google Code-in.

We’ve invited contest winners and organizations to write about their experience and will be sharing their stories in a series of blog posts. This marks the first post in the series.

Google Code-in 2015 Grand Prize Winners and Mentors

This guest post is a part of a short series about Tatyana Goldberg and Guy Yachdav, instructors at Technical University of Munich, and the journey that was inspired by their participation as Google Summer of Code mentors for the BioJS project.

Tatyana Goldberg and Guy Yachdav, GSoC mentors and open source enthusiasts. Photo taken at the MorpheusCup competition Luxembourg, May 2016.

Spatial audio is a key element for an immersive virtual reality (VR) experience. By bringing spatial audio to the web, the browser can be transformed into a complete VR media player with incredible reach and engagement. That’s why the Chrome WebAudio team has created and is releasing the Omnitone project, an open source spatial audio renderer with the cross-browser support.

Our challenge was to introduce the audio spatialization technique called ambisonics so the user can hear the full-sphere surround sound on the browser. In order to achieve this, we implemented the ambisonic decoding with binaural rendering using web technology. There are several paths for introducing a new feature into the web platform, but we chose to use only the Web Audio API. In doing so, we can reach a larger audience with this cross-browser technology, and we can also avoid the lengthy standardization process for introducing a new Web Audio component. This is possible because the Web Audio API provides all the necessary building blocks for this audio spatialization technique.

Omnitone Audio Processing Diagram

The AmbiX format recording, which is the target of the Omnitone decoder, contains 4 channels of audio that are encoded using ambisonics, which can then be decoded into an arbitrary speaker setup. Instead of the actual speaker array, Omnitone uses 8 virtual speakers based on an the head-related transfer function (HRTF) convolution to render the final audio stream binaurally. This binaurally-rendered audio can convey a sense of space when it is heard through headphones.

The beauty of this mechanism lies in the sound-field rotation applied to the incoming spatial audio stream. The orientation sensor of a VR headset or a smartphone can be linked to Omnitone’s decoder to seamlessly rotate the entire sound field. The rest of the spatialization process will be handled automatically by Omnitone. A live demo can be found at the project landing page.

Throughout the project, we worked closely with the Google VR team for their VR audio expertise. Not only was their knowledge on the spatial audio a tremendous help for the project, but the collaboration also ensured identical audio spatialization across all of Google’s VR applications – both on the web and Android (e.g. Google VR SDK, YouTube Android app). The Spatial Media Specification and HRTF sets are great examples of the Google VR team’s efforts, and Omnitone is built on top of this specification and HRTF sets.

With emerging web-based VR projects like WebVR, Omnitone’s audio spatialization can play a critical role in a more immersive VR experience on the web. Web-based VR applications will also benefit from high-quality streaming spatial audio, as the Chrome Media team has recently added FOA compression to the open source audio codec Opus. More exciting things like VR view integration, higher-order ambisonics and mobile web support will also be coming soon to Omnitone.

We look forward to seeing what people do with Omnitone now that it’s open source. Feel free to reach out to us or leave a comment with your thoughts and feedback on the issue tracker on GitHub.

By Hongchan Choi and Raymond Toy, Chrome Team

Due to the incomplete implementation of multichannel audio decoding on various browsers, Omnitone does not support mobile web at the time of writing.

With all of the excitement being generated around the Kubernetes 1.3 release and the first anniversary of Kubernetes 1.0 (#k8sbday), now is a great time to point out some of the features that enterprise users should be taking note of.

If you’re not familiar with Kubernetes, let me get you up to speed.

Kubernetes is an open-source container automation framework that builds upon 15 years of experience of running production workloads at Google. Once you declare a desired state, Kubernetes works to drive your system toward that state. As a developer this means less time handling trivial tasks that a computer can automate and more time focusing on developing applications that provide value to users.

Additionally, Kubernetes aims to be a framework that you can operate at planetary scale, run anywhere, and never outgrow.

From Google Summer of Code to Google Code-in, the Open Source Programs Office does a lot to get students involved with open source. In order to learn more about supporting open source in academia, I attended the NSF funded Professors’ Open Source Software Experience (POSSE) in Philadelphia. It was a great opportunity for us to better understand the challenges instructors face in weaving open source into their curriculum and hear solutions on how to bridge the gap.

Almost 30 university professors and community college lecturers attended the 3-day workshop. During the workshop, attendees worked in small groups getting hands on experience incorporating humanitarian free and open source software (HFOSS) into their teaching. Professors were able to talk, mingle and share best practices throughout the event.

The POSSE workshop is led by Heidi Ellis, Professor, Department of Computer Science and Information Technology at Western New England University, and Greg Hislop, Professor of Software Engineering and Senior Associate Dean for Academic Affairs at Drexel University. Heidi and Greg took over running POSSE five years after Red Hat began the program as an outreach effort to the higher education community. Red Hat continues as a collaborator in the effort. Around 40 university and community college professors participate in the program every year with over 100 individuals attending the workshop in the last four years.

Here are some of the challenges professors shared:

• Very little guidance on how to bring FOSS into the classroom. No standard curriculum / syllabus available to reference. 
• Time investment required to change the curriculum.
• Will not be rewarded for teaching FOSS courses.
• Will not get funds to travel for workshops/conferences unless it’s to present a paper at a conference.
• Many administrations aren’t aware that adding open source is beneficial for students since more and more companies use open source and expect their new hires to be familiar with it.

We also discussed a number of open source programs that are currently working to engage students with open source software development:

• Corporate
  • Google Summer of Code
  • Google Code-in
  • Red Hat Open Source in Education
  • Facebook Open Academy
• Academic
  • Rochester Institute of Technology: Free and Open Source Software and Free Culture Minor Program
  • Rensselaer Polytechnic Institute: Rensselaer Center for Open Source
  • Oregon State University: Open Source Lab
  • University of California at Santa Cruz: Center for Research on Open Source Software

Thanks to Heidi, Greg and the FOSS2Serve team for organizing POSSE 2016! We look forward to taking what we’ve learned and using it to better support FOSS education in academia.

By Feiran Helen Hu, Open Source Programs Office

Posted by Felipe Hoffa, Google Developer Advocate

Google, in collaboration with GitHub, is releasing an incredible new open dataset on Google BigQuery. So far you’ve been able to monitor and analyze GitHub’s pulse since 2011 (thanks GitHub Archive project!) and today we’re adding the perfect complement to this. What could you do if you had access to analyze all the open source software in the world, with just one SQL command?

The Google BigQuery Public Datasets program now offers a full snapshot of the content of more than 2.8 million open source GitHub repositories in BigQuery. Thanks to our new collaboration with GitHub, you’ll have access to analyze the source code of almost 2 billion files with a simple (or complex) SQL query. This will open the doors to all kinds of new insights and advances that we’re just beginning to envision.

For example, let’s say you’re the author of a popular open source library. Now you’ll be able to find every open source project on GitHub that’s using it. Even more, you’ll be able to guide the future of your project by analyzing how it’s being used, and improve your APIs based on what your users are actually doing with it.

On the security side, we’ve seen how the most popular open source projects benefit from having multiple eyes and hands working on them. This visibility helps projects get hardened and buggy code cleaned up. What if you could search for errors with similar patterns in every other open source project? Would you notify their authors and send them pull requests? Well, now you can. Some concepts to keep in mind while working with BigQuery and the GitHub contents dataset:

• With BigQuery everyone gets a terabyte every month to run queries. If you’ve never tried BigQuery before, follow these getting started instructions.
• The contents table has all the non-binary files in GitHub that are less than 1MB. It’s a huge table, with more than 1.5 terabytes of data! This means the monthly terabyte for BigQuery queries won’t last long if you want to query this table. To make your life easier, we’ve created extracts with only a sample of 10% of all files of the most popular projects, as well as another dataset with all the .go, .rb. .js, .php, .py, and .java code. Use them to make your free quota last!
• If these tables are not enough, you can always create your own extracts (but you’ll be billed for the respective storage). To do so, you could sign up for $300 in Google Cloud Platform credits. These credits could be used to store terabytes (and more) of data in BigQuery.
• BigQuery makes it easy to join different datasets. How about ranking coding patterns by the number of stars their projects get? See a related post looking at the Hacker News effect on a project’s GitHub stars.
• SQL is not enough? Learn how BigQuery allows you to run arbitrary JavaScript code inside SQL to enable a full range of possibilities.

To learn more, read GitHub’s announcement and try some sample queries. Share your queries and findings in our reddit.com/r/bigquery and Hacker News posts. The ideas are endless, and I’ll start collecting tips and links to other articles on this post on Medium.

Stay curious!

Google Summer of Code (GSoC) 2016 is officially at its halfway point. Mentors and students have just completed their midterm evaluations and it’s time for our second stats post. This time we take a closer look at our participating students.

First, we’d like to highlight the universities with the most student participants. Congratulations are due to the International Institute of Information Technology – Hyderabad for claiming the top spot for the third consecutive year!

Next, we are proud to announce that 2016 marks the largest number of female GSoC participants to date — 12% of accepted students are female, up 2.2% from 2015. This is good progress, but we are certain we can do better in the future to diversify our program. The Google Open Source team will continue our outreach to many organizations, for example, Grace Hopper and Black Girls Code, to increase this number even more 2017. If you have any suggestions of organizations we should work with, please let us know in the comments.

Finally, each year we like to look at the majors of students. As expected, the most common area of study for our participants is Computer Science (approximately 78%), but this year we have a wide variety of studies including Linguistics, Law, Music Technology and Psychology.  The majority of our students this year are undergraduates (67%), followed by Masters (23%) and then PhD students (9%).

Although reviewing GSoC statistics each year is great fun, we want to stress that being “first place” is not the point of the program. Our goal is to get more and more students involved in creating free and open source software. We hope Google Summer of Code encourages contributions to projects that have the potential to make a difference worldwide. Congratulations to the students from all over the globe and keep up the good work!

By Mary Radomile, Open Source Programs Office