Friday, October 26, 2012

[Gd] About today's App Engine outage

| More

Google App Engine Blog: About today's App Engine outage

This morning we failed to live up to our promise, and Google App Engine applications experienced increased latencies and time-out errors.

We know you rely on App Engine to create applications that are easy to develop and manage without having to worry about downtime. App Engine is not supposed to go down, and our engineers work diligently to ensure that it doesn’t. However, from approximately 7:30 to 11:30 AM US/Pacific, about 50% of requests to App Engine applications failed.

Here’s what happened, from what we know today:


  • 4:00 am - Load begins increasing on traffic routers in one of the App Engine datacenters.

  • 6:10 am - The load on traffic routers in the affected datacenter passes our paging threshold.

  • 6:30 am - We begin a global restart of the traffic routers to address the load in the affected datacenter.

  • 7:30 am - The global restart plus additional load unexpectedly reduces the count of healthy traffic routers below the minimum required for reliable operation. This causes overload in the remaining traffic routers, spreading to all App Engine datacenters. Applications begin consistently experiencing elevated error rates and latencies.

  • 8:28 am - is updated with notification that we are aware of the incident and working to repair it.

  • 11:10 am - We determine that App Engine’s traffic routers are trapped in a cascading failure, and that we have no option other than to perform a full restart with gradual traffic ramp-up to return to service.

  • 11:45 am - Traffic ramp-up completes, and App Engine returns to normal operation.

In response to this incident, we have increased our traffic routing capacity and adjusted our configuration to reduce the possibility of another cascading failure. Multiple projects have been in progress to allow us to further scale our traffic routers, reducing the likelihood of cascading failures in the future.  

During this incident, no application data was lost and application behavior was restored without any manual intervention by developers. There is no need to make any code or configuration changes to your applications.

We will proactively issue credits to all paid applications for ten percent of their usage for the month of October to cover any SLA violations. This will appear on applications’ November bills. There is no need to take any action to receive this credit.

We apologize for this outage, and in particular for its duration and severity. Since launching the High Replication Datastore in January 2011, App Engine has not experienced a widespread system outage.  We know that hundreds of thousands of developers rely on App Engine to provide a stable, scalable infrastructure for their applications, and we will continue to improve our systems and processes to live up to this expectation.

- Posted by Peter S. Magnusson, Engineering Director, Google App Engine

[Gd] Why Are There So Many C++ Testing Frameworks?

| More

Google Testing Blog: Why Are There So Many C++ Testing Frameworks?

By Zhanyong Wan - Software Engineer

These days, it seems that everyone is rolling their own C++ testing framework, if they haven't done so already. Wikipedia has a partial list of such frameworks. This is interesting because many OOP languages have only one or two major frameworks. For example, most Java people seem happy with either JUnit or TestNG. Are C++ programmers the do-it-yourself kind?

When we started working on Google Test (Google’s C++ testing framework), and especially after we open-sourced it, people began asking us why we were doing it. The short answer is that we couldn’t find an existing C++ testing framework that satisfied all our needs. This doesn't mean that these frameworks were all poorly designed or implemented. Rather, many of them had great ideas and tricks that we learned from. However, Google had a huge number of C++ projects that got compiled on various operating systems (Linux, Windows, Mac OS X, and later Android, among others) with different compilers and all kinds of compiler flags, and we needed a framework that worked well in all these environments and ccould handle many different types and sizes of projects.

Unlike Java, which has the famous slogan "Write once, run anywhere," C++ code is being written in a much more diverse environment. Due to the complexity of the language and the need to do low-level tasks, compatibility between different C++ compilers and even different versions of the same compiler is poor. There is a C++ standard, but it's not well supported by compiler vendors. For many tasks you have to rely on unportable extensions or platform-specific functionality. This makes it hard to write a reasonably complex system that can be built using many different compilers and works on many platforms.

To make things more complicated, most C++ compilers allow you to turn off some standard language features in return for better performance. Don't like using exceptions? You can turn it off. Think dynamic cast is bad? You can disable Run-Time Type Identification, the feature behind dynamic cast and run-time access to type information. If you do any of these, however, code using these features will fail to compile. Many testing frameworks rely on exceptions. They are automatically out of the question for us since we turn off exceptions in many projects (in case you are curious, Google Test doesn’t require exceptions or run-time type identification by default; when these language features are turned on, Google Test will try to take advantage of them and provide you with more utilities, like the exception assertions.).

Why not just write a portable framework, then? Indeed, that's a top design goal for Google Test. And authors of some other frameworks have tried this too. However, this comes with a cost. Cross-platform C++ development requires much more effort: you need to test your code with different operating systems, different compilers, different versions of them, and different compiler flags (combine these factors and the task soon gets daunting); some platforms may not let you do certain things and you have to find a workaround there and guard the code with conditional compilation; different versions of compilers have different bugs and you may have to revise your code to bypass them all; etc. In the end, it's hard unless you are happy with a bare-bone system.

So, I think a major reason that we have many C++ testing frameworks is that C++ is different in different environments, making it hard to write portable C++ code. John's framework may not suit Bill's environment, even if it solves John's problems perfectly.

Another reason is that some limitations of C++ make it impossible to implement certain features really well, and different people chose different ways to workaround the limitations. One notable example is that C++ is a statically-typed language and doesn't support reflection. Most Java testing frameworks use reflection to automatically discover tests you've written such that you don't have to register them one-by-one. This is a good thing as manually registering tests is tedious and you can easily write a test and forget to register it. Since C++ has no reflection, we have to do it differently. Unfortunately there is no single best option. Some frameworks require you to register tests by hand, some use scripts to parse your source code to discover tests, and some use macros to automate the registration. We prefer the last approach and think it works for most people, but some disagree. Also, there are different ways to devise the macros and they involve different trade-offs, so the result is not clear cut.

Let’s see some actual code to understand how Google Test solves the test registration problem. The simplest way to add a test is to use the TEST macro (what else would we name it?):

TEST(Subject, HasCertainProperty) {
  … testing code goes here …

This defines a test method whose purpose is to verify that the given subject has the given property. The macro automatically registers the test with Google Test such that it will be run when the test program (which may contain many such TEST definitions) is executed.

Here’s a more concrete example that verifies a Factorial() function works as expected for positive arguments:

TEST(FactorialTest, HandlesPositiveInput) {
  EXPECT_EQ(1, Factorial(1));
  EXPECT_EQ(2, Factorial(2));
  EXPECT_EQ(6, Factorial(3));
  EXPECT_EQ(40320, Factorial(8));

Finally, many C++ testing framework authors neglected extensibility and were happy just providing canned solutions, so we ended up with many solutions, each satisfying a different niche but none general enough. A versatile framework must have a good extension story. Let's face it: you cannot be all things to all people, no matter what. Instead of bloating the framework with rarely used features, we should provide good out-of-box solutions for maybe 95% of the use cases, and leave the rest to extensions. If I can easily extend a framework to solve a particular problem of mine, I will feel less motivated to write my own thing. Unfortunately, many framework authors don't seem to see the importance of extensibility. I think that mindset contributed to the plethora of frameworks we see today. In Google Test, we try to make it easy to expand your testing vocabulary by defining custom assertions that generate informative error messages. For instance, here’s a naive way to verify that an int value is in a given range:

bool IsInRange(int value, int low, int high) {
  return low <= value && value <= high;
  EXPECT_TRUE(IsInRange(SomeFunction(), low, high));

The problem is that when the assertion fails, you only know that the value returned by SomeFunction() is not in range [low, high], but you have no idea what that return value and the range actually are -- this makes debugging the test failure harder.

You could provide a custom message to make the failure more descriptive:

  EXPECT_TRUE(IsInRange(SomeFunction(), low, high))
      << "SomeFunction() = " << SomeFunction() 
      << ", not in range ["
      << low << ", " << high << "]";

Except that this is incorrect as SomeFunction() may return a different answer each time.  You can fix that by introducing an intermediate variable to hold the function’s result:

  int result = SomeFunction();
  EXPECT_TRUE(IsInRange(result, low, high))
      << "result (return value of SomeFunction()) = " << result
      << ", not in range [" << low << ", " << high << "]";

However this is tedious and obscures what you are really trying to do.  It’s not a good pattern when you need to do the “is in range” check repeatedly. What we need here is a way to abstract this pattern into a reusable construct.

Google Test lets you define a test predicate like this:

AssertionResult IsInRange(int value, int low, int high) {
  if (value < low)
    return AssertionFailure()
        << value << " < lower bound " << low;
  else if (value > high)
    return AssertionFailure()
        << value << " > upper bound " << high;
    return AssertionSuccess()
        << value << " is in range [" 
        << low << ", " << high << "]";

Then the statement EXPECT_TRUE(IsInRange(SomeFunction(), low, high)) may print (assuming that SomeFunction() returns 13):

   Value of: IsInRange(SomeFunction(), low, high)
     Actual: false (13 < lower bound 20)
   Expected: true

The same IsInRange() definition also lets you use it in an EXPECT_FALSE context, e.g. EXPECT_FALSE(IsInRange(AnotherFunction(), low, high)) could print:

   Value of: IsInRange(AnotherFunction(), low, high)
     Actual: true (25 is in range [20, 60])
   Expected: false

This way, you can build a library of test predicates for your problem domain, and benefit from clear, declarative test code and descriptive failure messages.

In the same vein, Google Mock (our C++ mocking framework) allows you to easily define matchers that can be used exactly the same way as built-in matchers.  Also, we have included an event listener API in Google Test for people to write plug-ins. We hope that people will use these features to extend Google Test/Mock for their own need and contribute back extensions that might be generally useful.

Perhaps one day we will solve the C++ testing framework fragmentation problem, after all. :-)


[Gd] GWT 2.5 Final is here!

| More

Google Web Toolkit Blog: GWT 2.5 Final is here!

Thanks to all developers who helped us test GWT 2.5 release candidates and reported issues to us. We have fixed several of these and are happy to announce availability of GWT 2.5 Final.

You can download this release from our main GWT download page.  Release notes are here.

- GWT Team

[Gd] Dev Channel Update for Chrome OS

| More

Chrome Releases: Dev Channel Update for Chrome OS

The Dev channel has been updated to 24.0.1305.3 (Platform version: 3083.1.0) for Chromebooks on Samsung Chromebook Series 5 550, Samsung Chromebook Series 5, Samsung Chromebox Series 3, Acer AC700, and Cr-48). Systems will receive updates over the next several days.

This build contains stability fixes.

Some known issues in this release include:
  • 35464 - Audio on some systems may be distorted when playing a single audio stream for a long period of time, or when playing audio on multiple tabs.
  • 157420 - "Allow proxies for shared networks" is enabled by default.
  • 35632 - Password is asked in crosh 3 times. This occurs in normal mode. Workaround - Press Enter 3 times to bypass this request.
  • On the Settings tab when modifying your avatar image, or when creating a new user, the camera LED may remain illuminated for several seconds after leaving the page.

If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu.

Danielle Drew
Google Chrome

Thursday, October 25, 2012

[Gd] New Image Metadata for the Google Drive SDK

| More

Google Apps Developer Blog: New Image Metadata for the Google Drive SDK

Do you like to store photos in Google Drive? You are not alone! Photographs are one of the most common file types stored in Google Drive. The Google Drive API now exposes Exif data for photos, so that Google Drive Apps can use it. The Exif data contains information about camera settings and photo attributes.

Despite being an awful photographer, I love photographing benches, and here is one I took while at the beach. Let’s have a look at some of these new fields for this photo.

When I examine the metadata for this image using a drive.files.get call, there is now a field, imageMediaMetadata, containing the detailed photo information:

"imageMediaMetadata": {
"width": 2888,
"height": 1000,
"rotation": 0,
"date": "2012:07:08 15:22:25",
"cameraMake": "NIKON CORPORATION",
"cameraModel": "NIKON D90",
"exposureTime": 8.0E-4,
"aperture": 5.6,
"flashUsed": false,
"focalLength": 105.0,
"isoSpeed": 200

So whether you are just storing your amateur snaps like me, or using Google Drive to store serious photographs, we hope this will be useful information for Drive apps. For example, a photo organizing application will be able to create thumbnail and information views for photos without ever having to download them.

For more information, please visit our documentation, and if you have any technical questions, please ask them on StackOverflow. Our team are waiting to hear from you.

Ali Afshar profile | twitter

Tech Lead, Google Drive Developer Relations. As an eternal open source advocate, he contributes to a number of open source applications, and is the author of the PIDA Python IDE. Once an intensive care physician, he has a special interest in all aspects of technology for healthcare


[Gd] Beta Channel Update for Chrome OS

| More

Chrome Releases: Beta Channel Update for Chrome OS

The Beta channel has been updated to 23.0.1271.53 (Platform version 2723.135.0) for all devices. This release delivers a number of stability improvements. 

Notable non-stability changes:
  • Pepper Flash version on new Chromebook updated to

If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the hotdog (3 horizontal bars in the upper right corner of the browser) menu.

Ben Henry and Josafat Garcia

Chrome OS

[Gd] Beta Channel Update

| More

Chrome Releases: Beta Channel Update

The Beta channel has been updated to 23.0.1271.52 for Windows, Mac, Linux, and ChromeFrame platforms.

  • Fixed geolocation (Issue: 152428)
  • Fixed sync to use all datatypes when user chooses default (Issue: 154940)
  • Pepper Flash not setting local timezone (Issue: 154060)
More details about additional changes are available in the svn log of all revisions. 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

Wednesday, October 24, 2012

[Gd] Stable Channel Update for Chrome OS

| More

Chrome Releases: Stable Channel Update for Chrome OS

The Stable channel has been updated to 21.0.1180.92 (Platform version: 2465.227.0) for Chromebooks.

This build contains stability fixes.

Some highlights of these changes are:
  • 34398 - Connection manager crashes on resume when 3G is enabled

If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu.

Danielle Drew
Google Chrome

[Gd] Dev Channel Update

| More

Chrome Releases: Dev Channel Update

The Dev channel has been updated to 24.0.1305.3  for Windows, Mac, Linux, and Chrome Frame.  This build contains following updates:


  • Updated V8 -
  • Bookmarks are now searched by their title while typing into the omnibox with matching bookmarks being shown in the autocomplete suggestions pop-down list. Matching is done by prefix. Example: if there is a bookmark with a title of “Doglettes & Catlettes” typing any of the following into the omnibox will likely present the bookmark as a suggestion:: “dog”, “cat”, “cat dog”, “dog cat”, “dogle”, etc. Typing “ogle” or “lettes” will not match.
  • Fixed issues 155871, 154173, 155133.


Full details about what changes are in this build are available in the SVN revision log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.

Dharani Govindan
Google Chrome

Tuesday, October 23, 2012

[Gd] GDG DevFest season isn’t slowing down

| More

Google Developers Blog: GDG DevFest season isn’t slowing down

Author PictureBy Phoebe Peronto, Developer Marketing

If the past three months have been any indication of the power of the global Google Developer community, then we have a lot to look forward to with the remainder of the DevFest season. From local experts in Google technologies hosting track sessions, to attendees creating usable and innovative apps in event hackathons, the Google Developer ecosystem is energized by big community momentum. The season continues this month through November end, so stay tuned for upcoming events and ways to get involved in your local chapter. See below for the latest from the most recent #gdg #devfest events around the world--we can assure you you’re in for a wonderful treat.

DevFest Berlin | Host: GDG Berlin
October 13, 2012, c-base
GDG Berlin captured DevFest Berlin sessions on video that are now available to the public. With sessions and a full agenda, DevFest Berlin also hosted a hackathon that yielded innovative projects built with Google tools and technologies. DevFest attendee Mister Schtief wrote of the hacked Chirp app: “It works!!! Transferring data with sound between two mobile phones with chirp app #devfest +DevFest Berlin.”

DevFest Amman | Host: GDG Amman
October 13, 2012, Talal Abu Ghazaleh Knowledge Center

DevFest Dhaka | Host: GDG Dhaka
October 14, 2012, United International University
DevFest Dhaka captured event highlights in a Google+ photo gallery


DevFest OAU | Host: GDG OAU
October 18, 2012, Obafemi Awolowo University

DevFest Chlef | Host: GDG Chlef
GDG Chlef thought outside the box when crafting their event announcement, bringing visibility to their developer event with a video showcasing cross-platform technologies featured in the weekend’s sessions.

DevFest Firenze | Host: GDG Firenze
October 19-20, 2012, Firenze, Italia Piazza Annigoni 9/B

DevFest Zurich | Host: GDG Zurich
October 19, 2012, Zurich Youth Hostel
Sessions, speakers, and a successful hackathon encapsulated the DevFest Zurich experience. Take a peek at the hackathon project ideas here. Of the event, attendee Andreas Müller posted on Google+: “Enjoyed this weekend from the beginning to the end. Many thanks to the orga team, well done!”

DevFest West | Host: GDG Silicon Valley
October 20, 2012, Mountain View, CA (Google Bldg 1900)
DevFest West took place this weekend in Google’s own backyard. With some fortune-telling, big smiles, and memes, the event was clearly a success!

DevFest Sicilia | Host: GDG Nebrodi
October 20, 2012
GDG Nebrodi took the registration and event experience to the next level for its attendees by providing a localized app directly downloadable from Google Play. The app features an agenda, calendar of events, session titles, and more.

DevFest Thiès | Host: GDG Thiès
October 20, 2012, CRE THIES
GDG Thiès documented event highlights in a shareable photo gallery on their Google+ page

DevFest Jkuat | Host: GDG Jkuat
October 20, 2012
View the full event gallery here

DevFest Goma | Host: GDG Goma
October 20, 2012, l'Institut Supérieur d'informatique et de Gestion (ISIG) de Goma

DevFest Cochabamba | Host: GDG Cochabamba
October 20, 2012, ULRA/UMSS

What’s up next?
La Paz, Bolivia | October 24, 2012
Bangkok, Thailand | October 26, 2012
Valley View University, Ghana | October 26, 2012
Lima, Peru | October 27, 2012
Ouaga, Burkina Faso | 10/27/2012
Chennai, India | October 27, 2012
Chandigarh, India |October 27, 2012
Brunei, Brunei | October 29, 2012

Want to learn more?  Find your nearest GDG chapter, get involved in local events, and join the conversation about all things Google Developer at

Phoebe Peronto is an Associate Product Marketing Manager on the Developer Marketing team here at Google. She’s a foodie who has a penchant for traveling, politics, and running. Oh, and of course...Go Cal Bears!

Posted by Scott Knaster, Editor

[Gd] App Engine 1.7.3 Released

| More

Google App Engine Blog: App Engine 1.7.3 Released

For our October release we have a number of offerings, fixes, and small refinements as colorful as the fall season.

General Enhancements

  • Java classloading priority can now be granted to specific JAR files.  This is an experimental feature. More information can be found here.

App Engine SDK support for Java 7

With Java 7, many new language enhancements have been added, including:

  • The ability to use the String class in Switch statements

  • Expression of binary literals using simple prefixes 0b or 0B

  • Single catch blocks that can handle multiple exceptions

  • Improved type inference for generic instance creation

  • Auto closing of resources when enclosed within a try-with-resources statement

  • Simplified varargs method invocation

We’re happy to announce that as of this release the App Engine Java SDK has support for running and testing your applications using a local Java 7 installation. To get started now, developers should download the latest App Engine Java SDK and a Java SE 7 or JDK 7 distribution. From there they can follow the existing documentation for running and testing applications locally.  

In an upcoming release, we will be including some of the new Java 7 functionality as well as formal Java 7 support within the App Engine Java runtime. Before this is available, we strongly encourage developers to start testing their applications using Java 7 and the latest App Engine Java SDK. 

And while Java 7 support is not yet available within the App Engine Java runtime, developers interested in an early preview can sign up for our trusted tester program.

Want more information?

The complete list of features and bug fixes for 1.7.3 can be found in our release notes. For App Engine coding questions and answers check us out on Stack Overflow, and for general discussion and feedback, find us on our Google Group.

- Posted by the Google App Engine Team


[Gd] Do more with Chrome Developer Tools

| More

Chromium Blog: Do more with Chrome Developer Tools

The Chrome Developer Tools team recently launched new features and made several UI changes to improve your development and debugging workflow.

Develop for mobile 

Since we launched Chrome for Android, you’ve been able to use Chrome Developer Tools to debug and profile mobile web pages and web apps.

Today, we take this feature one step further by introducing device emulation support in Chrome Developer Tools. Device emulation includes, among other things, native User Agent and dimension overriding. This allows developers to debug mobile browsers on different devices and operating systems via the Settings Menu. So, now, you can emulate the exact device metrics of devices like the Galaxy Nexus and the iPhone to test your media query-driven design.

Chrome Developer Tools also supports single touch event emulation to make it easier to debug mobile applications on the desktop.

Profile rendering performance 

The Timeline’s Frame Mode feature now allows you to profile Chrome’s rendering performance, remove the jank and deliver the silky smooth performance users expect from your apps. To learn more about this topic, check out the recent "Jank Busters" video from Google I/O.

Preview your log items

The console now prints a user-friendly snapshot of the object properties taken at log time, whereas by expanding the object manually, you can still see its live content. This is especially useful when logging an object in a loop and observing its mutation. With this change, we resolved a longstanding bug many of you prioritized on

Play with experimental features

You can now try new experimental features in Chrome Developer Tools by visiting chrome:flags and enabling them there. Once you do that, a new tab called “Experiments” will be visible in the settings menu, allowing you to enable and use any of the following experiments:
  • Snippets (essentially multi-line console on steroids) 
  • Source mapping support for SASS 
  • Native memory profiling 
  • Geolocation / orientation override 
  • FileSystem inspection 
  • Canvas inspection 
  • CPU activity in Timeline 
  • CSS Regions support 
Some of these experimental features are almost ready while others have just landed and need some more refining. In either case, we’d love your feedback before we bake these fully in Chrome Developer Tools. You can also read our recently updated contribution guide if you’re interested in helping us make the tools better.

To get more information on all of Chrome Developer Tools features, check out our “Chrome Developer Tools Evolution” talk at the I/O 2012. You can also follow Google Chrome Developers on Google+ or @ChromiumDev on Twitter for more news on changes landing in Chrome Developer Tools.

Posted by Stefano Cazzulani, Product Manager