Friday, June 12, 2009

[Gd] 1 Wave Sandbox, 5 Hours, 17 Awesome Demos

| More

Google Wave Developer Blog: 1 Wave Sandbox, 5 Hours, 17 Awesome Demos

Posted by Pamela Fox, Developer Relations Team

On May 28th, the second day of Google I/O, we unveiled Google Wave as a developer preview. But, we'd never actually had non-Google developers use it, and we were eager to see how it'd play out... So, on the Friday after I/O, about 60 developers assembled down at Google HQ for the very first Google Wave API hackathon.

After five hours of hacking and ad-hoc discussions with members of the Wave APIs team, there were a whopping 17 demos to show off. We were awed by how enthusiastically developers dove in to the APIs that day, and excited to see what they created. Their accomplishments were especially amazing as no one had even used the product prior to the hackathon.

Evan Coke kicked off the demos with an amazing app that showed off the Twilio API by calling a phone number from a Wave, transcribing the conversation to text, and pasting it back into the wave. Andres Ferrate, who had never before programmed in Python or App Engine, showed off the first monetizing extension: a robot that searched Amazon for DVDs and books, and gave him a cut of any purchases made off the links.

Takashi Matsuo, who only showed up halfway through the afternoon, showed his simple but adorable app, a robot named 'Kay' that responds to you in a scrambled version of your original message, akin to baby talk. This robot is named after Takashi's upcoming product launch - a daughter named Kay. We believe 'Kay' to be the first Wave robot named after a future human.

Two developers demonstrated musically inclined gadgets; Dave Peck with his Dum Drumz" gadget, and Yasushi Ando with an HTML5-powered Piano gadget. The two have since collaborated to create the first collaborative Wave band.

Several of the Google engineers had stuff to show as well. David Byttow, lead on the Python Client library, showed off "Monty", an app that runs Python code and evaluates CALC macros. We suspect that this is just another of David's attempts to prove Python is the best language ever, but it was a great demo nonetheless. Alex North, a backend API engineer, showed off a bot based on the classic "Alice" AI. When Alex told Alice that "Google Wave is the shit", she responded, "But is it the only one?" Touché.

At the end of all the demos (too many to describe here!), Lars thanked all the developers and said, "I was so happy after seeing the first two demos, I nearly cried." We were all awed by how enthusiastically the developers dove into the APIs that day, and the great stuff they came up with in such a short period of time. We're hoping to replicate the awesomeness at the upcoming Google Wave API Day in Sydney on June 19th, and perhaps see some Australian themed extensions (Kangaroo-ey? Matey?).

We won't be able to personally organize hackathons all over the world, but we encourage co-located Wave developers to hold their own events and share the results. Always ahead of the trends, a group of Japanese developers held a meetup last week and shared their photos in a Wave.

If you're a developer that's eager to hack on Wave, read through the documentation, check out the various samples, and make sure to request sandbox access. A few enterprising developers have even created Google Wave gadget emulators, so you can get started hacking before you even have access. Have fun, and let us know in the forum if you have questions or problems.

(Note: Some of the links in this blogpost require access to view.)


Thursday, June 11, 2009

[Gd] Google Technology User Groups

| More

Google Code Blog: Google Technology User Groups

My favorite part about Google I/O is the dozens of interesting conversations with developers -- getting a first-hand look at the different things that they are doing with our technologies. That's the spirit of the Google Technology User Groups -- regular meetups where local developers can get together to network and discuss, demo, and hack on Google's many developer offerings.

From lightning talks in Mountain View, to App Engine hackathons in Tokyo, to lectures in Berlin, the GTUGs are a great place to meet fellow developers and learn (or teach) something new.

At Google I/O, there were many folks eager to bring the spirit of the conference back to their hometowns by starting up GTUGs of their own. Since the conference ended, our list of current GTUGs has grown to include this 'baby boomer' generation of chapters. The following are all new groups looking for members and starting to set up their first events.

If there's one near you, check it out! Let the organizers know you're interested; suggest topics for discussion and even offer to do a talk about your own experiences.


Paris GTUG -
Hamburg GTUG -
GTUG Munich -
Istanbul GTUG -
Polish GTUG -

North America

Tri-Valley California GTUG -
Berkeley GTUG -
San Diego GTUG -
New Jersey GTUG -
Philly/Delaware GTUG -
Boston GTUG -
Denver GTUG -
Twin Cities GTUG -
Austin GTUG -
Michigan GTUG -
Utah GTUG -
Laguna GTUG -

South America
Chile GTUG -
Argentina GTUG -

Kuala Lumpur GTUG -
Hyderabad GTUG -

Also a big shout-out to our existing chapters:

Silicon Valley GTUG - (watch the organizers, Kevin and Van, talk about GTUGs at Google I/O)
Pune GTUG -
Chico GTUG
Berlin GTUG -
Tokyo GTUG -

View GTUGs in a larger map

Don't see a chapter near you? Start one! Join our GTUG managers mailing list. Other info at

By Stephanie Liu, Google Developer Programs

[Gd] Dev Channel Update:

| More

Google Chrome Releases: Dev Channel Update:

Yesterday's Dev Channel update ( for Windows had a critical bug which crashes the browser when you use the wrench or page menus.  This release fixes that issue.

If you already have you cannot get to About Google Chrome to force an update.  You have a couple of choices to get the update.

  1. Wait.  If you wait about 5 hours Google Chrome will check for an update and install it for you.
  2. Uninstall Google Chrome and reinstall from
The Mac and Linux builds were not affected by this bug so they are not being updated.

We apologize for the problem and we are making changes to our process to try and avoid issues like this in the future.  The dev channel is always going to be a little risky but we agree that major features like this should not go out broken.

Jonathan Conradt
Engineering Program Manager

[Gd] GWT Community Updates

| More

Google Web Toolkit Blog: GWT Community Updates

Community announcements

Gilead GWT adapter for Google App Engine: Bruno Marchesson, creator of the Gilead (aka Hibernate4GWT) library, has created another adapter - this time for GWT applications running on App Engine. It is still in its early stages, but this may be useful to those looking to build their applications using GWT and Google App Engine and who don't mind hammering on fresh code.

Vaadin 6 (formerly IT Mill Toolkit) releases: The IT Mill team has come out with the latest release of their toolkit built using GWT technology. Vaadin offers a different take on Ajax application development that employs server-driven architecture with widgets composed of both client and server-side components. Their latest release is available on their new site.

SmartGWT out of beta with v1.1 release: Sanjiv Jivan has been hard at work getting the SmartGWT library ready for its out of beta release. It includes many useful new features that you might be interested in checking out.

Google I/O 2009 - Caught on video

GWT at Google I/O: In case you missed it, we've captured all the GWT sessions at Google I/O on video, including the keynote presenting Google Wave (built with GWT).

GWT Developers at Google I/O: A few external developers who use GWT also stopped by I/O and participated in the Developer Sandbox. Despite all the hustle and bustle around the sandbox area, we managed to talk to some of them on video about their development experience. Some of those we talked to include:

We also talked to many other developers using Google Technologies to create some great applications.


[Gd] App Engine @ Google I/O goodness for all to enjoy

| More

Google App Engine Blog: App Engine @ Google I/O goodness for all to enjoy

Back in April when we launched Java support, we gave the first 10,000 developers who signed up access to the new runtime. In case you haven't heard, we recently announced at Google I/O that App Engine for Java signup is now open. We're excited to see more developers joining our community!

For those who missed Google I/O or want a refresher on the sessions, the videos are now posted online. From building a complex and scalable app on App Engine to offline processing, there are a lot of things to learn from these sessions. You can find a more detailed write up of the App Engine sessions in this post to the Google Code Blog, but here's the complete list:

Apart from the sessions, we also had a Developer Sandbox featuring App Engine partners and customers. We got a chance to interview and ask many of them to share their experience developing on App Engine. Check out these video interviews to get more insight to App Engine:

Last but not least, we've also made available the handy Python cheat sheet we gave out during Google I/O. You can download it here. We want to thank our partners and the App Engine developer community for a fantastic Google I/O 2009! It was great meeting those of you who were there. We look forward to the next year!

Posted by Amanda Surya, App Engine Team

Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.

[Gd] Ext-core ready to go

| More

Google AJAX APIs Blog: Ext-core ready to go

Recently, the guys over at Ext JS released ext-core under an MIT license, which was a big win for open source! Today, they released a stable (non-beta) version of this library and we are proud to be part of that announcement by hosting the new version. You can now pull ext-core from Google servers:
// directly access it
// alias the newest 3.x version
// directly access the uncompressed code
You can also use it from the loader:
google.load('ext-core', '3.0');
google.load('ext-core', '3', {uncompressed : true});
Thanks to all for the requests to add ext-core to our Libraries API, and big thanks to Ext JS for providing their library so openly! For more information, head over to their blog post.

[Gd] [Libraries][Update] - ext-core 3.0 was added

| More

Google AJAX API Alerts: [Libraries][Update] - ext-core 3.0 was added

ext-core 3.0 was added to the Libraries API! Hooray!

[Gd] [Libraries][Update] - jQuery UI 1.7.2

| More

Google AJAX API Alerts: [Libraries][Update] - jQuery UI 1.7.2

jQuery UI was updated to version 1.7.2

[Gd] An Update on Sitemaps at Google

| More

Official Google Webmaster Central Blog: An Update on Sitemaps at Google

Did you know that the number of website hosts that have been submitting Sitemap files has almost tripled over the last year? It's no wonder: the secret is out - as a recent research study showed, Sitemaps helps search engines to find new and changed content faster. Using Sitemaps doesn't guarantee that your site will be crawled and indexed completely, but it certainly helps us understand your website better.

Together with the Webmaster Tools design update, we've been working on Sitemaps as well:
  • Google and the other search engines which are a part of now support up to 50,000 child Sitemaps for Sitemap index files (instead of the previous 1,000). This allows large sites to submit a theoretical maximum of 2.5 billion URLs with a single Sitemap Index URL (oh, and if you need more, you can always submit multiple Sitemap index files). 

  • The Webmaster Tools design update now shows you all Sitemap files that were submitted for your verified website. This is particularly useful if you have multiple owners verified in Webmaster Tools or if you are submitting some Sitemap files via HTTP ping or through your robots.txt file.

  • The indexed URL count in Webmaster Tools for your Sitemap files is now even more precise.

  • For the XML developers out there, we've updated the XSD schemas to allow Sitemap extensions. The new schema helps webmasters to create better Sitemaps by verifying more features. By validating Sitemap files with the new schema, you can be more confident that the Sitemap files are correct.

  • Do I need to mention that Sitemap file processing is much faster than ever before? We've drastically reduced the average time from submitting a Sitemap file to processing it and showing some initial data in Webmaster Tools. 

For more information about using Sitemaps, make sure to check out our blog post about frequently asked questions on Sitemaps and our Help Center. If you have any questions that aren't covered here, don't forget to search our Help Forum and start a thread in the Sitemaps section for more help. 

Written by John Müller, Webmaster Trends Analyst, Google Switzerland

Wednesday, June 10, 2009

[Gd] Dev Channel Update:

| More

Google Chrome Releases: Dev Channel Update:

Google Chrome has been released to the Dev channel for Windows, Mac OS X, and Linux.

Highlights for this release:

  • Linux: Import passwords from Firefox. (Issue: 11191)
  • On Mac use Keychain for passwords. (Issue: 11745)
  • Fix regression where Omnibox would drop characters during rapid typing. (Issue: 13428)
  • The web inspector is now working again. (Issue 13411)
  • Fix browser hang due to plugin deadlock. (Issue: 12624)
  • --enable-user-scripts is working again. (Issue 13290)
  • Clicking an extension toolstrip no longer selects the first tab. (Issue 13547)
  • Extension buttons now show after install (Issue 13609)
  • Increase the maximum number of cookies to 3000. This matches Firefox. (Issue: 8850)
  • When the contents don't have title, use URL for the name of bookmark entry. (Issue: 5965)
  • Move download shelf from per-tab to per-window. (Issue: 9025)
  • Improved support for Squid proxies. (Issue: 8771)
  • Fixes a flash plugin hang on Google Finance ticker symbols in a background tab. (Issue: 12993)

Version Changes:
  • V8 - 1.2.7

The release notes are available as well as a detailed list of all revisions.

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

Jonathan Conradt
Engineering Program Manager

[Gd] Dev Channel Update:

| More

Google Chrome Releases: Dev Channel Update:

Google Chrome has been released to the Dev channel for Windows, Mac OS X, and Linux.

Highlights for this release:

  • Linux: Import passwords from Firefox. (Issue: 11191)
  • On Mac use Keychain for passwords. (Issue: 11745)
  • Fix regression where Omnibox would drop characters during rapid typing. (Issue: 13428)
  • The web inspector is now working again. (Issue 13411)
  • Fix browser hang due to plugin deadlock. (Issue: 12624)
  • --enable-user-scripts is working again. (Issue 13290)
  • Clicking an extension toolstrip no longer selects the first tab. (Issue 13547)
  • Extension buttons now show after install (Issue 13609)
  • Increase the maximum number of cookies to 3000. This matches Firefox. (Issue: 8850)
  • When the contents don't have title, use URL for the name of bookmark entry. (Issue: 5965)
  • Move download shelf from per-tab to per-window. (Issue: 9025)
  • Improved support for Squid proxies. (Issue: 8771)
  • Fixes a flash plugin hang on Google Finance ticker symbols in a background tab. (Issue: 12993)

Version Changes:
  • V8 - 1.2.7

The release notes are available as well as a detailed list of all revisions.

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

Jonathan Conradt
Engineering Program Manager

[Gd] Changing Quotas To Keep Most Apps Serving Free

| More

Google App Engine Blog: Changing Quotas To Keep Most Apps Serving Free

Since App Engine launched, it has been our goal has been to offer substantial free hosting resources to as many developers as possible. As previously announced, we are changing our free resource quota levels, effective on June 22nd. Our target level of free support has been 5 million page views per month for a reasonably efficient web application.

When we launched App Engine, we were intentionally generous in our free quotas, both because we didn't know resources usage of a typical request, and because we didn't offer a billing feature to allow developers to buy more resources for a higher-traffic app. Since our billing feature launched in February, developers with high-traffic applications can purchase additional resources far beyond our original fixed free quotas. Having been live for more than a year, we now have good empirical data on the average resource consumption per request, so we're able to set our quotas to more accurately support our 5 million page views target.

This change in the free quotas offered to every application is intended to allow us to continue to offer substantial free application hosting to any interested developer. We have grown a lot in the last year, with over 80,000 applications created, and with these changes to our free quotas, more than 90% of these applications will continue to serve completely free. To empirically determine reasonable levels for our quotas, we measured resource usage for all applications running on App Engine over a recent 7-day period. For each of the quotas, we took the highest daily average resource usage per HTTP request out of the 7-day period:

CPU: 167 megacycles/request
Outbound data transfer: 6149 bytes out
Inbound data transfer: 803 bytes in

Multiplied by 5 million requests spread over a 30 day month, these per-request resource statistics translate to daily resource usage of 6.4 CPU-hours and 1.02 gigabytes of outbound data transfer. We top off the numbers by offering 6.5 CPU-hours and 1.07 gigabytes of outbound transfer. Though typically inbound data transfer is a small fraction of outbound data transfer, we made inbound and outbound data transfer symmetric to ease initial data uploads.

Finally — what do we mean by reasonably efficient applications? Simply put, efficient applications avoid unnecessary computation or data transfer, and two techniques common to efficient App Engine applications are the use of caching headers and memcache. Caching headers in an HTTP response prevent a user's browser from needlessly re-downloading information that hasn't changed, both speeding up the user experience and saving bandwidth. Similarly, memcache keeps frequently accessed data in a memory cache on App Engine servers, rather than always reading from disk in the Datastore, therefore saving CPU usage and Datastore load.

Again, these changes ensure we can keep our continuing promise to make it free to get started with App Engine.

Posted by Chris Beckmann, App Engine team

[Gd] Google I/O Interactive Map: Now with videos + some Open Source goodness!

| More

Google Code Blog: Google I/O Interactive Map: Now with videos + some Open Source goodness!

If you attended Google I/O 2009 a few weeks ago, you may have noticed a kiosk station on the 2nd and 3rd floors of Moscone West labelled 'Interactive Conference Map, powered by Google Maps'. The kiosk simply pointed to a JavaScript Maps API-based interactive map of the venue I created in my 20% time.

Now that all the I/O session videos and presentations are live, we took the opportunity to mash up the videos with our interactive conference map to provide developers with an alternate way to navigate through 80+ keynote and session videos, and bring the action at I/O to life virtually. For example, here are videos of sessions that took place in Room 1 (click the tabs for Wednesday and Thursday sessions). And here's where the keynote sessions took place. Check out where we filmed interviews with I/O sandbox developers on their apps, technical challenges and business best practices.

Now, hopefully you enjoyed using the map and are now thinking, "Cool, I want to do something like this for my next event!" (or your college campus, or such). If you are, then good news everyone, I've open sourced the interactive conference map and all relevant resources. Inside the project, you'll also find a how to article outlining the steps I went through to create the map.

If you attended I/O, then I hope you enjoyed it and had time to stop by the conference map kiosk! If not, no worries, just make sure to check out the open source project and see if you can use the code and/or techniques in your next mapping project!

By Roman Nurik, Developer Programs Engineer

[Gd] Check out these videos and slides from Google I/O

| More

OpenSocial API Blog: Check out these videos and slides from Google I/O

If you weren't able to make it to Google I/O, or if you're looking for a refresher on one of the sessions you saw, the Google I/O site now has videos of all the social sessions so everyone can watch and learn. From design principles to saving on bandwidth and hosting costs, you're sure to learn something new about how to improve your OpenSocial app. You can find a summary of all the social sessions in this post on the Google Code blog, but here's the list:
Like all things with OpenSocial, our presence at Google I/O was a community effort. We had lots of guest speakers in sessions and many developers volunteered for interviews, so thanks again to everyone who helped make the social track at Google I/O a success.

Posted by Lane LiaBraaten, OpenSocial Team

[Gd] To make Webmaster Tools' Message Center more accessible, we've

| More

Official Google Webmaster Central Blog: To make Webmaster Tools' Message Center more accessible, we've

To make Webmaster Tools' Message Center more accessible, we've just made it possible to forward messages to your personal email. The Webmaster Tools Message Center is used to communicate confidential information about sites you've verified. This may be anything related to your site, from details about potential issues with Google's Webmaster Guidelines to confirmations of actions taken within Webmaster Tools like changes to site-wide settings. To enable the feature, simply update your settings on the Home page.

Messages can be forwarded in any of our 40 supported languages to any email associated with your Google Account. To associate another email address with your Google Account, simply click on the "My Account" link at the top of the page and verify the new email address. All emails will be sent from <>, so update your spam filters to make sure you don't miss these emails.

Posted By Tanya Gupta, Software Engineer

[Gd] Out with the old, in with the new

| More

Official Google Webmaster Central Blog: Out with the old, in with the new

Webmaster Level: All

We launched a preview of our new Webmaster Tools interface three weeks ago, and received a lot of valuable feedback. Most of you liked the update, appreciating features such as the one-stop dashboard, more top search query data, and the improved menu and navigation.

You offered some constructive feedback as well:
  • You missed the option to switch listing 25, 50, or 100 rows in features such as links to your site. We did not add the option back to select how many rows you would like to see but increased our default to 100!
  • Top search query information differed between the old and new versions. We expected this since we went through a lot of re-engineering to improve the new top search queries backend. We reviewed many of the issues posted on our forums, and verified that the new backend is far more accurate and reliable.
  • Initially, the Sitemaps downloaded and indexed URL counts differed between the two versions. We resolved this issue quickly.
  • Backlinks numbers between the old and the new user interface (UI) may differ since our new UI shows the original anchor (not following redirects) as it's linked on the web. Let's say links to, then 301s to
    • In the new UI -- only verified site owners of will see's backlink (because we show the original link prior to any redirects)
    • In the old UI -- verified site owners of could see's backlink
  • The new site switcher lists only five sites, and some of you who manage a large number of sites found this limiting. We appreciate the feedback and will work on addressing this limitation in a future release.
From today, only the new user interface will be available (! You'll see that in addition to fixing many of the issues users addressed, we took some time to launch a new feature: Change of Address. The Change of Address feature lets you notify Google when you are moving from one domain to another, enabling us to update our index faster and hopefully creating a smoother transition for your users.

Thanks to all the users that took time to give us feedback on the new user interface. To those users using it for the first time today, we hope you enjoy it. As always, your feedback is appreciated.

Posted by Sagar Kamdar, Product Manager, Webmaster Tools Team

[Gd] Gmail for Mobile HTML5 Series: Suggestions for Better Performance

| More

Google Code Blog: Gmail for Mobile HTML5 Series: Suggestions for Better Performance

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow-up blog posts. This week, I'll talk about a few small things you can do to improve performance of your HTML5-based applications. Our focus here will be on performance bottlenecks related to the database and AppCache.

Optimizing Database Performance

There are hundreds of books written about optimizing SQL and database performance, so I won't bother to get into these details, but instead focus on things which are of particular interest for mobile HTML5 apps.

Problem: Creating and deleting tables is slow! It can take upwards of 200 ms to create or delete a table. This means a simple database schema with 10 tables can easily take 2-4 seconds (or more!) just to delete and recreate the tables. Since this often needs to be done at startup time, this really hurts your launch time.

Solution: Smart versioning and backwards compatible schema changes (whenever possible). A simple way of doing this is to have a VERSION table with a single row that includes the version number (e.g., 1.0). For backwards-compatible version changes, just update the number after the decimal (e.g., 1.1) and apply any updates to the schema. For changes that aren't backwards compatible, update the number before the decimal (e.g., 2.0) at which point you can drop all the tables and recreate them all. With a reasonable schema design to begin with, it should be very rare that a schema change is not backwards compatible and even if this happens every month or so, users should get to use your application 20, 30 even 100 times before they hit this startup delay again. If your schema changes very infrequently, a simple 1, 2, 3 versioning scheme will probably work fine; just make sure to only recreate the database when the version changes!

Problem: Queries are slow! Queries are faster than creates and updates, but they can still take 100ms-150ms to execute. It's not uncommon for traditional applications to execute dozens or even hundreds of queries at startup – on mobile this is not an option.

Solution: Defer and/or combine queries. Any queries that can be deferred from startup (or at any other significant point in the application) should be deferred until the data is absolutely needed. Adding 2-3 more queries on a user-driven operation can turn an action from appearing instantaneous to feeling unresponsive. Any queries that are performed at startup should be optimized to require as few hits to the database as possible. For example, if you're storing data about books and magazines, you could use the following two queries to get all the authors along with the number of books and magazine articles they've writen:

SELECT Author, COUNT(*) as NumArticles
FROM Magazines
ORDER BY NumArticles;

SELECT Author, COUNT(*) as NumBooks
FROM Books
ORDER BY NumBooks;

This will work fine, but the additional query will generally cost you about 100-200 ms over a different (albeit less pretty) query like:

SELECT Author, NumPublications, PubType
SELECT Author, COUNT(*) as NumPublications, 'Magazine' as PubType, 0 as SortIndex
FROM Magazines
SELECT Author, COUNT(*) as NumPublications, 'Book' as PubType, 1 as SortIndex
FROM Books
ORDER BY SortIndex, NumPublications;

This will return all the entries we want, with the magazine entries first in increasing order of number of articles, followed by the book entries, in increasing order of the number of books. This is a toy example and there are clearly other ways of improving this, such as merging the Magazines and Books tables, but this type of scenario shows up all the time. There's always a trade-off between simplicity and speed when dealing with databases, but in the case of HTML5 on mobile, this trade-off is even more important.

Problem: Multiple updates is slow!

Solution: Use Triggers whenever possible. When the result of a database update requires updating other rows in the database, try to do it via SQL triggers. For example, let's say you have a table called Books listing all the books you own and another called Authors storing the names of all the authors of books you own. If you give a book away, you'll want to remove it from the Books table. However, if this was the only book you owned by that author, you would also want to remove the author from the Authors table. This can be done with two UPDATE statements, but a "better" way is to write a trigger that automatically deletes the author from the Authors table when the last book by this author is removed. This will execute faster and because triggers happen asynchronously in the background, it will have less of an impact on the UI than executing two statements. Here's an example of a simple trigger for this case:

(SELECT Author
FROM Books);
We'll get into more detail on triggers and how to use them in another performance post to come.

Optimizing AppCache Performance

Problem: Logging in is slow!

Solution: Avoid redirects to the login page. App-Cache is great because it can launch the application without needing to hit the network, which makes it much faster and allows you to launch offline. One problem you might encounter though, is that the application will launch and then you'll need to hit the network to get some data for the current user. At this point you'll have to check that the user is authenticated and it might turn out that they're not (e.g., their cookies might have expired or have been deleted). One option is to redirect the user to a login page somewhere, allow him to authenticate and then redirect him back to the application. Regardless of whether or not the login page is listed in the manifest, when it redirects back to your application, the entire application will reload. A nicer approach is for the application itself to display an authentication interface which sends the credentials and does the authentication seamlessly in the background. This will avoid any additional reloads of the application and makes everything feel faster and better integrated.

Problem: AppCache reloading causes my app to be slow!

Solution: List as few URLs in the manifest as possible. In a series of posts on, we talked about the HTML5 AppCache manifest file. An important aspect of the manifest file is that when the version gets updated, all the URLs listed in the file are fetched again. This happens in the background while the user is using the application, but opening all these network connections and transferring all that data can cause the application to slow down considerably during this process. Try to setup your application so that all the resources can be fetched from as few URLs as possible to speed up the manifest download and minimize this effect. Of course you could also just never update your manifest version, but what's the point of having rapid development if you never make any changes?

That's a brief intro to some performance considerations when developing HTML5 applications. These are all issues that we ran into ourselves and have either fixed or are in the process of fixing in our application. I hope this helps you to avoid some of the issues we ran into and makes your application blazing fast!

We plan to write several more performance related posts in the future, but for now stay tuned for next post where we'll discuss the cache pattern for building offline capable web applications.

By Derek Phillips, Software Engineer, Google Mobile

Previous posts from Gmail for Mobile HTML5 Series
HTML5 and Webkit pave the way for mobile web applications
Using AppCache to launch offline - Part 1
Using AppCache to launch offline - Part 2
Using AppCache to launch offline - Part 3
A Common API for Web Storage

[Gd] AdWords Downtime: June 13, 10am-2pm PDT

| More

AdWords API Blog: AdWords Downtime: June 13, 10am-2pm PDT

We'll be performing routine system maintenance on Saturday, June 13 from approximately 10:00am to 2:00pm PDT. You won't be able to access AdWords or the API during this time frame, but your ads will continue to run as normal.

-Jeffrey Posnick, AdWords API Team

[Gd] Client Library Updates: Part 2

| More

AdWords API Blog: Client Library Updates: Part 2

Last month we announced an update of our client libraries to improve their feature sets and make them more consistent across the various programming languages we support. This coincided with the release of the v2009 Sandbox, and a lot of those changes were meant to ensure that the client libraries were still just as easy to use, but also supported the newly-released v200902 API version.

We've continued our work on the client libraries and are now making more features available:

  • Utility methods that make use of the API to retrieve a breakdown of API usage per method or per client.
  • The ability to retrieve report data in CSV format.
  • Utility methods for retrieving several types of codes used with the API (cities, metros, timezones, etc.).
  • Full NDoc/JavaDoc/RDoc/Epydoc/perldoc documentation for the client library code.
  • Unit tests for the core library functionality and utility modules.
  • Finer-grained handling of API exceptions.
  • Improved runtime validation on the client side.

Some of these features are already present in a few client libraries, but we're now making them all available across Java, .NET, Python, Ruby and, where applicable, our newly released Perl libraries (which only support v200902).

You can find all the client libraries at the usual place: Don't miss out on all the cool new stuff!

-- Sérgio Gomes, AdWords API Team

[Gd] Another Round of Deprecation Policies for Labs Graduates

| More

Google Code Blog: Another Round of Deprecation Policies for Labs Graduates

We recently published deprecation policies for a number of APIs that graduated from Google Code Labs. They state how long we'll support each version from when it's deprecated or a newer version is introduced. It will be 3 years for most, but the time period varies a bit from product to product.
We still need to update the terms for a couple remaining graduates, but should have them all done within the next couple weeks.

By Neel Kshetramade, Google Developer Programs

Tuesday, June 9, 2009

[Gd] Burning Test Questions at Google

| More

Google Testing Blog: Burning Test Questions at Google

By James Whittaker

One of the best parts about change is meeting new people and I've met a lot of Googlers in Mountain View and Kirkland over the past two weeks. There are many burning questions we've discussed but one has surfaced so much that it has to take top billing: manual vs. automated testing.

Google, I've learned, has come full circle on this issue. When the company was new and Search was king most testing was manual and like a lot of startups there was little focus on actual QA. In recent years the pendulum has swung to automation with developers writing a lot of unit tests and testers creating automation frameworks like the octomom pushes out fetuses.

And now with my recent work on manual testing making the rounds what will throwing me into this mix produce?

Actually, I'd like to put the manual vs. automation debate to bed. Instead, I think the issue is test design versus doing something because we can. How much automation is written not because there is a clear need but because we can? Or, perhaps, because we think we must? Hmm.

Before you cry bias, how much manual testing is seat of the pants versus intentional, purposeful testing?

See the point? Whether you are talking about manual or automated testing, it's test design ... identifiying what needs testing and what is the best way to test it ... that has to take center stage. Too often we are solution focused and marry ourselves to our automation rather than the product we are testing. Whenever I see testers that seem more vested in their automation than in the product they are shipping I worry the pendulum has swung too far. Automation suffers from this because there is a product - the tool - that can become the object of obession. Manual testers don't really produce such a physical baby they can fuss over or they probably would fuss just as much as the automaters. Ignore the tool, focus on the problem it should solve!

Besides, I think fundamentally that manual and automated testing are irreversibly linked. All good automation begins it's life as manual test cases. And to create really good automation, you have to be good at manual testing. It's during manual testing that a tester gets good at test design, identifying important testing problems and crafting the solution approach. Any tester who isn't good at test design should think twice before they automate.

Let's shift the debate to good test design. Whether those tests ultimately end up being executed manually or via a tool is a moot point, let's just make them good ones that solve real testing problems.

How many octomoms does the testing world need anyway?

[Gd] Public Service Announcement - Upload Regression Testing

| More

YouTube API Blog: Public Service Announcement - Upload Regression Testing

The team has been working to improve the API upload infrastructure behind the scenes, and the new build is up at:

Please do regression testing on your systems and report problems in our discussion forum.

Barring any major complications, this will begin rolling out to the production uploads URL ( in two weeks.

Posted by Stephanie Liu, YouTube APIs and Tools Team

[Gd] Nicholas C. Zakas: Speed Up Your JavaScript

| More

Google Code Blog: Nicholas C. Zakas: Speed Up Your JavaScript

Nicholas C. Zakas delivers the seventh Web Exponents tech talk at Google. Nicholas is a JavaScript guru and author working at Yahoo!. Most recently we worked together on my next book, Even Faster Web Sites. Nicholas contributed the chapter on Writing Efficient JavaScript, containing much of the sage advice found in this talk. Check out his slides and watch the video.

Nicholas starts by asserting that users have a greater expectation that sites will be fast. Web developers need to do most of the heavy lifting to meet these expectations. Much of the slowness in today's web sites comes from JavaScript. In this talk, Nicholas gives advice in four main areas: scope management, data access, loops, and DOM.

Scope Management: When a symbol is accessed, the JavaScript engine has to walk the scope chain to find that symbol. The scope chain starts with local variables, and ends with global variables. Using more local variables and fewer global variables results in better performance. One way to move in this direction is to store a global as a local variable when it's referenced multiple times within a function. Avoiding with also helps, because that adds more layers to the scope chain. And make sure to use var when declaring local variables, otherwise they'll end up in the global space which means longer access times.

Data Access: In JavaScript, data is accessed four ways: as literals, variables, object properties, and array items. Literals and variables are the fastest to access, although the relative performance can vary across browsers. Similar to global variables, performance can be improved by creating local variables to hold object properties and array items that are referenced multiple times. Also, keep in mind that deeper object property and array item lookup (e.g., obj.name1.name2.name3) is slower.

Loops: Nicholas points out that for-in and for each loops should generally be avoided. Although they provide convenience, they perform poorly. The choices when it comes to loops are for, do-while, and while. All three perform about the same. The key to loops is optimizing what is performed at each iteration in the loop, and the number of iterations, especially paying attention to the previous two performance recommendations. The classic example here is storing an array's length as a local variable, as opposed to querying the array's length property on each iteration through a loop.

DOM: One of the primary areas for optimizing your web application's interaction with the DOM is how you handle HTMLCollection objects: document.images, document.forms, etc., as well as the results of calling getElementsByTagName() and getElementsByClassName(). As noted in the HTML spec, HTMLCollections "are assumed to be live meaning that they are automatically updated when the underlying document is changed." Any idea how long this code takes to execute?

var divs = document.getElementsByTagName("div");
for (var i=0; i < divs.length; i++) {
var div = document.createElement("div");

This code results in an infinite loop! Each time a div is appended to the document, the divs array is updated, incrementing the length so that the termination condition is never reached. It's best to think of HTMLCollections as live queries instead of arrays. Minimizing the number of times you access HTMLCollection properties (hint: copy length to a local variable) is a win. It can also be faster to copy the HTMLCollection into a regular array when the contents are accessed frequently (see the slides for a code sample).

Another area for improving DOM performance is reflow - when the browser computes the page's layout. This happens more frequently than you might think, especially for web applications with heavy use of DHTML. If you have code that makes significant layout changes, consider making the changes within a DocumentFragment or setting the className property to alter styles.

There is hope for a faster web as browsers come equipped with JIT compilers and native code generation. But the legacy of previous, slower browsers will be with us for quite a while longer. So hang in there. With evangelists like Nicholas in the lead, it's still possible to find your way to a fast, efficient web page.

By Steve Souders, Performance Evangelist

Check out other blog posts and videos in the Web Exponents speaker series: