Google Developers Blog

Dart: Faster Editor and more

2013-06-19T13:06:00.000-07:00

By Dan Rubel, Productivity Enhancer, Dart Editor team

Cross-posted from the Chromium Blog

Today's release of the Dart SDK and Editor is the first beta release, and contains performance and productivity improvements across the platform. This latest release helps Dart developers automate code evolution, produce smaller JavaScript code and deploy Dart web apps.

The Editor's analysis engine, responsible for reporting warnings and errors, is completely rewritten and is 20% faster at parsing and analyzing. Now, there’s no need to run all the unit tests just to discover a typo. The Dart Editor watches your back as you type.

In addition, Dart Editor makes it easier for developers to manage an evolving app. Some of the new features include:

"Rename Library" refactoring
"Convert Method to Getter" and "Convert Getter to Method" refactorings
"Import Library" quick fix
"Create Class" and "Create part" quick fixes

Code completion has also improved. For example, completion is now camelcase aware. Type iE and Dart Editor finds isEmpty.

Compiling Dart to JavaScript now results in smaller code. For example, some Dart programs that use reflection and HTML can compile to JavaScript that is 3.7x smaller than previous compilation sizes.

Dart VM performance has also improved. Compared against the previous release of Dart, DeltaBlue is 33% faster and Tracer is 40% faster. This release also includes full SIMD acceleration in Dart VM.

Finally, deploying a Dart web app is now easier, with the beta pub deploy command. It creates a directory with your app's code and assets and prepares it for hosting on your favorite web server. You can use this command from Dart Editor or the pub command-line utility.

That's just the highlights - there are more improvements across the platform. You can read the full release notes for more details and changes. You can download the latest version of Dart Editor, including everything you need for Dart development, from dartlang.org. We look forward to your feedback!

Written by Dan Rubel, Dart Editor Team

Posted by Scott Knaster, Editor

Google Developers Live: our first year

2013-06-19T10:34:00.001-07:00

By Louis Gray, Program Manager, Google Developers Live

One year ago, we took the magic of Google I/O and brought it home with Google Developers Live (+GDL) - engaging with our developer community all year round, live, from our offices around the world. Nearly 1,000 videos and several million views later, we’ve seen you connect with Googlers and industry experts every day, gaining knowledge, sharing insights, and getting feedback on how to create incredible apps and leverage Google’s tools.

Thanks to the combination of Google+ Hangouts and YouTube Live, you can now see our engineers face to face and gain up to the minute insights on +Android, +Google Chrome, +Google Cloud Platform, and many more.

But Google Developers Live is not just all Google products, all the time. It’s an interactive platform for innovative applications, design wizards and entrepreneurs. We’ve hosted initiatives like Women Techmakers, Google Top Geek from Mexico City, Android Design In Action and Root Access, and we hear directly from the minds behind applications many of us use every day.

It was on GDL where we saw Google Fellow +Sebastian Thrun introduce a new HTML5 course on Udacity. GDL debuted the Mirror API for +Project Glass. And it was on GDL where we first demonstrated YouTube API v3, went behind the scenes with Santa Tracker, and answered questions on the Blink rendering engine.

And when we returned to I/O last month, it was Google Developers Live with wall-to-wall broadcasts, featuring exceptional guests like Megan Smith of Google[x], Bradley Horowitz of Google+ and Hiroshi Lockheimer and Hugo Barra of Android.

While we love the live interaction, Google Developers Live is more than just live. Our archives make it easy for you to watch on your own schedule - in any order, on any product.

Although GDL is only a year old, we’re now broadcasting from Mountain View, New York, Sydney, Tokyo, Milan, Moscow, Buenos Aires, and many places around the world, to bring you the latest Google tools for developers in your time zone, in your language. And we’ve got a lot more planned. So make sure you don’t miss a show, by subscribing to Google Developers on YouTube and staying tuned to https://developers.google.com/live/.

+Louis Gray is a Program Manager on Google's Developer Relations Team, running Google Developers Live. He believes life is but a (live) stream.

Posted by +Scott Knaster, Editor

Play Cube Slam, a real-time WebRTC video game

2013-06-12T10:04:00.000-07:00

By Justin Uberti, Chromium team

Cross-posted with the Chromium Blog

Cube Slam is a Chrome Experiment built with WebRTC, an open web technology that lets you communicate in real-time in the browser (and in this case, play an old-school arcade game with your friends) without downloading and installing any plug-ins. In this post, we wanted to explain a bit about how Cube Slam works.

Cube Slam uses getUserMedia to access your webcam and microphone (with your permission, of course), RTCPeerConnection to stream your video to a friend, and RTCDataChannel to transfer the bits that keep the gameplay in sync. If you and your friend are behind firewalls, RTCPeerConnection uses a TURN relay server (hosted on Google Compute Engine) to make the connection. When there are no firewalls in the way, however, the entire game happens directly peer-to-peer, reducing latency for players and server costs for developers.

Cube Slam is the first large-scale application to use RTCDataChannel, which provides an API similar to WebSocket, but sends the data over the RTCPeerConnection peer-to-peer link. RTCDataChannel sends data securely, and supports an "unreliable" mode for cases where you want high performance but don't care about every single packet making it across the network. In cases like games where low delay often matters more than perfect delivery, this ensures that a single stray packet doesn't slow down the whole app.

RTCDataChannel only supports unreliable mode in desktop Chrome today. We're working on implementing the latest WebRTC spec, where we'll use the standard SCTP protocol to support reliable mode. WebRTC will also be available on Chrome for Android later this year, and you can try it now by flipping “Enable WebRTC Android” in chrome://flags. Several browsers are currently working on implementing WebRTC, and we’re looking forward to the day when you can have a Cube Slam face-off against your friends on any browser and any device.

To learn more about the tech in Cube Slam, you can check out our technology page and source code. Disable the shields! Destroy the screen! Have fun!

Justin Uberti is one of the co-creators of the WebRTC initiative, and leads the WebRTC engineering team at Google. Previously, Justin helped create Google+ Hangouts.

Posted by Ashleigh Rentz, Editor Emerita

Race across screens and platforms, powered by the mobile web

2013-06-11T09:01:00.000-07:00

By Pete LePage, Chromium team

Cross-posted with the Chromium Blog

You may have seen our recent demo of Racer at Google I/O, and wondered how it was made. So today we wanted to share some of the web technologies that made this Chrome Experiment “street-legal” in a couple of months. Racer was built to show what’s possible on today’s mobile devices using an entirely in-browser experience. The goal was to create a touch-enabled experience that plays out across multiple screens (and speakers). Because it was built for the web, it doesn’t matter if you have a phone or a tablet running Android or iOS, everyone can jump right in and play.

Racer required two things: speedy pings and a consistent experience across screens. We delivered our minimal 2D vector drawings to each device’s HTML5 Canvas using the Paper.js vector library. Paper.js can handle the path math for our custom race track shapes without getting lapped. To eke out all the frame rate possible on such a large array of devices we rendered the cars as image sprites on a DOM layer above the Canvas, while positioning and rotating them using CSS3’s transform: matrix().

Racer’s sound experience is shared across multiple devices using the Web Audio API (available in latest iOS and Android M28 beta). Each device plays one slice of Giorgio Moroder’s symphony of sound—requiring five devices at once to hear his full composition. A constant ping from the server helps synchronize all device speakers allowing them to bump to one solid beat. Not only is the soundtrack divided across devices, it also reacts to each driver’s movements in real time—the accelerating, coasting, careening, and colliding rebalances the presence of every instrument.

To sync your phones or tablets, we use WebSockets, which enables rapid two-way communication between devices via a central server. WebSocket technology is just the start of what multi-device apps of the future might use. We’re looking forward to when WebRTC data channels—the next generation of speedy Web communication—is supported in the stable channel of Chrome for mobile. Then we’ll be able to deliver experiences like Racer with even lower ping times and without bouncing messages via a central server. Racer’s backend was built on the Google Cloud Platform using the same structure and web tools as another recent Chrome Experiment, Roll It.

To get an even more detailed peek under the hood, we just published two new case studies on our HTML5 Rocks site. Our friends at Plan8 wrote one about the sound engineering and Active Theory wrote one about the front-end build. You can also join the team at Active Theory for a Google Developers Live event this Thursday, June 13, 2013 at 3pm GMT for an in depth discussion.

Pete LePage is a Developer Advocate on the Google Chrome team and helps developers create great web applications and mobile web experiences.

Posted by Ashleigh Rentz, Editor Emerita

Google BigQuery new features: bigger, faster, smarter

2013-06-11T08:00:00.000-07:00

By Felipe Hoffa, Cloud Platform team

Google BigQuery is designed to make it easy to analyze large amounts of data quickly. Today we announced several updates that give BigQuery the ability to handle arbitrarily large result sets, use window functions for advanced analytics, and cache query results. You are also getting new UI features, larger interactive quotas, and a new convenient tiered pricing scheme. In this post we'll dig further into the technical details of these new features.

Large results

BigQuery is able to process terabytes of data, but until today BigQuery could only output up to 128 MB of compressed data per query. Many of you asked for more and from now on BigQuery will be able to output results as large as the largest tables our customers have ever had.

To get this benefit, you should enable the new "--allow_large_results" flag when issuing a query job, and specify a destination table. All results will be saved to the new specified table (or appended, if the table exists). In the updated web UI these options can be found under the new "Enable Options" menu.

With this feature, you can run big transformations on your tables, plus get big subsets of data to further analyze from the new table.

Analytic functions

BigQuery's power is in the ability to interactively run aggregate queries over terabytes of data, but sometimes counts and averages are not enough. That's why BigQuery also lets you calculate quantiles, variance and standard deviation, as well as other advanced functions.

To make BigQuery even more powerful, today we are adding support for window functions (also known as "analytical functions") for ranking, percentiles, and relative row navigation. These new functions give you different ways to rank results, explore distributions and percentiles, and traverse results without the need for a self join.

To introduce these functions with an advanced example, let's use the dataset we collected from the Data Sensing Lab at Google I/O. With the percentile_cont() function it's easy to get the median temperature over each room:

SELECT percentile_cont(0.5) OVER (PARTITION BY room ORDER BY data) AS median, room
FROM [io_sensor_data.moscone_io13]
WHERE sensortype='temperature'

In this example, each original data row shows the median temperature for each room. To visualize it better, it's a good idea to group all results by room with an outer query:

SELECT MAX(median) AS median, room FROM (
  SELECT percentile_cont(0.5) OVER (PARTITION BY room ORDER BY data) AS median, room
  FROM [io_sensor_data.moscone_io13]
  WHERE sensortype='temperature'
)
GROUP BY room

We can add an additional outer query, to rank the rooms according to which one had the coldest median temperature. We'll use one of the new ranking window functions, dense_rank():

SELECT DENSE_RANK() OVER (ORDER BY median) rank, median, room FROM (
  SELECT MAX(median) AS median, room FROM (
    SELECT percentile_cont(0.5) OVER (PARTITION BY room ORDER BY data) AS median, room
    FROM [io_sensor_data.moscone_io13]
    WHERE sensortype='temperature'
  )
  GROUP BY room
)

We've updated the documentation with descriptions and examples for each of the new window functions. Note that they require the OVER() clause, with an optional PARTITION BY and sometimes required ORDER BY arguments. ORDER BY tells the window function what criteria to use to rank items, while PARTITION BY allows you to define multiple groups to be analyzed independently of each other.

The window functions don't work with the big GROUP EACH BY and JOIN EACH BY operators, but they do work with the traditional GROUP BY and JOIN BY. As a reminder, we announced GROUP EACH BY and JOIN EACH BY last March, to allow large join and group operations.

Query caching

BigQuery now remembers values that you've previously computed, saving you time and the cost of recalculating the query. To maintain privacy, queries are cached on a per-user basis. Cached results are only returned for tables that haven't changed since the last query, or for queries that are not dependent on non-deterministic parameters (such as the current time). Reading cached results is free, but each query still counts against the max number of queries per day quota. Query results are kept cached for 24 hours, on a best effort basis. You can disable query caching with the new flag --use_cache in bq, or "useQueryCache" in the API. This feature is also accessible with the new query options on the BigQuery Web UI.

BigQuery Web UI: Query validator, cost estimator, and abandonment

The BigQuery UI gets even better: You'll get instant information while writing a query if its syntax is valid. If the syntax is not valid, you'll know where the error is. If the syntax is valid, the UI will inform you how much the query would cost to run. This feature is also available with the bq tool and API, using the --dry_run flag.

An additional improvement: When running queries on the UI, previously you had to wait until its completion before starting another one. Now you have the option to abandon it, to start working on the next iteration of the query without waiting for the abandoned one.

Pricing updates

Starting in July, BigQuery pricing becomes more affordable for everyone: Data storage costs are going from $0.12/GB/month to $0.08/GB/month. And if you are a high-volume user, you'll soon be able to opt-in for tiered query pricing, for even better value.

Bigger quota

To support larger workloads we're doubling interactive query quotas for all users, from 200GB + 1 concurrent query, to 400 GB of concurrent queries + 2 additional queries of unlimited size.

These updates make BigQuery a faster, smarter, and even more affordable solution for ad hoc analysis of extremely large datasets. We expect they'll help to scale your projects, and we hope you'll share your use cases with us on Google+.

The BigQuery UI features a collection of public datasets for you to use when trying out these new features. To get started, visit our sign-up page and Quick Start guide. You should take a look at our API docs, and ask questions about BigQuery development on Stack Overflow. Finally, don't forget to give us feedback and join the discussion on our Cloud Platform Developers Google+ page.

Felipe Hoffa has recently joined the Cloud Platform team. He'd love to see the world's data accessible for everyone in BigQuery.

Posted by Ashleigh Rentz, Editor Emerita

Making Google’s CalDAV and CardDAV APIs available for everyone

2013-06-05T09:15:00.000-07:00

By Piotr Stanczyk, Tech Lead

In March we announced that CalDAV, an open standard for accessing calendar data across the web, would become a partner-only API because it appeared that almost all the API usage was driven by a few large developers. Since that announcement, we received many requests for access to CalDAV, giving us a better understanding of developers’ use cases and causing us to revisit that decision. In response to those requests, we are keeping the CalDAV API public. And in the spirit of openness, today we’re also making CardDAV – an open standard for accessing contact information across the web – available to everyone for the first time.

Both of these APIs are getting other updates as well:

Integration with the Google APIs Console. To start using CalDAV or CardDAV in your project, just enable it in the Console.
OAuth 2.0 authentication.

In addition, the CalDAV API now has a new endpoint:
https://apidata.googleusercontent.com/caldav/v2

Piotr Stanczyk is the Tech Lead of the Google Calendar APIs group. His current focus is to provide next generation Calendar APIs which make developers’ lives easier. He also participates in CalConnect consortium.

Posted by Scott Knaster, Editor

Hacking for change at Google

2013-06-04T16:00:00.000-07:00

By Patrick Copeland, Google.org

Cross-posted with the Google.org Blog

On June 1st and 2nd, thousands of developers from across the U.S. came together at nearly 100 different locations to participate in the first ever National Day of Civic Hacking. Using public data recently released by the government on topics like crime, health and the environment, developers built new applications that help address social challenges.

At the Googleplex in Mountain View, we hosted nearly 100 developers, statisticians, data scientists, and designers, who stayed long into the night hacking together prototypes that show how data on health and the environment can be used to enrich lives. Fusion Tables and Google App Engine were used to prototype, and groups relied on BigQuery as a workhorse to crunch the biggest datasets. Participants used Google+ Hangouts to connect with hackathons in other states and collaborated with Google Apps and platforms.

Here are a few highlights from the hackathon that stood out as useful, visually stunning, and informative ways to use public data:

Eat Healthy for Less, the winner of our Mountain View hackathon, is a mobile web application that uses the Consumer Pricing Index to suggest healthy recipes that can be made on a budget.
Data+, a reimagining of how we access data, can make exploring public datasets more intuitive and easily understandable for everyone.
Detoxic.org is a web experience and Android app that shows you toxic sites and landfills nearby that you might not know about so that you can take civic action against toxic waste.

Many of the ideas have great potential, and we are encouraging participants to continue their work. We hope that the National Day of Civic Hacking will be a catalyst for innovation in this space, and encourage you to keep track of our tools for civic developers at g.co/civicdevelopers.

Congratulations and thanks to everyone who participated!

Patrick Copeland is director of engineering at Google.org, where he works to build systems that leverage Google's reach to help people around the world.

Posted by Scott Knaster, Editor

A classic boardwalk game rolls from your phone to your computer—using only your browser

2013-06-04T09:00:00.000-07:00

By Pete LePage, Developer Advocate and Boardwalk King

Cross-posted from the Chromium Blog

Last week we launched Roll It, a Chrome Experiment that links phones to computers and gets people out of their chairs and swinging. We wanted to share how we built a physical game experience with no dedicated hardware. It requires just the web, your computer and a phone.

Here’s a look at the APIs and browser-based features we used to create it.

Roll It is a three-dimensional (3D) experience, from the swing of your phone’s accelerometer right up to the virtual models rendered on your computer’s HTML5 Canvas. On the phone side, we hooked into browser events like DeviceOrientation and DeviceMotion to detect the speed and direction of a swing. On the computer side we rendered our scene using Three.js and plugged in Physijs to add physics to the ball and environment.

To sync the phone to the computer we employed WebSockets which enable rapid two-way communication between devices via a central server.

For extra stability we built our backend on Google Cloud Platform:

Our Google App Engine application, built in Go, dynamically balances users across our relay servers.
A Google Compute Engine server maintains game state across synced devices.
Google Cloud Storage speedily serves up the static assets.

We couldn’t have brought this experiment to life without a great team. The theme for Roll It was composed by Mr. Tim Healey. Legwork Studio developed the interfaces and game environment, and teamed up with Mode Set for the development.

To dig deeper into the technology behind Roll It, check out the HTML5 Rocks Case Study, or join the team for a Google Developers Live event this Friday, June 7, 2013 at 5pm GMT for an in-depth discussion.

Pete LePage is a Developer Advocate on the Google Chrome team and helps developers create great web applications and mobile web experiences.

Posted by Scott Knaster, Editor

Fridaygram: supporting nonprofits, yawning dogs, Easter egg in space

2013-05-31T12:19:00.001-07:00

Scott

Maya

By Maya Amoils, Google.org, and Scott Knaster, Developer Relations

Throughout this month, we’ve asked developers around the world to sign up for Be Mindful in May, a one-month meditation campaign that challenges participants to learn about meditation while simultaneously dedicating their efforts to a global cause: providing clean water to people in developing nations. So far the campaign has raised over $75,000 AUD for this important issue, and the Google Developers team has raised $1700 AUD.

The money raised through Be Mindful in May will go to charity:water, an organization that’s helping to bring clean, safe drinking water to the nearly 1 billion people who struggle every day without it.

To help support nonprofits like charity:water, last month we released the One Today mobile app as a limited pilot in the US. One Today introduces users to new projects each day across a wide range of issues, and enables users to donate $1 to the cause. One Today users can amplify their impact by matching their friends’ donations. If you’re in the US, you can join the One Today pilot by requesting an invite.

From making a difference in the world to wacky science, studies suggest that dogs yawn in response to humans. And not only that: further research shows that sometimes, dogs yawn in empathy with humans yawning, while other times, dogs yawn because they’re feeling stress, as when they’re listening to their owners. Much more research involving yawning dogs and people will be necessary to fully sort this out.

Finally, if you’re previewing the new Google Maps, you might be interested in this cool Easter egg. And if you’re not on the new Google Maps, you can request an invite. It’s really nice, and might even keep you from yawning.

Fridaygrams provide a chance for us to focus on fun and interesting stuff that’s not necessarily related to writing code. Sometimes we even get to feature inspiring content, like this week’s information about helping nonprofits.

Maya Amoils is a member of the Google.org marketing team where she works on a number of the team's charitable giving initiatives. Maya holds a BA in Science Technology & Society from Stanford University. Outside of work, you can find her biking around the Bay Area or making playlists on Spotify.

Scott Knaster is the editor of Google Developers Blog. He likes family time, technology, and watching the San Francisco Giants win baseball games.

Fridaygram: Galapagos images, smart dog, timely entanglement

2013-05-24T11:20:00.003-07:00

By Scott Knaster, Google Developers Blog Editor

On Fridaygram we love to celebrate amazing new Street View images. This week we announced new panoramic views of the Galapagos Islands, collected with with the Street View Trekker in partnership with the Charles Darwin Foundation (CDF) and the Galapagos National Parks Directorate (GNPD). These images will go live on Google Maps later this year, but you can see a preview below and on the Official Google Blog.

The Maps team’s 10-day adventure included lots of interaction with local wildlife, but didn’t take place entirely on land. The team worked with the Catlin Seaview Survey to collect underwater ocean images too. And in addition to being beautiful and fun, these pictures have a practical use: they act as a visual record that can be compared to changes observed in the future.

Speaking of wildlife, do you have a smart dog? And does your smart dog know 1000+ words, plus have a basic comprehension of grammar? Meet Chaser, a 9-year-old border collie who has been taught to recognize the names of 1000 objects, as well as the meaning of some verbs and prepositions. In tests, Chaser correctly (most of the time) responded to commands such as “take ball to Frisbee”, or even “to Frisbee take ball”. If only our friends and family were that helpful.

Finally, there’s some typically mind-blowing news from the world of quantum physics. We already know that quantum particles can share a connection called entanglement, which allows one particle to reflect the state of another no matter how far apart they are. Now an experimental discovery shows that particles can be entangled even if they don’t exist at the same time. We agree with experimenter Jeremy O'Brien of the University of Bristol, who said “It’s really cool”.

Fridaygram is about randomly cool and nerdy stories that we hope will amuse you and possibly inspire your weekend. Around here we’re still feeling the Google I/O afterglow, so we’re going to recommend you spend some time this weekend watching some of the many session videos from I/O. If that’s not your thing, maybe you’d like this brief but inspiring video that kicked off the conference.

Google I/O 2013: For the developers

2013-05-17T16:30:00.000-07:00

By Scott Knaster, Google Developers Blog Editor

“Google I/O is an annual developer conference featuring highly technical, in-depth sessions, and showcasing the latest from Google's product teams and partners.”
– official description

Google I/O 2013 has just ended, and even more than usual, this one was for you, our developers. This year, we focused on providing new tools and services you’ve been asking for, plus a few surprises that we hope inspired and delighted you.

Android gets its own IDE: Android Studio, based on IntelliJ IDEA Community Edition.
Google Play Services 3.1 brings game services, location APIs, Google Cloud Messaging enhancements, and Cross-Platform Single Sign On.
An updated Google Play Developer Console adds a very cool app translation service, revenue graphs, alpha and beta testing and staged rollouts, optimization tips, and referral tracking.
We showed off a whole new look for Google Maps and Maps APIs, featuring new base map tiles, a new default marker, a new info window style, and a style refresh for controls.
In Google Cloud Platform news, we announced that Google Compute Engine is now open to everyone and has sub-hour billing, we’ve added a PHP runtime to App Engine, and we introduced Google Cloud Datastore.
We showed new Google Wallet features: the Instant Buy Android API, which makes buying in native Android apps fast and easy, and the Wallet Objects API, which lets you connect your loyalty programs, offers and more to Google Wallet.

Although we put developer announcements first this year, we didn’t skimp on the cool stuff for everyone: we refreshed the look of the Google+ stream, launched expanded Hangouts, totally revamped Google+ photos, announced Google Play Music All Access, showed off conversational search, and demoed some amazing Chrome Experiments.

Of course, Google I/O isn’t just about announcements. It’s our chance to share what’s new with you in those highly technical, in-depth sessions and for you to meet and interact with our engineers and other Googlers, in person and via the Internet. Once again this year, all sessions were recorded and are being posted to Google Developers Live (GDL) for you to peruse whenever it’s convenient for you.

We love putting on Google I/O, and that’s one reason we created GDL. With GDL, we don’t have to pack all our presentations into a 3-day conference. You’ll find new programs on GDL every week, from the same people who present at Google I/O. Just like during I/O, you can watch live or see recordings whenever you want. You can subscribe to the Google Developers channel on YouTube to be notified when new programs are posted.

Whether you came to San Francisco, participated in I/O Extended, or watched our live streams, we thank you for your attention and dedication. Here’s to Google I/O 2014!

Get started with App Engine for PHP: scalable, secure and reliable

2013-05-16T14:51:00.001-07:00

By Andrew Jessup, Product Manager

Cross-posted from the Google Cloud Platform Blog

At Google I/O, we announced PHP as the latest supported runtime for Google App Engine in Limited Preview. PHP is one of the world's most popular programming languages, used by developers to power everything from simple web forms to complex enterprise applications.

Now PHP developers can take advantage of the scale, reliability and security features of App Engine. In addition, PHP runs well with other parts of Google Cloud Platform. Let's look at how this works.

Connecting to Google Cloud SQL from App Engine for PHP

Many PHP developers start with MySQL when choosing a database to store critical information, and a wide variety of products and frameworks such as WordPress make extensive use of MySQL’s rich feature set. Google Cloud SQL provides a reliable, managed database service that is MySQL 5.5 compatible and works well with App Engine.

To set up a Cloud SQL database, sign into Google Cloud Console - create a new project, choose Cloud SQL and create a new instance.

After you create the instance, it's automatically associated with your App Engine app.

You will notice Cloud SQL instances don’t need an IP address. Instead they can be accessed via a compound identifier made up of their project name and instance name, such as hello-php-gae:my-cloudsql-instance.

From within PHP, you can access Cloud SQL directly using the standard PHP MySQL libraries - mysql, mysqli or PDO_MySQL. Just specify your Cloud SQL database with its identifier, such as:

<?php

$db = new PDO(
  'mysql:unix_socket=/cloudsql/hello-php-gae:my-cloudsql-instance;dbname=demo_db;charset=utf8',
  'demo_user',
  'demo_password'
);

foreach($db->query('SELECT * FROM users') as $row) {
  echo $row['username'].' '.$row['first_name']; //etc...
}

Methods such as query() work just as you’d expect with any MySQL database. This example uses the popular PDO library, although other libraries such as mysql and mysqli work just as well.

Storing files with PHP and Google Cloud Storage

Reading and writing files is a common task in many PHP projects, whether you are reading stored application state, or generating formatted output (e.g., writing PDF files). The challenge is to find a storage system that is as scalable and secure as Google App Engine itself. Fortunately, we have exactly this in Google Cloud Storage (GCS).

The first step in setting up Google Cloud Storage is to create a bucket:

With the PHP runtime, we’ve implemented native support for GCS. In particular, we’ve made it possible for PHP’s native filesystem functions to read and write to a GCS bucket.

This code writes all prime numbers less than 2000 into a file on GCS:

<?php

$handle = fopen('gs://hello-php-gae-files/prime_numbers.txt','w');

fwrite($handle, "2");
for($i = 3; $i <= 2000; $i = $i + 2) {
  $j = 2;
  while($i % $j != 0) {
    if($j > sqrt($i)) {
      fwrite($handle, ", ".$i);
      break;
    }
    $j++;
  }
}

fclose($handle);

The same fopen() and fwrite() commands are used just as if you were writing to a local file. The difference is we’ve specified a Google Cloud Storage URL instead of a local filepath.

And this code reads the same file back into memory and pulls out the 100th prime number, using file_get_contents():

<?php

$primes = explode(",",
  file_get_contents('gs://hello-php-gae-files/prime_numbers.txt')
);

if(isset($primes[100]))
  echo "The 100th prime number is ".$primes[100];

And more features supported in PHP

Many of our most popular App Engine APIs are now supported in PHP, including our zero-configuration Memcache, Task Queues for asynchronous processing, Users API, Mail API and more. The standard features you’d expect from App Engine, including SSL support, Page Speed Service, versioning and traffic splitting are all available as well.

Open today in Limited Preview

Today we’re making App Engine for PHP available in Limited Preview. Read more about the runtime in our online documentation, download an early developer SDK, and sign up to deploy applications at https://cloud.google.com/appengine/php.

Andrew Jessup is a Product Manager at Google, working on languages and runtimes for Google App Engine.

Posted by Scott Knaster, Editor

Get started with Google Cloud Datastore - a fast, powerful, NoSQL database

2013-05-16T09:00:00.000-07:00

By Chris Ramsdale, Product Manager

Cross-posted from the Google Cloud Platform Blog

At Google I/O, we announced Google Cloud Datastore, a fully managed solution for storing non-relational data. Based on the popular Google App Engine High Replication Datastore (HRD), Cloud Datastore provides a schemaless, non-relational datastore with the same accessibility of Google Cloud Storage and Google Cloud SQL.

Cloud Datastore builds off the strong growth and performance of HRD, which has over 1PB of data stored, 4.5 trillion transactions per month and a 99.95% uptime. It also comes with the following features:

Built-in query support: near SQL functionality that allows you to search, sort and filter across multiple indexes that are automatically maintained
ACID transactions: data consistency (both Strong and Eventual) that spans multiple replicas and requests
Automatic scaling: built on top of Google’s BigTable infrastructure, the Cloud Datastore will automatically scale with your data
High availability: by utilizing Google’s underlying Megastore service, the Cloud Datastore ensures that data is replicated across multiple datacenters and is highly available
Local development environment: the Cloud Datastore SDK provides a full-featured local environment that allows you to develop, iterate and manage your Cloud Datastore instances efficiently
Free to get started: 50k read & write operations, 200 indexes, and 1GB of stored data for free per month

Getting started with Cloud Datastore

To get started, head over to the Google Cloud Console and create a new project. After supplying a few pieces of information you will have a Cloud Project that has the Cloud Datastore enabled by default. For this post we’ll use the project ID cloud-demo.

With the project created and the Cloud Datastore enabled, we’ll need to download the Cloud Datastore client library. Once installed, it’s time to start writing some code. For the sake of this post, we’ll focus on accessing the Cloud Datastore from a Python application running on a Compute Engine VM (which is also now in Preview). We’ll assume that you’ve already created a new VM instance.'

import googledatastore as datastore

def main()
  writeEntity()
  readEntity()

Next include writeEntity() and readEntity() functions:

def WriteEntity():
  req = datastore.BlindWriteRequest()
  entity = req.mutation.upsert.add()
  path = entity.key.path_element.add()
  path.kind = 'Greeting'
  path.name = 'foo'
  message = entity.property.add()
  message.name = 'message'
  value = message.value.add()
  value.string_value = 'to the cloud and beyond!'
  try:
    datastore.blind_write(req)
  except datastore.RPCError as e:
    # remember to do something useful with the exception pass

def ReadEntity(): 
  req = datastore.LookupRequest()
  key = req.key.add()
  path = key.path_element.add()
  path.kind = 'Greeting0'
  path.name = 'foo0'
  try:
    resp = datastore.lookup(req)
    return resp
  except datastore.RPCError as e:
    # remember to do something useful with the exception pass

First create a new file called “demo.py”. Inside demo.py, we’ll add code to write and then read an entity from the Cloud Datastore. Finally we can update main() to print out the property values within the fetched entity:

def main()
  writeEntity();
  resp = readEntity();

  entity = resp.found[0].entity
  for p in entity.property:
    print 'Entity property name: %s', p.name
    v = p.value[0]
    print 'Entity property value: %s', v.string_value

Before we can run this code we need to tell the SDK which Cloud Datastore instance we would like to use. This is done by exporting the following environment variable:

~$ export DATASTORE_DATASET cloud-datastore-demo

Finally we’re able to run the application by simply issuing the following:

~$ python demo.py

Besides the output that we see in console window, we’re also able to monitor our interactions within the Cloud Console. By navigating back to Cloud Console, selecting our cloud-datastore-demo project, and then selecting the Cloud Datastore we’re taken to our instance’s dashboard page that includes number of entities, properties, and property types, as well as index management, ad-hoc query support and breakdown of stored data.

And that’s really just the beginning. To fully harness the features and functionality that the Cloud Datastore offers, be sure to check out the larger Getting Started Guide and the Cloud Datastore documentation.

Cloud Datastore is the latest addition to the Cloud Platform storage family, joining Cloud Storage for storing blob data, Cloud SQL for storing relational data, and Persistent Disk for storing block data. All fully managed so that you can focus on creating amazing solutions and leave the rest to us.

And while this is a Preview Release, the team is off to a great start. As we move the service towards General Availability we’re looking forward to improving JSON support, more deeply integrating with the Cloud Console, streamlining our billing and driving every bit of performance that we can out of the API and underlying service.

Happy coding!

Chris Ramsdale has worked extensively in the mobile space, starting as a Software Engineer at Motorola in 1997, and then joining local start ups as a Tech Lead and Product Manager. Chris is currently a Product Manager for Google Cloud Platform focused on developer tools and platform services like Google App Engine and Google Cloud Datastore.

Posted by Scott Knaster, Editor

Google Compute Engine is now open to all

2013-05-15T18:00:00.000-07:00

By Navneet Joneja, Product Manager

Cross-posted from the Google Cloud Platform Blog

Last year we announced Google Compute Engine to enable any business or developer to use Google’s infrastructure for their applications. Now we’re taking the next step: Google Compute Engine is open to everyone in preview, and you can sign up online now.

Over the past year, we’ve launched several features and made significant improvements behind the scenes. We’re now announcing several new capabilities that make it easier and more economical to use Compute Engine for a broader set of applications.

Sub-Hour Billing: We heard feedback from our early users who wanted more granular billing increments so they could run short-lived workloads. Now all instances are charged for in one-minute increments with a ten-minute minimum, so you don’t pay for compute minutes that you don’t use.
New shared-core instance types: Compute Engine’s new micro and small instance types are designed as a cost-effective option for running small workloads that don’t need a lot of CPU power, like development and test workloads.
Larger Persistent Disks: We’re increasing the size of Persistent Disks that can be attached to instances by up to 8,000%. You can now attach up to 10 terabytes of persistent disk to a Compute Engine virtual machine, giving you plenty of persistent storage for a wide variety of applications.
Advanced Routing Capabilities: Compute Engine now supports software-defined routing capabilities based on our broad SDN innovation. These capabilities are designed to handle your advanced network routing needs like configuring instances to function as gateways, configuring VPN servers and building applications that span your local network and Google’s cloud.
ISO 27001 Certification: We’ve also completed ISO 27001:2005 certification for Compute Engine, App Engine, and Cloud Storage to demonstrate that these products meet the international standard for managing information security.

To get started, go to the Google Cloud Console, select Compute Engine and click the “New Instance” button.

Fill out the required information and click “Create” on the right hand side. Your new virtual machine will be ready to use in about a minute.

To all of our customers who helped us evolve the product over the past months, thank you; your feedback has helped shape Compute Engine. To those of you who have been eager to try Compute Engine, the wait is over and you can sign up for Compute Engine online today.

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 three-year-old.

Posted by Scott Knaster, Editor

Cross-Platform SSO technology

2013-05-15T14:00:00.000-07:00

By Tim Bray, Google Identity Team

During the Android portion of the Google I/O keynote, we showed Cross-Platform Single Sign-On; the effect was that for Wallet and Google+ users, signing in to a Web browser resulted in automatic download of, and sign-in to, an Android app.

To support this, we have introduced general-purpose API tools which allow developers to achieve cross-client authentication and authorization, in particular between Android and Web apps.

Not having to sign in repeatedly feels so natural for users that they don’t even notice it. But as more and more apps deploy this sort of magic, you don’t want to be the hold-out that’s pestering users for passwords on Web sites or, worse, on tiny mobile-device keyboards.

On the Android side, client libraries like PlusClient, GamesClient, and WalletClient have “connect” methods that take care of this as automatically as possible; they check whether any of the accounts on the phone have already been authorized for access to the service in question, conduct sign-in if necessary but avoid it if possible, and when they return to your code, everything’s all set up.

If you’re writing server-side code and using libraries like Google+ Sign-In, once again, all the right things happen automatically; when you start accessing the service, the software imposes the minimum necessary pain on the user, ideally zero, and lets you get to work.

Of course, some people want less automation, and finer control over how things work. If you want to access our services at the HTTP level rather than via a library, or to deal with multiple accounts on an Android device in a customized way, you can do these things and in most cases still deliver the no-sign-in magic.

Of course, this involves working with HTTP message flows, validating tokens, and securing shared secrets. This may sound intimidating but will be straightforward for one well-versed in HTTP-level Web programming. If you’re one of those, check out the low-level protocols and APIs that support this, in “Cross-Client Identity”.

The time is now to start moving your apps towards a sign-in-free future.

Tim says: By day, I help in the struggle against passwords on the Internet.
The rest of my life is fully documented on my blog.

Posted by Scott Knaster, Editor

Ushering in the next generation of computing at Google I/O

2013-05-15T12:45:00.000-07:00

By Urs Hölzle, Senior Vice President, Technical Infrastructure, and Google Fellow

Cross-posted from the Google Cloud Platform Blog

Watch the video of the Cloud track kickoff.

Over the last fourteen years we have been developing some of the best infrastructure in the world to power Google’s global-scale services. With Google Cloud Platform, our goal is to open that infrastructure and make it available to any business or developer anywhere. Today, we are introducing improvements to the platform and making Google Compute Engine available for anyone to use.

Google Compute Engine - now available for everyone

Google Compute Engine provides a fast, consistently high-performance environment for running virtual machines. Later today, you’ll be able to go online to cloud.google.com and start using Compute Engine.

In addition, we’re introducing new Compute Engine features:

Sub-hour billing charges for instances in one-minute increments with a ten-minute minimum, so you don’t pay for compute minutes that you don’t use
Shared-core instances provide smaller instance shapes for low-intensity workloads
Advanced Routing features help you create gateways and VPN servers, and enable you to build applications that span your local network and Google’s cloud
Large persistent disks support up to 10 terabytes per volume, which translates to 10X the industry standard

We’ve also completed ISO 27001:2005 international security certification for Compute Engine, Google App Engine, and Google Cloud Storage.

Google App Engine adds the PHP runtime

App Engine 1.8.0 is now available and includes a Limited Preview of the PHP runtime - your top requested feature. We’re bringing one of the most popular web programming languages to App Engine so that you can run open source apps like WordPress. It also offers deep integration with other parts of Cloud Platform including Google Cloud SQL and Cloud Storage.

We’ve also heard that we need to make building modularized applications on App Engine easier. We are introducing the ability to partition apps into components with separate scaling, deployments, versioning and performance settings.

Introducing Google Cloud Datastore

Google Cloud Datastore is a fully managed and schemaless solution for storing non-relational data. Based on the popular App Engine High Replication Datastore, Cloud Datastore is a standalone service that features automatic scalability and high availability while still providing powerful capabilities such as ACID transactions, SQL-like queries, indexes and more.

Over the last year we have continued our focus on feature enhancement and developer experience across App Engine, Compute Engine, Google BigQuery, Cloud Storage and Cloud SQL. We also introduced Google Cloud Endpoints and Google Cloud Console.

With these improvements, we have seen increased usage with over 3 million applications and over 300,000 unique developers using Cloud Platform in a given month. Our developers inspire us everyday, and we can’t wait to see what you build next.

Urs Hölzle is Senior Vice President of Technical Infrastructure and Google Fellow. As one of Google's first ten employees and its first VP of Engineering, he has shaped much of Google's development processes and infrastructure.

Posted by Scott Knaster, Editor

Introducing Google Play game services

2013-05-15T12:00:00.000-07:00

By Greg Hartrell, Lead Product Manager

We love to talk about games at Google. Especially the old ones, like Pac-man, Pitfall and Frogger. Since those classics, games have changed a lot. They’ve moved from that clunky box in your living room to the screen that you carry with you in your pocket wherever you go. They’re mobile, they’re social, and they’re an important part of Google Play.

Today, we’re launching Google Play game services, a core part of building a gaming platform for the next generation of games. These services help you make your games more social, with achievements, leaderboards, and multiplayer, as well as more powerful, storing game saves and settings in the cloud. They are available on Android, and many on iOS or any other connected device. By building on Google’s strengths in mobile and cloud services, you can focus on what you’re good at as game developers: creating great gaming experiences for your users.

With game services, you can incorporate:

Achievements that increase engagement and promote different styles of play.
Social and public leaderboards that seamlessly use Google+ circles to track high scores across friends and across the world.
Cloud saves that provide a simple and streamlined storage API to store game saves and settings. Now players never have to replay Level 1 again.
Real-time multiplayer for easy addition of cooperative or competitive game play on Android devices. Using Google+ Circles, a game can have up to 4 simultaneous friends or auto-matched players in a game session together with support for additional players coming soon.

Several great Android games are already using these new game services, including World of Goo, Super Stickman Golf 2, Beach Buggy Blitz, Kingdom Rush, Eternity Warriors 2, and Osmos.

And many more titles launch today as well:

Google Play game services are available today through an SDK for Android, and a native iOS SDK for iPhone and iPad games. Web and other platform developers will also find corresponding REST APIs, with libraries for JavaScript, Java, Python, Go, Dart, PHP, and more.

We’re excited to see what games will do with these new services and experiences, and this is only the beginning. Wait until you get to the boss battle... er.. Check out our developer site to get started: https://developers.google.com/games/.

Greg Hartrell is Lead Product Manager on Google Play game services, devoted to helping developers make incredible games through Google Play. In his spare time, he enjoys jumping from platform to platform, boss battles and matching objects in threes.

Posted by Scott Knaster, Editor

Data Sensing Lab at Google I/O 2013: Google Cloud Platform meets the Internet of Things

2013-05-13T10:00:00.000-07:00

By Michael Manoochehri, Developer Programs Engineer, Google Cloud Platform

Cross-posted with the Google Cloud Platform Blog

After last year's Google I/O conference, the Google Cloud Platform Developer Relations team started to think about how attendees experienced the event. We wanted to help attendees gain more insight about the conference space and the environment itself. Which developer Sandboxes were the busiest? Which were the loudest locations, and which were the best places to take a quick nap? We think about data problems all the time, and this looked like an interesting big data challenge that we could try to solve. So this year, we decided to try to answer our questions with a project that's a bit different, kind of futuristic, and maybe a little crazy.

Since we love open source hardware hacking as much as we love to share open source code, we decided to team up with the O'Reilly Data Sensing Lab to deploy hundreds of Arduino-based environmental sensors at Google I/O 2013. Using software built with the Google Cloud Platform, we'll be collecting and visualizing ambient data about the conference, such as temperature, humidity, air quality, in real time! Altogether, the sensors network will provide over 4,000 continuous data streams over a ZigBee mesh network managed by Device Cloud by Etherios.

In addition, our motes will be able to detect fluctuations in noise level, and some will be attached to footstep counters, to understand collective movement around the conference floor. Of course, since a key goal of Google I/O is to promote innovation in the open, the project's Cloud Platform code, the Arduino hardware designs, and even the data collected, will be open source and available online after the conference.

Google Cloud Platform, which provides the software backend for this project, has a variety of features for building applications that collect and process data from a large number of client devices - without having to spend time managing hardware or infrastructure. Google App Engine Datastore, along with Cloud Endpoints, provides a scalable front end API for collecting data from devices. Google Compute Engine is used to process and analyse data with software tools you may already be familiar with, such as R and Hadoop. Google BigQuery provides fast aggregate analysis of terabyte datasets. Finally, App Engine's web application framework is able to surface interactive visualizations to users.

Networked sensor technology is in the early stages of revolutionizing business logistics, city planning, and consumer products. We are looking forward to sharing the Data Sensing Lab with Google I/O attendees, because we want to show how using open hardware together with the Google Cloud Platform can make this technology accessible to anyone.

With the help of the Google Maps DevRel team, we'll be displaying visualizations of interesting trends on several screens around the conference. Members of the Data Sensing Lab will be on hand in the Google I/O Cloud Sandbox to show off prototypes and talk to attendees about open hardware development. Lead software developer Amy Unruh and Kim Cameron from the Cloud Platform Developer Relations team will talk about how we built the software involved in this project in a talk called "Behind the Data Sensing Lab". In case you aren't able to attend Google I/O 2013, this session will be available online after the conference. Learn more about the Google Cloud Platform on our site, and to dive in to building applications, check out our developer documentation.

Michael Manoochehri is a Developer Programs Engineer supporting the Google Cloud Platform. He is passionate about making cloud computing and data analysis universally accessible and useful.

Posted by Scott Knaster, Editor

Find the hidden patterns with YouTube’s new Analytics API

2013-05-11T11:55:00.001-07:00

By Ted Hamilton, YouTube Analytics

Cross-posted from the YouTube API Blog

Trying to figure out how YouTube’s one billion monthly users are interacting with your videos? Try the new YouTube Analytics API to get custom reports of the YouTube statistics you care about in a direct JSON or CSV response, perfect for dashboards and ad hoc reports.

The new API includes all the standard view and engagement metrics you would expect, including views, shares, and subscriber numbers. Compared to the previous Insight Data API, you also get:

Watch metrics: Track estimated minutes watched across channel, content owner, or video, and dive into the video details with average view time and average view percentage.
Earning performance metrics: Track estimated earnings (net revenue) from select advertising sources across your content.
Ad performance metrics: Break down video performance with monetized playbacks, ad impressions, gross revenue, and cost per impression reports.
Annotation metrics: Optimize overlays/annotations with click through and close rate metrics.

Client libraries and code samples
You’ll find client libraries for the languages you use most, with nine different languages available today. You can also make HTTP RESTful requests directly, and with our API Explorer, you can try out sample reports before writing any code.

Don’t write your code from scratch! Get started with code examples in Java, JavaScript, Python, and Ruby. If you want a step-by-step walkthrough of building a complete web application, have a look at our JavaScript exercise.

App examples
Check out some apps that are already using the API:

Next Big Sound provides analytics and insights for the music industry by tracking billions of social signals including YouTube. This enables record labels, artists, and band managers to make better decisions on everything from promotion strategies to tour locations.
vidIQ is an audience development suite that works with global brands to organically grow their views and subscribers. Their features include cross-platform social analytics, advanced comment management, SEO tools, social syndication and influencer identification.

Wizdeo’s WizTracker provides in-depth analysis of YouTube channels to help with cross promotion and video comparisons during their initial launch. Users get access to detailed analytics about views, subscriber engagement, traffic sources and demographics.
Vidyard is a video marketing platform. With powerful analytics, built-in marketing tools, and integration with key marketing automation platforms, Vidyard helps marketers drive results with video content.

Fullscreen is building a global network of YouTube channels with content creators and brands. Fullscreen provides a full suite of end-to-end YouTube tools and uses the new API for internal, business-intelligence tools.

Learn more
In addition to the documentation, check out our Analytics API playlist to make getting started even easier.

If your goal is to export all statistics for a large number of channels on a recurring basis for your data warehouse, look forward to using the upcoming scheduled reports feature of the API, expected to launch later this year.

To get more info on the YouTube APIs, subscribe to our YouTube for Developers channel and YouTubeDev on Google+.

Ted Hamilton is the Product Manager for YouTube Analytics based out of Zurich, Switzerland. Prior to Google, Ted was a consultant at Bain and Company in London. Ted has a Computer Science degree from Northwestern University and holds an MBA from MIT Sloan.

Posted by Scott Knaster, Editor

The results are in: Hardcode, the secure coding contest for App Engine

2013-05-10T15:40:00.002-07:00

By Eduardo Vela Nava, Security Team

This January, Google and SyScan announced a secure coding competition open to students from all over the world. While Google’s Summer of Code and Code-in encourage students to contribute to open source projects, Hardcode was a call for students who wanted to showcase their skills both in software development and security. Given the scope of today’s online threats, we think it’s incredibly important to practice secure coding habits early on. Hundreds of students from 25 countries and across five continents signed up to receive information about the competition, and over 100 teams participated.

During the preliminary online round, teams built applications on Google App Engine that were judged for both functionality and security. Five teams were then selected to participate in the final round at the SyScan 2013 security conference in Singapore, where they had to do the following: fix security bugs from the preliminary round, collaborate to develop an API standard to allow their applications to interoperate, implement the API, and finally, try to hack each other’s applications. To add to the challenge, many of the students balanced the competition with all of their school commitments.

We’re extremely impressed with the caliber of the contestants’ work. Everyone had a lot of fun, and we think these students have a bright future ahead of them. We are pleased to announce the final results of the 2013 Hardcode Competition:

1st Place: Team 0xC0DEBA5E
Vienna University of Technology, Austria (SGD $20,000)

Daniel Marth
Lukas Pfeifhofer
Benedikt Wedenik

2nd Place: Team Gridlock
Loyola School, Jamshedpur, India (SGD $15,000)

Aviral Dasgupta

3rd Place: Team CeciliaSec
University of California, Santa Barbara, California, USA (SGD $10,000)

Nathan Crandall
Dane Pitkin
Justin Rushing

Runner-up: Team AppDaptor
The Hong Kong Polytechnic University, Hong Kong (SGD $5,000)

Lau Chun Wai

Runner-up: Team DesiCoders
Birla Institute of Technology & Science, Pilani, India (SGD $5,000)

Yash Agarwal
Vishesh Singhal

Honorable Mention: Team Saviors of Middle Earth (withdrew due to school commitments)
Walt Whitman High School, Maryland, USA

Wes Kendrick
Marc Rosen
William Zhang

A big congratulations to this very talented group of students!

Eduardo Vela Nava is a Tech Lead for Google's WOOPS (Web or Other Product Security) team, helping teams build safer products.

Posted by Scott Knaster, Editor

Clarifying the deprecation policy for Google APIs and services

2013-05-10T12:13:00.001-07:00

By Adam Feldman, APIs Product Manager

We know that deprecation policies can be complex. But it shouldn’t be hard for you to determine which features of our APIs and services are covered by a deprecation policy and which ones aren’t. To date, we’ve often used the label “Experimental” to indicate that certain new versions, features, or functionality don’t have the deprecation policy. But we know you don’t want to hunt through documentation looking for what is “Experimental” and what isn’t.

So starting today, for each API or service that has the deprecation policy, we are creating an explicit list of what is covered by that policy. For instance, here’s what this list will look like for the Google Maps APIs:

We are not adding or subtracting anything, but only changing how we display this information to make it easier to locate and understand. This change will be fully rolled out in the coming weeks. Please refer to each API or service’s terms of service for more information. We hope this will make your life easier so you get back to your code sooner!

Adam Feldman is a Product Manager, focusing on all of Google's APIs and making sure Google provides the best possible platform to developers.

Posted by Scott Knaster, Editor

Building efficient apps and extensions with push messaging

2013-05-09T11:00:00.000-07:00

By Mark Scott, Product Manager, Chrome

Cross-posted from the Chromium Blog

Event pages keep apps and extensions efficient by allowing them to respond to a variety of events such as timers or navigation to a particular site, without having to remain running persistently. But what if you need to respond to something that occurs outside of Chrome, such as a news alert, a message sent to a user or a stock hitting a price threshold? Until now, you had to do this by repeatedly polling a server. This process consumed bandwidth and reduced the battery life of your users’ machines. For a more efficient solution, starting today you can use Google Cloud Messaging for Chrome (GCM) - across all channels of Chrome.

GCM will be familiar to developers who have used Google Cloud Messaging for Android. To send a message, all you need to do is:

Request a token (channel ID) via chrome.pushMessaging.getChannelId().
Pass the returned token to your server.
Whenever you need to send a message to your app or extension, post the message along with the token to the GCM server-side API.

Your message is then delivered in near real time to Chrome. This makes your event page wake up (if it’s not already running), and the message is delivered to your chrome.pushMessaging.onMessage listener.

To use GCM, your users must be signed into Chrome, as the service relies on an efficient push channel that’s only established for signed-in users. Messages are automatically delivered to all the devices where the user has signed in and installed your app/extension.

To add GCM to your app/extension, take a look at the overview of the service or start with some of the sample apps—and start pushing!

Mark Scott is a Product Manager on the Google Chrome team. He works with a team in Kirkland on features that make Chrome a great platform for building apps.

Posted by Scott Knaster, Editor

An easier way to save files to Google Drive

2013-05-09T09:00:00.000-07:00

By Nicolas Garnier, Developer Relations

We surf the web for a million different reasons – for everything from school research projects to time-killing memes. And when we find something relevant for us, whether that be our most recent pay stub or just an adorably awesome pic, we may want to save it for later reference or to share with friends in the future.

Starting today, Drive users can use the "Save to Drive" button to do exactly that. The “Save to Drive” button is an easier way to save files directly from a website. If you have your own website, you can improve the experience for your site visitors by adding the “Save to Drive” button to your page using two easy lines of HTML.

Saving an ebook to Google Drive from the O’Reilly website

Just try it out. Save this cute kitten’s image to Google Drive using the button below:

Credit: Krzysztof P. Jasiutowicz

Adding a Save to Drive button on your website is easy. You simply have to include the script and HTML tag below:

<script src="https://apis.google.com/js/plusone.js"></script>
<div class="g-savetodrive"
 data-filename="My Statement.pdf"
 data-sitename="My Company Name"
 data-src="/path/to/myfile.pdf">
</div>

You can also use the Save to Drive button’s JavaScript API, which allows programmatic and flexible control of the creation of Save to Drive buttons in your web pages.

The Save to Drive button works in the context of the user’s browser. This allows your users to save files that could require some form of HTTP authorization – such as a session cookie – without any special customization from you. In most cases, the Save to Drive button should be simple to integrate, plug-and-play!

Check out some companies that have already added Save to Drive buttons on their sites: Bigstock, Delta Dental, Fotolia, O'Reilly, Outbox, Ultimate Software, and Zen Payroll.

Saving a dental statement from Delta Dental

Saving your physical mail to Drive from your Outbox account

To learn more, have a look at our technical documentation, and if you have questions, don’t hesitate to post on Stack Overflow.

Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate for Google Drive and Google Apps. Nicolas is also the lead engineer for the OAuth 2.0 Playground.

Posted by Scott Knaster, Editor

We’re going live from Google I/O

2013-05-08T15:32:00.000-07:00

By Mike Winton, Director of Developer Relations

At Google I/O 2013, we will share the future of our platforms with you. Developers from all over the world are the key innovators of powerful, breakthrough technologies, and that’s why we challenged ourselves to make the Google I/O experience available to every developer, everywhere.

Watch Google I/O live
From the comfort of your own home, office, secret lair, or anywhere you have a reliable Internet connection, you can stream Google I/O May 15-16 live. Brought to you by Google Developers Live (GDL), the Google I/O homepage will become the GDL at I/O live streaming hub starting on May 15th at 9:00 AM PT (16:00 UTC). From this page, you can:

Stream 4 channels of technical content on your computer, tablet, or phone. You’ll feel like you’re right there in the keynote and session rooms, listening to product announcements straight from the source. Live streaming will run on developers.google.com/io from 9 AM PT (16:00 UTC) to 7 PM PT (2:00 UTC) on May 15 and 16.
Watch exclusive interviews with the Googlers behind the latest product announcements. This year, GDL will be on site, broadcasting one-on-one product deep dives, executive interviews, and Sandbox walkthroughs from the GDL stage.
Get the latest news in real-time. We’ll be posting official announcements during I/O. You’ll be able to see the feed on the Google I/O homepage, in the I/O mobile app (coming soon), and on +Google Developers.
Never miss a session. All Google I/O technical sessions will be recorded and posted to GDL and the Google Developers YouTube channel. Subscribe to our YouTube channel for archived session updates.

Live blog the keynote
Grab our live blogging gadget to add the keynote live stream to your own site or blog. Customize the gadget with your site or blog name, live blog alongside real-time Google announcements, and share a dynamic Google I/O experience with your readers. Have questions? For more info, check out our live blogging gadget FAQ.

Get together locally
Experience Google I/O with your local developer community by hosting or attending an I/O Extended event. If you’re hosting, register here and learn how to hold a totally epic event with our handy Organizer Guide. Otherwise, with over 400 sites in 90+ countries, chances are good that there is an I/O Extended event near you. Find an event now!

And before I/O, tune in to Google Developers Live programming to connect with Google engineers, prep for this year’s event, and browse our archived content. For official conference updates, add +Google Developers to your Circles, follow #io13 for big announcements, join the Google I/O community, and keep an eye on the Google I/O site.

Mike Winton founded and leads Google's global Developer Relations organization. He also enjoys spending time with his family and DJing electronic music.

Posted by Scott Knaster, Editor

Google API infrastructure outage incident report

2013-05-03T16:07:00.000-07:00

By the Google API Infrastructure Team

As we described in a previous post, earlier this week we experienced an outage in our API infrastructure. Today we’re providing an incident report that details the nature of the outage and our response.

The following is the incident report for the Google API infrastructure outage that occurred on April 30, 2013. We understand this service issue has impacted our valued developers and users, and we apologize to everyone who was affected.

Issue Summary

From 6:26 PM to 7:58 PM PT, requests to most Google APIs resulted in 500 error response messages. Google applications that rely on these APIs also returned errors or had reduced functionality. At its peak, the issue affected 100% of traffic to this API infrastructure. Users could continue to access certain APIs that run on separate infrastructures. The root cause of this outage was an invalid configuration change that exposed a bug in a widely used internal library.

Timeline (all times Pacific Time)

6:19 PM: Configuration push begins
6:26 PM: Outage begins
6:26 PM: Pagers alerted teams
6:54 PM: Failed configuration change rollback
7:15 PM: Successful configuration change rollback
7:19 PM: Server restarts begin
7:58 PM: 100% of traffic back online

Root Cause

At 6:19 PM PT, a configuration change was inadvertently released to our production environment without first being released to the testing enviroment. The change specified an invalid address for the authentication servers in production. This exposed a bug in the authentication libraries which caused them to block permanently while attempting to resolve the invalid address to physical services. In addition, the internal monitoring systems permanently blocked on this call to the authentication library. The combination of the bug and configuration error quickly caused all of the serving threads to be consumed. Traffic was permanently queued waiting for a serving thread to become available. The servers began repeatedly hanging and restarting as they attempted to recover and at 6:26 PM PT, the service outage began.

Resolution and recovery

At 6:26 PM PT, the monitoring systems alerted our engineers who investigated and quickly escalated the issue. By 6:40 PM, the incident response team identified that the monitoring system was exacerbating the problem caused by this bug.

At 6:54 PM, we attempted to rollback the problematic configuration change. This rollback failed due to complexity in the configuration system which caused our security checks to reject the rollback. These problems were addressed and we successfully rolled back at 7:15 PM.

Some jobs started to slowly recover, and we determined that the overall recovery would be faster by a restart of all of the API infrastructure servers globally. To help with the recovery, we turned off some of our monitoring systems which were triggering the bug. As a result, we decided to restart servers gradually (at 7:19 PM), to avoid possible cascading failures from a wide scale restart. By 7:49 PM, 25% of traffic was restored and 100% of traffic was routed to the API infrastructure at 7:58 PM.

Corrective and Preventative Measures

In the last two days, we’ve conducted an internal review and analysis of the outage. The following are actions we are taking to address the underlying causes of the issue and to help prevent recurrence and improve response times:

Disable the current configuration release mechanism until safer measures are implemented. (Completed.)
Change rollback process to be quicker and more robust.
Fix the underlying authentication libraries and monitoring to correctly timeout/interrupt on errors.
Programmatically enforce staged rollouts of all configuration changes.
Improve process for auditing all high-risk configuration options.
Add a faster rollback mechanism and improve the traffic ramp-up process, so any future problems of this type can be corrected quickly.
Develop better mechanism for quickly delivering status notifications during incidents.

Google is committed to continually and quickly improving our technology and operational processes to prevent outages. We appreciate your patience and again apologize for the impact to you, your users, and your organization. We thank you for your business and continued support.

Sincerely,

The Google API Infrastructure Team

Posted by Scott Knaster, Editor