Contributing to the AMP Project

This is a guest post by Adam Silverstein who was recently recognized through the Google Open Source Peer Bonus Program for contributions to the AMP Project. We invited Adam to share about his work on our blog.

I started my web career building websites for small businesses on WordPress, so when I decided to begin contributing to open source, WordPress was a natural place to start.

Now I work at the digital agency 10up, where I am a part of our open source team. We build popular sites like FiveThirtyEight where having the best possible AMP experience is critical. However, bringing FiveThirtyEight’s AMP version up to parity with the site’s responsive mobile experience was challenging, in part because of advanced features that aren’t directly supported in AMP.

One of those unsupported features was MathML, a standard for displaying mathematical formulas on the web. To avoid a clumsy work around (amp-iframe) and improve our presentation of formulas, I proposed a native `amp-mathml` component which could display formulas inline. Contributing improvements “upstream” to open source projects – especially as we encounter friction in real-world projects – is a core value at 10up and important to the health of the web. I expected that I could leverage the same open source MathJax library we used on the responsive website for an AMP implementation. Contributing this component would strengthen my understanding of AMP’s internals while simultaneously improving a client site and enabling the open MathML standard on any AMP page. Win, win, win!

I started by opening an issue on Google’s amphtml repository, describing MathML and proposing a native `amp-mathml` component. Justin Ridgewell from the AMP team immediately responded to the issue and asked Ali Ghassemi to track it. I offered to help write the code and received an enthusiastic response, encouraging me and assuring me that the team would be available on GitHub and in Slack to answer any questions.

This warm welcome gave me the confidence to dive in, but ramp up was daunting. The build tools and coding standards were quite different from other projects I work on and setup required some editor reconfiguring and reflex retraining. Getting the unit test to run on my system required tracking down and installing some missing dependencies.

Fortunately, AMP’s project documentation is thorough, and Ali guided me through the implementation, pointing me to existing, similar samples in the project. I already knew how to use JavaScript to render formulas with MathJax – my challenge was building an AMP component that ran this code and displayed it inline.

After a few days of concerted effort, I built a proof of concept and opened a pull request. The real fun began as I refined the approach and wrote documentation with help from the team. The team’s active engagement helped the process move along rapidly. Amazingly, the pull request was merged one week later, and today amp-mathml is live in the wild. FiveThirtyEight is already using the new, native implementation.

From opening the issue all the way to the merge of my pull request, I was impressed by the support and encouragement I received. Ali and honeybadgerdontcare provided regular reviews and thorough suggestions on the pull request when I pushed iterations. Their engagement throughout the process made me and my work feel valued, and helped me stay motivated to continue working on the feature.

Adding MathML to AMP reminded me why I find so much joy and professional growth in contributing to open source projects. I have a better understanding of AMP from the inside out, and I was welcomed into the project’s community with wide open arms. I'm proud of my contribution, and ready to tackle new challenges after seeing its success!
 
By Adam Silverstein, AMP Project contributor

My first open source project and Google Code-in

This is a guest post from a mentor with coala, an open source tool for linting and fixing code in many different languages, which participated in Google Code-in 2017.

About two years ago, my friend Gyan and I built a small web app which checked whether or not a given username was available on a few popular social media websites. The idea was simple: judge availability of the username on the basis of an HTTP response. Here’s a pseudo-code example:

website_url = form_website_url(website, username)
# Eg: form_website_url('github', 'manu-chroma') returns 'github.com/manu-chroma'

if website_url_response.http_code == 404:
  username available
else:
  username taken

Much to our delight, it worked! Well, almost. It had a lot of bugs but we didn’t care much at the time. It was my first Python project and the first time I open sourced my work. I always look back on it as a cool idea, proud that I made it and learned a lot in the process.

But the project had been abandoned until John from coala approached me. John suggested we use it for Google Code-in because one of coala’s tasks for the students was to create accounts on a few common coding related websites. Students could use the username availability tool to find a good single username–people like their usernames to be consistent across websites–and coala could use it to verify that the accounts were created.

I had submitted a few patches to coala in the past, so this sounded good to me! The competition clashed with my vacation plans, but I wanted to get involved, so I took the opportunity to become a mentor.

Over the course of the program, students not only used the username availability tool but they also began making major improvements. We took the cue and began adding tasks specifically about the tool. Here are just a few of the things students added:

• Regex to determine whether a given username was valid for any given website
• More websites, bringing it to a total of 13
• Tests (!)

The web app is online so you can check username availability too!

I had such a fun time working with students in Google Code-in, their enthusiasm and energy was amazing. Special thanks to students Andrew, Nalin, Joshua, and biscuitsnake for all the time and effort you put into the project. You did really useful work and I hope you learned from the experience!

I want to thank John for approaching me in the first place and suggesting we use and improve the project. He was an unstoppable force throughout the competition, helping both students and fellow mentors. John even helped me with code reviews to really refine the work students submitted, and help them improve based on the feedback.

Kudos to the Google Open Source team for organizing it so well and lowering the barriers of entry to open source for high school students around the world.

By Manvendra Singh, coala mentor

A galactic experience in Google Code-in 2017

This is a guest post from Liquid Galaxy, one of the organizations that participated in both Google Summer of Code and Google Code-in 2017.

Liquid Galaxy, an open source project that powers panoramic views spanning multiple computers and displays, has been participating in Google Summer of Code (GSoC) since 2011. However, we never applied to participate in Google Code-in (GCI) because we heard stories from other projects about long hours and interrupted holidays in service of mentoring eager young students.

That changed in 2017! And, while the stories are true, we have to say it’s also an amazing and worthwhile experience.

It was hard for our small project to recruit the number of mentors needed. Thankfully, our GSoC mentors stepped up, as did many former GSoC students. We even had forward thinking students who were interested in participating in GSoC 2018 volunteer to mentor! While it was challenging, our team of mentors helped us have a nearly flawless GCI experience.

The Google Open Source team only had to nudge us once, when a student’s task had been pending review for more than 36 hours. We’re pretty happy with that considering we had nearly 500 tasks completed over the 50 days of the contest.

More important than our experience, though, is the student experience. We learned a lot, seeing how they chose tasks, the attention to detail some of them put into their work, and the level of interaction between the students and the mentors. Considering these were young students, ranging in age from 13 to 17, they far exceeded our expectations.

There was one piece of advice the Google Open Source team gave us that we didn’t understand as GCI newbies: have a large number of tasks ready from day one, and leave some unpublished until the halfway point. That ended up being key, it ensured we had enough tasks for the initial flood of students and some in reserve for the second flood around the holidays. Our team of mentors worked hard from the moment we were accepted into GCI to the moment we began to create over 150 tasks in five different categories. Students seemed to think we did a good job and told us they enjoyed the variety of tasks and level of difficulty.

We’re glad we finally participated in Google Code-in and we’ll definitely be applying next time! You can learn more about the project and the students who worked with us on our blog.

By Andreu Ibáñez, Liquid Galaxy org admin

Celebrating open source mentorship with Joomla

Let’s marvel for a moment: as Google Summer of Code (GSoC) 2018 begins, 46 of the participating open source organizations are celebrating a decade or more with the program. There are 586 collective years of mentorship between them, and that’s just through GSoC.

Free and open source software projects have been doing outreach and community building since the beginning. The free software movement has been around for 35 years, and open source has been around for 20.

Bringing new people into open source is necessary for project health and sustainability, but it’s not easy. It takes time and effort to prepare onboarding materials and mentor people. It takes personal dedication, a welcoming culture, and a commitment to institutional knowledge. Sustained volunteerism at this scale is worthy of celebration!

Joomla is one open source project that exemplifies this and Puneet Kala is one such person. Joomla, a web content management system (CMS) that was first released in 2005, is now on their 11th year of GSoC. More than 80 students have participated over the years. Most students are still actively contributing, and many have gone on to become mentors.

Puneet, now Joomla’s GSoC team lead, began with the project as a student five years ago. He sent along this article celebrating their 10th anniversary, which includes links to interviews with other students who have become mentors, and this panel discussion from Joomla World Conference.

It’s always great to hear from the people who have participated in Google Summer of Code. The stories are inspiring and educational. They know a thing or two about building open source communities, so we share what they have to say: you can find guest posts here.

We’d like to extend our heartfelt thanks to the 608 open source organizations and 12,000 organization administrators and mentors who have been a part of GSoC so far. We’d also like to applaud the 46 organizations that have 10+ years under their belts!

Your tireless investment in the future of people and open source is a testament to generosity.

By Josh Simmons, Google Open Source

Coding your way into cinemas

This is a guest post from apertus° and TimVideos.us, open source organizations that participated in Google Summer of Code last year and are back for 2018!

The apertus° AXIOM project is bringing the world’s first open hardware/free software digital motion picture production camera to life. The project has a rich history, exercises a steadfast adherence to the open source ethos, and all aspects of development have always revolved around supporting and utilising free technologies. The challenge of building a sophisticated digital cinema camera was perfect for Google Summer of Code 2017. But let’s start at the beginning: why did the team behind the project embark on their journey?

Modern Cinematography

For over a century film was dominated by analog cameras and celluloid, but in the late 2000’s things changed radically with the adoption of digital projection in cinemas. It was a natural next step, then, for filmmakers to shoot and produce films digitally. Certain applications in science, large format photography and fine arts still hold onto 35mm film processing, but the reduction in costs and improved workflows associated with digital image capture have revolutionised how we create and consume visual content.

The DSLR revolution

Photo by Matthew Pearce
licensed CC SA 2.0.

Filmmaking has long been considered an expensive discipline accessible only to a select few. This all changed with the adoption of movie recording capabilities in digital single-lens reflex (DSLR) cameras. For multinational corporations this “new” feature was a relatively straightforward addition to existing models as most compact digital photo cameras could already record video clips. This was the first time that a large diameter image sensor, a vital component for creating the typical shallow depth of field we consider cinematic, appeared in consumer cameras. In recent times, user groups have stepped up to contribute to the DSLR revolution first-hand, including groups like the Magic Lantern community.

Magic Lantern

Photo by Dave Dugdale licensed CC BY-SA 2.0.

Magic Lantern is a free and open source software add-on that runs from a camera’s SD/CF card. It adds a host of new features to Canon’s DSLRs that weren't included from the factory, such as allowing users to record high-dynamic range (HDR) video or 14-bit uncompressed RAW video. It’s a community project and many filmmakers simply wouldn’t have bought a Canon camera if it weren’t for the features that Magic Lantern pioneered. Because installing Magic Lantern doesn’t replace the stock Canon firmware or modify the read-only memory (ROM) but runs alongside it, it is both easy to remove and carries little risk. Originally developed for filmmaking, Magic Lantern’s feature base has expanded to include tools useful for still photography as well.

Starting the revolution for real 

Of course, Magic Lantern has been held back by the underlying proprietary hardware routines on existing camera models. So, in 2014 a team of developers and filmmakers around the apertus° project joined forces with the Magic Lantern team to lay the foundation for a totally independent, open hardware, free software, digital cinema camera. They ran a successful crowdfunding campaign for initial development, and they completed hardware development of the first developer kits in 2016. Unlike traditional cameras, the AXIOM is designed to be completely modular, and so continuously evolve, thereby preventing it from ever becoming obsolete. How the camera evolves is determined by its user community, with its design files and source code freely available and users encouraged to duplicate, modify and redistribute anything and everything related to the camera.

While the camera is primarily for use in motion picture production, there are many suitable applications where AXIOM can be useful. Individuals in science, astronomy, medicine, aerial mapping, industrial automation, and those who record events or talks at conferences have expressed interest in the camera. A modular and open source device for digital imaging allows users to build a system that meets their unique requirements. One such company for instance, Mavrx Inc, who use aerial imagery to provide actionable insight for the agriculture industry, used the camera because it enabled them to not only process the data more efficiently than comparable camera equivalents, but also to re-configure its form factor so that it could be installed alongside existing equipment configurations.

Google Summer of Code 2017

Continuing their journey, apertus° participated in Google Summer of Code for the first time in 2017. They received about 30 applications from interested students, from which they needed to select three. Projects ranged from field programmable gate array (FPGA) centered video applications to creating Linux kernel drivers for specific camera hardware. Similarly TimVideos.us, an open hardware project for live event streaming and conference recording, is working on FPGA projects around video interfaces and processing.

After some preliminary work, the students came to grips with the camera’s operating processes and all three dove in enthusiastically. One student failed the first evaluation and another failed the second, but one student successfully completed their work.

That student, Vlad Niculescu, worked on defining control loops for a voltage controller using VHSIC Hardware Description Language (VHDL) for a potential future AXIOM Beta Power Board, an FPGA-driven smart switching regulator for increasing the power efficiency and improving flexibility around voltage regulation.

Left: The printed circuit board (PCB) (printed circuit board) for testing the switching regulator FPGA logic. Right: After final improvements the fluctuation ripple in the voltages was reduced to around 30mV at 2V target voltage.

Vlad had this to say about his experience:

“The knowledge I acquired during my work with this project and apertus° was very satisfying. Besides the electrical skills gained I also managed to obtain other, important universal skills. One of the things I learned was that the key to solving complex problems can often be found by dividing them into small blocks so that the greater whole can be easily observed by others. Writing better code and managing the stages of building a complex project have become lessons that will no doubt become valuable in the future. I will always be grateful to my mentor as he had the patience to explain everything carefully and teach me new things step by step, and also to apertus° and Google’s Summer of Code program, without which I may not have gained the experience of working on a project like this one.”

We are grateful for Vlad’s work and congratulate him for successfully completing the program. If you find open hardware and video production interesting, we encourage you to reach out and join the community–both apertus° and TimVideos.us are back for Google Summer of Code 2018.

By Sebastian Pichelhofer, apertus°, and Tim 'mithro' Ansell, TimVideos.us

A year full of new open source at Catrobat

This is a guest post from Catrobat, an open source organization that participated in both Google Summer of Code and Google Code-in last year.

Catrobat was selected to participate in Google Summer of Code (GSoC) for the sixth time and Google Code-in (GCI) for the first time in 2017, which helped us reach new students and keep our mentors busy.

We tried something new in 2017 by steering GSoC students toward refactoring and performance, rather than developing new features. Implementing a crash tracking and analysis system, modularizing existing code, and rewriting our tests resulted in more lines of code being deleted than added – and we’re really happy about that!

This improved the quality and stability of oursoftware and both students and mentors could see progress immediately. The immediacy of the results kept students engaged - some weeks it almost seemed as if they had been working 24/7 (they weren’t :)! And we’re happy to say that most are still motivated to contribute after GSoC, and now they’re adding code more often than they are deleting it.

Although new features are exciting, we found that working on existing code offers a smooth entry for GSoC students. This approach helped students assimilate into the community and project more quickly, as well as receive rapid rewards for their work.

The quality improvements made by GSoC students also made things smoother for the younger, often less experienced GCI students. Several dozen students completed hundreds of tasks, spreading the love of open source and coding in their communities. It was our first time working with so many young contributors and it was fun!

We faced challenges in the beginning – such as language barriers and students’ uncertainty in their work – and quickly learned how to adapt our processes to meet the needs (and extraordinary motivation) of these new young contributors. We introduced them to open source through our project’s app Pocket Code, allowing them to program games and apps with a visual mobile coding framework and then share them under an open license. Students had a lot of fun starting this way and mentors enjoyed reviewing so many colorful and exciting games.

Students even asked how they could improve on quality work that we had already accepted, if they could do more work on it, and if they could share their projects with their friends. This was a great first experience of GCI for our organization and, as one of our mentors mentioned in the final evaluation phase, we would totally be up for doing it again!

By Matthias Mueller, Catrobat Org Admin

Google Summer of Code 2016 wrap-up: LabLua

This is the final guest post from the students, mentors and organization administrators that participated in Google Summer of Code (GSoC) 2016. We’ve seen recaps of student work and lessons learned, which you can check out the rest of the series as we gear up for this year’s program.

LabLua is a lab at PUC-Rio dedicated to research on programming languages, with emphasis on the Lua language. Lua is a powerful, fast, lightweight, embeddable scripting language that is used in many industrial applications, and on many embedded systems and games.

We were very happy to participate in Google Summer of Code (GSoC) for the third time, and to mentor eight fine students that all completed their projects successfully. We thank them, and Google, for this extraordinary contribution to our research and development work.

Here is a brief summary of this year's projects:

Next Generation of the LuaRocks test suite - Robert Karasek

LuaRocks is the package manager for Lua modules. Its test suite was implemented as a big shell script that performed only black-box testing and ran only on Linux. The goal for this project was to port the test suite to Lua, improving its portability and allowing more types of tests so we could improve test coverage.

Robert ported the test suite to Lua using Busted. His new test suite, now merged into LuaRocks, runs on Linux and Mac OS X, accessible via Travis CI, as well as Windows, accessible via AppVeyor. 

This was a welcome addition, bringing greater confidence to developers. Robert improved the checks in existing tests and wrote many new ones, including a new mock-server for testing a client API for uploading packages to the repository.

Typed Lua Typechecker - Tomasz Dyczek 

Typed Lua provides static type checking for the Lua language. Typed Lua extends the syntax of Lua 5.3 to introduce type annotations, and performs local type inference for more precise detection of unannotated expressions.

Tomasz implemented the core of Typed Lua in Haskell. Tomasz's implementation parses code written in a syntax close to the abstract syntax of Typed Lua, then type checks the generated AST. Besides providing a support for testing and reasoning about new features, Tomasz's typechecker can be also used to validate tests to be included in Typed Lua's test suite.

Classes and Generics for Typed Lua - Kevin Clancy

Kevin worked on the implementation of a class system for Typed Lua. He also added parametric polymorphism (generics) for classes and existing Typed Lua types, such as functions and tables.

Kevin's work currently lives in its own branch, but will be merged into the main branch soon. Meanwhile, Kevin has written a detailed post explaining all the features he implemented

Improving Error Reporting in PEG Parsers - Matthew Allen Go 

LPegLabel is an extension of LPeg, a pattern matching tool for Lua, based on Parsing Expression Grammars (PEGs). LPegLabel supports labeled failures, a facility that improves error reporting and recovery for PEG-based parsers.

The goal of this project was to use LPegLabel to write parsers with good error reporting. These parsers could then be used by the Lua community and also serve as a guide for LPegLabel users. Because LPegLabel is a young tool, another important contribution was to improve the tool's usability.

Matthew achieved both goals. He developed a parser for Lua 5.3, which has been incorporated into the new release of lua-parser (1.0.0), and improved LPegLabel’s usability with work on its API and documentation.

Improving elasticsearch-lua tests and build - Dhaval Kapil

Elasticsearch is a distributed and scalable search engine written in Java that offers a REST API accessed through JSON. During GSoC 2015, Dhaval implemented elasticsearch-lua, a client for the Lua language following a model similar to clients written in Python and PHP.

During GSoC 2016, Dhaval worked on improving elasticsearch-lua. He added a test suite, documented the entire codebase, and updated the current client to work with the newest version of Elasticsearch.

Dhaval went above and beyond, creating a new library called luaver. This work was motivated by having to frequently switch between different versions of Lua while developing the test suite. A full blog post about his project can be found here.

Admin Center and Elasticsearch integration for Sailor - Nikhil Ramesh 

Sailor is a web framework with a model-view-controller (MVC) architecture. Like other web frameworks, such as Ruby on Rails and Django, it is designed to make development faster by making some assumptions and conventions and encouraging principles like Don’t Repeat Yourself (DRY).

Nikhil focused on extending Sailor. The first feature he worked on was an Admin Center, which is a web interface for configuring an application. He also integrated Sailor and elasticsearch-lua, allowing Elasticsearch indexes to be stored as Sailor Models. His work is currently pending as a pull request and will soon be merged.

Extending the online tutorial of Céu with Emscripten and SDL - Margarit Vicentiu

Céu is a language for developing reactive applications such as video games and embedded systems. Its compiler generates output in plain C to integrate easily with the underlying platform (e.g. Arduino, SDL). For this project, we wanted to integrate Céu with Emscripten in order to run applications in a web browser.

Vicentiu started with Céu’s online tutorial, which is a server-side application: the user types code in a text area and hits the send button; the server receives the code, executes it, and sends the output back to the user. During the summer, Vicentiu made most of the examples compile with Emscripten and run in real-time on the user’s screen.

Our next goal is to make the graphical examples with user interactions also work in the browser, and Vicentiu plans to continue contributing to the project to achieve this goal.

An automatic generator of WSDL documents for LuaSOAP - Victor Dias

LuaSOAP is a library for working with the Simple Object Access Protocol (SOAP). WSDL is an XML format for describing network services; it is used to describe operations, messages and types offered by Web Services.

This summer Victor extended LuaSOAP's WSDL support by building a software layer for the automatic generation of WSDL documents. This new layer eases the description of most WSDL "bureaucracy" -- types, operations, ports, messages -- which have no counterparts in Lua. He also improved the test suite and the documentation. Victor's work will be integrated into the next version of LuaSOAP.

By Ana Lúcia de Moura, Organization Administrator for LabLua

Google Summer of Code 2016 wrap-up: CloudCV

This guest post is part of our ongoing series of posts from the students, mentors and organization administrators who participated in Google Summer of Code (GSoC), a program which gets university students contributing to open source software.

Google Summer of Code 2016 was a memorable one for CloudCV. Despite being a relatively “young” organization (this is just our second year as a mentor organization), there were many excellent applicants who put a tremendous amount of effort into their proposals and ramp-up tasks. It was difficult to choose!

CloudCV began in the summer of 2014 as a research project within the Machine Learning and Perception Lab at Virginia Tech, with the ambitious goal of democratizing computer vision and machine learning. We’re run exclusively by students and are working to enable developers, researchers, and fellow students to leverage artificial intelligence technology as a service and to share state of the art algorithms with the research community.

In line with this goal, we decided to build two tools that cater to computer vision researchers and hobbyists alike: CloudCV-fy your code and CloudCV-IDE. Though building two new platforms from the ground up was going to be challenging, our students’ motivation was overwhelming and their performance surpassed all expectations. We even demonstrated their work at CVPR 2016, a top-tier computer vision conference!

CloudCV-fy

A recurring use case for computer vision researchers, and many others, is to build a web-based demo and REST API to demonstrate the capabilities of their creations to the world. But web development involves writing hundred of lines of additional code across multiple languages (HTML, CSS, JavaScript, etc), which takes time away from research.


Our first student, Ashish Chaudhary, took on this problem by building CloudCV-fy. Over many iterations of design and development, Ashish delivered a tool that allows a user to simply write lightweight wrappers around their machine learning model/library and be done. CloudCV-fy automatically builds web-based interactive demos for them -- no need to tinker with HTML, CSS or JavaScript. Code to demo. Done.

The demo can be hosted on our servers, the user’s own server or any third party cloud service. As a result of this, researchers can focus on what they do best: designing and training models. CloudCV handles the rest. You can learn more in the write-up Ashish did on his blog.

CloudCV-IDE

There has been an explosion in the number of deep learning frameworks and it is difficult for researchers to keep up with all the latest tools. CloudCV-IDE, built by student Gaurav Gupta, addresses this by allowing a user to build a deep learning network with a drag-and-drop interface, then export to the deep learning framework of their choice (Caffe, TensorFlow, etc).

Gaurav also added support to import model configuration files in order to visualize any architecture. This is one of the first attempts to do this.



By the end of the summer, Gaurav delivered a great UI to visualize models with robust support for Caffe and TensorFlow back-ends. This was a successful start that we plan to build on by supporting more frameworks and facilitating collaborative building of deep learning models.

Overall, this was a highly productive GSoC for CloudCV. Our tools are under active development and we welcome contributions and ideas for new features.

We will definitely apply for GSoC 2017. If you are a student interested in participating we encourage you to get involved early! Feel free to reach out to us on our Gitter channel or on our mailing list.

By Viraj Prabhu, Organization Administrator for CloudCV

Google Summer of Code 2016 wrap-up: Orange

This post is part of our ongoing series of guest posts from the students, mentors and organization administrators who participated in Google Summer of Code (GSoC). GSoC is a program that pairs university students with mentors for a summer where they apply their computer science skills to building open source software.

Orange Data Mining is a data mining suite with visual programming and interactive data analysis at its core. Orange was developed at Bioinformatics Lab at University of Ljubljana, Slovenia, it is written mainly in Python, and you can find it hosted on GitHub.

This was our third Google Summer of Code and we were given five slots and decided to select students based on two criteria: their proposal joined with their coding skills and the importance of the project to our organization.

Great work was done over the summer and we are proud to present our students’ projects!

Recommender Systems add-on by Salva Carrion

Salva independently implemented a new Orange3 add-on for recommender systems. He developed a scripting library for collaborative filtering for the core of the add-on, which includes a number of published matrix factorization algorithms. The scripting library is then further extended to include GUI-based widgets for visual programming.

Educational add-on by Primož Godec

Primož took on a task of developing a series of educational widgets for Orange3. The end result was a full Orange3-Educational add-on with four widgets that can be used to demonstrate key data mining and machine learning procedures in the classroom. These widgets are useful for helping beginners understand the inner workings of key algorithms in data mining, and for teachers to be able to visually explain the various methods. They include interactive and step-by-step visualizations of k-means, polynomial classification, and gradient descent.

Text add-on by Aliaxey Sukharevich

Orange3-Text add-on was already an active project before GSoC, but Aliaxey took it to another level. Twitter and Wikipedia public RESTful services were introduced as widgets to allow acquisition of data from new sources. Many widgets were boosted with new functionalities and methods (e.g. HDP, LDA and LSP methods in Topic Modelling widget). Preprocessing was redesigned and reimplemented such that it now handles n-grams and POS Tagging.

CN2 Rule Induction by Matevž Kren

The goal of this project was to implement a CN2 rule induction algorithm, and Orange widgets for learning and exploration of inferred classification rules. At the heart of the project is an implementation of a scripting library, which can be easily extended with additional divide and conquer algorithms or its components.

Porting Orange codebase to Pandas by Sašo Stanovnik

This was a gargantuan task and Sašo handled it beautifully. The goal was to consolidate Orange data structures and management routines to support data from Pandas. Sašo redesigned Orange data management core, did a massive amount of refactoring and improvements and removed legacy and unused code. The biggest challenge was of course preserving as much compatibility with the existing Orange interaction as possible while providing full Pandas flexibility. The result is a functional Pandas-based core Orange.

All contributions were committed on GitHub (Orange3, Orange3-Text, Orange3-Recommendation and Orange3-Educational repositories) and most of them are already pip-installable. The only contribution that has not yet been merged is the migration to Pandas, which will require adaptation and careful compatibility checking of other components of the system.

We are extremely grateful to be given the chance to participate in Google Summer of Code and to have had such amazing students at our lab. We can’t wait to apply again next year!

By Ajda Pretnar, Organization Administrator for Orange

Google Summer of Code 2016 wrap-up: QEMU

This post is part of a series of guest posts from students, mentors and organization administrators reflecting on Google Summer of Code (GSoC) 2016.

QEMU is a machine emulator and virtualizer. It can run operating systems and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC).  It is also used by hypervisors like KVM and Xen to virtualize x86, ARM, POWER and other architectures so virtual machines can run at near-native performance.

This year was QEMU's sixth time participating in Google Summer of Code and we had 6 students from around the world. Here are highlights from GSoC 2016:

Pranith Kumar worked on Multi-threaded TCG, a larger effort to make QEMU's just-in-time compiler multi-core friendly. He studied the memory ordering CPU instructions for many architectures supported by QEMU and devised a TCG opcode that can represent the memory ordering semantics. His patches allow TCG to correctly translate memory ordering instructions (previously they were ignored!). This is one piece of the puzzle to support multi-threaded translation and will help emulation scale to many cores. Pranith also contributed to testing and debugging multi-threaded TCG issues that he encountered while contributing to this cutting-edge part of QEMU.

Gerard Garcia worked on packet capture support for AF_VSOCK in Linux, tcpdump and Wireshark. QEMU recently gained support for the virtio-vsock device that allows socket communication between guest and host. The AF_VSOCK address family didn't support packet capture yet, making it hard to debug and observe communication between applications. Gerard’s patches implement the kernel interfaces and tcpdump/Wireshark functionality needed to monitor traffic over AF_VSOCK. This project was challenging because it required getting code merged in multiple open source projects. Gerard pulled it off with great skill!

Every year QEMU applies to participate in GSoC and we’re delighted for the opportunity to mentor students interested in systems programming, emulation, compilers and low-level code like firmware. You are welcome to get in touch on IRC or our mailing lists any time of the year to find out about contributing to QEMU. We also have a wiki page with small tasks you can get started on as your first step in QEMU programming.

By Stefan Hajnoczi, Organization Administrator for QEMU

Google Summer of Code 2016 wrap-up: GitHub

Every year open source organizations, mentors, and university students come together to build and improve open source software through Google Summer of Code (GSoC). This guest post is part of a series of blog posts from people who participated in GSoC 2016.

Open source maintainers at GitHub mentored 5 students in Google Summer of Code last year. The students did great work that we’d like to highlight and congratulate them on:

Updates to GitHub Classroom 

GitHub Classroom helps teachers automate their work and interact with students in issues and pull requests. Last summer two students took on projects to help teachers work more efficiently and with greater insight into their classrooms.

Classroom Project #1 

Cheng-Yu Hsu is a student who worked to implement new features suggested by teachers using GitHub Classroom, including due dates for assignment submissions and visualizations of classroom activities. In reflecting on the project, Cheng-Yu said:

"Having a great community is one of the most important factors of a successful open source project, so participating [in] the community is also a huge part of this project. It is great to have chances responding to user feedback, helping people resolve issues and brainstorming new features with them."

Classroom Project #2

Shawn Ding worked on student identifiers and team management for GitHub Classroom. This means that teachers using GitHub Classroom can use things such as student emails to identify their assignments. Teachers can also now manage their students and teams of students using GitHub Classroom via drag and drop in the settings page which then updates the data on GitHub.

Front-end controls for Jekyll

Jekyll Admin is a Jekyll plugin that provides users with a traditional CMS-like graphical interface to author content and administer Jekyll sites from the comfort of their browser. GSoC student Mert Kahyaoğlu has been using Facebook’s React framework to create the front-end that will allow you to write a new post, edit existing pages or add new files. And it will all work with GitHub Pages.

Best of all, Mert's plugin allows people to author content and administer Jekyll sites without knowledge of command line or installing an external text editor like Atom. Once installed, Jekyll users start their site as they would normally and simply append “/admin” to their site's URL to launch the WordPress-like administrative interface. Jekyll Admin's initial release is ready for use on your own site.

Octokit.net 

Alexander Efremov added support to Octokit.net for interacting with the GitHub API using a repository ID, alongside the existing support for providing the owner and repository name. This means integrators do not have to update their systems when a repository changes ownership. The changes to support these APIs were rolled out incrementally over a number of pull requests, and 0.21 release of Octokit.net made these new APIs available to the public.

We had a great time mentoring these students on their projects last year!

By Carol Smith, John Britton and Brandon Keepers, Organization Administrators for GitHub

Google Summer of Code 2016 wrap-up: Oppia

Google Summer of Code (GSoC) is an annual program that encourages university students to become open source contributors. This guest post is part of a series of blog posts from the open source projects and organizations that participated in GSoC 2016.

The Oppia project makes it easy for anyone to create lightweight, interactive online lessons that simulate personal tutoring. These activities, called “explorations,” can be shared with others around the world as standalone tutorials (such as Programming with Carla and Quadratic Equations), or embedded in websites to supplement an existing course (such as “Take Your Medicine” on edX and Computational Thinking for Educators).

2016 was Oppia’s first year participating in GSoC and it was a blast! More students flocked to our ideas page than we had expected, and our Gitter channel was full of people saying hello and looking for starter projects. Over the course of the summer, with the help of two capable and enthusiastic students, we were able to bring the following new features to the Oppia codebase:

A new creator dashboard -- Avijit Gupta


An important principle of Oppia is that lessons can be easily improved over time -- it’s hard to figure out all the possible ways a student can go wrong at the outset, but it’s much easier to respond appropriately to a new misconception that arises.

Each creator on Oppia has a “creator dashboard” which allows them to see the lessons they’ve created, as well as the feedback they’ve received from learners. Avijit completed a full revamp of this page, updating its design (for both desktop and mobile) and finding ways to display all the necessary information in an intuitive way so that creators can easily improve their lessons while getting feedback on their teaching.

The new creator dashboard.

In addition, Avijit added functionality allowing creators to view student misconceptions that were not well-addressed, to make it easier for them to improve the feedback for those answers. He has continued to help out with the Oppia open source project as a maintainer and reviewer, even after GSoC, and is mentoring other contributors who are working on further improvements to the creator dashboard. You can read more about the project in his GSoC writeup!

Speed improvements -- Vishal Gupta


In order to improve the accessibility of lessons for students with poor internet connectivity, Vishal’s project aimed to make Oppia speedier and less bandwidth-intensive. He started by implementing a performance testing framework to benchmark his efforts, and also integrated it with our continuous integration system in order to protect against performance regressions. He then turned his efforts to caching as many static resources as possible, implementing a cache slug system that causes new files to be downloaded only after a new release is made.

In addition, Vishal removed JavaScript code that was inlined in the main templates, and refactored it out into an external script which could then be cached for better performance. You can read more about this project in his post on the Oppia blog.

We’d like to extend our grateful thanks not only to Avijit and Vishal, but also to our many willing and enthusiastic mentors, and to Google for supporting our open source work with GSoC.

Join us in helping improve educational opportunities for students around the world. If you’d like to subscribe to news and updates about Oppia’s participation in GSoC, you can sign up to the oppia-gsoc-announce mailing list -- or, if you’re already feeling enthusiastic, you can start helping out with the project right away!

By Ben Henning and Sean Lip, Organization Administrators for Oppia

Google Summer of Code 2016 wrap-up: Public Lab

This post is part of our series of guest posts from students, mentors and organization administrators who participated in Google Summer of Code 2016.

How we made this our best Google Summer of Code ever

This was our fourth year doing Google Summer of Code (GSoC), and it was our best year ever by a wide margin! We had five hard-working students who contributed over 17,000 new lines of (very useful) code to our high-priority projects.

Students voluntarily started coding early and hit the ground running, with full development environments and a working knowledge of GitHub Flow-style pull request process. They communicated with one another and provided peer support. They wrote tests. Hundreds of them! They blogged about their work as they went, and chatted with other community members about how to design features.

All of that was amazing, and it was made better by the fact that we were accepting pull requests with new code twice weekly. Tuesdays and Fridays, I went through new submissions, provided feedback, and pulled new code into our master branch, usually publishing it to our production site once a week.

I don't know how other projects do things, but this was very new for us, and it's revolutionized how we work together. In past years, students would work on their forks, slowly building up features. Then in a mad dash at the end, we’d try to merge them into trunk, with lots of conflicts and many hours (weeks!) of work on the part of project maintainers.

What made this year so good?

Many things aligned to make this summer great, and basically none of them are our ideas. I'm sure plenty of you are cringing at how we used to do things, but I also don't think that it's that unusual for projects not "born" in the fast-paced world of modern code collaboration.

We used ideas and learned from Nicolas Bevacqua, author of JavaScript Application Design and of the woofmark and horsey libraries which I've contributed to. We've also learned a great deal from the Hoodie community, particularly Gregor Martynus, who we ran into at a BostonJS meetup. Lastly, we learned from SpinachCon, organized by Shauna Gordon McKeon and Deb Nicholson, where people refine their install process by actually going through the process while sitting next to each other.

Broadly, our strategies were:

• Good documentation for newcomers (duh)
• Short and sweet install process that you've tried yourself (thanks, SpinachCon!)
• Predictable, regular merge schedule
• Thorough test suite, and requiring tests with each pull request
• Modularity, insisting that projects be broken into small, independently testable parts and merged as they’re written

Installation and pull requests

Most of the above sound kind of obvious or trivial, but we saw a lot of changes when we put it all together. Having a really fast install process, and guidance on getting it running in a completely consistent environment like the virtualized Cloud9 service, meant that many students were able to get the code running the same day they found the project. We aimed for an install time of 15 minutes max, and supplied a video of this for one of our codebases.

We also asked students to make a small change (even just add a space to a file) and walk through the GitHub Flow pull request (PR) submission process. We had clear step-by-step guidance for this, and we took it as a good sign when students were able to read through it and do this.

Importantly, we really tried to make each step welcoming, not demanding or dismissive, of folks who weren’t familiar with this process. This ultimately meant that all five students already knew the PR process when they began coding.

Twice-weekly merge schedule

We were concerned that, in past years, students only tried merging a few times and typically towards the end of the summer. This meant really big conflicts (with each other, often) and frustration.

This year we decided that, even though we’re a tiny organization with just one staff coder, we’d try merging on Tuesday and Friday mornings, and we mostly succeeded. Any code that wasn’t clearly presented, commits squashed, passing tests, and submitting new tests, was reviewed and I left friendly comments and requests so it could be merged the following week.

At first I felt bad rejecting PRs, but we had such great students that they got used to the strictness. They got really good at separating out features, demonstrating their features through clear tests, and some began submitting more than two PRs per week - always rebasing on top of the latest master to ensure a linear commit history. Sweet!

Wrap-up and next steps

The last thing we did was to ask each student, essentially as their documentation, to write a series of new issues which clearly described the problem and/or desired behavior, leave suggestions and links to specific lines of code or example code, and mark them with the special “help-wanted” tag which was so helpful to them when they first started out. We asked each to also make one extra-welcoming “first-timers-only” issue which walks a new contributor through every step of making a commit and even provides suggested code to be inserted.

This final requirement was key. While I personally made each of the initial set of “help-wanted” and “first-timers-only” issues before GSoC, now five students were offloading their unfinished to-dos as very readable and inviting issues for others. The effect was immediate, in part because these special tags are syndicated on some sites. Newcomers began picking them up within hours and our students were very helpful in guiding them through their first contributions to open source.

I want to thank everyone who made this past summer so great, from our champion mentors and community members, to our stellar students, to all our inspirations in this new process, to the dozen or so new contributors we’ve attracted since the end of August.

By Jeff Warren, Organization Administrator for PublicLab.org

Google Summer of Code 2016 wrap-up: CSE@TU Wien

Every year over a thousand university students work with more than a hundred open source organizations as part of the Google Summer of Code (GSoC). This post is part of a series of guest posts from students, mentors and organization administrators reflecting on GSoC 2016.

CSE@TU Wien is a loose interest group at the Technische Universität Wien (TU Wien) focused on developing, providing and utilizing free and open source software for research. We’re an umbrella organization for several open source projects and we participate in Google Summer of Code (GSoC) to ensure that future generations continue building open source software for scientific computing.

We’ve participated in GSoC most years since 2011, and in 2016 we had ten successful projects. The thematic areas are -- befitting an engineering-focused university -- very diverse. Let’s take a look at the projects and what students accomplished:

Carbon Footprint for Google Maps is a browser extension that calculates CO2 emissions that users would incur by driving on routes suggested by popular mapping services and displays this information alongside time and distance. The aim is to raise awareness of the environmental impact of driving cars.

Kolya Opahle brilliantly re-factored the extension, making it much more modular. This enabled expansion to include other map services and port to other browsers, with browser-specific implementations reduced to a minimum. Building for specific browsers was made easy through a Gradle build script. He took on the Firefox port himself, which turned out to be more challenging than expected due to incompatibilities between the extension API’s of Firefox and Chrome. Overcoming this challenge required ingenuity. 

Prateek Gupta completely re-designed and reimplemented the extension’s user interface, optimizing the storage of user options and allowing localization. He added support for more mapping services and calculations of additional greenhouse gases. He added new features to give the user more information about greenhouse gas emissions, including: 

• a page with air quality index using an API from the World Air Quality Index
• a page with tips to reduce emissions; a calculator to compute CO2 absorption by trees
• another calculator for the benefits of walking and cycling instead of driving

Chirag Arora ported the extension to the Safari web browser. Like the port to Firefox, this proved challenging due to discrepancies between the Chrome and Safari extension API’s. Chirag also implemented several new features, including: 

• more unit systems in the options page
• automatic configuration of fuel price based on location and the Global Petrol Prices API
• approximate calculation of CO2 emissions for public transportation

The Colibri project focuses on smart building energy management. Intelligent control strategies are becoming more and more important for efficiently operating residential and commercial buildings, as buildings are responsible for a significant amount of global energy consumption.

Georg Faustmann implemented a connector for Open Automated Demand Response (OpenADR) networks. OpenADR information and signals can now be processed and stored in the Colibri data store. One challenge for this student was comprehensive handling of the OpenADR specification. Based on the specification, Georg identified a set of relevant use cases which were finally realized in this Colibri component.

Josef Wechselauer worked on a connector for gateways based on the OASIS Open Building Information Exchange (OBIX) standard. This connector links physical devices and data from building automation systems to Colibri. Josef was very enthusiastic and he implemented the connector with an additional graphical user interface for browsing through available OBIX objects. The system test with real hardware was challenging, but he solved all of the problems.

Pratyush Talreja implemented a connector that enables the integration of MATLAB Simulink simulations. More precisely, the connector links to the MATLAB environment and can read and write data over interfaces provided by the simulation. Pratyush had some initial troubles with the system design and the role of the connector in the overall system. However, he tackled those challenges and succeeded in the end.

Mind the Word is a browser extension that helps users learn a new language. It randomly translates a few words per sentence on websites as the user browsers. Since the user sees the translated words in context, they can infer its meaning and thus gradually learns new vocabulary with minimal effort. The extension uses Google, Microsoft and Yandex translation APIs.

Ankit Muchhala re-factored and modernized the code base to ES6 using JSPM, fixing critical bugs in the process and setting up a test environment in Karma and Jasmine. After that, he redesigned the user interface, making extensive use of Bootstrap 3 along with AngularJS. He also implemented various features to make the extension more usable, such as: 

• dispersed word translation
• (automatic) blacklisting and easy whitelisting of words and websites
• and the ability to backup and restore the user's configurations

Rohan Katyal ported the extension to Firefox and implemented several new features, including: 

• speech of translated words
• generation of quizzes with the translated words
• search for visual hints, similar words and usage examples, and more. 

R/sdcMicro is the state-of-the-art R package for data anonymization and is used by national and international institutions. Data privacy has become a hot topic in research and requires serious effort to ensure that individuals cannot be identified.

Probhonjon Baruah improved the code quality of sdcMicro. He wrote unit tests that should help other contributors keep the package consistent and free of bugs. The main challenge for the student was understanding the object-oriented implementation of sdcMicro that goes beyond typical R packages. The student learned that standardized tests are too general to be useful, and that more problem-oriented and specific tests are more effective.

Classilist is an open source visualization dashboard for probabilistic classification data.

Medha Katehara of LNMIIT India developed Classilist, an interactive system for visualizing the performance of probabilistic classifiers. Additionally, she developed plugins to pull classification data from machine learning frameworks such as RapidMiner, WEKA and R.

In conclusion, we are -- again -- very happy with Google Summer of Code. Students advanced themselves and our research software, a clear win-win. Our large team of experienced mentors performed well and we’re grateful for their continued dedication and the support of our university. We hope to participate again in 2017!

By Josef Weinbub and Florian Rudolf, Organization Administrators for TU Wien, Austria

Google Summer of Code 2016 wrap-up: AOSSIE

We’re sharing guest posts from students, mentors and organization administrators who participated in Google Summer of Code (GSoC) 2016. This is the seventh post in the series.

AOSSIE (Australian Open Source Software Innovation and Education) is an organization created by the leaders of four research-oriented open source projects at the Australian National University. This was our first year in Google Summer of Code, but one of our projects had already participated three times as part of another organization.

We had 6 students and they surpassed our expectations. It was a great experience to mentor these students and provide them the opportunity to get involved in our cutting-edge research. We expect that their projects will lead to several publications and will be the starting point for long term collaborations.

Here are some highlights of their contributions:

Extempore is a programming language and runtime environment that supports live programming.

Joseph Penington adapted some cpp fluid dynamics code to show how live programming could be used to improve the workflow of scientific simulation. Joseph's project builds a series of increasingly complex fluid solvers in Extempore, allowing the programmer to make interesting and non-trivial changes to the simulation at runtime, including switching the way the fluids are solved in the middle of a simulation.

PriMedLink is software for matching similar patients in a way that preserves privacy (i.e. only using masked or encoded values of records without compromising privacy and confidentiality of patients) for health informatics applications such as clinical trials, advanced treatments and personalized patient care. The initial version of PPSPM software included masking and matching techniques for string, categorical and numerical (integer, floating point and modulus) data.

Mathu Mounasamy developed a module for PPSPM for masking and matching textual data which commonly occur in patient records (such as clinical notes and medical reports containing text data). The TextMM module developed by Mathu extends the functionality of PPSPM by allowing advanced privacy-preserving matching of similar patients based on various features containing textual data, thereby improving the quality and scope of PPSPM.

Rogas is a platform which integrates a collection of graph analysis tools and algorithms into a unified framework in order to support network analysis tasks.

Mojtaba Rezvani added the local community search (also known as local community detection) capability to Rogas. He has implemented several state-of-the-art algorithms proposed for local community detection, such as: k-core, k-truss, k-edge-connected, γ-quasi, and k-cliques. He has also designed a new algorithm for local community detection, which can efficiently identify local communities in large-scale networks.

Yan Xiao redesigned the GUI of Rogas in order to improve usability. He also implemented several visualization techniques to support the graph primitives of Rogas, including cluster, rank and path finding. These developments support dynamic network analysis at different scales so as to predict trends and patterns.

Skeptik is a Scala-based framework for proof theory and automated reasoning.

Ezequiel Postan generalized a challenging proof compression algorithm (the Split algorithm) from propositional logic to first-order logic and implemented it. This enables Skeptik to execute this algorithm not only on proofs output by SAT- and SMT-solvers but also on proofs output by resolution-based automated theorem provers. Ezequiel also implemented parsers for the TPTP and TSTP formats for theorem proving problems and proofs, and implemented a random proof generator to allow comprehensive experimental evaluation of the algorithms.

Daniyar Itegulov implemented a theorem prover for classical first-order logic using Skeptik's data structures and based on a novel logical calculus recently proposed by his mentor. This new calculus, called Conflict Resolution, is inspired by the propositional conflict-driven clause learning procedure used by SAT- and SMT-solvers and generalizes it to first-order logic. Daniyar also went further, conceiving and developing a concurrent proof search strategy for this calculus using Akka actors.

By Bruno Paleo, Organization Administrator for AOSSIE

Google Summer of Code 2016 wrap-up: STE||AR

This is part of a series of guest posts from students, mentors and organization administrators who participated in Google Summer of Code (GSoC) 2016. GSoC is an annual program which pairs university students with mentors to work on open source software.

This summer the STE||AR Group was proud to mentor four students through Google Summer of Code. These students worked on a variety of projects which helped improve our software, HPX. This library is a distributed C++ runtime system which supports a standards compliant API and helps users scale their applications across thousands of machines.

The improvements to the code base will help our team and users of HPX around the world. A summary of our students’ projects:

Parsa Amini – HPX Debugger

Developing a better distributed debugging tool is essential to increase the programmability of HPX. Parsa’s project, Scimitar, aims to facilitate the debugging process for HPX programmers by extending the features of GDB, an existing debugger. The project then complements it with new commands for easier switching between localities across clusters, HPX thread debugging, awareness of internal HPX data structures, and semi-automated preparation for distributed debugging sessions. Additional functionality such as locating an object and viewing the queue information on each core is provided through using API provided by HPX itself. His work can be found on GitHub.

Aalekh Nigam – Implement a Map/Reduce Framework

This project aimed to expose a Map/Reduce programming model over HPX. During the summer, Aalekh was able to develop a single node implementation of HPXflow (map/reduce programming model) and laid the groundwork for the further multi-node version with database support. Although the initial task was limited to implementing the Map/Reduce model, he was also able to implement an improved dataflow model as well.

Minh-Khanh Do - Working on Parallel Algorithms for HPX::Vector

Minh-Khanh’s task was to take the parallel algorithms and add the functionality required to work on the segmented hpx::vector. Under his mentor John Biddscombe, he implemented the segmented_fill algorithm, which was successfully merged into the main codebase. Additionally, Minh-Khanh implemented the segmented_scan algorithm which includes inclusive and exclusive_scan. These changes are included in a pull request and have been merged. Using the segmented scan algorithm it is possible to perform tasks such as evaluating polynomials and to implement other algorithms such as quicksort.

Satyaki Upadhyay - Plugin Mechanism for thread schedulers in HPX

In HPX, schedulers are statically linked and must be built at compile-time. Satyaki’s project involved converting this statically linked scheme into a plugin system which would allow arbitrary schedulers to be dynamically loaded. These changes bring several benefits. They provide a layer of abstraction and follow the open/closed principle of software design as well as allowing developers to write their own custom schedulers while conforming to a uniform API. The project proceeded in two steps. The first involved the creation of plugin modules of the schedulers and registering them with HPX. The second step was to implement the loading and subsequent use of the chosen scheduler.

We would like to thank our students and mentors for the time that they have contributed to HPX this summer. In addition, we would like to thank Google for the opportunity that they provided the STE||AR Group to work with developers around the globe as well as the ability for students to interact with vibrant open source projects worldwide.

By Adrian Serio, Organization Administrator for The STE||AR Group