Posted:
Student applications for Google Summer of Code (GSoC) 2015 closed on March 27th and this year’s mentoring organizations are now busy reviewing student proposals. While we await the results of that process, we’ve been looking at some of the early statistics for this year’s program.

One thing we’re very excited to see is that we received nearly four times as many student applications from Sub-Saharan Africa compared to last year! The gain primarily came from four countries: Cameroon, Kenya, Nigeria, and Uganda. These countries combined had just 45 students apply in 2014, but that number jumped up to 183 this year. Why was the increase concentrated in these locations? There’s a common thread that seems to be responsible: they are places where students active in the Google Student Ambassador (GSA) program organized local GSoC meet-up events.

Cameroon

After lending a hand to a fellow student organizing a meetup in December, GSA Tekang Check brought 77 students together in March at the University of Buea to learn about GSoC and help students apply. Participants from past years shared their experiences and encouraged attendees to submit proposals for projects they felt passionate about.


Kenya

GSA John Muchiri welcomed over 100 students from St Paul’s University to a GSoC meet-up. The speakers talked about the characteristics good programmers develop and encouraged students to challenge themselves by applying to the program.

At Jomo Kenyatta University of Agriculture and Technology, GSAs Isaac Jumba and Dickson Marienga introduced students to GSoC as part of the local DevFest event which drew over 150 attendees. The session gave an overview of GSoC and encouraged students to sign up for a regional GSoC enthusiasts mailing list.


Nigeria

GSAs Ilo Calistus, Okwara Godswill, and Mgbemena Chike collaborated on a pair of events at the University of Nigeria in Nsukka. The first introduced students to the basics of programming for Android while the second taught students about using Git. Both events also introduced students to the world of open source and encouraged them to take part in GSoC.


At Ekiti State University, GSAs Sadiq Mary Oiza and Alabea Dare Micheal organized a GSoC meet-up for 35 students. After a discussion about current events at the university, the presenters gave an overview of the GSoC program and encouraged students to create profiles on the program website.


GSA James Uzoma organized a meet-up at the Federal University of Agriculture, Abeokuta where 40 students from 6 colleges enjoyed a series of talks featuring stories from fellow Nigerians who had participated in past years, an explanation of the requirements for participating, and some details about the different open source organizations students could apply to work with.

Uganda

GSA Kagimu Brian brought together 72 students for a GSoC meet-up at Mbarara University of Science and Technology. Attendees learned about the benefits and experiences that can come from taking part in GSoC, along with an introduction to Git.



Only a limited number of students can be accepted in GSoC each year, but we hope to welcome several of the students who attended these events into this year’s program. Accepted students will be notified via email by 19:00 UTC on April 27th, so keep watching your inbox.


By Ashleigh Rentz, Open Source team

Posted:
Microsoft’s Event Tracing for Windows (ETW, aka xperf) is an amazing tool for understanding the performance of Windows computers. ETW offers an incredibly deep view into the entire system and allows investigations of complex problems that would otherwise be intractable. It can even be used to record traces on a customer’s machine for later analysis on a developer’s machine, to investigate performance problems that cannot be reproduced locally.


However, the process of recording ETW trace has always been challenging, so we’re pleased to share a new tool we’ve been developing:  UIforETW. This tool brings point-and-click simplicity to recording ETW traces, works around several trace recording bugs, and is a handy dashboard for managing and annotating traces. And since UIforETW is open source, you can add additional features for your own particular needs.




Tracing can be done to a file or to an in-memory circular buffer. Trace compression, high-speed sampling, heap tracing, and other options can be configured with the click of a button. UIforETW lists the recorded traces and lets users rename and annotate them. When you want to analyze a trace, you can launch Microsoft’s trace viewers from UIforETW, and UIforETW will configure improved viewer defaults for WPA.


UIforETW was written by a Chrome developer, so it has a few Chrome specific features. If the Chrome symbol server is enabled, then UIforETW downloads and strips the Chrome symbols in order to avoid a twenty five minute delay when WPA loads the symbols. UIforETW also preprocesses the traces in order to categorize the Chrome processes by type. These features can be turned off in the Settings dialog if you aren’t working on Chrome. While the Chrome specific features will not be needed by most developers, they demonstrate the potential value from custom processing of traces.


UIforETW is a new project but is already being used for production work. More technical details and information about UIforETW and ETW in general can be found in the author's blog post and discussions can be had at our discussion group. Information about contributing to UIforETW can be found in the CONTRIBUTING file in the GitHub repo.

by Bruce Dawson, Chrome team

Posted:
Drupal, one of the Google Code-in 2014 mentoring organizations, has been working toward the release of a new major version. Grand prize winner Getulio Valentin Sanchez contributed to the upcoming release during the contest and shared his story with us.


I was 13 years old the first time I got access to a computer. I had no idea how to connect it to the internet, but that didn’t stop me from experimenting. When I was 14, I saw a documentary about Google and discovered that “programming” and “coding” were completely different things than I’d thought. In that same documentary, I saw Google’s offices and I resolved to myself that I would try to visit them in person by the time I turned 18.

After participating in an OMAPA Computer Olympics event here in Paraguay, a Google Code-in (GCI) mentor from Sugar Labs contacted me to ask if I could help spread the word about GCI in my local community. During that conversation, the mentor encouraged me to enter GCI myself. He pointed out that Drupal was one of the mentoring organizations and they use a lot of PHP, the language I’m most familiar with.

Before GCI, I had never worked with an open source project, nor did I know how to create a patch or anything like that. But since it was a possible opportunity to achieve the dream I’d set for myself, I thought “why not learn something new?”

When the contest began, I got to work on my first task: porting the simple but useful Scroll To Top module to Drupal 8. It was astonishing to me when my patch was approved and committed. With that astonishment came an amazing sensation in knowing that somewhere in the world, someone will be using something that I made. Tasks like these were a little challenging, but I quickly fell in love with this type of work and created a series of blog posts and a video about the process.

I continued porting modules to Drupal 8 throughout the GCI contest. I think the most difficult task I faced was porting the Administer Users by Role module. This wasn’t because it’s a large module, but rather because I had to learn about access checking which I’d never heard about before. Although this wasn’t impossible, it took me about a week to get an initial version ready for the community’s consideration.

The seven weeks I spent participating in GCI taught me a lot. I learned about following coding standards, programming concepts like dependency injection and the Hollywood principle, some of the more powerful features of Git, and features of PHP that I hadn’t even known existed!

People say every end is a new beginning, and that’s been true for me. The end of GCI 2014 was also the beginning of my experience as a regular contributor to Drupal. I now spend my weekends working with this amazing platform and collaborating with the Drupal community. And soon, I’ll be beginning my journey to see Google’s offices in person like I’d dreamed of before -- I began with a humble “Hello World” and eventually became one of the GCI 2014 Grand Prize Winners.


by Getulio Valentin Sanchez, GCI grand prize winner

Posted:

(Cross-posted with the Google Developers Blog)

Fun Propulsion Labs at Google* is back today with some new releases for game developers. We’ve updated Pie Noon (our open source Android TV game) with networked multi-screen action, and we’ve also added some delicious new libraries we’ve been baking since the original release: the Pindrop audio library and the Motive animation system.

Pie Noon multi-screen action

Got an Android TV and up to 4 friends with Android phones or tablets? You’re ready for some strategic multi-player mayhem in this updated game mode. Plan your next move in secret on your Android phone: will you throw at an opponent, block an incoming attack, or take the risky approach and wait for a larger pie? Choose your target and action, then watch the Android TV to see what happens!

We used the NearbyConnections API from the most recent version of Google Play Games services to easily connect smartphones to your Android TV and turn our original Pie Noon party game into a game of turn-based strategy. You can grab the latest version of Pie Noon from Google Play to try it out, or crack open the source code and take a look at how we used FlatBuffers to encode data across the network in a fast, portable, bandwidth-efficient way.

Pindrop: an open source game audio library

Pindrop is a cross-platform C++ library for managing your in-game audio. It supports cross compilation to Android, Linux, iOS and OSX. An early version of this code was part of the first Pie Noon release, but it’s now available as a separate library that you can use in your own games. Pindrop handles loading and unloading sound banks, tracking sound locations and listeners, prioritization of your audio channels, and more.

Pindrop is built on top of several other pieces of open source technology:

  • SDL Mixer is used as a backend for actually playing the audio.
  • The loading of data and configuration files is handled by our serialization library, FlatBuffers.
  • Our own math library, MathFu, is used for a number of under-the-hood calculations.

You can download the latest open source release from our GitHub page. Documentation is available here and a sample project is included in the source tree. Please feel free to post any questions in our discussion list.

Motive: an open source animation system

The Motive animation system can breathe life into your static scenes. It does this by applying motion to simple variables. For example, if you’d like a flashlight to shine on a constantly-moving target, Motive can animate the flashlight so that it moves smoothly yet responsively.

Motive animates both spline-based motion and procedural motion. These types of motion are not technically difficult, but they are artistically subtle. It's easy to get the math wrong. It's easy to end up with something that moves as required but doesn't quite feel right. Motive does the math and lets you focus on the feeling.

Motive is scalable. It's designed to be extremely fast. It also has a tight memory footprint -- smaller than traditional animation compression -- that's based on Dual Cubic Splines. Our hope is that you might consider using Motive as a high-performance back-end to your existing full-featured animation systems.

This initial release of Motive is feature-light since we focused our early efforts on doing something simple very quickly. We support procedural and spline-based animation, but we don't yet support data export from animation packages like Blender or Maya. Motive 1.0 is suitable for props -- trees, cameras, extremities -- but not fully rigged character models.  Like all FPL technologies, Motive is open source and cross-platform. Please check out the discussion list, too.

What’s Fun Propulsion Labs at Google?

You might remember us from such Android games as Pie Noon, LiquidFun Paint, and VoltAir, and such cross-platform libraries as MathFu, LiquidFun, and FlatBuffers.

Want to learn more about our team? Check out this recent episode of Game On! with Todd Kerpelman for the scoop!

by Jon Simantov, Fun Propulsion Labs at Google

* Fun Propulsion Labs is a team within Google that's dedicated to advancing gaming on Android and other platforms.

Posted:
Although best known for their namesake conference, FOSSASIA also acts as an umbrella organization which supports development of open source software linked to Asia or Asian developers. They participated in Google Code-in 2014 and shared this report with us.


2014 marked FOSSASIA’s first year participating in Google Code-in (GCI) as a mentoring organization, and what a splash we made! Students completed 587 tasks with us, the most of any organization in this year’s program. These bite-sized tasks gave young students ages 13 to 17 an opportunity to participate in open source development with the help of mentors. A total of 174 students completed at least one task with us -- they wrote code, designed artwork, tested software, and had a lot of fun.

GCI is a contest and each mentoring organization chooses two Grand Prize winners. Ours were Namanyay Goel and Samarjeet Singh. They’ll travel all-expenses-paid with a parent or guardian to Google headquarters in Mountain View, California. We also had three finalists who deserve a hearty congratulations: Alvis Wong, Amr Ramadan, and Tymon Radzik. We are thankful for your contributions.

Students contributed to the FOSSASIA website along with open source projects like the ExpEYES tool for at-home science experiments, the sup console-based email client, the TiddlySpace idea-organizer, and the p5.js drawing library. This wide variety of opportunities was possible thanks to the efforts of our 24 mentors who found time between their other obligations to help students. Thank you, mentors!

Usually, novice contributors to a project face a significant barrier to entry. There are coding conventions to follow, guidelines for combining or breaking up multiple commits, and more that can be specific to a project. Such requirements help keep the codebase healthy and consistent, but their value isn’t apparent to beginners who have already struggled to produce a contribution and just want to see it integrated. To reduce the discouragement GCI students would face, we decided to merge students’ first pull requests if they get the job done, even if they don’t follow our usual practices. Later, students could accept a task which teaches them about our standards for contributions, giving them a chance to clone and rebase a sample repo so that it follows the rules. Students who completed this task and continued working with us understood the terminology and were able to apply our feedback to their later commits without the usual frustration.

We had a fantastic time participating in GCI and would like to thank all the students who took part in the contest. We’re thrilled to see some of them still hanging around in our community and wish them all an exciting and fruitful future.

By Aruna Herath, FOSSASIA mentor

Posted:
After months in development, the FlatBuffers 1.1 update is here. Originally released in June 2014, it’s a highly efficient open source cross-platform serialization library that allows you to read data without parsing/unpacking or allocating additional memory. It supports schema evolution (forwards/backwards compatibility) and optional JSON conversion. We primarily created it for games written in C++ where performance is critical, but it’s also useful more broadly. This update brings:


  • an extensive overhaul to the Java API
  • out-of-the-box support for C# and Go
  • an optional verifier to make FlatBuffers practical in untrusted scenarios
  • .proto parsing for easier migration from Protocol Buffers
  • optional manual assignment of field IDs
  • dictionary functionality through binary search on a key field
  • bug fixes and other improvements thanks to 200+ commits from 28 contributors -- thank you!


Download the latest release from our github page and join our discussion list for more details.

By Wouter van Oortmerssen, Fun Propulsion Labs at Google*

*Fun Propulsion Labs is a team within Google that's dedicated to advancing gaming on Android and other platforms.

Posted:
Years of writing and maintaining Python code have taught us the value of automated tools for code formatting, but the existing ones didn’t quite do what we wanted. In the best traditions of the open source community, it was time to write yet another Python formatter.

YAPF takes a different approach to formatting Python code: it reformats the entire program, not just individual lines or constructs that violate a style guide rule. The ultimate goal is to let  engineers focus on the bigger picture and not worry about the formatting. The end result should look the same as if an engineer had worried about the formatting.

You can run YAPF on the entire program or just a part of the program. It’s also possible to flag certain parts of a program which YAPF shouldn’t alter, which is useful for generated files or sections with large literals.

Consider this horribly-formatted code:

x = {  'a':37,'b':42,

'c':927}

y = 'hello ''world'
z = 'hello '+'world'
a = 'hello {}'.format('world')
class foo  (     object  ):
 def f    (self   ):
   return       \
37*-+2
 def g(self, x,y=42):
     return y
def f  (   a ) :
 return      37+-+a[42-x :  y**3]

YAPF reformats this into something much more consistent and readable:

x = {'a': 37, 'b': 42, 'c': 927}

y = 'hello ' 'world'
z = 'hello ' + 'world'
a = 'hello {}'.format('world')


class foo(object):
   def f(self):
       return 37 * -+2

   def g(self, x, y=42):
       return y


def f(a):
   return 37 + -+a[42 - x:y ** 3]

Head to YAPF's GitHub page for more information on how to use it, and take a look at YAPF’s own source code to see a much larger example of the output it produces.

by Bill Wendling, YouTube Code Health Team

Posted:
OpenMRS is a medical records system used around the world, especially in places where resources are scarce. It’s also being used with Google’s chlorine-submersible tablets designed for Médecins Sans Frontières to use while treating ebola patients. The OpenMRS community recently participated in Google Code-in, providing young students with an opportunity to get involved with real open source projects and learn about contributing to them. Chaitya Shah, one of OpenMRS’ two grand prize winners, shared this story with us about his participation in the contest.

GCI_2014_logo_small.png

For 7 weeks in December 2014 and January 2015, I worked with OpenMRS in the Google Code-in (GCI) competition. GCI introduces highschool aged kids to open source software development by providing a wide variety of tasks we can complete. For me, it has worked wonders. I’d been interested in the concept of open source software for about a year and even participated in GCI 2013, but this year, the experience turned my interest into a passion. I worked on many new things, met lots of new people, and learned several important skills along the way.

A few days before the competition started, I decided to see how OpenMRS’s software worked. I went through the GitHub repositories and tried to get openmrs-core, the main application, running. After a few tries and the help of several contributors on IRC, I was finally able to do so. Their help showed me what the OpenMRS community was truly about: everyone was very helpful throughout the contest and there was always someone online to help me out at any time of the day.

Several of the tasks I worked on this year were much more complex than the ones I worked on last year, giving me more of a challenge and motivating me to put forth my best effort! The early tasks, however, involved getting acquainted with the OpenMRS community and learning how things work in the organization. Several of these tasks taught some key aspects of open source software or of programming in general. One of the simplest but most important tasks was introducing myself to the community. If the communication between a developer and an organization is weak, the code produced will suffer. It was also inspiring to see so many other people interested in contributing to OpenMRS through GCI.

After learning the basics of OpenMRS, I started to explore tasks in the UI Revamp epic. With guidance from a mentor, I worked on making the OpenMRS ID site look more like the redesigned wireframes provided. These tasks really taught me a lot about design, one of my weak points. I used to know very little about HTML/CSS in general. The revamp tasks taught me about good practices in UI Design and I loved every minute of it.

In the last two weeks of the competition, I decided that I was ready to contribute something brand new to the organization. While deploying OpenMRS on the OpenShift cloud platform as part of a task, I found the developer guide was vague in some areas and difficult to follow. It took me a few days and some experimentation to get it working. To ensure that others wouldn’t have the same troubles, I made two videos showing the exact steps to follow: one for Windows and one for Unix-based systems.

After that, I decided to take on a Docker task. Docker is a system that lets you build, ship, and run distributable applications. This task directed me to create an image that downloads, sets up, and runs OpenMRS automatically. I was slightly overwhelmed at first, but Docker proved to be quite useful because it uses a system of containers rather than virtual machines, making it much faster and easier to deploy applications. I felt a big sense of accomplishment once I had finished publishing my work, writing up documentation, and making a quick video tutorial on how to set it up.

I learned a lot from OpenMRS and GCI this year. I was especially impacted by the weight that community interaction has in open source work. Previously, I’d always had the notion that being a programmer is very lonesome, sitting in a room with nothing but a computer for many hours at a time. However, I now know that everything in open source software development is collaborative; everyone works together to accomplish a single goal. I hope to someday find a job with a company that embraces this collaborative nature. Thank you to OpenMRS and GCI for an awesome experience this year!


By Chaitya Shah, GCI grand prize winner

Posted:
If you’ve worked on compilers, translators, or other tools that need to read a programming language, chances are you’ve spent many painful hours detailing that language’s grammar. Recently, we opened up the source code for Classp, a side-project a few of us have been working on that demonstrates it’s possible to have an automatic parser generator that is not based on formal grammars. Instead of grammar productions, you write classes similar to C++ or Java and you write class patterns to define the syntax. Although there are libraries like Boost.Spirit and Scala Parsers that give you a nice way to write a grammar in the programming language itself, in the end you are still writing a grammar. Even though Classp looks a lot like C++ or Java, it is not just a C-like way to write a grammar. It’s an entirely different way to specify syntax.

Grammars are great for diagramming a complex syntactic structure for human readers, but as a computer specification, they leave a lot to be desired. Four key problems with grammars inspired us to work on Classp as an alternative.

First, a grammar is intended to represent the actual syntactic structure of the language: all of the little details like what goes first and what goes second, where to put your commas and semicolons, where can you substitute one thing for another, etc... But this surface structure doesn’t really matter to the programmer who wants to process the language. It just gets in the way. What you really care about are the logical parts of the declaration: what is the type? What is the name? Is there an initializer and what is it?

Second, many common parser generators don’t actually specify any tree at all. They let the programmer write actions to build up a parse tree. But the actions in most systems tend to form an awkward fit with the grammar.

Next, when you write a grammar, you have to worry not just about the surface structure of the language, but also about how the language will be parsed. You have to write the grammar around ambiguities in the language and sometimes around other features. You can’t just write the rules as you would write them for a human reader:

Expr ::= Int | ( Expr ) | Expr + Expr | Expr - Expr | Expr * Expr | Expr / Expr

instead, you have to write them in a way that avoids ambiguity:

Expr ::= Expr + Term | Expr - Term;
Term ::= Term * Factor | Term / Factor
Factor ::=  Int | ( Expr )

Finally, grammar-based parsers are extremely verbose. For serious parsing tasks, it is common to write a grammar, design a parse tree, write actions in the grammar to create the parse tree, design an abstract syntax tree, and write code to translate the parse tree into an abstract syntax tree. There are many dependencies among these parts that all have to be kept consistent over the life of the program. It’s a complex and error-prone process.

Classp attempts to avoid these problems. The abstract syntax tree is what programmers typically want to work with. With class patterns, you only have two jobs: design the abstract syntax tree and write a formatter for it. (A formatter is the function that writes out the abstract syntax tree in the target language.)

Here’s an example class declaration for an abstract syntax tree. The class pattern is the part inside the parentheses of the syntax statement: “arg1 '+' arg2”.

class Plus: Expression {
 Expression arg1;
 Expression arg2;
 syntax(arg1 '+' arg2);
}

This class pattern says that to print a Plus node, you first print arg1, then you print a plus sign, then you print arg2. So it looks like a nice formatting language, but where do we specify the parser? The answer is that we don’t specify a parser; Classp will invert the formatter to generate a parser for us. Since formatters are typically much easier to write and maintain than parsers, it almost feels like magic.

Classp is still a work in progress. We still have to deal with ambiguity in languages, features that are only output in one way but may be input in several ways, and a few other issues. But it’s ready to play with now and we’d love to hear from others interested in this subject. To learn more, visit http://google.github.io/classp.


By David Gudeman, Classp team