Saturday, March 26, 2011

[Gd] How Google Tests Software - Part Five

| More

Google Testing Blog: How Google Tests Software - Part Five

By James Whittaker

Instead of distinguishing between code, integration and system testing, Google uses the language of small, medium and large tests emphasizing scope over form. Small tests cover small amounts of code and so on. Each of the three engineering roles may execute any of these types of tests and they may be performed as automated or manual tests.

Small Tests are mostly (but not always) automated and exercise the code within a single function or module. They are most likely written by a SWE or an SET and may require mocks and faked environments to run but TEs often pick these tests up when they are trying to diagnose a particular failure. For small tests the focus is on typical functional issues such as data corruption, error conditions and off by one errors. The question a small test attempts to answer is does this code do what it is supposed to do?

Medium Tests can be automated or manual and involve two or more features and specifically cover the interaction between those features. I've heard any number of SETs describe this as "testing a function and its nearest neighbors." SETs drive the development of these tests early in the product cycle as individual features are completed and SWEs are heavily involved in writing, debugging and maintaining the actual tests. If a test fails or breaks, the developer takes care of it autonomously. Later in the development cycle TEs may perform medium tests either manually (in the event the test is difficult or prohibitively expensive to automate) or with automation. The question a medium test attempts to answer is does a set of near neighbor functions interoperate with each other the way they are supposed to?

Large Tests cover three or more (usually more) features and represent real user scenarios to the extent possible. There is some concern with overall integration of the features but large tests tend to be more results driven, i.e., did the software do what the user expects? All three roles are involved in writing large tests and everything from automation to exploratory testing can be the vehicle to accomplish accomplish it. The question a large test attempts to answer is does the product operate the way a user would expect?

The actual language of small, medium and large isn’t important. Call them whatever you want. The important thing is that Google testers share a common language to talk about what is getting tested and how those tests are scoped. When some enterprising testers began talking about a fourth class they dubbed enormous every other tester in the company could imagine a system-wide test covering nearly every feature and that ran for a very long time. No additional explanation was necessary.

The primary driver of what gets tested and how much is a very dynamic process and varies wildly from product to product. Google prefers to release often and leans toward getting a product out to users so we can get feedback and iterate. The general idea is that if we have developed some product or a new feature of an existing product we want to get it out to users as early as possible so they may benefit from it. This requires that we involve users and external developers early in the process so we have a good handle on whether what we are delivering is hitting the mark.

Finally, the mix between automated and manual testing definitely favors the former for all three sizes of tests. If it can be automated and the problem doesn’t require human cleverness and intuition, then it should be automated. Only those problems, in any of the above categories, which specifically require human judgment, such as the beauty of a user interface or whether exposing some piece of data constitutes a privacy concern, should remain in the realm of manual testing.

Having said that, it is important to note that Google performs a great deal of manual testing, both scripted and exploratory, but even this testing is done under the watchful eye of automation. Industry leading recording technology converts manual tests to automated tests to be re-executed build after build to ensure minimal regressions and to keep manual testers always focusing on new issues. We also automate the submission of bug reports and the routing of manual testing tasks. For example, if an automated test breaks, the system determines the last code change that is the most likely culprit, sends email to its authors and files a bug. The ongoing effort to automate to within the “last inch of the human mind” is currently the design spec for the next generation of test engineering tools Google is building.

Those tools will be highlighted in future posts. However, my next target is going to revolve around The Life of an SET. I hope you keep reading.

[Gd] Innovation at Google

| More

Google Testing Blog: Innovation at Google

by Patrick Copeland

Google Innovation and the Pretotyping Manifesto*: I had the pleasure of keynoting at the sold out San Francisco and London QCon conferences. Combined about 1300 people attended. They recently published the video and I'm including it here with some reviews. Enjoy!

The slides and video.

Reviews and commentary from attendees:

*not your typical testing post, but once you see the talk you'll understand why we think testing and innovation go hand in hand.

Thursday, March 24, 2011

[Gd] In-App Billing on Android Market: Ready for Testing

| More

Android Developers Blog: In-App Billing on Android Market: Ready for Testing

[This post is by Eric Chu, Android Developer Ecosystem. —Dirk Dougherty]

Back in January we announced our plan to introduce Android Market In-app Billing this quarter. We're pleased to let you know that we will be launching In-app Billing next week.

In preparation for the launch, we are opening up Android Market for upload and end-to-end testing of your apps that use In-app Billing. You can now upload your apps to the Developer Console, create a catalog of in-app products, and set prices for them. You can then set up accounts to test in-app purchases. During these test transactions, the In-app Billing service interacts with your app exactly as it will for actual users and live transactions.

Note that although you can upload apps during this test development phase, you won’t be able to actually publish the apps to users until the full launch of the service next week.

To get you started, we’ve updated the developer documentation with information about how to set up product lists and test your in-app products. Also, it is absolutely essential that you review the security guidelines to make sure your billing implementation is secure.

We encourage you start uploading and testing your apps right away.


[Gd] Memory Analysis for Android Applications

| More

Android Developers Blog: Memory Analysis for Android Applications

[This post is by Patrick Dubroy, an Android engineer who writes about programming, usability, and interaction on his personal blog. — Tim Bray]

The Dalvik runtime may be garbage-collected, but that doesn't mean you can ignore memory management. You should be especially mindful of memory usage on mobile devices, where memory is more constrained. In this article, we're going to take a look at some of the memory profiling tools in the Android SDK that can help you trim your application's memory usage.

Some memory usage problems are obvious. For example, if your app leaks memory every time the user touches the screen, it will probably trigger an OutOfMemoryError eventually and crash your app. Other problems are more subtle, and may just degrade the performance of both your app (as garbage collections are more frequent and take longer) and the entire system.

Tools of the trade

The Android SDK provides two main ways of profiling the memory usage of an app: the Allocation Tracker tab in DDMS, and heap dumps. The Allocation Tracker is useful when you want to get a sense of what kinds of allocation are happening over a given time period, but it doesn't give you any information about the overall state of your application's heap. For more information about the Allocation Tracker, see the article on Tracking Memory Allocations. The rest of this article will focus on heap dumps, which are a more powerful memory analysis tool.

A heap dump is a snapshot of an application's heap, which is stored in a binary format called HPROF. Dalvik uses a format that is similar, but not identical, to the HPROF tool in Java. There are a few ways to generate a heap dump of a running Android app. One way is to use the Dump HPROF file button in DDMS. If you need to be more precise about when the dump is created, you can also create a heap dump programmatically by using the android.os.Debug.dumpHprofData() function.

To analyze a heap dump, you can use a standard tool like jhat or the Eclipse Memory Analyzer (MAT). However, first you'll need to convert the .hprof file from the Dalvik format to the J2SE HPROF format. You can do this using the hprof-conv tool provided in the Android SDK. For example:

hprof-conv dump.hprof converted-dump.hprof

Example: Debugging a memory leak

In the Dalvik runtime, the programmer doesn't explicitly allocate and free memory, so you can't really leak memory like you can in languages like C and C++. A "memory leak" in your code is when you keep a reference to an object that is no longer needed. Sometimes a single reference can prevent a large set of objects from being garbage collected.

Let's walk through an example using the Honeycomb Gallery sample app from the Android SDK. It's a simple photo gallery application that demonstrates how to use some of the new Honeycomb APIs. (To build and download the sample code, see the instructions.) We're going to deliberately add a memory leak to this app in order to demonstrate how it could be debugged.

Imagine that we want to modify this app to pull images from the network. In order to make it more responsive, we might decide to implement a cache which holds recently-viewed images. We can do that by making a few small changes to At the top of the class, let's add a new static variable:

private static HashMap<String,Bitmap> sBitmapCache = new HashMap<String,Bitmap>();

This is where we'll cache the Bitmaps that we load. Now we can change the updateContentAndRecycleBitmap() method to check the cache before loading, and to add Bitmaps to the cache after they're loaded.

void updateContentAndRecycleBitmap(int category, int position) {
if (mCurrentActionMode != null) {

// Get the bitmap that needs to be drawn and update the ImageView.

// Check if the Bitmap is already in the cache
String bitmapId = "" + category + "." + position;
mBitmap = sBitmapCache.get(bitmapId);

if (mBitmap == null) {
// It's not in the cache, so load the Bitmap and add it to the cache.
// DANGER! We add items to this cache without ever removing any.
mBitmap = Directory.getCategory(category).getEntry(position)
sBitmapCache.put(bitmapId, mBitmap);
((ImageView) getView().findViewById(;

I've deliberately introduced a memory leak here: we add Bitmaps to the cache without ever removing them. In a real app, we'd probably want to limit the size of the cache in some way.

Examining heap usage in DDMS

The Dalvik Debug Monitor Server (DDMS) is one of the primary Android debugging tools. DDMS is part of the ADT Eclipse plug-in, and a standalone version can also be found in the tools/ directory of the Android SDK. For more information on DDMS, see Using DDMS.

Let's use DDMS to examine the heap usage of this app. You can start up DDMS in one of two ways:

  • from Eclipse: click Window > Open Perspective > Other... > DDMS
  • or from the command line: run ddms (or ./ddms on Mac/Linux) in the tools/ directory

Select the process in the left pane, and then click the Show heap updates button in the toolbar. Then, switch to the VM Heap tab in DDMS. It shows some basic stats about our heap memory usage, updated after every GC. To see the first update, click the Cause GC button.

We can see that our live set (the Allocated column) is a little over 8MB. Now flip through the photos, and watch that number go up. Since there are only 13 photos in this app, the amount of memory we leak is bounded. In some ways, this is the worst kind of leak to have, because we never get an OutOfMemoryError indicating that we are leaking.

Creating a heap dump

Let's use a heap dump to track down the problem. Click the Dump HPROF file button in the DDMS toolbar, choose where you want to save the file, and then run hprof-conv on it. In this example, I'll be using the standalone version of MAT (version 1.0.1), available from the MAT download site.

If you're running ADT (which includes a plug-in version of DDMS) and have MAT installed in Eclipse as well, clicking the “dump HPROF” button will automatically do the conversion (using hprof-conv) and open the converted hprof file into Eclipse (which will be opened by MAT).

Analyzing heap dumps using MAT

Start up MAT and load the converted HPROF file we just created. MAT is a powerful tool, and it's beyond the scope of this article to explain all it's features, so I'm just going to show you one way you can use it to detect a leak: the Histogram view. The Histogram view shows a list of classes sortable by the number of instances, the shallow heap (total amount of memory used by all instances), or the retained heap (total amount of memory kept alive by all instances, including other objects that they have references to).

If we sort by shallow heap, we can see that instances of byte[] are at the top. As of Android 3.0 (Honeycomb), the pixel data for Bitmap objects is stored in byte arrays (previously it was not stored in the Dalvik heap), and based on the size of these objects, it's a safe bet that they are the backing memory for our leaked bitmaps.

Right-click on the byte[] class and select List Objects > with incoming references. This produces a list of all byte arrays in the heap, which we can sort based on Shallow Heap usage.

Pick one of the big objects, and drill down on it. This will show you the path from the root set to the object -- the chain of references that keeps this object alive. Lo and behold, there's our bitmap cache!

MAT can't tell us for sure that this is a leak, because it doesn't know whether these objects are needed or not -- only the programmer can do that. In this case, the cache is using a large amount of memory relative to the rest of the application, so we might consider limiting the size of the cache.

Comparing heap dumps with MAT

When debugging memory leaks, sometimes it's useful to compare the heap state at two different points in time. To do this, you'll need to create two separate HPROF files (don't forget to convert them using hprof-conv).

Here's how you can compare two heap dumps in MAT (it's a little complicated):

  1. Open the first HPROF file (using File > Open Heap Dump).
  2. Open the Histogram view.
  3. In the Navigation History view (use Window > Navigation History if it's not visible), right click on histogram and select Add to Compare Basket.
  4. Open the second HPROF file and repeat steps 2 and 3.
  5. Switch to the Compare Basket view, and click Compare the Results (the red "!" icon in the top right corner of the view).


In this article, I've shown how the Allocation Tracker and heap dumps can give you get a better sense of your application's memory usage. I also showed how The Eclipse Memory Analyzer (MAT) can help you track down memory leaks in your app. MAT is a powerful tool, and I've only scratched the surface of what you can do with it. If you'd like to learn more, I recommend reading some of these articles:


[Gd] Chrome OS Beta Channel Update

| More

Google Chrome Releases: Chrome OS Beta Channel Update

The Chrome OS Beta channel has been updated to the latest R10 release including Chrome update (10.0.648.151) and trackpad dead zone width adjustment.

Full details of the Chrome 10 beta update is available in the blogpost. If you find new issues, please let us know by visiting our help site or filing a bug.

Josafat Garcia
Google Chrome


[Gd] Chrome Beta Release

| More

Google Chrome Releases: Chrome Beta Release

The Chrome team is happy to announce the arrival of Chrome 11.0.696.16 to the Beta channel for Windows, Mac, and Linux.

Chrome 11 contains some really great improvements including:
  • HTML5 speech input API
  • GPU-accelerated 3D CSS
  • The brand new shiny Chrome icon

More on what's new at the Official Chrome Blog.

You can find full details about the changes that are in Chrome 11 in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Karen Grunberg
Google Chrome

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 11.0.696.16 for Macintosh, Windows, Linux and Chrome Frame platforms

The following bugs were fixed
  • clicking on the labels of checkboxes / radio buttons closes content settings dialog box (Issue 76115).
  • Unlock Keyring makes chrome unusable (Issue 72499 ).
  • Sample extension for chrome.experimental.proxy API (Issue 62700 ).
  • Several known crashes (Issue 76401 and Issue 75264 ).

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Karen Grunberg
Google Chrome

[Gd] Discover v201101: Generic selectors

| More

AdWords API Blog: Discover v201101: Generic selectors

AdWords API v201101 changes the way you retrieve data using the get() method of most services. This blog post discusses the new feature in detail and highlights the changes you need to make in your code to migrate to generic selectors.


Prior to v201101 of AdWords API, every service had its own selector to retrieve data using the get() method. For instance, to retrieve all active ad group criteria in an ad group, you would write your code as
// OLD CODE - v201008.
// Create selector.
AdGroupCriterionSelector selector = new AdGroupCriterionSelector();
selector.userStatuses = new UserStatus[] {UserStatus.ACTIVE};

// Create id filter.
AdGroupCriterionIdFilter idFilter = new AdGroupCriterionIdFilter();
idFilter.adGroupId = adGroupId;

selector.idFilters = new AdGroupCriterionIdFilter[] {idFilter};

// Get all ad group criteria.
AdGroupCriterionPage adGroupCriterionPage =
While simple to use, since each service had its own selector class, you needed to know about selectors of each service with which you worked. Also, since filtering options were specified as member fields of the selector, adding support for new filtering involved changing the selector definition in the service. and hence could be done properly only across versions.

On the other hand, the selector model used by reports is much more flexible - you can specify a list of fields, provide any number of filtering conditions on any Filterable field using predicates, use multiple operators (unlike the implicit EQUALS operator in the code above) and so on. Also, since field names aren’t tied to a SOAP schema, it is easy to add new selectable and filterable fields. Additionally, the code you need to write to generate and download any report remains the same. In v201101, we decided to take this design and apply it across all services.

Using v201101 of AdWords API, you can retrieve all active ad group criterion in an ad group as follows:
// NEW CODE - v201101.
// Create a selector.
Selector selector = new Selector();
selector.fields = new string[] {"Id", "AdGroupId", "KeywordText", "Status"};

// Set filter conditions.
Predicate adGroupPredicate = new Predicate();
adGroupPredicate.field = "AdGroupId";
adGroupPredicate.@operator = PredicateOperator.EQUALS;
adGroupPredicate.values = new string[] {adGroupId.ToString()};

Predicate statusPredicate = new Predicate();
statusPredicate.field = "Status";
statusPredicate.@operator = PredicateOperator.EQUALS;
statusPredicate.values = new string[] {UserStatus.ACTIVE.ToString()};

selector.predicates = new Predicate[] {adGroupPredicate, statusPredicate};

// Get all ad group criteria.
AdGroupCriterionPage adGroupCriterionPage =
Understanding selector properties

The main properties of the selector are:

Fields: When using generic selectors to retrieve an object, the server will not return every field of the object by default; it will return only the requested set of fields. Other fields in the object will be set as undefined/null depending on the programming language you use. You can use the Fields property to specify the list of fields to be returned. You can use any Selectable field from the entity here. For example, when using CampaignService, you can use any Selectable field from Campaign. is marked as a Selectable field, and its selector field name is specified as “Name”, so you can use that as an entry for Fields.

Note that when an object has a field that is a reference to another object, then that property may not be marked as Selectable. In such cases, its sub fields will be marked as Selectable. For example, Campaign.budget is a property of type Budget, so Campaign.budget is not a Selectable field. To retrieve a campaign’s budget fields, you have to request Selectable fields from the Budget object.

Predicates: You can use predicates to filter the returned data by field values. You can use any Filterable field from the entity in a predicate. You can also use various operators to specify the filtering condition. Also, when using multiple predicates in a single selector, the predicates are ANDed to evaluate the effective filter condition.

Each service provides a set of service-specific fields and generic selector fields that can be used with Predicates. E.g. you can use CampaignId as a predicate field with AdGroupAdService, even though CampaignId is not a member of AdGroupAd. For the list of all the generic selector fields, you can refer to the selector migration guide.

DateRange: You can provide an optional DateRange to control the date range for which the data is retrieved. Specifying a date range only affects the stats returned by the server (if applicable), not the actual entities being returned by the server. The date format for min and max fields have the format yyyymmdd. The date range should be in the range [19700101, 20380101].

Ordering: You can use the ordering field to specify the fields on which you want to sort the data (ascending or descending). The order in which you specify the OrderBy objects in the ordering field is significant; the first element specifies the primary sort order, the second element specifies the secondary sort order and so on.

Paging: You can use the paging field to specify the position from which to start returning results and the number of results to return per page.

Migrating from service-specific selectors to generic selectors

Service-specific selectors (e.g. CampaignSelector) aren’t supported from v201101 onwards, so you will have to modify your code to use generic selectors when migrating to v201101 of AdWords API. You can refer to the selector migration guide to get the field mapping for each service-specific selector. Also note that a few services do not use generic selectors yet. This will happen in a future version of AdWords API.

We have added support for generic selectors in all of our client libraries, so please take advantage of this new feature and share your feedback with us on the forum.

  --Anash P. Oommen, AdWords API Team


Tuesday, March 22, 2011

[Gd] Page Speed for Chrome, and in 40 languages!

| More

The official Google Code blog: Page Speed for Chrome, and in 40 languages!

(Cross-posted from the Google Webmaster Central Blog.)

Today we’re launching the most requested feature for Page Speed, Page Speed for Chrome. Now Google Chrome users can get Page Speed performance suggestions to make their sites faster, right inside the Chrome browser. We would like to thank all our users for your great feedback and support since we launched. We’re humbled that 1.4 M unique users are using the Page Speed extension and finding it useful to help with their web performance diagnosis.

Google Chrome support has always been high on our priority list but we wanted to get it right. It was critical that the same engine that powers the Page Speed Add-On for Firefox be used here as well. So we first built the Page Speed SDK, which we then integrated into the Chrome extension.

Page Speed for Chrome retains the same core features as the Firefox add-on. In addition, there are two major improvements appearing in this version first. We’ve improved scoring and suggestion ordering to help web developers focus on higher-potential optimizations first. Plus, because making the web faster is a global initiative, Page Speed now supports displaying localized rule results in 40 languages! These improvements are part of the Page Speed SDK, so they will also appear in the next release of our Firefox add-on as well.

If your site serves different content based on the browser’s user agent, you now have a good method for page performance analysis as seen by different browsers, with Page Speed coverage for Firefox and Chrome through the extensions, and Internet Explorer via, which integrates the Page Speed SDK.

We’d love to hear from you, as always. Please try Page Speed for Chrome, and give us feedback on our mailing list about additional functionality you’d like to see. Stay tuned for updates to Page Speed for Chrome that take advantage of exciting new technologies such as Native Client.

By Matthew Steele and Richard Rabbat, Page Speed Team

[Gd] Enomaly chooses Google App Engine for

| More

Google App Engine Blog: Enomaly chooses Google App Engine for

is the realization of a dream originating more than 7 years ago when we first started Enomaly. SpotCloud was born from a desire to change the way cloud computing is bought and sold for the better by overcoming the inefficiencies (including large capital commitments and low utilization rates) that beset the traditional models. SpotCloud is the first multi-supplier, multi-buyer model of cloud computing, all built on Google App Engine.

SpotCloud is the first marketplace where service providers can sell their unutilized or under-utilized IaaS cloud services, and where buyers can shop competitively for these services on the basis of quality, price, and geography across a federated global pool of capacity with a single, consistent set of access and management mechanisms.

SpotCloud provides its users with the following main services:

  • VM image repository & VM image provisioning services
  • REST API for cloud service users, with management and monitoring functionality
  • REST API for cloud service providers
  • REST client to access service provider API endpoints
  • Single-point unified access & authentication to all underlying cloud services
  • Federated management portal, providing management & monitoring over all connected cloud services
  • Cloud service quality, reliability, and performance measurement instrumentation and rating
  • Runtime management service (to enable time-limited instances)
  • Billing, payment, and settlement services

Why Google App Engine?

We realized early on that a traditional data center infrastructure -- even one built on our own ECP technology -- was not a fit for a platform which needs to be global from day one. We also had a strong preference for Python, given that large parts of our existing IaaS software stack is built using it. Cost was also very important: SpotCloud needs to manage potentially very large Virtual Machines, delivering them to a globally distributed group of providers and managing them in near-real time across this extended footprint. With Google App Engine we have the power, flexibility, and global breadth of the Google infrastructure at our disposal. This was a key selling feature for us. Also the cost was practically impossible to beat.

How App Engine powers SpotCloud

As you can see from the list of services provided by SpotCloud, most of our application actually runs in the background. This is made possible by App Engine task queues and cron jobs. We need to poll for stage changes across hundreds (soon thousands) of service providers -- we need a near-real-time view of instance states, available virtual hardware profiles, cloud utilization data, etc. These things are triggered by cron schedules. Each of these tasks goes into a queue. We're able to execute these tasks to allow us to keep our view of service provider resources up to date without interrupting the front-end UI and API workflows.

Another challenge is executing tasks at a particular point in the future. Running instances deployed out to a provider through SpotCloud may expire, and renewal may or may not be allowed depending on the seller’s settings. So we need a way to terminate them if their time is up. We can use the task queue API to execute this in the future. We're able to ensure our data is consistent by adding tasks to the queue in a transactional way.

Buyers upload the appliances they want to provision to the market. So we obviously have a big storage requirement. App Engine’s data store allows us to do this in a highly performant, cost-effective manner. SpotCloud can then distribute these appliances out to providers on demand. We're able to do this because of the low-cost bandwidth Google provides.

We're big fans of Django at Enomaly, and we use it in SpotCloud. We've been able to loosely couple Django with the App Engine data store, along with other App Engine components and services like urlfetch. This means that we're not "locked-in" with App Engine. The App Engine API is structured in such a way that we're able to extend any web framework we want with App Engine components that help us scale.

SpotCloud Success

Since announcing the SpotCloud private beta at the end of last year, we’ve been overwhelmed by the amount of interest we’ve gathered, and have had large numbers of service providers from all over the globe join our beta. We now have more than 10,000 servers from 40+ countries represented in the marketplace.

Since we opened the marketplace to buyers and sellers early in 2011, the market has been off to a roaring start -- as noted by The Economist, ComputerWorld, and many others. Google App Engine has performed up to our (high!) expectations, serving an ever-increasing transaction rate in the market without a hiccup. We’re looking forward, as the market ramps up even further, to seeing if we can make App Engine break a sweat! Sign up today as a cloud capacity buyer or seller at

Posted by Reuven Cohen, Founder & Chief Technologist, Enomaly Inc.

Monday, March 21, 2011

[Gd] Google I/O extends virtually around the world

| More

The official Google Code blog: Google I/O extends virtually around the world

In celebration of Google I/O 2011, many Google offices around the world, as well as GTUG partners and Student Ambassadors, are hosting free viewing parties of Google I/O sessions. If you can't attend Google I/O in person, these events are a way to connect with other talented developers and watch live feeds of the conference.

Part viewing party and part community building, Google I/O Extended events are free and worldwide, focused on bringing the developer community together to live-stream the keynote and other major sessions of Google I/O. Each location’s event will be a little different, so check the registration page of the closest location to see what they have planned. With limited space, registration is required. Learn more and find an I/O Extended event near you on the I/O Extended site. These events are being organized by local developer community leaders and university ambassadors, so please reach out to them specifically if you have any questions about the details.

Here are just a few of the locations hosting an I/O Extended event:

North America
South America and Central America

See more locations on the map and register for a Google I/O Extended event in your area.

We look forward to having you join us for Google I/O Extended!

By Amy Walgenbach, Google I/O Team

Sunday, March 20, 2011

[Gd] Best Practices for User Authentication

| More

YouTube API Blog: Best Practices for User Authentication

(Cross-posted from the Google Code blog.)

By now, many of you have seen our recent announcement regarding 2-step verification for Google Accounts. It’s an optional way of protecting your Google Account from unauthorized access, providing a level of security beyond that of a password alone. The initial announcement did not detail the impact enabling 2-step verification has on programmatic account access from code written against one of Google’s official APIs. We want to go into some more detail regarding the implications of 2-step verification on various authentication (and authorization) techniques, and offer best practices that you as a developer should follow.

There are three forms of authentication supported by almost all of Google’s APIs. AuthSub andOAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.

If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.

ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an HTTP 403 error response from our servers with the following in error included in the response body:


There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.

The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.

While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.

By Jeffrey Posnick, Google Developer Relations

[Gd] AdWords Downtime: March 20, 3am-7am PT

| More

AdWords API Blog: AdWords Downtime: March 20, 3am-7am PT

We'll be performing routine system maintenance on Sunday, March 20 from approximately 3:00am to 7:00am PT. You won't be able to access AdWords or the API during this time frame, but your ads will continue to run as normal.

- Eric Koleda, AdWords API Team