Friday, June 5, 2009

[Gd] 10 things you (probably) didn't know about App Engine

| More

Google App Engine Blog: 10 things you (probably) didn't know about App Engine

What could be better than nine nifty tips and tricks about App Engine? Why, ten of course. As we've been participating in the discussion groups, we've noticed that some features of App Engine often go unnoticed so we've come up with just under eleven fun facts which might just change the way that you develop your app. Without further ado, bring on the first tip:

1. App Versions are strings, not numbers

Although most of the examples show the 'version' field in app.yaml and appengine-web.xml as a number, that's just a matter of convention. App versions can be any string that's allowed in a URL. For example, you could call your versions "live" and "dev", and they would be accessible at "" and "".

2. You can have multiple versions of your app running simultaneously

As we alluded to in point 1, App Engine permits you to deploy multiple versions of your app and have them running side-by-side. All the versions share the samedatastore and memcache, but they run in separate instances and have different URLs. Your 'live' version always serves off as well as any domains you have mapped, but all your app's versions are accessible at Multiple versions are particularly useful for testing a new release in a production environment, on real data, before making it available to all your users.

Something that's less known is that the different app versions don't even have to have the same runtime! It's perfectly fine to have one version of an app using the Java runtime and another version of the same app using the Python runtime.

3. The Java runtime supports any language that compiles to Java bytecode

It's called the Java runtime, but in fact there's nothing stopping you from writing your App Engine app in any other language that compiles to JVM bytecode. In fact, there are already people writing App Engine apps in JRuby, Groovy, Scala, Rhino (a JavaScript interpreter), Quercus (a PHP interpreter/compiler), and even Jython! Our community has shared notes on what they've found to work and not work on the following wiki page.

4. The 'IN' and '!=' operators generate multiple datastore queries 'under the hood'

The 'IN' and '!=' operators in the Python runtime are actually implemented in the SDK and translate to multiple queries 'under the hood'.

For example, the query "SELECT * FROM People WHERE name IN ('Bob', 'Jane')" gets translated into two queries, equivalent to running "SELECT * FROM People WHERE name = 'Bob'" and "SELECT * FROM People WHERE name = 'Jane'" and merging the results. Combining multiple disjunctions multiplies the number of queries needed, so the query "SELECT * FROM People WHERE name IN ('Bob', 'Jane') AND age != 25" generates a total of four queries, for each of the possible conditions (age less than or greater than 25, and name is 'Bob' or 'Jane'), then merges them together into a single result set.

The upshot of this is that you should avoid using excessively large disjunctions. If you're using an inequality query, for example, and you expect only a small number of records to exactly match the condition (e.g. in the above example, you know very few people will have an age of exactly 25), it may be more efficient to execute the query without the inequality filter and exclude any returned records that don't match it yourself.

5. You can batch put, get and delete operations for efficiency

Every time you make a datastore request, such as a query or a get() operation, your app has to send the request off to the datastore, which processes the request and sends back a response. This request-response cycle takes time, and if you're doing a lot of operations one after the other, this can add up to a substantial delay in how long your users have to wait to see a result.

Fortunately, there's an easy way to reduce the number of round trips: batch operations. The db.put(), db.get(), and db.delete() functions all accept lists in addition to their more usual singular invocation. When passed a list, they perform the operation on all the items in the list in a singledatastore round trip and they are executed in parallel, saving you a lot of time. For example, take a look at this common pattern:

for entity in MyModel.all().filter("color =",
entity.color = new_favorite

Doing the update this way requires one datastore round trip for the query, plus one additional round trip for each updated entity - for a total of up to 101 round trips! In comparison, take a look at this example:

updated = []
for entity in MyModel.all().filter("color =",
entity.color = new_favorite

By adding two lines, we've reduced the number of round trips required from 101 to just 2!

6. Datastore performance doesn't depend on how many entities you have

Many people ask about how the datastore will perform once they've inserted 100,000, or a million, or ten million entities. One of the datastore's major strengths is that its performance is totally independent of the number of entities your app has. So much so, in fact, that every entity for every App Engine app is stored in a singleBigTable table! Further, when it comes to queries, all the queries that you can execute natively (with the notable exception of those involving 'IN' and '!=' operators - see above) have equivalent execution cost: The cost of running a query is proportional to the number of results returned by that query.

7. The time it takes to build an index isn't entirely dependent on its size

When adding a new index to your app on App Engine, it sometimes takes a significant amount of time to build. People often inquire about this, citing the amount of data they have compared to the time taken. However, requests to build new indexes are actually added to a queue of indexes that need to be built, and processed by a centralized system that builds indexes for all App Engine apps. At peak times, there may be other index building jobs ahead of yours in the queue, delaying when we can start building your index.

8. The value for 'Stored Data' is updated once a day

Once a day, we run a task to recalculate the 'Stored Data' figure for your app based on your actual datastore usage at that time. In the intervening period, we update the figure with an estimate of your usage so we can give you immediate feedback on changes in your usage. This explains why many people have observed that after deleting a large number of entities, theirdatastore usage remains at previous levels for a while. For billing purposes, only the authoritative number is used, naturally.

9. The order that handlers in app.yaml, web.xml, and appengine-web.xml are specified in matters

One of the more common and subtle mistakes people make when configuring their app is to forget that handlers in the application configuration files are processed in order, from top to bottom. For example, when installing remote_api, many people do the following:

- url: /.*

- url: /remote_api
script: $PYTHON_LIB/google/appengine/ext/remote_api/
login: admin

The above looks fine at first glance, but because handlers are processed in order, the handler for is encountered first, and all requests - even those for remote_api - get handled by Since doesn't know about remote_api, it returns a 404 Not Found error. The solution is simple: Make sure that the catchall handler comes after all other handlers.

The same is true for the Java runtime, with the additional constraint that all the static file handlers in appengine-web.xml are processed before any of the dynamic handlers in web.xml.

10. You don't need to construct GQL strings by hand

One anti-pattern that comes up a lot looks similar to this:

q = db.GqlQuery("SELECT * FROM People "
"WHERE first_name = '" + first_name
+ "' AND last_name = '" + last_name + "'")

As well as opening up your code to injection vulnerabilities (link), this practice introduces escaping issues (what if a user has an apostrophe in their name?) and potentially, encoding issues. Fortunately,GqlQuery has built in support for parameter substitution, a common technique for avoiding the need to substitute in strings in the first place. Using parameter substitution, the above query can be rephrased like this:

q = db.GqlQuery("SELECT * FROM People "
"WHERE first_name = :1 "
"AND last_name = :2", first_name, last_name)

GqlQuery also supports using named instead of numbered parameters, and passing a dictionary as an argument:

q = db.GqlQuery("SELECT * FROM People "
"WHERE first_name = :first_name "
"AND last_name = :last_name",
first_name=first_name, last_name=last_name)

Aside from cleaning up your code, this also allows for some neat optimizations. If you're going to execute the same query multiple times with different values, you can useGqlQuery .bind() to 'rebind' the values of the parameters for each query. This is faster than constructing a new query each time, because the query only has to be parsed once:

q = db.GqlQuery("SELECT * FROM People "
"WHERE first_name = :first_name "
"AND last_name = :last_name")
for first, last in people:
q.bind(first, last)
person = q.get()
print person

Posted by Nick Johnson, App Engine Team

[Gd] The Developer Sandbox, now with Video Interviews!

| More

Google Code Blog: The Developer Sandbox, now with Video Interviews!

The Developer Sandbox was a new addition to this year's Google I/O. The Sandbox featured a diverse range of developers and apps, all with one thing in common -- they've all built applications based on technologies and products featured at I/O. The Sandbox was very popular with attendees and saw a lot of foot traffic throughout both days of the event. Sandbox developers welcomed the opportunity to interact with fellow developers, discuss their products and answer questions.

We interviewed these developers about their apps, the challenges they faced and the problems they solved, and finally their learnings & hopes for web technologies going forward. We also asked these developers to create screencast demos of their apps, much like the demos they gave to people visiting their station during I/O.

These video interviews and demos are now available in the Developer Sandbox section of the I/O website. Each developer has their own page with a brief description of their company, their app, and their interview video (if one was filmed) and screencast demo video (if available). For instance, here's a video interview with Gustav Soderstrom of Spotify, who walks us through a demo of their Android app and then talks about the platform and why Spotify chose to develop their app on Android.

Are you building an app on one of Google's platforms or using Google APIs? Please send us a video about your company and your app and you could be featured on Google Code Videos. Click here for the submission form and guidelines.

Each Sandbox developer page also features a Friend Connect gadget that allows anyone visiting the page to sign in with their Friend Connect id and leave comments & feedback. It's a great way to continue the conversation or to ask questions if you did not get a chance to meet them at I/O.

By Neel Kshetramade, Google Developer Programs

[Gd] Pilot a Ship in Google Earth

| More

Featured Projects on Google Code: Pilot a Ship in Google Earth


Google APIs used:

Google Earth API

Pilot a ship around Google Earth in your browser. Amazing 3D graphics and controls.


[Gd] Tech Talk Videos from Google I/O

| More

Google Code Blog: Tech Talk Videos from Google I/O

This year's Tech Talk sessions at Google I/O cast light on a few key ingredients necessary for developing great software and applications, including faster methods and techniques, a re-envisioning of how to do things better, down to a robust architecture that is designed to scale and sustain. At the same time, developers themselves need to successfully manage the growth of new ideas in a collaborative environment, while remembering to put the user and customer first.

Kicking off Tech Talks at Google I/O this year, Steve Souders challenged developers to build faster, high-performing websites and presented a few best practices and tactics to these ends. Dhanji Prassana and Jesse Wilson revealed the fast, lightweight Guice framework and how it is used at Google to power some of the largest and most complex applications in the world. Dion Almaer and Ben Galbraith walked the audience through the Bespin project at Mozilla Labs in their session, expanding on the project's core motivation to re-envision how we develop software and to provide pointers on what it takes to build bleeding edge applications for today's browsers. Jacob Lee unveiled the architecture behind Mercurial on BigTable, a new version-control component of Project Hosting on Google Code that was built to host hundreds of thousands of open source projects.

Brian Fitzpatrick and Ben Collins-Sussman ran a duet of talks that turned the focus from the tools to the developer. First, they discussed the myth of the "genius programmer" in the social dynamics of collaborative software development. In a subsequent session, they talked about the lost art of putting the user first and "selling" the software in an exciting and honest manner through usability and uncomplicated design. Keeping with the focus on developers and what motivates developers to action, we invited Brady Forrest to run an Ignite session at Google I/O, featuring nine speakers with deeply interesting perspectives on technology. Topics ranged from growing up a geek, big data and open source, and the law of gravity for scaling, to life as a developer at the frontlines with a humanitarian agency.

We also wanted to share one of our favorite tidbits from Google I/O -- a series of ink on paper portraits by Dave Newman, an ex-courtroom sketch artist (now enthusiastic technologist!). Dave put his pen to paper at the conference floor and drew wonderful sketches of a few of the folks at I/O - we're delighted to share a few of his portrait sketches.

We hope you enjoy this year's interesting combination of perspectives at the Google I/O Tech Talks series, now available online. Watch the blog next week as we bring live more videos and presentations from the breakout session tracks at Google I/O!

By Min Li Chan, Google Developer Products

[Gd] SEO Starter Guide now available in 40 languages

| More

Official Google Webmaster Central Blog: SEO Starter Guide now available in 40 languages

Webmaster Level: Beginner

Since the release of our Search Engine Optimization Starter Guide last November, we've steadily been adding localized versions for our international users. Today, we're happy to announce that the guide is now available in 40 languages, which covers 98% of the global Internet audience. We hope that webmasters around the world can use the guide to improve their sites' crawlability and indexing in search engines.

We'd also like to thank everyone for their continued feedback on the guide. We're taking notes on what you liked and what you thought was missing for use in future updates and possibly a version for advanced users.

Here's a list of the languages available:Written by Brandon Falls, Search Quality Team

Thursday, June 4, 2009

[Gd] Danger: Mac and Linux builds available

| More

Chromium Blog: Danger: Mac and Linux builds available

In order to get more feedback from developers, we have early developer channel versions of Google Chrome for Mac OS X and Linux (for a couple of different Linux distributions), but whatever you do, please DON'T DOWNLOAD THEM! Unless of course you are a developer or take great pleasure in incomplete, unpredictable, and potentially crashing software.

How incomplete? So incomplete that, among other things , you won't yet be able to view YouTube videos, change your privacy settings, set your default search provider, or even print.

Meanwhile, we'll get back to trying to get Google Chrome on these platforms stable enough for a beta release as soon as possible!

Posted by Mike Smith and Karen Grunberg, Product Managers

[Gd] Introducing Page Speed

| More

Google Code Blog: Introducing Page Speed

At Google, we focus constantly on speed; we believe that making our websites load and display faster improves the user's experience and helps them become more productive. Today, we want to share with the web community some of the best practices we've used and developed over the years, by open-sourcing Page Speed.

Page Speed is a tool we've been using internally to improve the performance of our web pages -- it's a Firefox Add-on integrated with Firebug. When you run Page Speed, you get immediate suggestions on how you can change your web pages to improve their speed. For example, Page Speed automatically optimizes images for you, giving you a compressed image that you can use immediately on your web site. It also identifies issues such as JavaScript and CSS loaded by your page that wasn't actually used to display the page, which can help reduce time your users spend waiting for the page to download and display.

Page Speed's suggestions are based on a set of commonly accepted best practices that we and other websites implement. To help you understand the suggestions and rules, we have created detailed documentation to describe the rationale behind each of the rules. We look forward to your feedback on the Webmaster Help Forum.

We hope you give Page Speed a try.

By Richard Rabbat and Bryan McQuade, Page Speed Team

[Gd] Dev Channel Release

| More

Google Chrome Releases: Dev Channel Release

Google Chrome has been released to the Dev channel.

Highlights for this release:
  • Fixed issue where non-media types such as text would display a media player. (Issue: 12777)
  • New Downloads page shows the remaining time left for downloads. (Issue: 9607)
  • Various fixes for right-to-left langugages
  • Multiple crash and usability fixes.

Known Issue:
  • Google Chrome crashes on Windows XP when you click the "Reset to default theme" button (Issue 13075).

Version Changes:
  • V8 -

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

Anthony Laforge
Technical Program Manager

[Gd] Introducing Page Speed

| More

Official Google Webmaster Central Blog: Introducing Page Speed

At Google, we focus constantly on speed; we believe that making our websites load and display faster improves the user's experience and helps them become more productive. Today, we want to share with the web community some of the best practices we've used and developed over the years, by open-sourcing Page Speed.

Page Speed is a tool we've been using internally to improve the performance of our web pages -- it's a Firefox Add-on integrated with Firebug. When you run Page Speed, you get immediate suggestions on how you can change your web pages to improve their speed. For example, Page Speed automatically optimizes images for you, giving you a compressed image that you can use immediately on your web site. It also identifies issues such as JavaScript and CSS loaded by your page that wasn't actually used to display the page, which can help reduce time your users spend waiting for the page to download and display.

Page Speed's suggestions are based on a set of commonly accepted best practices that we and other websites implement. To help you understand the suggestions and rules, we have created detailed documentation to describe the rationale behind each of the rules. We look forward to your feedback on the Webmaster Help Forum.

Posted by Richard Rabbat and Bryan McQuade, Page Speed Team

[Gd] Google Wave @ Google I/O

| More

Google Code Blog: Google Wave @ Google I/O

The high point of presenting Google Wave at I/O? The joy of seeing crazy smart developers react to the product and technology as we showed it publicly for the first time. The low point? Typing twephanie's Twitter password in clear text on the big screen (luckily, a team member reset it before anything questionable happened!). We had the chance to continue the Google Wave conversations through breakout sessions, which we are happy to now make available in the Google I/O series of videos now available online, and in office hours with the engineering team.

Douwe Osinga kicked off the series with a deep dive into the Google Wave APIs using demos and code samples to show how waves can be embedded into other sites as well as how to extend Wave with both client- and server-side code. After the wow of the chess gadget and the 'Rosy' robot demos during the keynote, developers flocked to the Programming with and for Google Wave session to learn how to start building extensions themselves. Notice how Douwe's good humor persevered through even tougher network problems than we had in the keynote.

The next session, Google Wave: Under the Hood, focused on core technologies behind Google Wave, diving into the heavy lifting we did in platform design to make it simple for developers to build concurrent applications. David Wang introduced the technology stack behind Google Wave's real-time collaboration and concurrency controls followed by an explanation of the operational transformation algorithms by Alex Mah. Dan Danilatos explained how the AJAX editor renders wave content and sends and receives fine-grained changes down to the level of keystrokes. Finally, Casey Whitelaw unveiled the natural language processing magic behind 'Spelly' our context-sensitive spelling system.

In the third and final session, Adam Schuck outlined the team's experience using Google Web Toolkit to build the Google Wave client. Adam went from GWT skeptic to zealous GWT advocate over the course of building Google Wave. In his talk, Adam covered some recent advances in GWT which enabled Google Wave to look and feel like a desktop application with comparable performance. He also discussed the use of WebDriver (an automated web testing tool) which is integral to the project's success.

We simply can't wait to see what developers build. Check out our docs on Google Code and request a developer sandbox account. For technical news and updates on the APIs and protocol, don't forget to bookmark the Google Wave Developer Blog .

By Stephanie Hannon, Google Wave Team

[Gd] Android: Now beaming I/O videos and presentations to the world

| More

Google Code Blog: Android: Now beaming I/O videos and presentations to the world

Google I/O was one of Android's biggest events of the year, with a Mobile track that focused primarily on all things Android, and 22 developers showcasing some of their great Android applications at the Google I/O developer sandbox.

For those of you who missed I/O or could not make all the Android sessions, we're excited to release session videos and presentations from the Mobile track online and free to developers worldwide.

At this year's I/O, we wanted to help developers further optimize their applications for the Android platform by creating better user experiences. Romain Guy explored techniques for making Android apps faster and more responsive using the UI toolkit. Chris Nesladek discussed the use of interaction design patterns in the Android system framework to create an optimal user experience. Since mobile application development is inextricably tied to battery performance, Jeff Sharkey provided an insightful look at the impact of different application features and functionalities on battery life. Taking the mobile experience further, T.V. Raman and Charles Chen discussed building applications that are optimized for eyes-busy environments, taking advantage of the Text-to-Speech library, as well as new UI innovations that allow a user to interface with the device without needing to actually look at the screen.

We also offered a few sessions on building compelling and fun apps that take advantage of the Android media framework and 2D and 3D graphic libraries. Chris Pruett discussed the gaming engine that he built and used as a case study to explain best practices and common pitfalls in building graphics-intensive applications. David Sparks lifted the hood on the infrastructure by diving into Android's multimedia capabilities and expanding on how to use them to write secure and battery-efficient media code.

We also had several sessions that meditate on challenges, best practices, and philosophies for writing apps for Android. Dan Morrill demonstrated multiple techniques for developing apps for Android in different scenarios, to help developers make the right decisions on the right techniques for writing their apps. Joe Onorato talked to developers about leveraging Android's ability to support multiple hardware configurations to make their applications run on a wide variety of devices without the overhead of building a custom version for each. Justin Mattson talked about advanced usage of Android debugging tools in his session and presented real-world examples in which these tools were used at Google.

Lastly, Robert Kroeger returns from the frontlines of launching Gmail Mobile Web for iPhone and Android's offline capabilities and shares the team's experiences in using a portable write-through caching layer running on either HTML 5 or Gears databases to build offline-capable web applications.

We hope these session videos and presentations are helpful to all Android developers out there. Don't forget to check out our newly announced Android Developer Challenge 2 - we look forward to seeing your passion, creativity, and coding prowess come together in the great apps you submit in this next challenge!

By Azhar Hashem, Google Developer Products

Wednesday, June 3, 2009

[Gd] Web Developers: Keeping Up With Google Chrome

| More

Chromium Blog: Web Developers: Keeping Up With Google Chrome

Google Chrome is moving fast. Version 2.0 was stabilized just six months after 1.0, and auto-updates have ensured that nearly all users are using the newest version of the browser within days of a release. As a web developer, it can be a bit daunting that the browser version changes so fast: What if the new version breaks something? How can I be prepared for changes that will affect my sites?

To answer these questions, it's helpful to know how Google Chrome releases are made, the relationship between "dev," "beta," and "stable" update channels, and how you can test new versions. In this post, we'll be expanding on Mark Larson's earlier explanation of the update channel system.
  • Stable channel. As Mark outlines, the Stable channel is, well, stable. As a web developer, that means that as long as the major version — the "2" in "version" — doesn't change, you can count on Stable channel builds to use the same versions of WebKit (CSS, layout, etc.), V8 (JavaScript), and other components that might affect how a page loads or renders. Stable updates between major version releases are generally focused on addressing security issues, fixing egregious bugs, and improving stability. The big developer-facing bits of the browser won't change on the Stable channel until the next major version is released, and you can always preview upcoming changes using the Beta channel.
  • Beta channel. As a web developer, being on the Beta channel will ensure that you can test your sites with the next version of Google Chrome's rendering behavior before it's sent to the Stable channel and into the hands of most users. Whenever a major version lands in the Beta channel, the versions of WebKit, V8, networking, and the other systems that affect how web pages load and render generally become fixed. These versions may change during the major version's beta cycle, but changes are usually incremental fixes to help stabilize a feature rather than changes in behavior. New versions of WebKit may be introduced during a beta period, but those versions are always accompanied by a new build number (e.g. 2.0.169.xx vs. 2.0.172.xx) and are unlikely to differ drastically. As this major version moves closer to a stable release, these kinds of changes become more and more infrequent. Since Google Chrome development moves so quickly, you should stay on the Beta channel to catch compatibility issues ahead of time.
  • Dev channel. The Dev channel is where the sausage gets made. Dev releases happen frequently, and they track what's happening upstream in WebKit, V8, and other relevant systems very closely. This means that changes that might affect rendering, performance, and layout are likely to occur on the Dev channel on a regular basis. We don't recommend that you install the Dev channel if you're looking to maintain site compatibility, since tracking breaking changes as they happen can be a major headache. You should be able to spot any problems early enough via the Beta channel.
Users are on the Stable channel by default. To get onto the Beta or Dev channel, follow these instructions. Once you change to a less stable channel, e.g. from Stable to Dev, there isn't a supported "downgrade" path. If you change from the less stable channel back to a more stable one, Google Chrome will simply stop updating until your new channel "catches up" with the installed build. To force an immediate downgrade, uninstall and reinstall using an appropriate installer. This may occasionally cause errors when your more stable (older) version tries to read the newer user data left over from the previous installation.

Once you have a copy of Google Chrome, you can test your site's compatibility. Google Doctype has a helpful FAQ on best practices for Google Chrome compatibility. In short, prefer object detection over userAgent string parsing; don't rely on pixel-accurate font and element sizes; declare your pages' encodings correctly; double check <object> and <embed> parameters; check for illegal markup; and avoid browser-specific CSS.

The Chromium and WebKit teams work hard to ensure compatibility with websites. If after reading the above you discover browser problems, please don't hesitate to file a bug. If a particular problem with your site occurs in both Google Chrome and a corresponding version of Safari, it may be due to a WebKit issue, which you can file in the WebKit bug tracker. If the problem only happens in Google Chrome, log an issue in the Chromium bug tracker.

Posted by Alex Russell, Software Engineer

[Gd] Activities and Tasks Design Guidelines

| More

Android Developers Blog: Activities and Tasks Design Guidelines

For our third post in the series of Android UI, we're releasing Activity and Task Design Guidelines. This section of our guidelines aims to help you understand basic concepts of activities and tasks, how they work, and how to enrich the user experience you are creating.

We've packed a lot into this section, which is targeted at designers and developers. You'll see examples that will illustrate how to use our core principles and mechanisms, such as multitasking, activity reuse, intents, and the back stack.

Additionally, we are providing some best practices around our UI patterns such as notifications. For example, we'll show you how to design a notification so that it will take the user to the screen they expect. This behavior needs to be thought out, and doesn't necessarily just happen by default.

With helpful pointers to the API's and this documentation, we look forward to building your understanding of what it means to design and develop an Android UI.


[Gd] Google I/O: Now online, starting with all things Client

| More

Google Code Blog: Google I/O: Now online, starting with all things Client

The Google Client Team had an exciting and inspiring two days last week at Google I/O. We had the opportunity to talk to developers and have insightful conversations on what we're doing in the realm of HTML 5, Chrome, V8, Native Client, and 3D graphics on the web.

Today we're excited to reflect on these conversations at I/O, and kick off a series of videos and presentations from Google I/O. Starting with the Client track today, session videos and presentations from I/O will be posted online over the course of the next seven days and free to the world, on the Google I/O website.

Chrome: Extensions, Internals, V8 and more

Aaron Boodman gave a great talk on creating extensions for Chrome, and built several extensions live during his talk. I think this reflects our commitment to make it easy to build extensions, and I hope that developers -- not only those in the room, but those around the world who watch the recorded video of Aaron's talk -- will be inspired to create great extensions.

Darin Fisher delved into Chrome internals, managing to cover large swaths of Chrome code, philosophy, and lore without breaking a sweat. Darin's talk is a great way for developers to see that Chrome is more than just a fast browser with a slick UI -- we believe that developers at I/O came away realizing that there is a lot going on behind the scenes that sets Chrome apart.

Mads Ager talked about V8, walking attendees through the reason Google decided to build a new JavaScript engine, how some of the internals of V8 work including hidden classes, inline caching and garbage collection, and recent improvements made to further speed up JavaScript execution in V8. We were glad to present a thought-provoking session for developers, as attendees left the session with impressed and contemplative looks on their faces.

HTML5, Native Client, O3D and moving the web forward

Matt Papakipos, in addition to making an appearance in Wednesday's keynote, gave a great talk on where Chrome is, with respect to HTML5 and the open web platform. He explored what the platform means for developers, how they can use it, as well as the vision going forward. Matt delivered this talk to a packed room - attendees were spilling out to the aisles and doorways in our largest session room at the Moscone Convention Center in San Francisco. We're thrilled and humbled that developers are as excited as we are about the web platform and where we are taking it.

At the session on Native Client, Brad Chen got developers excited about the possibility of running native code as part of their web applications. Brad gave a comprehensive low-down on how Native Client works, and how it can be used to further strengthen the platform and move the web forward.

Vangelis Kokkevis and Gregg Tavares gave a talk on bringing 3D graphics to the web via O3D. Vangelis started the presentation with an overview of the O3D project and its goals and highlighted some its most significant features. Gregg then took over and demonstrated how, in a few simple steps, one can go from a blank HTML page to the beginnings of an entertaining mini-game with only a handfull of calls to the O3D API.

In addition, Henry Bridge led a panel with developers from Large Animal and Crazy Pixel, sharing insights about developing 3D graphics applications using O3D and getting developers excited about 3D on the web. You can also view sandbox video interviews with these two developers (Large Animal, Crazy Pixel) in the Developer Sandbox section, along with many other developers.

Browsers and standards development

To give developers more insight into how standards development and implementation in browsers work, we put together a panel with Jonas Sicking from Mozilla, Charles McCathieNevile from Opera, and myself, moderated by Mike Schroepfer (formerly of Mozilla now at Facebook). At this session, we talked more about the vision advanced by various browsers, and deliberated questions on where the browsers and the web are going.

Beyond the sessions, I/O provided the Client team the opportunity to interact with developers through Fireside Chats, where developers freely asked a broad range of questions. We also staffed Chrome Office Hours, where I/O attendees could stop by with their burning questions about the browser and chat with the team. We got developers excited about Chrome extensions, HTML5, <video>, O3D and more at the the Client developer sandbox pod.

All in all, we're thrilled to have spent two days with developers in conversation about Chrome, the web platform, and a shared future that we are all working so hard to create. We're excited to now bring these conversations to a larger community of developers with our I/O session videos and presentations. If you like, drop us comments through the Google Friend Connect gadget we have enabled on the session web pages - we'd be delighted to hear from you.

By Ian Fette, Chrome Team

Tuesday, June 2, 2009

[Gd] Post Google I/O 2009

| More

Google Code Blog: Post Google I/O 2009

We would like to thank the thousands of developers who joined us last week and made this year's Google I/O a wonderful developer gathering. We announced some of the things we've been working on and shared our thoughts on the future of the web. 140 companies joined us to showcase what they've been working on and talk about their experiences building web applications. We hope you left I/O inspired with new ideas for your own products. Our engineers were pumped to get your feedback and were inspired by what they learned from conversations at Office Hours, in the Sandbox, and during the After Hours party.

If you missed a session you really wanted to see at Google I/O, you'll be happy to know that over 70 of the sessions (videos and slides) will be made available over the next few days. For your convenience, you'll also be able to download those videos to view them on the go.

These will be going live soon at We'll be releasing I/O content in the following waves:
  • Wed, June 3: Client (Chrome, HTML 5, V8, O3D, Native Client, and more)
  • Thurs, June 4: Google Wave, Mobile/Android
  • Fri, June 5: Tech Talks
  • Mon, June 8: Google Web Toolkit, App Engine, Enterprise
  • Tues, June 9: AJAX + Data APIs, Social
You can check out some of our favorite Google I/O photos here. In addition, check out video interviews with the 3rd Party developers featured in our Developer Sandbox, and see how they've implemented products & technologies represented at I/O.

We've gotten many inquiries about the opening video for the Day 1 keynote. The video is comprised of different Chrome Experiments and the soundtrack music and lyrics were created by our very own Matt Waddell. Lastly, wondering why the Lego character on the Google I/O t-shirt is holding a spray can? For those of you who have t-shirts, turn off your room light and see what's written on the back of the green brick :)

Stay tuned for more updates on Google I/O!

By Azhar Hashem, Google Developer Products

[Gd] James Whittaker joins Google

| More

Google Testing Blog: James Whittaker joins Google

By Patrick Copeland

I'm excited to announce that James Whittaker has joined us as our newest Test Director at Google. 

James comes to us most recently from Microsoft. He has spent his career focusing on testing, building high quality products, and designing tools and process at the industrial scale. In the not so distant past, he was a professor of computer science at Florida Tech where he taught an entire software testing curriculum and issued computer science degrees with a minor in testing (something we need more schools to do). Following that , he started a consulting practice that spanned 33 countries. Apparently, fashion is not high on his list as he he has collected soccer jerseys from many of these countries and wears those during major tournaments. At Microsoft he wrote a popular blog, and in the near future you can expect him to start contributing here. 

He has trained thousands of testers worldwide. He's also written set of books in the How to Break Software series. They have won awards and achieved best seller status. His most recent book is on exploratory testing is coming out this summer. It is not a stretch to say that he is one of the most recognizable names in the industry and has had a deep impact on the field of testing. If you have a chance, strike up a conversation with James about the future of testing. His vision for what we'll be doing and how our profession will change is interesting, compelling and not just a little bit scary.

Join me in welcoming James to Google!

[Gd] Google Wave team heads to Google Developer Days in Asia

| More

Google Wave Developer Blog: Google Wave team heads to Google Developer Days in Asia

Since Google Wave was unveiled as a developer preview at Google I/O, a few of us are heading on the road to let more developers know about the API platform and the underlying federation protocol. Later this week, some of us will be participating in Google Developer Day Beijing (Friday, June 5). Here are a couple of the sessions:

The Google Wave APIs
Speaker: David Byttow
In this session, we will show how to use the Google Wave APIs through demos and code samples. Learn how to add waves to your web site, extend Google Wave with both client- and server-side code, and integrate Google Wave with other services like Twitter or your favorite bug database.

The Google Wave Client: Powered by GWT
Speaker: Adam Schuck
This talk follows the Google Wave team's experience building the Google Wave client using Google Web Toolkit (GWT). We'll cover some recent advances in GWT which enabled Google Wave to look and feel like a desktop application with comparable performance. In addition, we will discuss the use of WebDriver (an automated web testing tool) which is integral to the project's success.

Next week, if you're in Japan, you can join Greg D'alesandre, Douwe Osinga, David Wang, and Daniel Danilatos at Google Developer Day Tokyo (Tuesday, June 9). Douwe will be presenting about the Google Wave APIs as well.

To get a deeper understanding of the Google Wave APIs, please request a sandbox account, check out the documentation, and review the code samples.

Stay tuned for more about our plans for events later in June in Sydney, AU and Sao Paulo, Brazil.

Posted By: Dan Peterson, Product Manager, Google Wave

[Gd] Hi5 launches hi5 Coins payment platform using OpenSocial Virtual Currency API

| More

OpenSocial API Blog: Hi5 launches hi5 Coins payment platform using OpenSocial Virtual Currency API

Ever since launching our OpenSocial platform in March 2008, developers have been eager for a unified payment platform for collecting micro-transactions on hi5. Over the past year, we have moved ahead to make such a virtual currency platform available to developers while ensuring a positive user experience for our members. Over the last few weeks, hi5 has been launching our first third-party games integrated via OpenSocial-compliant APIs to our virtual currency platform – providing a standard payment method for developers to monetize their applications through our audience of over 60 million active users around the world.

The first step in this progression was the launch of our virtual currency back in December 2008, which allowed users to buy hi5 Coins and use them to purchase virtual goods on the site. This platform was initially accessible only for hi5 premium features like Gifts. We rapidly expanded the ways that users could get real currency into the system – going beyond credit/debit cards to include payment methods, such as mobile SMS, offers and alternate cards, like Ultimate Game cards, that are popular in different parts of the world.

The next step was to make our payments interface OpenSocial compliant. In order to make our virtual currency more universal across hi5 and non-hi5 applications, our OpenSocial platform team collaborated with other containers to propose an OpenSocial Virtual Currency API as an extension to the OpenSocial specification. Our virtual currency interface was expedited due to the work started by other OpenSocial containers like,, and With real use cases from Asia, Europe and Latin America, the containers quickly converged on the API specifications.

The hi5 OpenSocial Virtual Currency interface is already live in public beta with several third-party developers like RockYou (RockYou Pets), Playdom (Poker Palace) and Small Worlds, enabling them to collect direct user payments within their games. We have a number of additional partnerships that will launch soon. OpenSocial developers can now leverage a standard virtual currency spec across containers – allowing them to monetize through micro-transactions without worrying about the details of payment processing, currency conversions, localized payment methods or other logistical challenges. Our users benefit, as well, with more outlets for spending their hi5 Coins and a simplified and familiar process for making payments on the hi5 site. We look forward to continuing to work with the OpenSocial community to innovate on the virtual currency standard and to make micro-transactions between users and developers a viable and growing revenue stream.

Posted by Anil Dharni, VP of Products at hi5 and member of the OpenSocial Foundation Board of Directors

[Gd] My Selenium Tests Aren't Stable!

| More

Google Testing Blog: My Selenium Tests Aren't Stable!

By Simon Stewart

It's a complaint that I've heard too many times to ignore: "My Selenium tests are unstable!" The tests are flaky. Sometimes they work, sometimes they don't. How deeply, deeply frustrating! After the tests have been like this for a while, people start to ignore them, meaning all the hard work and potential value that they could offer a team in catching bugs and regressions is lost. It's a shameful waste, but it doesn't have to be.

Firstly, let's state clearly: Selenium is not unstable, and your Selenium tests don't need to be flaky. The same applies for your WebDriver tests.

Of course, this raises the obvious question as to why so many selenium tests fail to do what you intended them to. There are a number of common causes for flaky tests that I've observed, and I'd like to share these with you. If your (least) favourite bugbear isn't here, please tell us about it, and how you would like to approach fixing it, in a comment to this post!

Problem: Poor test isolation.
Example: Tests log in as the same user and make use of the same fixed set of data.
Symptoms: The tests work fine when run alone, but fail "randomly" during the build.
Solution: Isolate resources as much as makes sense. Set up data within the tests to avoid relying on a "set up the datastores" step in your build (possibly using the Builder pattern). You may want to think about setting up a database per developer (or using something like Hypersonic or SQLite as a light-weight, in-memory, private database) If your application requires users to log in, create several user accounts that are reserved for just your tests, and provide a locking mechanism to ensure that only one test at a time is using a particular user account.

Problem: Relying on flaky external services.
Example: Using production backends, or relying on infrastructure outside of your team's control
Symptom: All tests fail due to the same underlying cause.
Solution: Don't rely on external services that your team don't control. This may be easier said than done, because of the risk of blowing out build times and the difficulty of setting up an environment that models reality closely enough to make the tests worthwhile. Sometimes it makes sense to start servers in-process, using something like Jetty in the Java world, or webrick in Ruby.

Watching the tests run is a great way to spot these external services. For example, on one project the tests were periodically timing out, though the content was being served to the browser. Watching the tests run showed the underlying problem: we were serving "fluff" --- extra content from an external service in an iframe. This content was sometimes not loading in time, and even though it wasn't necessary for our tests the fact it hadn't finished loading was causing the problem. The solution was to simply block the unnecessary fluff by modifying the firewall rules on the Continuous Build machine. Suddenly, everything ran that little bit more smoothly!

Another way to minimize the flakiness of these tests is to perform a "health check" before running the tests. Are all the services your tests rely on running properly? Given that end-to-end tests tend to run for a long time, and may place an unusual load on a system, this isn't a fool-proof approach, but it's better to not run the tests at all rather than give a team "false negatives".

Problem: Timeouts are not long enough
Example: You wait 10 seconds for an AJAX request that takes 15 to complete
Symptom: Most of the time the tests run fine, but under load or exceptional circumstances they fail.
Solution: The underlying problem here is that we're attempting to determine how long something that lasts a non-deterministic amount of time will take. It's just not possible to know this in advance. The most sensible thing to do is not to use timeouts. Or rather, do use them, but set them generously and use them in conjunction with a notification from the UI under test that actions have finished so that the test can continue as soon as possible.

For example, it's not hard to change the production code to set a flag on the global Javascript "window" object when an XmlHttpRequest returns, and that could form the basis of a simple latch. Rather than polling the UI, you can then just wait for the flag to be set. Alternatively, if your UI gives an unambiguous "I'm done" signal, poll for that. Frameworks such as Selenium RC and WebDriver provide helper classes that make this significantly easier.

Problem: Timeouts are too long
Example: Waiting for a page to load by polling for a piece of text, only to have the server throw an exception and give a 500 or 404 error and for the text to never appear.
Symptom: Your tests keep timing out, probably taking your Continuous Build with them.
Solution: Don't just poll for your desired end-condition, also think of polling for well-known error conditions. Fail the test with an informative error message when you see the error condition. WebDriver's SlowLoadableComponent has an "isError" method for exactly this reason. You can push the additional checks into a normal Wait for Selenium RC too.

The underlying message: When your tests are flaky, do some root cause analysis to understand why they're flaky. It's very seldom because you're uncovered a bug in the test framework. In order for this sort of analysis and test-stability improvement work to be done effectively, you may well need support and help from your team. If you're working on your own, or in a small team, this may not be too hard. On a large project, it may be harder. I've had some success when a person or two is set aside from delivering functionality to work on making the tests more stable. The short-term pain of not having that extra pair of hands focusing on writing production code is more than made up for by the long-term benefit of a stable and effective suite of end-to-end tests that only fail when there's a real issue to be addressed.

Monday, June 1, 2009

[Gd] Google Chrome, Sandboxing, and Mac OS X

| More

Chromium Blog: Google Chrome, Sandboxing, and Mac OS X

Sandboxing is a technique that Google Chrome employs to help make the browser more secure, and was discussed in a previous blog post. On Windows, getting a process sandboxed in a way that's useful to us is a pretty complicated affair. The relevant source code consists of over 100 files and is located under the sandbox/ directory in Chromium's Open Source repository. But for our Mac and Linux ports, sandboxing is a very different story. On Linux there are a number of different sandboxing mechanisms available. Different Linux distributions ship with different (or no) sandboxing APIs, and finding a mechanism that is guaranteed to work on end-user's machines is a challenge. Fortunately, on Mac OS X, the OS APIs for sandboxing a process are easy to use and straightforward.

Sandboxing on the Mac

Starting a sandbox involves a single call to sandbox_init() specifying which resources to block for a specific process. In our case we lock down the process pretty tightly. That means no network access, and very limited or no access to files and Mach ports.

When Chromium starts a renderer process, we open an IPC channel (a UNIX socketpair) back to the browser process before turning on the sandbox. Any resources a process owns before turning on the sandbox stay with the process, so this channel can still be used after the sandbox is enabled. When we want to pass a shared memory area between processes, we send it over as an mmaped file handle using the sendmsg() API. We don't need to do anything else, as Apple's sandbox API is smart enough to allow access to file descriptors passed between processes in this manner even if the receiving process itself is forbidden from calling open().

One sticky point we run into is that the sandboxed process calls through to OS X system APIs. There is no documentation available about which privileges each API needs, such as whether they need access to on-disk files, or call other APIs to which the sandbox restricts access. Our approach to date has been to "warm up" any problematic API calls before turning the sandbox on. This means that we call through to the API, to allow it to cache whatever resource it needs. For example, color profiles and shared libraries can be loaded from disk before we "lock down" the process. To get a more complete understanding of our use of the sandbox in OSX, you can read the OSX sandboxing design doc.

As we continue the porting efforts for Chromium on the Mac, it's very satisfying to see the puzzle pieces fit into place alongside the native system APIs. It's important to us that the Mac port of Chromium feels and performs like a native Mac application, and that it provides the kind of high-quality experience Mac users expect.

Posted by Jeremy Moskovich, Software Engineer

[Gd] Webmaster Central YouTube update for May 26-29

| More

Official Google Webmaster Central Blog: Webmaster Central YouTube update for May 26-29

In February, we launched the Webmaster Central YouTube channel, and since then we've been busy keeping it fresh with new content. We're not yet uploading 20 hours every minute, but did you know that we've been releasing a new video almost every weekday? You can keep up with the latest updates by subscribing to our channel in YouTube, or by adding our feed to your RSS reader.

If you're more of a weekly digest kind of person, we're here for you too. For every week that we have new videos available, we'll let you know here on the blog. In the videos uploaded in the past week, you'll find answers to these questions from Matt's Grab Bag:

Can product descriptions be considered duplicate content?
How can new pages get indexed quickly?
What are your views on PageRank sculpting?
Will you ever switch to a Mac?

Feel free to leave comments letting us know how you liked the videos, and if you have any specific questions, ask the experts in the Webmaster Help Forum.

Posted by Michael Wyszomierski, Search Quality Team

[Gd] [image: Screenshot] Author and view Google Earth tours in

| More

Featured Projects on Google Code: [image: Screenshot]
Author and view Google Earth tours in



Google APIs used:

Google Earth API

Snoovel allows you to create and view Google Earth tours in your browser and share them with others.


[Gd] A search box for Blogger

| More

Google Custom Search: A search box for Blogger

Posted by: Nicholas Weininger, Software Engineer

Custom Search enables anyone to create a tuned search experience that's contextually relevant. For example:
  • Individuals can create a personalized search experience around their bookmarks, blogs, and public web sites
  • Web site owners can provide Site Search
  • Publishers can provide search across multiple publications
  • Communities can collaborate to create topical search engines across thousands of web pages
For bloggers, blogging platforms typically provide in-built search tools that allow searching across published blog posts, or across tags and categories. With Custom Search, you can go one step further: you can define a search experience that evolves over time, and includes not just your blog posts, but links extracted from those posts, as well as links from your blog's link lists and blog lists - in short, all items of interest related to your blog.

If you author a blog on Blogger, we've built a search gadget for you that does this - the AJAX Custom Search gadget creates a Linked Custom Search engine that automatically updates to allow your readers to search your blog's entire neighbo(u)rhood. It is a uniquely flavo(u)red search experience that gets richer over time. Search results appear inline, so your users don't have to leave your blog. The results inherit the look and feel of the blog, as shown in the screenshot below.

On Blogger, you can add the gadget with a couple of clicks:
  1. Edit your blog's layout (Page Elements tab)
  2. Click on "Add a Gadget" and configure the new "Search Box" gadget.
You can configure tabs that will allow your blog's readers to restrict their search to specific link lists or blog lists; you decide which ones you want to configure.

If you are using this gadget, we'd love to hear your feedback in our discussion group.

The AJAX Search and the Custom Search APIs have also been combined to create the Custom Search element that we recently announced at Google I/O.

[Gd] AJAX Custom Search Gadget on Blogger

| More

Google AJAX APIs Blog: AJAX Custom Search Gadget on Blogger

The AJAX Search gadget for Blogger is now available to all users on This gadget accesses a Custom Search Engine (CSE) that is created automatically for your blog and provides search results inline, with the look and feel of your blog. You can get all this with just a few clicks from the Blogger control panel.

One cool feature of the gadget is the 'Linked From Here' feature that searches the pages you've linked to from your blog posts. As you create new posts, we automatically update your search engine to include all the linked pages, as well as all the pages linked from your link lists and blog lists. Check out the gadget — the search results match the look and feel of your blog and show up inline, as shown in the screenshot below. You can click a button to dismiss the results when you are done, and go back to reading the current post.

If you are not using Blogger but use the AJAX Search API, you can still create something similar for your website using Linked Custom Search Engines.

To add this to your site simply use the .setSiteRestriction method in the AJAX Search API as you would to add a normal CSE restriction. For the site argument, use the URL of your website and the makecse tool to create a CSE specification. You can then pass the dynamic CSE definition into the .setSiteRestriction method, as shown below:

var customSearch = new GwebSearch();
var extractLinks = "";

crefUrl : "" +

If you already have a CSE specification, simply pass in the address of your CSE specification as the argument. See this sample for more details.

Or, for an even easier Custom Search implementation (with zero configuration), check out the new Custom Search element.