Google Code-in: sixteen and counting

Today we have a guest post from Chirayu Desai, one of the twenty amazing teenagers from around the globe who took top honors in Google Code-in 2013. Read more about Chirayu and his introduction into the world of open source software below.

If I told you a 16 year-old kid could work on software which runs on millions of devices, contribute to an operating system which is present on more than a billion devices, and work on code that goes into spacecraft, would you believe it?

Believe it! I am that very 16 year-old writing this blog post three months after visiting the Googleplex in California (a long-time dream) as one of the 20 grand prize winners of Google Code-in 2013 (GCI). Check me out on a Segway! I’m the one on the right.

I first read about GCI online, and I immediately decided to participate. I felt that it was the perfect opportunity for me to not only get involved in an open source project but also get to know new people. I chose RTEMS because I liked their hello world task — it involved setting up a development environment for RTEMS, compiling a test program, and running it in a simulator.

So what is involved when completing tasks for GCI? It isn’t just about writing code, but also really understanding the code and contributing back to it. While working with an open source organization, you have to ensure that the code quality meets the project’s guidelines.  The code must be as accurate and efficient as possible — no quick hacks here.

As an open source contributor, I worked with version control systems (they’re awesome, really), mailing lists (old school, but still effective) and code review systems. I then got feedback from my mentors, applied it, rinsed and repeated. The exciting part wasn’t just the coding process, but everything associated with working on such a project. I wrote the code, wrote tests for the code, read and closed bug reports, collaborated with other people, etc. It’s much more in depth than what I would experience with a personal project and I learned a ton!

As a high school student you may have worked on a personal project in your spare time, or maybe you even know a few coding languages. But I believe working with open source projects and participating in GCI gives you much more. I now know that when I get a job one day, I won’t just have to write code, I’ll also have to get it reviewed, and review other people’s code. This is not something you learn by working on personal projects, but by working collaboratively — something I practiced and refined by participating in GCI. In addition, the mentors assigned to help students were very supportive would help us students with everything that we needed which was really encouraging.

I really enjoyed participating in the contest. Even though I had worked on open source software before, my Google Code-in experience was completely different from anything I’d ever done. Flying halfway across the world and getting to meet the people with whom I had worked was something I didn’t imagine would ever happen. Every 13-17 year old pre-university student has the opportunity to participate in GCI, you just need to take that first step. Then you too can be a part of something that could change your life — I know it changed mine.

By Chirayu Desai, Google Code-in Grand Prize Winner, 2013

Are you interested in participating in Google Code-in this year? Keep an eye on the program website for important dates and information.

Google Summer of Code new organizations - Part Four

For the 4th post in our Google Summer of Code series highlighting the new open source organizations participating in this year’s program, we welcome administrators from jMonkeyEngine and BuildmLearn to describe their students’ projects.

jMonkeyEngine (JME3) is a modern 3D engine written entirely in Java. The full SDK comes bundled with industry-standard editing tools and an ever-growing library of plugins contributed by the community. The engine can publish to all PC platforms including Android and iOS.

This is our first year participating in Google Summer of Code (GSoC) and we are very excited about it. All our mentors are jME3 veterans, two of whom are from the core team and one is a long time trusted contributor. As for our students, they never cease to impress. Below are descriptions of the projects they are working on this summer.

Smooth Voxel Terrains, by John
jMonkeyEngine has become very popular among voxel game creators. John is exploring techniques such as dual marching cubes which might very well be the precursor to a next-gen Minecraft. We hope his work can serve as a starting point for similarly ambitious developers.

Cinematic Editor, by Mayank
We have an SDK with a lot of potential, but still need some flagship plugins to show developers what it's really capable of. Mayank has taken on the task of creating a comprehensive cinematic editor which will enable game developers to create cutscenes in a snap, all within a comfortable GUI.

Recast Navigation Integration, by Tihomir
Game AI is an incredibly difficult thing to get right for the masses, but luckily we have access to the Recast Navigation AI. Tihomir is creating Recast Navigation bindings and adjusting them to jME3 — a task which is easier said than done (jME3 is Java and Recast is C++). We're confident he is up to the challenge!

This year we also made our first attempt at a community-sponsored summer of code, for which we secured another four incredibly promising students. Albeit at a more relaxed schedule, they will follow along the GSoC schedule and take advantage of our support network just the same. If all goes well, we will have seven shiny new projects once the summer cools off.

By Erlend Sogge Heggen, Organization Administrator for jMonkeyEngine
----------------------

BuildmLearn is a group of volunteers who collaborate to promote mobile learning (m-Learning) with the specific aim of creating open source tools and enablers for teachers and students. The group is involved in developing m-Learning solutions, tool-kits and utilities for teachers, parents and students.

Our current projects include the BuildmLearn Toolkit which is an easy-to-use program that helps users make mobile apps without any knowledge of application development. The toolkit empowers users to create mobile applications with various functionality and custom content. Targeted at teachers, this program helps them make learning fun and engaging through mobile apps. Besides the toolkit, we have mobile application projects focussing on education.

What our students are working on?

This is BuildmLearn's first year in Google Summer of Code and we received a large number of proposals (over 250!) from students all over the world. Three of the best proposals were chosen based on a careful selection process.

- Martin from Czech Republic is working on porting the BuildmLearn Toolkit to Linux, OS/2 and Mac OS X. He has also proposed to work on several enhancements to the toolkit and stabilize the code base.

- Kelvin from Malaysia is working on an educational mobile game called “Tell the time” which teaches children about the concepts of time and date in an interesting manner. Targeted at children 4 to 8 years of age, this mobile game will use an interactive clock and calendar elements to engage the kids.

- Abhishekh from India is working on an interesting mobile application called “Learn from Map” which is focused on teaching geography. Targeted at kids studying in primary schools, this application would use interactive map elements to teach geography and related topics in an informal environment.

BuildmLearn is very excited about being a part of this amazing program and will be happy to showcase the work done by the students as the program progresses.

By Pankaj Nathani, BuildmLearn Organization Administrator

GSoC students create a Google Compute Engine interface to CloudStack

Today on the Open Source blog we have guest writer Sebastien Goasguen, an avid open source contributor and member of the Apache Software Foundation. Below, Sebastien highlights the significant contributions that two Google Summer of Code students have made to Apache CloudStack.

In December 2013, Google announced the General Availability (GA) of the public cloud, Google Compute Engine (GCE).  Apache CloudStack now has a brand new GCE compatible interface (Gstack) which allows users to take advantage of the GCE clients (i.e gcloud and gcutil) to access their CloudStack cloud. This interface was made possible through the Google Summer of Code (GSoC) program.

In the summer of 2013, Ian Duffy, a student from Dublin City University, participated in GSoC through the Apache Software Foundation and worked on a LDAP plugin to CloudStack. He did such a great job that he finished early and was made an Apache CloudStack committer. Since he finished his primary GSoC project so early, I encouraged him to take on another! He brought in a friend for the ride — Darren Brogan, another student at Dublin City University. Together they worked on the GCE interface to CloudStack and even learned Python in doing so.

Both Ian and Darren remained engaged with the CloudStack community and as their third year project in University, they successfully developed an Amazon EC2 interface to CloudStack. Since he enjoyed his experience so much, Darren also applied to the GSoC 2014 program and proposed to revisit Gstack, improve it, extend the unit tests, and make it compatible with the GCE v1 API. He is making excellent progress so far and we are all excited to see the results.

Technically, Gstack is a Python Flask application that provides a REST API compatible with the GCE API and forwards the requests to the corresponding CloudStack API. The source is available on GitHub and the binary is downloadable via PyPi.

Installation and Configuration of Gstack

Are you interested in using Gstack? Check out the full documentation. To get a taste for things, you can grab the binary package from Pypi using pip in one single command.

        pip install gstack

Or if you plan to explore the source and work on it, you can clone the repository and install it by hand. Pull requests are of course welcome.

       git clone https://github.com/NOPping/gstack.git
   
sudo python./setup.py install

Both of these installation methods will install a gstack and a gstack-configure binary in your path. Before running Gstack you must configure it. To do so run:

   gstack-configure

And enter your configuration information when prompted. You will need to specify the host and port where you want gstack to run on, as well as the CloudStack endpoint that you want gstack to forward the requests to. In the example below we use the exoscale cloud:

   $ gstack-configure

   gstack bind address [0.0.0.0]: localhost

   gstack bind port [5000]:
   
Cloudstack host [localhost]: api.exoscale.ch
   
Cloudstack port [8080]: 443
   
Cloudstack protocol [http]: https

   Cloudstack path [/client/api]: /compute

The information will be stored in a configuration file available at ~/.gstack/gstack.conf:

   $ cat ~/.gstack/gstack.conf 

   PATH = 'compute/v1/projects/'

   GSTACK_BIND_ADDRESS = 'localhost'
   
GSTACK_PORT = '5000'
   
CLOUDSTACK_HOST = 'api.exoscale.ch'
   
CLOUDSTACK_PORT = '443'
   
CLOUDSTACK_PROTOCOL = 'https'
 
   CLOUDSTACK_PATH = '/compute'

You are now ready to start Gstack in the foreground with:

   gstack

That's all there is to running Gstack. You can then use gcutil to send requests to gstack which will forward them to a CloudStack endpoint.  Although it is still a work in progress, it is now compatible with GCE GA v1.0 API. It provides a solid base to start working on hybrid solutions between GCE public cloud and a CloudStack based private cloud.

GSoC has been a terrific opportunity for all of us at Apache. Darren and Ian both learned how to work with an open source community and ultimately became an integral part of it. They learned tools like JIRA, git, and Review Board and gained confidence working publicly on mailing lists. Their work on Gstack and EC2stack is certainly of high value to CloudStack and could eventually become the base for interesting products that will use hybrid clouds.

By Sebastien Goasguen, Senior Open Source Architect, Citrix and Apache Software Foundation member

Flowing into your games: LiquidFun 1.1

We are thrilled to announce the 1.1 release of LiquidFun, an open-source 2D physics engine. It adds particle simulation to Erin Catto’s popular Box2D engine, and can be used as a drop-in replacement for Box2D. If your program is written in C++, Java, or JavaScript, you can easily use LiquidFun.

Today’s release adds some exciting new features to LiquidFun. Some highlights:

• LiquidFun now runs in your browser! Using Emscripten, we’ve translated LiquidFun into JavaScript. You can see LiquidFun’s Testbed application, rewritten in JavaScript, running on our landing page.

• We’ve added iOS support for LiquidFun’s internal Testbed and EyeCandy applications. Earlier versions of LiquidFun could be made to run on iOS, but iOS is now officially supported.

• We’ve optimized LiquidFun's particle simulation. In particular, we’ve written NEON (a.k.a., Advanced SIMD) code to improve performance on ARM processors.

• We’ve stabilized the simulation, fixed bugs, and added some cool new functions, including one that automatically splits a particle group into multiple, disjoint particle groups. 

• We’ve clarified and improved the documentation, thanks to questions from the LiquidFun community.

LiquidFun Games

The 1.1 release also includes two physics-based, open-source games from Google, currently available in the US Play Store.

VoltAir, written in C++, is a fast platformer based on a compelling physics system, plenty of speed and motion, and interesting puzzles. If you’re a native developer, VoltAir’s source code is a great example of how to use LiquidFun.

The second game, LiquidFun Paint, lets you create art that moves, shakes, and delights. It is written in Java, and uses LiquidFun via SWIG bindings. If you’re a Java programmer, you may want to peruse the source code of LiquidFun Paint.

Several other games also have incorporated LiquidFun since its initial 0.9 release last December. One such game is the beautiful Battle of the SeaSons, written by three students from the technology university ETH Zurich.

Adoption

Our March 2014 release of LiquidFun 1.0 has already been integrated into several game development toolkits.

• Industry legend Ricardo Quesada has created an excellent tutorial on how to use LiquidFun with his popular Cocos2D-X engine. 

• Corona Labs has integrated LiquidFun into Corona Pro and Enterprise. They also have two fantastic tutorials on using LiquidFun with Corona: one an introduction, and another for particle collisions.

• YoYo Games has integrated LiquidFun 0.9 into GameMaker: Studio, and provided an excellent tutorial on the basics of particle systems.

• LiquidFun is also now a built-in component of the Lobster game programming language. 

Inside LiquidFun

If you’d like to learn even more about how the LiquidFun particle simulation works, you may enjoy our new presentation describing the tech and algorithms, Inside LiquidFun.

By Jason Sanmiya, Fun Propulsion Labs at Google*

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

Hot weather, cool code: July Unix User's Group meeting

Unigroup is the oldest and largest Unix User's Group (Unix/Linux/BSD) serving the Greater New York City Regional Area. It has been serving the NYC Unix/BSD Community for over 30 years, and the NYC Linux Community for over 20 years.

Unigroup organizes monthly meetings, each of which contains a main presentation on a wide variety of topics. In this month's event, happening on Thursday, July 17th, 2014, I will present the FreeBSD Test Suite and its backing testing framework, Kyua, both of which are supported by the Google Open Source Programs Office.

Today's blog post features the key concepts behind the FreeBSD Test Suite and what you can expect from Thursday’s meeting. If you are attending, please do not forget to RSVP by July 17th!

The FreeBSD Test Suite
FreeBSD is a Unix-like, free, general purpose operating system with a large codebase — over 5 million lines according to Ohloh. In order to easily ascertain the quality of the system and to ensure that such quality does not regress over time, the foundations of a test suite and a collection of tests were needed.

With funding from a Google Summer of Code project in 2007, I got involved in writing a test suite framework for NetBSD known as ATF, parts of which were rewritten under the Kyua project name starting in 2010. Both ATF and Kyua have always been standalone components able to work on any Unix-like operating system. Until recently, NetBSD was the major consumer of these testing tools, but in 2013 they spilled into FreeBSD to equip the system with its own test suite.

The goals of the FreeBSD Test Suite are to assist developers in modifying the system, to assist end users in validating that the system works according to documented expectations, and to assist the release engineering team in vetting new releases and to put the shiny-new Kyua framework to use in a production-quality project.

Currently, the FreeBSD Test Suite is part of both FreeBSD 11.0-CURRENT (the development branch) and of stable/10 (the stable branch that will yield 10.1-RELEASE). The test suite currently holds about 570 test cases — a pretty small number considering its scope, but decent enough given that the test suite foundations are still under active development.

Kyua: the test suite glue
Kyua is a runtime engine for test suites, mostly engineered towards testing operating systems. In general terms, a test suite defines the layout of its test programs and its test cases using a declarative language that Kyua is in charge of. Based on this definition, Kyua allows to execute the tests in a controlled environment and to generate user-friendly and machine-parseable reports of the results. Continuous integration facilities are left to better-suited third-party systems such as Jenkins.

Kyua is able to run test programs implemented in a variety of languages with support for various different testing libraries. In particular, Kyua can run ATF-based test programs (written in either C, C++ or POSIX shell), legacy test programs (those that just exit with 0 or 1 depending on the test's success), and TAP-compliant test programs. It should be possible, and is in fact planned, to support other backends like GoogleTest.

The upcoming talk
In Thursday’s meeting, I will be presenting all of the above and much, much more.

The session will start with a bit of history about my involvement with the BSDs. I’ll talk about the goals of the FreeBSD Test Suite while comparing those with its NetBSD counterpart, presenting the Kyua project, outlining the current state of the test suite, showcasing Jenkins and possibly performing some live demonstrations. Expect code samples.

If you happen to be in the New York City area on the 17th, RSVP and join us for the session!

By Julio Merino, Google Site Reliability Engineering