Google Summer of Code 2015 midterms are here!

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

Impressions from the European Lisp Symposium, Goldsmith University April 2015

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.

Easier provisioning of Google Apps accounts for your domain

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

Google Code-in Wrap-up: Beyond the winners...

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

Google Code-in 2014 wrap up with Wikimedia, part two

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

Google Code-in 2014 wrap up with OpenMRS, part two

OpenMRS is a medical records system used around the world, especially in places where resources are scarce. This past December and January, the OpenMRS community took part in Google Code-in. Today, grand prize winner Parker Erway tells us about writing code during the contest. (We previously featured a story from OpenMRS’ other grand prize winner.)

I’m Parker Erway. I worked with OpenMRS as part of Google Code-in 2014, a contest encouraging kids ages 13-17 to contribute to open source organizations. I’d say it’s working!

OpenMRS itself has a wonderful mission statement: “to improve health care delivery in resource-constrained environments by coordinating a global community that creates a robust, scalable, user-driven, open source medical record system platform.”

I had fun and learned a great deal contributing to OpenMRS. I spent about three weeks on developing an iOS client and its accompanying tasks (adding more features to, documenting, and publishing the app). Although I could have done this faster, I wanted to incorporate every best practice I knew of. One of my favorite things to do is start a fresh new project and try to do everything perfectly. It was great seeing all that hard work and learning pay off, and I’m proud to have made a lasting contribution to the community.

Through six tasks, I also spent time helping to overhaul OpenMRS-ID’s user interface in accordance with their new designs. I had never worked with Node before, and I learned a lot about how partials work, how the asset pipeline works, etc… Other projects I got to work on included deploying OpenMRS to OpenShift and suggesting improvements to the documentation, improving the Modulus search algorithm, correcting bad code practices using Sonar, and fixing a few bugs.

I’d never contributed to a large open source organization before, but I think it’s totally worth it. You meet amazing people doing amazing things, and you get to work with and learn from them. Before working with OpenMRS, I had the impression that large organizations -- even open source ones -- tend to take forever to make changes and review work and such. But once I started, I found that things happened quickly and you could really get stuff done. I truly felt like a member of the community after the contest period, and I’m very grateful to the OpenMRS mentors.

Although I could have completed a larger number of tasks, what’s important to me is that every line of code I write is maintainable, solid, testable (ideally tested as soon as I write it), and in general, good. I want to do good work, not a large amount of mediocre work. Google Code-in has helped cement that concept in me, and I plan to continue contributing to OpenMRS. I hope to see other GCI students stay in the community, too!

by Parker Erway, GCI Grand Prize Winner