Google Prediction API graduates from labs, adds new features

By Zachary Goldberg, Product Manager

Since the general availability launch of the Prediction API this year at Google I/O, we have been working hard to give every developer access to machine learning in the cloud to build smarter apps. We’ve also been working on adding new features, accuracy improvements, and feedback capability to the API. Today we take another step by announcing Prediction v1.4. With the launch of this version, Prediction is graduating from Google Code Labs, reflecting Google’s commitment to the API’s development and stability. Version 1.4 also includes two new features:

• Data Anomaly Analysis
• One of the hardest parts of building an accurate predictive model is gathering and curating a high quality data set. With Prediction v1.4, we are providing a feature to help you identify problems with your data that we notice during the training process. This feedback makes it easier to build accurate predictive models with proper data.
• PMML Import
• PMML has become the de facto industry standard for transmitting predictive models and model data between systems. As of v1.4, the Google Prediction API can programmatically accept your PMML for data transformations and preprocessing.
• The PMML spec is vast and covers many, many features. You can find more details about the specific features that the Google Prediction API supports here.

We’re looking forward to seeing what you create with these new capabilities!

Feel free to find us and ask questions about these new features on our discussion group or submit feedback via our feedback form.


Zachary Goldberg is Product Manager for the Google Prediction API. He has a strange fascination with the Higgs Boson.

Posted by Scott Knaster, Editor

Google Cloud Storage is out of Code Labs, with new features and lower price

By Navneet Joneja, Product Manager for Google Cloud Storage

Google Storage for Developers is now out of Code Labs, and has a new name: Google Cloud Storage. In addition, we're also happy to announce some new features, and a significant price reduction.

App Engine File API Support

When we opened the service to all this summer, many of our customers asked for an easier way to use Google Cloud Storage with their App Engine applications. In response to your feedback, you can now read and write your data via the App Engine Files API, enabling you to quickly build your content management tools, data sharing applications, web games and more using the powerful combination of App Engine and Cloud Storage. This feature is experimental and currently Python-only, but we’re working on adding Java support and additional features.

Usage Information

We’re introducing a new API that gives you access to detailed usage information (including network access and storage use data). You can use this feature to analyze your usage, integrate with your analysis systems and build your own value-added applications using Google Cloud Storage. This feature is currently experimental.

Lower Prices

We're no longer charging for upload bandwidth into the Google cloud. In addition, we’re lowering our prices across the board and introducing volume discounts for our larger users. We are committed to offering an extremely high quality of service to all our customers. As the product has evolved, we’ve found ways to offer the same great service at a lower cost, so now our prices are lower too. For example, under our new prices, a customer storing a hundred terabytes of data, reading twenty terabytes and writing ten terabytes a month would pay approximately 40% less a month. The difference is even greater for customers with higher usage. Our new prices are retroactive to the beginning of October. Please see our updated pricing here.

As always, we welcome your feedback in our discussion group. If you haven’t yet tried Google Cloud Storage, you can sign up and get started here.


Navneet Joneja loves being at the forefront of the next generation of simple and reliable software infrastructure, the foundation on which next-generation technology is being built. When not working, he can usually be found dreaming up new ways to entertain his intensely curious one-year-old.

Posted by Scott Knaster, Editor

Dart: a language for structured web programming

By Lars Bak, Software Engineer, Dart Team

Cross-posted on the Chromium Blog

Today we are introducing an early preview of Dart, a class-based optionally typed programming language for building web applications. Dart’s design goals are:

• Create a structured yet flexible language for web programming.
• Make Dart feel familiar and natural to programmers and thus easy to learn.
• Ensure that Dart delivers high performance on all modern web browsers and environments ranging from small handheld devices to server-side execution.

Dart targets a wide range of development scenarios: from a one-person project without much structure to a large-scale project needing formal types in the code to state programmer intent. To support this wide range of projects, Dart has optional types; this means you can start coding without types and add them later as needed. We believe Dart will be great for writing large web applications.

Dart code can be executed in two different ways: either on a native virtual machine or on top of a JavaScript engine by using a compiler that translates Dart code to JavaScript. This means you can write a web application in Dart and have it compiled and run on any modern browser. The Dart VM is not currently integrated in Chrome but we plan to explore this option.

The language comes with a set of basic libraries and tools for checking, compiling, and running Dart code, all of which will evolve further with your participation. We've made the language and preliminary tools available as open source on dartlang.org. Check out the site to give feedback, learn more about Dart, and participate in its development.

We look forward to rapidly evolving Dart into a solid platform for structured web programming.


Lars Bak is a veteran virtual machinist, leaving marks on several software systems: Beta, Self, Strongtalk, Sun's HotSpot and CLDC HI, OOVM Smalltalk, and V8.

Posted by Scott Knaster, Editor

Google Cloud SQL: your database in the cloud

By Navneet Joneja, Product Manager for Google Cloud SQL

Cross-posted from the Google App Engine Blog

One of App Engine’s most requested features has been a simple way to develop traditional database-driven applications. In response to your feedback, we’re happy to announce the limited preview of Google Cloud SQL.

You can now choose to power your App Engine applications with a familiar relational database in a fully-managed cloud environment. This allows you to focus on developing your applications and services, free from the chores of managing, maintaining and administering relational databases.

Google Cloud SQL brings many benefits to the App Engine community:

• No maintenance or administration - we manage the database for you.
• High reliability and availability - your data is replicated synchronously to multiple data centers. Machine, rack and data center failures are handled automatically to minimize end-user impact.
• Familiar MySQL database environment with JDBC support (for Java-based App Engine applications) and DB-API support (for Python-based App Engine applications).
• Comprehensive user interface for administering databases.
• Simple and powerful integration with Google App Engine.

The service includes database import and export functionality, so you can move your existing MySQL databases to the cloud and use them with App Engine.

Cloud SQL is available free of charge for now, and we will publish pricing at least 30 days before charging for it. The service will continue to evolve as we work out the kinks during the preview, but let us know if you’d like to take it for a spin.


Navneet Joneja loves being at the forefront of the next generation of simple and reliable software infrastructure, the foundation on which next-generation technology is being built. When not working, he can usually be found dreaming up new ways to entertain his intensely curious one-year-old.

Posted by Scott Knaster, Editor

Google+ APIs: now with Search and more

By Jordanna Chord, Software Engineer, Google+ API Team

Cross-posted with the Google+ Platform Blog

Thank you to all of you who tried out our first Google+ API release and let us know how you were using it. And thank you also to those of you who asked for more. In the spirit of releasing early and often, today we’ve released some of the new features that you requested.

Search for it

Last month we launched search in Google+, and now it’s available in the API. You can search for public posts using the new activities.search method by sending the following HTTP request:

GET 
https://www.googleapis.com/plus/v1/activities?query=cookie%20recipes&orderBy=best&key=[yourAPIKey]

This method searches across the body and comments of public posts. It returns the following JSON encoded output (excerpted for brevity):

{
 "kind": "plus#activityFeed",
 "title": "Plus Search for cookie recipes",
 "updated": "2011-09-30T16:57:34.479Z",
 "id": "tag:google.com,2010:buzz-search-feed:x4rIYTKpR7NZCL8Id8RHXQ",
 "items": [
  {
   "kind": "plus#activity",
   “id”: “123”,
   "title": "You have to try these out.",
   "object": {
    "objectType": "note",
    "content": "I’m baking halloween cookies!",
   },
   {
   "kind": "plus#activity",
   “id”: “456”,
   "title": "Cookies",
   "object": {
    "objectType": "note",
    "content": "Cookies and milk for dinner. Don’t judge me.",
   },
 ]
}

You can search for people by using the people.search method:

GET https://www.googleapis.com/plus/v1/people?query=vic%20gundotra&key=[yourAPIKey]

This searches across public profile information including fields such as name, bio, location, tag line, and description.

The rest of the conversation

Our first API release let you retrieve public posts. We’ve now added ways for you to see how people are publicly engaging with those posts -- you can find out who reshared a post or who +1’d a post, and you can read the comments on a post.

The new method people.listByActivity supports retrieving resharers and +1’ers by sending the following HTTP requests:

GET https://www.googleapis.com/plus/v1/activities/{activityId}/people/resharers?key=[yourAPIKey]
GET https://www.googleapis.com/plus/v1/activities/{activityId}/people/plusoners?key=[yourAPIKey]

And comments can be retrieved by the new comments.list and comments.get methods:

GET https://www.googleapis.com/plus/v1/activities/{activityId}/comments?key=[yourAPIKey]
GET https://www.googleapis.com/plus/v1/comment/{commentId}?key=[yourAPIKey]

Tell us what you think

As an API developer, I love seeing what people build on top of the APIs I’ve worked on. We have been reading your posts on the Discussion Board and issue tracker and I am excited to see more of your creative ideas. We will continue incorporating your feedback into our design discussions, so please keep it coming.

Follow the conversation on Google+.

Jordanna Chord is a Software Engineer on the Google+ API Team


Posted by Scott Knaster, Editor

Fridaygram: Dead Sea Scrolls online, monument climbing, dinosaur feathers

By Scott Knaster, Google Code Blog Editor

The Dead Sea Scrolls were lost in the Judean desert for more than 2000 years before being rediscovered in 1947. Now The Digital Dead Sea Scrolls project makes five of the ancient documents available online to everyone.



The online scrolls contain incredibly high-resolution photography (up to 1200 megapixels) and an English translation along with the original Hebrew text. Looking through the scrolls online is a remarkable mashup of ancient artifacts and modern technology.

Not everything can be done online: sometimes you need to be there. When a magnitude 5.8 earthquake struck near Washington, D.C. last August, the Washington Monument suffered visible damage. This week the U. S. National Park Service sent its "difficult access team" to rappel up and down the monument to check for damage. Civil Engineer Emma Cardini seemed to enjoy the task and was quoted as saying "It’s really cool to see the planes flying under you". See, that’s why it’s great to be an engineer.

Birds fly, too – but dinosaurs with feathers? Check out this news from Canada about the discovery of amber-bound feathers that belonged to dinosaurs and birds from the late Cretaceous period.


Fridaygram is a weekly post containing a cool Google-related announcement and a couple of fun science-based tidbits. But no cake.

Coding with data from our Transparency Report

By Matt Braithwaite, Transparency Engineering Tech Lead

More than a year ago, we launched our Transparency Report, which is a site that shows the availability of Google services around the world and lists the number of requests we’ve received from governments to either hand over data or to remove content. We wanted to provide a snapshot of government actions on the Web — and in recent cases like Libya and Myanmar, we were glad to see users start to get back on our services.

Today, we’re releasing the raw data behind our Government Requests tool in CSV format. Interested developers and researchers can take this data and revisualize it in different ways, or mash it up with information from other organizations to test and draw up new hypotheses about government behaviors online. We’ll keep these files up-to-date with each biannual data release. We’ve already seen some pretty cool visualizations of this data, despite the lack of a machine-readable version, but we figure that easier access can only help others to find new trends and make new inferences.

The data has grown complex enough that we can no longer build a UI that anticipates every question you might want to ask. For example, the Transparency Report doesn’t allow you to ask the question, "Which Google products receive the greatest number of removal requests across all countries?" Using Google Fusion Tables you can answer that question easily. (The top four are Google Web Search, YouTube, orkut, and Blogger.)

We believe it’s important to keep providing data to anchor policy conversations about Internet access and censorship with real facts — and we’ll continue to add more raw data and APIs to the Transparency Report in the future. So much can be done when engineers and policy wonks come together to talk about the future of the Internet, and we’re psyched to see the graphs, mashups, apps, and other great designs people come up with.

To kick things off, we’re sponsoring a forum to demonstrate the power of what can happen when engineering and policy work together. If you're an EU-based hacker, we invite you to apply to join us for an all-expenses-paid hackathon using this data at the EU Parliament in Brussels on November 8-9, 2011.


Matt Braithwaite is the Tech Lead for Google's Chicago-based Transparency Engineering team. He has a beard (not shown).

Posted by Scott Knaster, Editor

What Does It Mean To Be A Google Developer? Share Your Story

By Amy Walgenbach, Google Developer Marketing

Our developer program started in 2005 with a handful of APIs and developer advocates. Fast forward to today: Google offers over 100 APIs, dozens of developer tools, and a raft of developer advocates around the world. Obviously, a lot has changed and the Web has matured significantly. Google has also evolved and matured, and we felt that it was time to step back and rethink how we interact with and support our developer community. We believe we can make it easier to find what you’re looking for, and facilitate connections with others in the Google Developer community. We know we can do better and we want your input so that we can understand your needs — and what drives you — better.

Now we want to hear from you.

We want to know what inspires you as a developer and how Google can support you. What does being a Google developer mean to you? Tell us what’s important to you and how we can make your experience as a Google developer better. Like any good open source project, the Google developers project needs your contributions. Share your story so we can we better support your success — and we may just pick you to be featured.

You can add a video (it's easy, really!) directly from the page, on your mobile phone, or write to us here. However you share with us, we’re looking forward to hearing what you have to say.

Amy Walgenbach is the Product Marketing lead for the Google+ platform and leads developer marketing for games at Google.

Posted by Ashleigh Rentz, Editor Emerita

Monetizing games with In-App Payments

This guest post was written by Beau Harrington, Senior Development Director, Kabam

Cross-posted with the Google Commerce Blog

Kabam was part of the initial launch of Google+ Games with two game titles, Dragons of Atlantis and Edgeworld, and we recently added Global Warfare. For these games, we integrated Google In-App Payments and we’re pleased with our games’ monetization to date. There are a couple things we learned along the way that we’re happy to share with the community.

Integrating In-App Payments

Integrating In-App Payments in our games was very simple, especially when compared to other payment platforms. There is excellent documentation available, complete with examples for each step of the purchase flow. We also used open-source libraries such as ruby-jwt to generate the tokens required for each purchase option.

We designed our games and purchase pages around the expectation of instant feedback, making sure to incorporate page loads or refreshes wherever possible. For example, in Edgeworld, a player attacking an enemy base can load the list of Platinum options instantly, without waiting for the list of payment options to load. After their Platinum purchase, the player is immediately brought back to the game, with their new currency and items waiting for them.

Pro tip: strive to reduce purchaser friction

One of the keys to maximizing revenue is to remove as much friction as possible from the purchase flow, making sure as many people as possible get from one step of the flow to the next. Many payment platforms send players to their own website and multi-page checkout flow. The Google In-App Payments approach allows us to keep players on our game page for the entire flow, making sure we can manage more of the process and reduce abandonment.

Additionally, the player's credit card information is stored securely, so once a player has made a purchase anywhere using In-App Payments, their information is available for future purchases without additional data entry. Finally, JavaScript callbacks provided by In-App Payments allow us to show the effects of the purchase immediately, improving customer satisfaction.

General recommendations

For those experienced in this space, the following may seem rudimentary. At the same time, I’d be remiss not to include these recommendations as they are important to developing a successful game payments system:

• Make sure your payment flow is as seamless as possible, never giving the player the opportunity to get bored waiting for something to load. 
• Record and monitor each step of the payment flow in order to identify potential problems. 
• Run A/B tests on your purchase option page to optimize the number of players who make a purchase, as well as the amount of the average purchase. 

We are proud to be among the first companies on Google’s exciting new monetization platform, and we look forward to the continuing growth in features, functionality and developer tools.

Beau Harrington is Senior Development Director of Kabam

Posted by Scott Knaster, Editor

Integrate Google Web Font selection into your apps

By Jeremie Lenfant-Engelmann, Google Web Fonts Engineer

We’ve received lots of requests from developers for a dynamic feed of the most recent web fonts offered via Google Web Fonts. Such a feed would ensure that you can incorporate Google Web Fonts into applications and menus dynamically, without the need to hardcode any URLs. The benefits of this approach are clear. As Google Web Fonts continues to add fonts, these fonts can become immediately available within your applications and sites.

To address this need, we’ve built the Google Web Fonts Developer API, which provides a list of fonts offered via Google Web Fonts. Results can be sorted by alpha, date added, popularity, number of styles available, and trending (which is a measure of fonts growing rapidly in usage). Check out the documentation to get started.

Some developers have helped us test this new API over the last few months, and the results are already public. Take a look at TypeDNA’s photoshop plugin as well as Faviconist, an app that makes generating favicons as simple as can be, and Google Web Fonts Families, a list of Google Web Fonts that have more than one style.

We look forward to seeing what you come up with!

Jeremie Lenfant-Engelmann is a Software Engineer on the Google Web Fonts team.

Posted by Scott Knaster, Editor