Author Archives: Open Source Programs Office

Getting ready for Google Summer of Code 2017

Spring is just around the corner here in the Northern Hemisphere and Google Summer of Code is fast approaching. If you are a student interested in participating this year, now is the time to prepare -- read on for tips on how to get ready.

This year we’ve accepted 201 open source organizations into the program, nearly 40 of which are new to the program. The organizations cover a wide range of topics including (but certainly not limited to!):

  • Operating systems
  • Web application frameworks
  • Healthcare and bioinformatics
  • Music and graphic design
  • Machine learning
  • Robotics
  • Security




How should you prepare for Google Summer of Code?

While student applications don’t open until March 20th at 16:00 UTC, you need to decide which projects you’re interested in and what you’ll propose. You should also communicate with those projects to learn more before you apply.

Start by looking at the list of participating projects and organizations. You can explore by searching for specific names or technologies, or filtering by topics you are interested in. Follow the “Learn More” link through to each organization’s page for additional information.

Once you’ve identified the organizations that you’re interested in, take a look at their ideas list to get a sense of the specific projects you could work on. Typically, you will choose a project from that list and write a proposal based on that idea, but you could also propose something that’s not on that list.

You should reach out to the organizations after you’ve decided what you want to work on. Doing this can make the difference between a good application and a great application.

Whatever you do, don’t wait until March 20th to begin preparing for Google Summer of Code! History has shown that students who reach out to organizations before the start of the application period have a higher chance of being accepted into the program, as they have had more time to talk to the organizations and understand what they are looking for with the project.

If you have any questions along the way, take a look at the Student Manual, FAQ and Timeline. If you can’t find the answer to your question, try taking your question to the mailing list.

By Josh Simmons, Open Source Programs Office

Another option for file sharing

Originally posted on the Google Security Blog

Existing mechanisms for file sharing are so fragmented that people waste time on multi-step copying and repackaging. With the new open source project Upspin, we aim to improve the situation by providing a global name space to name all your files. Given an Upspin name, a file can be shared securely, copied efficiently without "download" and "upload", and accessed by anyone with permission from anywhere with a network connection.

Our target audience is personal users, families, or groups of friends. Although Upspin might have application in enterprise environments, we think that focusing on the consumer case enables easy-to-understand and easy-to-use sharing.

File names begin with the user's email address followed by a slash-separated Unix-like path name:


Any user with appropriate permission can access the contents of this file by using Upspin services to evaluate the full path name, typically via a FUSE filesystem so that unmodified applications just work. Upspin names usually identify regular static files and directories, but may point to dynamic content generated by devices such as sensors or services.

If the user wishes to share a directory (the unit at which sharing privileges are granted), she adds a file called Access to that directory. In that file she describes the rights she wishes to grant and the users she wishes to grant them to. For instance,


allows Joe and Mae to read any of the files in the directory holding the Access file, and also in its subdirectories. As well as limiting who can fetch bytes from the server, this access is enforced end-to-end cryptographically, so cleartext only resides on Upspin clients, and use of cloud storage does not extend the trust boundary.

Upspin looks a bit like a global file system, but its real contribution is a set of interfaces, protocols, and components from which an information management system can be built, with properties such as security and access control suited to a modern, networked world. Upspin is not an "app" or a web service, but rather a suite of software components, intended to run in the network and on devices connected to it, that together provide a secure, modern information storage and sharing network. Upspin is a layer of infrastructure that other software and services can build on to facilitate secure access and sharing. This is an open source contribution, not a Google product. We have not yet integrated with the Key Transparency server, though we expect to eventually, and for now use a similar technique of securely publishing all key updates. File storage is inherently an archival medium without forward secrecy; loss of the user's encryption keys implies loss of content, though we do provide for key rotation.

It’s early days, but we’re encouraged by the progress and look forward to feedback and contributions. To learn more, see the GitHub repository at Upspin.

By Andrew Gerrand, Eric Grosse, Rob Pike, Eduardo Pinheiro and Dave Presotto, Google Software Engineers

By maintainers, for maintainers: Wontfix_Cabal

The Google Open Source Programs Office likes to highlight events we support, organize, or speak at. In this case, Google’s own Jess Frazelle was responsible for running a unique event for open source maintainers.

This year I helped organize the first inaugural Wontfix_Cabal. The conference was organized by open source software maintainers for open source software maintainers. Our initial concept was an unconference where attendees could discuss topics candidly with their peers from other open source communities.

The idea for the event stemmed from the response to a blog post I published about closing pull requests. The response was overwhelming, with many maintainers commiserating and sharing lessons they had learned. It seemed like we could all learn a lot from our peers in other projects -- if we had the space to do so -- and it was clear that people needed a place to vent.

Major thanks to Katrina Owen and Brandon Keepers from GitHub who jumped right in and provided the venue we needed to make this happen. Without their support this would’ve never become a reality!

It was an excellent first event and the topics discussed were wide ranging, including:
  • How to deal with unmaintained projects
  • Collecting metrics to judge project health
  • Helping newcomers
  • Dealing with backlogs
  • Coping with, and minimizing, toxic behavior in our communities


The discussion around helping newcomers focused on creating communities with welcoming and productive cultures right from the start. I was fascinated to learn that some projects pre-fill issues before going public so as to set the tone for the future of the project. Another good practice is clearly defining how one becomes a maintainer or gets commit access. There should be clear rules in place so people know what they have to do to succeed.

Another discussion I really liked focused on “saying no.” Close fast and close early was a key takeaway. There’s no sense in letting a contribution sit waiting when you know it will never be accepted. Multiple projects found that having a bot give the hard news was always better than having the maintainer do it. This way it is not personal, just a regular part of the process.

One theme seen in multiple sessions: “Being kind is not the same as being nice.” The distinction here is that being nice comes from a place of fear and leads people to bend over backwards just to please. Being kind comes from a place of strength, from doing the right thing.

Summaries of many of the discussions have been added to the GitHub repo if you would like to read more.

After the event concluded many maintainers got right to work, putting what they had learned into practice. For instance, Rust got help from the Google open source fuzzing team.


Our goal was to put together a community of maintainers that could support and learn from each other. When I saw Linux kernel maintainers talking to people who work on Node and JavaScript, I knew we had achieved that goal. Laura Abbott, one of those kernel developers, wrote a blog post about the experience.

Not only was the event useful, it was also a lot of fun. Meeting maintainers, people who care a great deal about open source software, from such a diverse group of projects was great. Overall, I think our initial run was a success! Follow us on Twitter to find out about future events.

By Jess Frazelle, Software Engineer

Introducing Python Fire, a library for automatically generating command line interfaces

Today we are pleased to announce the open-sourcing of Python Fire. Python Fire generates command line interfaces (CLIs) from any Python code. Simply call the Fire function in any Python program to automatically turn that program into a CLI. The library is available from pypi via `pip install fire`, and the source is available on GitHub.

Python Fire will automatically turn your code into a CLI without you needing to do any additional work. You don't have to define arguments, set up help information, or write a main function that defines how your code is run. Instead, you simply call the `Fire` function from your main module, and Python Fire takes care of the rest. It uses inspection to turn whatever Python object you give it -- whether it's a class, an object, a dictionary, a function, or even a whole module -- into a command line interface, complete with tab completion and documentation, and the CLI will stay up-to-date even as the code changes.

To illustrate this, let's look at a simple example.

#!/usr/bin/env python
import fire

class Example(object):
  def hello(self, name='world'):
    """Says hello to the specified name."""
    return 'Hello {name}!'.format(name=name)

def main():
  fire.Fire(Example)

if __name__ == '__main__':
  main()

When the Fire function is run, our command will be executed. Just by calling Fire, we can now use the Example class as if it were a command line utility.

$ ./example.py hello
Hello world!
$ ./example.py hello David
Hello David!
$ ./example.py hello --name=Google
Hello Google!

Of course, you can continue to use this module like an ordinary Python library, enabling you to use the exact same code both from Bash and Python. If you're writing a Python library, then you no longer need to update your main method or client when experimenting with it; instead you can simply run the piece of your library that you're experimenting with from the command line. Even as the library changes, the command line tool stays up to date.

At Google, engineers use Python Fire to generate command line tools from Python libraries. We have an image manipulation tool built by using Fire with the Python Imaging Library, PIL. In Google Brain, we use an experiment management tool built with Fire, allowing us to manage experiments equally well from Python or from Bash.

Every Fire CLI comes with an interactive mode. Run the CLI with the `--interactive` flag to launch an IPython REPL with the result of your command, as well as other useful variables already defined and ready to use. Be sure to check out Python Fire's documentation for more on this and the other useful features Fire provides.

Between Python Fire's simplicity, generality, and power, we hope you find it a useful library for your own projects.

By David Bieber, Software Engineer on Google Brain

Operation Rosehub

Twelve months ago, a team of 50 Google employees used GitHub to patch the “Apache Commons Collections Deserialization Vulnerability” (or the “Mad Gadget vulnerability” as we call it) in thousands of open source projects. We recently learned why our efforts were so important.

The San Francisco Municipal Transportation Agency had their software systems encrypted and shut down by an avaricious hacker. The hacker used that very same vulnerability, according to reports of the incident. He demanded a Bitcoin ransom from the government. He threatened to leak the private data he stole from San Francisco’s citizens if his ransom wasn’t paid. This was an attack on our most critical public infrastructure; infrastructure which underpins the economy of a major US city.

Mad Gadget is one of the most pernicious vulnerabilities we’ve seen. By merely existing on the Java classpath, seven “gadget” classes in Apache Commons Collections (versions 3.0, 3.1, 3.2, 3.2.1, and 4.0) make object deserialization for the entire JVM process turing complete with an exec function. Since many business applications use object deserialization to send messages across the network, it would be like hiring a bank teller who was trained to hand over all the money in the vault if asked to do so politely, and then entrusting that teller with the key. The only thing that would keep a bank safe in such a circumstance is that most people wouldn’t consider asking such a question.

The announcement of Mad Gadget triggered the cambrian explosion of enterprise security disclosures. Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP and SolarWinds all formally disclosed that they had been impacted by this issue.

But unlike big businesses, open source projects don’t have people on staff to read security advisories all day and instead rely on volunteers to keep them informed. It wasn’t until five months later that a Google employee noticed several prominent open source libraries had not yet heard the bad news. Those projects were still depending on vulnerable versions of Collections. So back in March 2016, she started sending pull requests to those projects updating their code. This was easy to do and usually only required a single line change. With the help of GitHub’s GUI, any individual can make such changes to anyone’s codebase in under a minute. Given how relatively easy the changes seemed, she recruited more colleagues at Google to help the cause. As more work was completed, it was apparent that the problem was bigger than we had initially realized.

For instance, when patching projects like the Spring Framework, it was clear we weren’t just patching Spring but also patching every project that depended on Spring. We were furthermore patching all the projects that depended on those projects and so forth. But even once those users upgraded, they could still be impacted by other dependencies introducing the vulnerable version of Collections. To make matters worse, build systems like Maven can not be relied upon to evict old versions.

This was when we realized the particularly viral nature of Mad Gadget. We came to the conclusion that, in order to improve the health of the global software ecosystem, the old version of Collections should be removed from as many codebases as possible.

We used BigQuery to assess the damage. It allowed us to write a SQL query with regular expressions that searched all the public code on GitHub in a couple minutes.

SELECT pop, repo_name, path
  FROM (SELECT F.id as id, repo_name, path
          FROM (SELECT id, repo_name, path
                  FROM [bigquery-public-data:github_repos.files]
                 WHERE path LIKE '%pom.xml') AS F
          JOIN (SELECT id
                  FROM (SELECT id,content
                          FROM (SELECT id,content
                                  FROM [bigquery-public-data:github_repos.contents]
                                 WHERE NOT binary)
                         WHERE content CONTAINS 'commons-collections<')
                 WHERE content CONTAINS '>3.2.1<') AS C
            ON F.id = C.id) AS V
  JOIN (SELECT difference.new_sha1 AS id,
               COUNT(repo_name) WITHIN RECORD AS pop
          FROM FLATTEN([bigquery-public-data:github_repos.commits], difference.new_sha1)) AS P
    ON V.id = P.id
 ORDER BY pop DESC;


We were alarmed when we discovered 2,600 unique open source projects that still directly referenced insecure versions of Collections. Internally at Google, we have a tool called Rosie that allows developers to make large scale changes to codebases owned by hundreds of different teams. But no such tool existed for GitHub. So we recruited even more engineers from around Google to patch the world’s code the hard way.

Ultimately, security rests within the hands of each developer. However we felt that the severity of the vulnerability and its presence in thousands of open source projects were extenuating circumstances. We recognized that the industry best practices had failed. Action was needed to keep the open source community safe. So rather than simply posting a security advisory asking everyone to address the vulnerability, we formed a task force to update their code for them. That initiative was called Operation Rosehub.

Operation Rosehub was organized from the bottom-up on company-wide mailing lists. Employees volunteered and patches were sent out in a matter of weeks. There was no mandate from management to do this—yet management was supportive. They were happy to see employees spontaneously self-organizing to put their 20% time to good use. Some of those managers even participated themselves.

Patches were sent to many projects, avoiding threats to public security for years to come. However, we were only able to patch open source projects on GitHub that directly referenced vulnerable versions of Collections. Perhaps if the SF Muni software systems had been open source, we would have been able to bring Mad Gadget to their attention too.

Going forward, we believe the best thing to do is to build awareness. We want to draw attention to the fact that the tools now exist for fixing software on a massive scale, and that it works best when that software is open.

In this case, the open source dataset on BigQuery allowed us to identify projects that still needed to be patched. When a vulnerability is discovered, any motivated team or individual who wants to help improve the security of our infrastructure can use these tools to do just that.

By Justine Tunney, Software Engineer on TensorFlow

We’d like to recognize the following people for their contributions to Operation Rosehub: Laetitia Baudoin, Chris Blume, Sven Blumenstein, James Bogosian, Phil Bordelon, Andrew Brampton, Joshua Bruning, Sergio Campamá, Kasey Carrothers, Martin Cochran, Ian Flanigan, Frank Fort, Joshua French, Christian Gils, Christian Gruber, Erik Haugen, Andrew Heiderscheit, David Kernan, Glenn Lewis, Roberto Lublinerman, Stefano Maggiolo, Remigiusz Modrzejewski, Kristian Monsen, Will Morrison, Bharadwaj Parthasarathy, Shawn Pearce, Sebastian Porst, Rodrigo Queiro, Parth Shukla, Max Sills, Josh Simmons, Stephan Somogyi, Benjamin Specht, Ben Stewart, Pascal Terjan, Justine Tunney, Daniel Van Derveer, Shannon VanWagner, and Jennifer Winer.

Introducing the Google Summer of Code 2017 Mentor Organizations

Today’s the day! We are excited to announce the mentor organizations accepted for this year’s Google Summer of Code (GSoC). Every year we receive more applications than we can accept and 2017 was no exception. After carefully reviewing almost 400 applications, we have chosen 201 open source projects and organizations, 18% of which are new to the program. Please see the program website for a complete list of the accepted organizations.

Interested in participating as a student? We will begin accepting student applications on Monday, March 20, 2017 at 16:00 UTC and the deadline is Monday, April 3, 2017 at 16:00 UTC.

Over the next three weeks, students who’d like to participate in Google Summer of Code should research the organizations and their Ideas Lists to explore which organizations are a good fit for their interests and skills and learn how they might contribute. Some of the most successful proposals have been completely new ideas submitted by students, so if you don’t see a project that appeals to you, don’t hesitate to suggest a new idea to the organization! There are contacts listed for each organization on their Ideas List — students should contact the organization directly to discuss their ideas. We also strongly encourage all interested students to reach out to and become familiar with the organization before applying.

You can find more information on our website, including a full timeline of important dates and program milestones. We also highly recommend all interested students read the Student Manual, FAQ and the Program Rules.

Congratulations to all of our mentor organizations! We look forward to working with all of you during Google Summer of Code 2017.

By Josh Simmons, Open Source Programs Office

Google Code-in 2016: even more young developers

Google Code-in (GCI), our contest introducing 13-17 year olds to open source software development, wrapped up last month with our largest contest to date: 1,340 students from 62 countries completed an impressive 6,379 tasks! Working with 17 open source organizations, students wrote code, created and edited documentation, designed UI elements and logos, conducted research, developed screencasts and videos teaching others about open source software, and helped find (and fix!) hundreds of bugs.

General statistics

  • 56.4% of students completed three or more tasks (earning themselves a fun Google Code-in 2016 t-shirt)
  • 21% of students were female
  • 30% of the participants from the USA were female
  • This was the first Google Code-in for 1,143 students (85.3%)

Student age

2017-02-23_07-48-36.png

Participating schools

Students from 550 schools competed in this year’s contest. While Google Code-in is a program for individuals, every year some schools emerge as hot spots of participation. This year, these five schools had the most students taking part:

School NameCountryNumber of Participants
Dunman High SchoolSingapore185
Sacred Heart Convent Senior Secondary SchoolIndia29
Jayshree Periwal International SchoolIndia26
Colegiul National Aurel VlaicuRomania23
Ly Tu Trong Specialized High SchoolsVietnam14

Countries

We are pleased to have a new country participating in GCI this year: Mauritius! The chart below displays the ten countries with the most students completing at least 1 task.




In June we will welcome all 34 grand prize winners (along with a mentor from each participating organization) for a fun-filled trip to the Bay Area. The trip will include meeting with Google engineers to hear about new and exciting projects, tours of the Google campuses and a fun day exploring San Francisco.

Keep an eye on the Google Open Source Blog in coming weeks for more stats on Google Code-in 2016, plus posts from the mentoring organizations describing some of their experiences with the contests and the work done by “their” students.

We are thrilled that Google Code-in was so popular this year. We hope to continue to grow and expand this contest in the future to introduce even more teenagers to the world of open source software development.

By Stephanie Taylor, Google Code-in Program Manager

Announcing TensorFlow 1.0

Originally posted on the Google Developer Blog

In just its first year, TensorFlow has helped researchers, engineers, artists, students, and many others make progress with everything from language translation to early detection of skin cancer and preventing blindness in diabetics. We're excited to see people using TensorFlow in over 6000 open source repositories online.

Today, as part of the first annual TensorFlow Developer Summit, hosted in Mountain View and livestreamed around the world, we're announcing TensorFlow 1.0:

It's faster: TensorFlow 1.0 is incredibly fast! XLA lays the groundwork for even more performance improvements in the future, and tensorflow.org now includes tips & tricksfor tuning your models to achieve maximum speed. We'll soon publish updated implementations of several popular models to show how to take full advantage of TensorFlow 1.0 - including a 7.3x speedup on 8 GPUs for Inception v3 and 58x speedup for distributed Inception v3 training on 64 GPUs!

It's more flexible: TensorFlow 1.0 introduces a high-level API for TensorFlow, with tf.layers, tf.metrics, and tf.losses modules. We've also announced the inclusion of a new tf.keras module that provides full compatibility with Keras, another popular high-level neural networks library.

It's more production-ready than ever: TensorFlow 1.0 promises Python API stability (details here), making it easier to pick up new features without worrying about breaking your existing code.

Other highlights from TensorFlow 1.0:
  • Python APIs have been changed to resemble NumPy more closely. For this and other backwards-incompatible changes made to support API stability going forward, please use our handy migration guide and conversion script.
  • Experimental APIs for Javaand Go
  • Higher-level API modules tf.layers, tf.metrics, and tf.losses - brought over from tf.contrib.learnafter incorporating skflowand TF Slim
  • Experimental release of XLA, a domain-specific compiler for TensorFlow graphs, that targets CPUs and GPUs. XLA is rapidly evolving - expect to see more progress in upcoming releases.
  • Introduction of the TensorFlow Debugger (tfdbg), a command-line interface and API for debugging live TensorFlow programs.
  • New Android demos for object detection and localization, and camera-based image stylization.
  • Installation improvements: Python 3 docker images have been added, and TensorFlow's pip packages are now PyPI compliant. This means TensorFlow can now be installed with a simple invocation of pip install tensorflow.
We're thrilled to see the pace of development in the TensorFlow community around the world. To hear more about TensorFlow 1.0 and how it's being used, you can watch the TensorFlow Developer Summit talks on YouTube, covering recent updates from higher-level APIs to TensorFlow on mobile to our new XLA compiler, as well as the exciting ways that TensorFlow is being used:



Click herefor a link to the livestream and video playlist (individual talks will be posted online later in the day).

The TensorFlow ecosystem continues to grow with new techniques like Foldfor dynamic batching and tools like the Embedding Projector along with updatesto our existing tools like TensorFlow Serving. We're incredibly grateful to the community of contributors, educators, and researchers who have made advances in deep learning available to everyone. We look forward to working with you on forums like GitHub issues, Stack Overflow, @TensorFlow, the [email protected]group, and at future events.

By Amy McDonald Sandjideh, Technical Program Manager, TensorFlow

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