Introducing Solar Permit AppEngine Examples

It was a milestone that took over 50 years, and at last solar panel manufacturers can produce their modules for less than $1/Watt. Now, the renewable energy community is faced with the dilemma that the permitting and interconnection costs, i.e. the paperwork, is a significant fraction of the cost of a rooftop installation. To deploy gigaWatts of solar energy in the United States these costs need to drop. In response, the Department of Energy has made permitting part of its Sun Shot Initiative and SolarTech has launched its Solar Permitting Challenge. And now Google is pleased to announce Solar Permitting Code Examples to make it faster for software developers to be productive using AppEngine.

A small team of Googlers (Alex Martelli, Arjun Satyapal, Clay Murphy, Luke Stone, Ross Koningstein and Dave Fork) pooled their 20% time to help out. We tried to make the task of building a web based permitting application easier by providing examples of essential tasks in AppEngine including login, creating new permit requests, uploading files, and gathering statistics. Two different versions, one in Python and one in Java, were created.

We were inspired to create this code example by the work that SolarTech has done to promote faster permitting through its Solar Permitting Challenge, and by the Solar ABCs efforts to produce a simple, uniform process for solar permitting. The user login screen for the Python code example appears below.

Navigant consulting estimates that there are 700 gigaWatts of solar power generation resource on rooftops in the United States. Overall, we believe that efforts to streamline the workflow connected with rooftop solar installations could reduce the costs of installations by 50 cents/Watt. Please help us help the industry make this a reality.

By Dave Fork, Solar Permitting Team Member

Googlers are everywhere this summer

June and July are especially packed with conferences this year and Googlers are hitting the roads to organize, speak at and participate in conferences all over the world.

Earlier in the month over the June 17-19 weekend, Google was pleased to host a gathering of GCC developers in our London office. The informal working meeting was organized by Diego Novillo and Ian Taylor with assistance from Cat Allman to discuss current/future work and coordinate efforts.

Members of the Open Source Programs Office were in Portland, Oregon last week at Open Source Bridge. Open Source Bridge is a conference for developers working with open source technologies and for anyone interested in learning the open source way. During the conference, Google hosted a BoF session one evening for all students, mentors and anyone interested in learning more about Google Summer of Code.

Also last week, a gaggle of Googlers including Alex Martelli and Wesley Chun descended on Florence, Italy for EuroPython, the official European conference about the Python programming language. The conference completely sold out this year.

This week, Googlers will be heading to Porto Alegre, Brazil to speak at FISL (International Free Software Forum), the largest free software event in Latin America from June 29 - July 2.

Jeremy Allison, OSPO team member and co-founder of Samba, will be speaking on “The State of Samba” Wednesday, June 29th at 10am.

Carol Smith, OSPO team member and Program Manager for Google Summer of Code, will be talking about the Google Summer of Code program on Wednesday, June 29th at 4pm. She'll include statistics and interesting tidbits from the previous 6 years and some interesting changes we've made to the program for this year.

Andrew Gerrand, Google Developer Advocate for the Go Programming language, will be presenting a talk Thursday, June 30th at 9am on “Writing Simpler Code: Programming in Go.” His talk will demonstrate how you can use Go to write elegant, reusable, and correct programs. Later that day at 3pm, Andrew will host a tutorial titled “Get Started with Go”.

Next month many Googlers and open source enthusiasts will be converging on Portland, Oregon for the largest open source conference, OSCON, held from July 25-29 at the Oregon Convention Center. We will have another post in the next couple of weeks with a comprehensive list of all of the Googlers speaking at OSCON. We hope to see you at an event soon!

By Stephanie Taylor, Open Source Programs

Who’s New in Google Summer of Code: Part 4

This summer we are writing a series of posts featuring the new organizations participating in their first Google Summer of Code. This is our fourth installment where the organizations explain their project in more detail and discuss the tasks the students are working on this summer.

Elgg is an open source social networking project that began as an experimental thesis project in 2004. The technical goals for Elgg are to create a social engine that is accessible to end users but easily extensible for developers. Elgg’s participation in this year’s Google Summer of Code is an amazing chance for Elgg to get involved with the larger OSS community.

As a first year organization, we were humbled and surprised by both the quantity and the quality of applications we received. Narrowing it down was difficult, but in the end we picked three talented and eager students with ambitious ideas.

Francisco Hidalgo is implementing a method to allow user-generated content to be translated into multiple languages -- an important feature for sites with a large international user base.

Ravindra Nath Kakarla is working to streamline the Elgg user experience by Ajaxifying large parts of the application. This is a high profile project that Elgg users (and core developers) can’t wait to see.

Saket Saurabh will implement a standardized web services API and build an accompanying Java client. This API will allow alternative interaction with Elgg sites and provide developers even more flexibility in how they work with Elgg.

By Brett Profitt, Elgg Organization Administrator

----------

OpenIntents is an open source project entirely focused on Android. Early-on, in 2008, we believed that more could be done to develop key concepts of the Android operating system and generate awareness. OpenIntents is one of the few open source projects actively targeting extension of the mobile operating system, and housing expert knowledge on it.

OpenIntents educates and empowers developers to use revolutionary new key features of Android, most notably the Intents mechanism that enables applications to reuse and interface with other applications. We provide a registry that brings developers together so they can make their applications compatible, and we act as a standardization body.

OpenIntents also aims to develop general functionality that is not in Android currently, but we feel should be, as well as to pioneer new ways of working. To illustrate or push forward the above we develop samples and free applications. Some of these applications have grown to be quite popular and we support them in the Market, like OI File Manager or OI Shopping List.

In 2011 OpenIntents was selected to mentor two projects in the Google Summer of Code. The first student, Elena, will enhance our SensorSimulator which is used by developers to debug applications that make use of the device sensors, and in particular, she will look into improving the device representation and handling. Our second student, Andras, will develop Historify, a new application that will become an open timeline module that 3rd party apps can post to. The timeline shows the interaction history between the user and contacts regardless of technology, like phone calls, messages, or social media.

By Peli Oi, OpenIntents Organization Administrator

----------

SymPy is a full fledged computer algebra system written completely in pure Python. It presently has some very powerful features, like symbolic differentiation and integration, series, limits, symbolic matrices, solvers, simplification, polynomials, and quantum physics. SymPy can be used as a library, or executed like a calculator from a Python or IPython prompt using the isympy script.

The SymPy code is written to be easy to read and easily extensible. This and the fact that SymPy is written in Python has made it a very popular open source computer algebra system. The code for SymPy is all BSD licensed, so just about anyone can use SymPy in their code. Also, SymPy does not require any external dependencies to run (other than Python), which means that SymPy can be used in any environment that can run Python, such as Google AppEngine or any desktop computer.

SymPy has participated in Google Summer of Code since 2007 under umbrella organizations such as the Python Software Foundation, Portland State University and the Space Telescope Science Institute. This year for the first time we were accepted by Google as a mentoring organization. We were able to accept nine student projects. You can follow the student’s progress on their projects here.

We look forward to what should be our best year for SymPy development ever!

By Aaron Meurer, SymPy Organization Administrator

These are just a few of the 50 new organizations participating in Google Summer of Code this year. Please check back next Friday when we highlight 4 more new organizations. For a complete list of the 175 organizations participating in the Google Summer of Code please visit our program site.

By Stephanie Taylor, Open Source Programs

Introducing Native Driver

NativeDriver is an implementation of the WebDriver API which drives the UI of a native application rather than a web application. I am happy to announce that the Android version is available for download and we are welcoming all users and contributors. We are hosting on Google Code (http://nativedriver.googlecode.com/). An iPhone (iOS) version is under development and will be available soon.

WebDriver exposes browser functionality as a clean, object-oriented API, and Google uses WebDriver to test web applications on many platforms. (For an introduction to WebDriver, see this blog post.)

You are probably wondering why anyone would use the WebDriver API to test native applications. Our reasoning is:

• user interactions with a native application and a web application are essentially the same: click, type, switch window, read text
• test writers will have to write the same test for each platform they want to support
• no one wants to learn yet another API
• WebDriver already has a user base and a tool ecosystem that can migrate easily to a new API if it is WebDriver-like
• therefore: let’s re-use our favorite UI testing API

NativeDriver is our attempt to apply WebDriver’s simplicity and success to native applications. It extends the WebDriver API in a few key places, and re-interprets the existing API for native applications.

Here is some code from a NativeDriver test against the Google Maps Android app (the test can be seen in action in this video):

AndroidNativeDriver driver = new AndroidNativeDriverBuilder()
.withDefaultServer()
.build();
driver.startActivity("com.google.android.maps.MapsActivity");

// Open the Places activity by clicking the places button
// (to the right of the search box)
AndroidNativeDriver btn
= driver.findElement(By.id("btn_header_places"));
btn.click();

// Dismiss the Places window
// Equivalent to pressing the Android Back button
driver.navigate().back();

// Rotate the device to show the UI in landscape mode
driver.rotate(ScreenOrientation.LANDSCAPE);

Except for the startActivity method, and the use of a builder object to create the driver, all the API calls made are standard WebDriver API calls. Creating the driver with a builder is necessary because the driver can also be set up with an Android Debug Bridge (ADB) connection.

Android NativeDriver uses Instrumentation to monitor and manipulate the application under test. Instrumentation is a standard feature of Android but it has some limitations. For instance, it cannot drive UI which is part of another process. (If it could a malicious application could hijack the device.) This is where ADB saves the day. The ADB is a connection from outside the device and is not tied to a particular application, so with it we can inject events across applications. ADB also made it possible to add screenshot support, and we plan to utilize it in new ways as NativeDriver matures. This is one way Android NativeDriver tests are more powerful than standard Instrumentation tests.

You can try out Android NativeDriver right away with the tutorials for running a sample test or instrumenting your own application. You may also want to join the users or developers mailing list.

Good luck and happy native testing!

By Matt DeVore, Engineering Productivity Team

Visualization Meetup at the Googleplex

Earlier this month we were excited to host a joint meetup with the Bay Area visualization group and the Bay Area R user group at Google’s headquarters in Mountain View.

Hadley Wickham from Rice University came and gave a talk on Interactive Graphics in R. Earlier in the day we were excited to host him for a Google Tech Talk on Engineering Data Analysis for the many internal Google teams using his ggplot2 software for visualization with R. The videos for both talks are available from YouTube.

You may remember our previous post about Hadley’s visualization work when his Google Summer of Code student was awarded a prestigious statistical computing award for his work with ggplot2.

Thanks to the Open Source Programs Office at Google for hosting this event, the meetup organizers, Zhou Yu, and of course Hadley Wickham.

By Murray Stokely and Zhou Yu, Google Engineers and Analysts