Posted:
Today we have a guest post from Sam Parkinson, a 15 year-old Google Code-in 2014 grand prize winner. Sam worked with Sugar Labs for two instances of Google Code-in and tells us more about his journey navigating the world of free and open source software. We hope this is only the beginning of Sam’s contributions.
Ever since I was young, naive and enjoying my first tastes of Linux, I've wanted to contribute to the FOSS community. For me, Google Code-in (GCI) made that dream come true. I was lucky enough to be able to participate for the last two years with the mentoring organization Sugar Labs.

Sugar Labs is a “desktop environment without a desktop” that uses Python. Officially, Sugar Labs is the core component of a worldwide effort to provide every child with an equal opportunity for a quality education. Available in 25 languages, Sugar Labs activities are used every school day by nearly 3 million children in more than 40 countries.

I started my FOSS journey in GCI 2013 by completing the simple task of changing a ValueError to a logged exception. At first, my confidence level went from "yeah, I know some cool Python tricks" to "omg! how do I code?". I discovered new (and sometimes confusing) things like PEP8, git-branch and mailing lists. However, having the GCI and Sugar Labs communities as a support system made my dream of contributing to FOSS manageable by breaking it up into small, manageable tasks.

I worked on some pretty cool features, like adding a nutcracker-style mode in a Speak activity, where users could insert a picture of a face and have it talk to them.
I also worked on some not-so-fun tasks, like fixing bugs caused by GTK updates while trying not to break compatibility with ancient versions. But by the end of GCI 2014, I had learned how to pass code reviews and even completed some of my own. Hopefully I’ve programmed something that has made somebody smile.

In 2014, I was lucky enough to be chosen as a GCI winner. The grand prize trip was the cherry on top of the proverbial cake. I got to meet the amazing people I'd been hacking with, plus some pretty inspiring people from Google and other FOSS projects. I found it mind blowing to actually talk with people about programming face to face, and even better to sit around laughing about the programming culture. A highlight of the trip was meeting Walter Bender, one of the Sugar Labs mentors. Together we hacked on a project improving the Sugar Labs website. It’s not done, but it’s in better shape than it was before, and I can claim that I did some coding during the trip.

GCI was truly something that changed my life. I went from being an open source newbie to being able to contribute to really cool projects, thanks to the amazing GCI and Sugar Labs communities. It's something that I would recommend any young programmer consider doing. Participating in GCI is something that can make dreams come true.

By Sam Parkinson, Google Code-in grand prize winner

Posted:
(Cross-posted from the Go Blog)

Today the Go project is proud to release Go 1.5, the sixth major stable release of Go.

This release includes significant changes to the implementation. The compiler tool chain was translated from C to Go, removing the last vestiges of C code from the Go code base. The garbage collector was completely redesigned, yielding a dramatic reduction in garbage collection pause times. Related improvements to the scheduler allowed us to change the default GOMAXPROCS value (the number of concurrently executing goroutines) from 1 to the number of available CPUs. Changes to the linker enable distributing Go packages as shared libraries to link into Go programs, and building Go packages into archives or shared libraries that may be linked into or loaded by C programs (design doc).

The release also includes improvements to the developer tools. Support for "internal" packages permits sharing implementation details between packages. Experimental support for "vendoring" external dependencies is a step toward a standard mechanism for managing dependencies in Go programs. The new "go tool trace" command enables the visualisation of  program traces generated by new tracing infrastructure in the runtime. The new "go doc" command is a substitute for the original "godoc" that provides an improved command-line interface.

There are also several new operating system and architecture ports. The more mature new ports are darwin/arm, darwin/arm64 (Apple's iPhone and iPad devices), and linux/arm64. There is also experimental support for ppc64 and ppc64le (IBM PowerPC 64-bit, big and little endian).
The new darwin/arm64 port and external linking features fuel the Go mobile project, an experiment to see how Go might be used for building apps on Android and iOS devices. (The Go mobile work itself is not part of this release.)

The only language change was the lifting of a restriction in the map literal syntax to make them more succinct and consistent with slice literals.

The standard library saw many additions and improvements, too. The flag package now shows cleaner usage messages. The math/big package now provides a Float type for computing with arbitrary-precision floating point numbers. An improvement to the DNS resolver on Linux and BSD systems has removed the cgo requirement for programs that do name lookups. The go/types package has been moved to the standard library from the golang.org/x/tools repository. (The new go/constant and go/importer packages are also a result of this move.) The reflect package provides the new ArrayOf and FuncOf functions, analogous to the existing SliceOf function. And, of course, there is the usual list of smaller fixes and improvements.

For the full story, see the detailed release notes. Or if you just can't wait to get started, head over to the downloads page to get Go 1.5 now.

by Andrew Gerrand, Go team

Posted:
Over the weekend, we released Shaderc: a library and command-line tool for translating graphics shaders from GLSL into SPIR-V.  It is a wrapper around Glslang, the open source reference compiler for GLSL published by the Khronos Group.

Shaderc is designed to be as developer-friendly as possible and encourage the widest adoption of best-in-class open GLSL compiler technology. It offers:

  • A C API that is portable, thread-safe, and easy to use.
  • An idiomatic object-based C++ API.  This is a headers-only wrapper around the C API, to minimize the impact of potential changes in the environment's C++ ABI.
  • glslc, a command-line shader compiler.  Its arguments and file handling are similar to Clang and GCC, for easy integration with standard build systems.

Shaderc works on Linux, and there is an initial port to Windows.

The Shaderc project is released under the Apache License, Version 2.0, and is available immediately on GitHub at http://github.com/google/shaderc. Contributions from the community are welcome.

By David Neto and Dejan Mircevski, Google Engineering

Posted:
The Google Open Source Programs Office recently co-sponsored a three-day hackathon for Haskell, an open source functional programming language. Johan Tibell from Google’s Zurich office talks more about the event below.



On the weekend of May 29th, 120 Haskell enthusiasts got together for the 5th installment of ZuriHac, a yearly open source Haskell hackathon held in Zurich, Switzerland. This year we were back where it all started in 2010: the ground floor of the Google Zurich office.


The schedule was packed solid, and we also put together a complete three day experience for the many beginners in attendance. One room was dedicated to beginner talks and staffed by volunteer mentors (thanks all of you!) that made sure everyone had someone to turn to for questions or just some casual chatting about Haskell. Videos from three of those talks are now online: Monads by Example, Beginning Web Programming in Haskell, and Performance.


The main event featured a mind-bending talk about interesting implementations of sorting algorithms by Edward Kmett (slides) and a deep-dive into writing high-performance binary serialization code by Duncan Coutts (slides).


20150529_131051.jpg
We ran out of whiteboards so we had to use flipcharts!



After the intense hacking sessions, we had organized barbeques down by the Zurich lake. We had a very good turnout, taking over a large part of the park.


2015-05-29 18-38-22.JPG
Sharing a public barbeque with the locals.



All in all it was a very intense and enjoyable weekend, and we’ll try to organize the event again next year. Perhaps we can beat the current 120 attendee record!

By Johan Tibell, YouTube team


(edited 23 July 2015 with a correct link for the Beginning Web Programming in Haskell video. Thanks to our sharp-eyed reader who commented!)

Posted:
GoogleSummer_2015logo_horizontal.jpg

Today marks the halfway point of Google Summer of Code 2015. Both students and mentors will be submitting their midterm evaluations of one another through Friday, July 3 as indicated in our timeline. If you would like to read more about these midterm evaluations, please check out the "How Do Evaluations Work?" link on our FAQ.

The next milestone for the program will be the “pencils down” date of August 17, after which students can take a week to scrub their code, write tests, improve calculations and generally polish their work before the firm end of coding on August 21.

There has been fantastic progress made so far, and we encourage all the students, mentors, and org admins to keep up the great work!


by Carol Smith, Open Source Team

Posted:
Martin Cracauer is a software engineer for Google’s Travel team and a dedicated Lisp enthusiast. Below, he shares his impressions of the recent European Lisp Symposium.

In April, I attended the 8th European Lisp Symposium in London. It was good to be there and I'm proud to have played a part by giving a talk about unwanted memory retention.


More than anything, I was struck by the professionalism of the performance-oriented Lisp programmers giving talks. The Lisp community has moved beyond fighting with their compilers and settling for a couple useless microoptimizations. At a modern Lisp conference like this one, the same terms used at any other performance computing conference rain down upon the audience. There isn't a generic "probably didn't fit the cache" -- now we talk specific caches and line counts. We don't say "swapping" -- we give specific counts of major and minor page faults and recognize the relative cost of each. We have a deep awareness of what will end up being a system call, and which ones are cheap in which OS.  I had a lot of interest at the 2006 European Common Lisp Meeting by describing how ITA uses Lisp only at compile time and gets full performance at runtime. In 2015, that’s just normal.


There’s still work to do, however. It’s not there yet, but I think Lisp should become the ideal language for both SIMD computing (via new primitives allowing the programmer to tell the compiler instead of relying on arbitrarily smart compilers) and for speculative execution (allow the programmer to make promises and crash if they turn out untrue). I'm always hoping somebody (else) will kick off that effort.


The second thing that struck me was how much people at this conference leverage two of Lisp’s major advantages:


  • compile time computing (having the full runtime language at compile time to expand your compiled code from whatever abstraction is most suitable)
  • and the "commandline", the REPL, inside a high performance language


Several presenters combined those features to construct 3D objects, and even built a bridge between computed 3D objects and interactively built objects (in a graphical editor). One of those sessions was Dave Cooper’s tutorial. Both could create sets of 3D objects that mixed computed objects and interactive building at an astonishing rate.


Breanndán Ó Nualláin’s talk, "Executable Pseudocode for Graph Algorithms", was useful to me because it gave a digestible example of more complex compile time computing. It’s difficult to illustrate the concept, but Breanndán used Lisp’s power as a "programmable programming language" to make a frontend that expresses pseudocode for algorithms in an optimized s-expression syntax. The result is readable, executable, and fast. In addition, you can easily create a backend that targets LaTeX so that you could put your running algorithm in a textbook. This is so useful when trying to understand what the power of a "programmable programming language" really means. Now your LaTex for the algorithms paper is derived from proven working code.


To me, the most jaw-dropping talk of the conference was Christian E. Schafmeister’s "Clasp - A Common Lisp that Interoperates with C++ and Uses the LLVM Backend". The title is the understatement of the year. What is going on here is building tiny 3-nanometer protein-like structures to do useful things like cure cancer and destroy sarin. Although many C++ libraries exist for building such structures, it would be too painful to glue them all together in C++. Instead of feeding C++ through a layer of C and back into some object representation (like the rest of us, cough) Christian presented a Common Lisp implementation running in LLVM, using the LLVM runtime libraries that provide introspection to directly interface to C++. He was kind enough to give the talk again at our Google Cambridge office where it was recorded.


At large scale, Lisp exposes some rough spots. A lot of Googlers like really clean modularization, but Common Lisp packages don't quite provide it. This used to be a big problem for CMUCL, reducing the number of people who could build it. Robert Strandh talked about “First-class Global Environments in Common Lisp”. I am sure people would love to see that in SBCL. I also liked Paul van der Walt's talk, bringing forward ideas to improve restricted runtime environments (such as mobile devices) while keeping them easy to describe in their dependencies.


In my own talk on “Unwanted Memory Retention”, I didn’t just limit the discussion to Lisp, SBCL, and its garbage collector. I addressed group culture and perception bias: how imbalanced performance tradeoffs come about in long-running software projects, how they mix with rapid changes in the computing environment around your Lisp, and how Lisp is just a bit more flexible dealing with them.


This conference was an enlightening experience and I hope slides and videos will become available. For now, many of the topics covered are also discussed in the Symposium’s peer-reviewed papers (16MB PDF). But honestly, just reading doesn't do justice to the conference. People there were great presenters, too, and attending it was inspirational.


by Martin Cracauer, Travel team

2015-06-24 Edited to clarify the subject of Martin's 2006 talk.

Posted:
Creating a large number of Google Apps accounts (for Work or for Education) can be challenging. Today, we are introducing a new API to generate available usernames and create Google Apps accounts in your domain: Account provisioning for Google Apps. We are releasing the implementation of this API as open source under Google's GitHub organization. It can be installed as a RESTful service or Java library and can be used in a website where users create their own accounts or in a script that creates accounts in bulk.
Each user selects and creates their account (included under demos)

Account provisioning for Google Apps uses configurable patterns to generate usernames based on first name, last name and optional custom fields (e.g. second last name). For example: for someone named "Carlos Alvarez Martinez", the pattern [C1_firstname].[lastname][C1_secondlastname] will generate the username c.alvarezm. Further custom fields can be defined (e.g. [studentId]) and a list of patterns can be configured to generate multiple available usernames. In addition, this API caches existent usernames, so it's fast and prevents hitting Admin SDK API limits.
Accounts are created in bulk (included under demos)

by Miguel Alvarez, Enterprise team

Posted:
To conclude our series of posts about Google Code-in (GCI) 2014, we have an inspiring story from FOSSASIA mentor Praveen Patil. Although we’ve been shining a well-deserved spotlight on the contest winners -- including the two from FOSSASIA -- GCI is also about helping students take their very first steps toward becoming contributors to open source projects. For some students this year, GCI was even more than that: it was a first step toward essential computer literacy and the new possibilities it opens up for them.


December 2014 and January 2015 marked FOSSASIA’s first time participating in Google Code-in (GCI). Attending the FOSSASIA conference in February 2014 was a life-changing experience for me, and I spent the summer contributing to a FOSSASIA-sponsored project during the 2014 Google Summer of Code. Mario Behling and Hong Phuc, the mentors who helped me complete my project, asked me to take part in GCI with them and help pre-university students take their first steps into the world of free and open source software.

Ahead of the contest’s start, I began spreading the word about GCI with presentations at local schools and through online social networks. But when the contest began on December 1st, I noticed that most of my tasks had been claimed by students outside of India and that there was hardly any response from students of my own institute or the neighboring pre-university colleges. The few local students we did see participating were finding it difficult to complete even the beginner tasks, and none claimed any tasks in the coding category. So we began trying to understand why and see what we could do about it.

Ours is a small city in south India and we found that the main reason students weren’t participating was a lack of IT infrastructure in schools. Less than 1% of high school students have access to computers and the internet. They get a chance to learn coding after high school in the 11th standard, but only if they’ve opted to study computer science. In rural India, the situation is even worse. I realized that students are willing to participate in programs like GCI, but most are unable to do so because they lack even basic computer skills.

With suggestions and guidance from Mario and Hong Phuc, we organized a series of workshops at my home for students on every Saturday, Sunday and holiday. The first workshop in the series was “An Introduction to Free and Open Source Software and Google Code-in”. More than 100 students turned out for the session. We also held a session on installing Gnu/Linux and software like Libre Office, Gimp, Inkscape, and more. I was happy to see students engaged with FOSS, learning ‘til late in the evening even though their final exams were approaching.


Our next few workshops focused on using FOSS for documentation, basic image processing, designing, blogging, and an introduction to Python. These interactive sessions helped develop confidence and motivation in our students. More than 70 students registered for GCI! Many said that it was the first time they’d been able to have hands-on experience with computers and that they enjoyed learning and creating.


Many of our friends helped us by providing laptops, internet dongles, a projector, and -- most importantly -- their valuable time. My best friend (and better half) Minal Patil provided snacks for students and helped us conduct the workshops. We even had a GCI session on Christmas Day and celebrated in a different and meaningful way.

It was amazing to see the happiness on the face of students when they completed their first GCI tasks. After starting with no previous hands-on experience with computers, many were able to complete beginner tasks related to documentation and outreach. Some could create blogs and write about themselves and their GCI experiences. And a few students were even able to contribute to our open source project ExpEYES (Experiments for Young Engineers and Scientists) which turns a $35 Raspberry Pi computer into a lab for conducting science experiments. Some students also worked on building a small website about our group intended to give the students an opportunity to experience open source development culture.

It was great fun to learn new things every day along with the students, and it was incredibly fulfilling when the GCI 2014 results were announced on Google’s Open Source Blog. FOSSASIA had more completed tasks than any other participating organization, with 587 tasks completed by 174 students. And our school, Govindram Seksaria Science P.U. College, Belgaum (GSS), ranked #2 among 397 schools worldwide for participation with 49 students completing tasks. The school’s management were happy to learn about our success with GCI, displaying a congratulatory banner on the campus, and they are exploring ways to work with FOSSASIA to continue helping students in our region learn to code and contribute to FOSS.


Participating in GCI with FOSSASIA was a great learning experience for myself also, and I’m very grateful to Hong Phuc, Mario Behling, and the Google Open Source Programs Office. You have inspired me to take up this task of helping kids from this region to learn to code as a lifelong mission. Thanks a billion to all the students who participated in the contest, and I wish them a great future ahead.


by Praveen Patil, GSoC alumnus and GCI mentor

Posted:
The Wikimedia Foundation was one of twelve organizations who participated in Google Code-in (GCI) this past December and January, our open source contest for 13 to 17 year old students. Today, grand prize winner Danny Wu tells us about his experience. He was also a GCI winner in 2012 with Fedora.



We all use open source software every day, but although I had contributed patches here and there, I’d never contributed in-depth to a major project before taking part in Google Code-in (GCI). This year, GCI helped me dive into open source development and join the wonderful, helpful, and talented community of Wikimedia.

This year’s contest wasn’t my first time participating in GCI, though. I had completed tasks with KDE and Fedora in the past. But this time, I was intrigued when I saw that Wikimedia -- the non-profit behind Wikipedia and MediaWiki -- was a mentoring organization. Like many people, I've used Wikipedia countless times. I also knew that MediaWiki powers several of the sites I visit. The web-dev nature of Wikimedia sites meant my skills were a good match too.

My first task involved refactoring Citoid, a Node.js service for looking up citation metadata. I was initially a little scared. There are so many established conventions, and everyone seems so busy. What if I make a mistake? I hoped I wouldn't waste anyone's time. Regardless, I followed a guide and set up my development environment for Gerrit code review, then submitted my first patch. My mentor helpfully pointed out some code convention issues (like trailing whitespace). After fixing those, my patch got merged!

I also completed a variety of other interesting tasks like improving extensions, adding internationalization, and working on MediaWiki core. They were fun and I even learned Python through working on pywikibot. More importantly, it was fun to work with my mentors and the other people in the community. Software isn't made in a vacuum -- it’s written by real people with real interests. Being a part of a community is one of the best things about many open source projects. People helped me graciously when I couldn’t figure something out, and I was happy to answer others’ questions on IRC when I could.

I’ve learned a lot through GCI: new tools, the value of code reviews, and even that it’s fine to not know exactly what you're doing at first as long as you're willing to learn! I had a fantastic time and am grateful to have been selected as a Grand Prize winner. I'd like to repeat what Wikimedia mentor Andre Klapper said previously -- thank you!


by Danny Wu, GCI grand prize winner