Friday, May 22, 2009

[Gd] OpenSocial from an Enterprise perspective

| More

OpenSocial API Blog: OpenSocial from an Enterprise perspective

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O.

As a Platform Evangelist at I have the enviable job of evaluating various technologies and how they relate to the platform. Part of my recent exploration has been around the possibility of leveraging social networking for the enterprise, which has led me to explore many social networking technologies, including OpenSocial.

Social and professional networking revolve around people. Customer Relationship Management (CRM) is also all about people, but with a bit of formality around the relationships between the people. In my CRM system, I have friends and colleagues, but I also have relationships with customers and potential customers (contacts and leads in the CRM parlance) that may be friends, professional acquaintances, or complete strangers.

Now, understanding that I have these formal and informal relationships, how do I combine the two in a way that respects all the aspects or characteristics of these relationships? That's a big question.

The platform allows you to address this question by leveraging social networks at the business logic level. That means your integration with a social network is not limited to users viewing apps on a page. Using OpenSocial's REST APIs, you can create solutions that work their magic behind the scenes, allowing true innovation in developing enterprise applications that leverage social and professional networks. is one of several companies building technology to help bring social elements to the enterprise. Next week at Google I/O several of us will be participating in an OpenSocial in the Enterprise panel where we (and you!) can help move this field forward. Come challenge us with your own thought-provoking questions about mixing social and enterprise. You can even start posting your questions now on this Q&A page and we'll address them next week.

Posted by Dave Carroll, Platform Evangelist -

[Gd] Yet Another JavaScript Testing Framework

| More

Google Testing Blog: Yet Another JavaScript Testing Framework

by Miško Hevery & Jeremie Lenfant-engelmann

Did you notice that there are a lot of JavaScript testing frameworks out there? Why has the JavaScript community not consolidated on a single JavaScript framework the way Java has on JUnit. My feeling is that all of these frameworks are good at something but none solve the complete package. Here is what I want out of JavaScript unit-test framework:
I want to edit my JavaScript code in my favorite IDE, and when I hit Ctrl-S, I want all of the tests to execute across all browsers and return the results immediately.

I don't know of any JavaScript framework out there which will let me do what I want. In order to achieve my goal I need a JavaScript framework with these three features:

Command Line Control

Most JavaScript test runners consist of JavaScript application which runs completely in the browser. What this means in practice is that I have to go to the browser and refresh the page to get my results. But browsers need an HTML file to display, which means that I have to write HTML file which loads all of my production code and my tests before I can run my tests. Now since browsers are sandboxes, the JavaScript tests runner can only report the result of the test run inside the browser window for human consumption only. This implies that 1) I cannot trigger running of the tests by hitting Ctrl-S in my IDE, I have to Alt-tab to Browser, hit refresh and Alt-tab back to the IDE and 2) I cannot display my test result in my IDE, the results are in the browser in human readable form only.

On my continuous build machine I need to be able to run the same tests and somehow get the failures out of the browser and on to the status page. Most JavaScript test runners have a very poor story here, which makes integrating them into a continuous build very difficult.

What we need, is the ability to control test execution from command line so that I can trigger it from my IDE, or my continuous build machine. And I need test failures to be reported on the command line (not inside the browser where they are unreachable) so that I can display them in IDE or in continuous build status page.

Parallel Execution

Since most JavaScript test runners run fully in the browser I can only run my test on one browser at a time during my development process. In practice this means that you don't find out about failures in other browser until you have checked in the code to your continuous build machine (if you were able to set it up) and your code executes on all browsers. By that point you have completely forgotten about what you have written and debugging becomes a pain. When I run my test I want to run them on all browser platforms in parallel.

Instant Feedback in IDE

After I hit Ctrl-S on my IDE, my patience for test results is about two seconds before I start to get annoyed. What this means in practice is that you can not wait until the browser launches and runs the tests. The browser needs to be already running. Hitting refresh on your browser manually is very expensive since the browser needs to reload all of the JavaScript code an re-parse it. If you have one HTML file for each TestCase and you have hundred of these TestCases, The browser may be busy for several minutes until it reloads and re-parses the same exact production code once for each TestCase. There is no way you can fit that into the patience of average developer after hitting Ctrl-S.

Introducing JsTestDriver

Jeremie Lenfant-engelmann and I have set out to build a JavaScript test runner which solves exactly these issues so that Ctrl-S causes all of my JavaScript tests to execute in under a second on all browsers. Here is how Jeremie has made this seemingly impossible dream a reality. On startup JsTestDriver captures any number of browsers from any number of platforms and turns them into slaves. As slave the browser has your production code loaded along with all of your test code. As you edit your code and hit Ctrl-S the JsTestDriver reloads only the files which you have modified into the captured browsers slaves, this greatly reduces the amount of network traffic and amount of JavaScript re-parsing which the browser has to do and therefore greatly improves the test execution time. The JsTestDriver than runs all of your test in parallel on all captured browsers. Because JavaScript APIs are non-blocking it is almost impossible for your tests to run slow, since there is nothing to block on, no network traffic and no re-parsing of the JavaScript code. As a result JsTestDriver can easily run hundreds of TestCases per second. Once the tests execute the results are sent over the network to the command which executed the tests either on the command line ready to be show in you IDE or in your continuous build.


[Gd] Lightning talks at Google I/O

| More

Android Developers Blog: Lightning talks at Google I/O

Google I/O is approaching, and with over ten quality talks lined up, we should all strive to be attentive, avid learners. But for the last Android session of the conference, we thought it would be fun to unwind and open up the podium for lightning talks. This is where anyone can take the stage for six minutes and talk about anything. If you've done a cool hack involving Android, if you've devised a clever technique for a common problem, or even if you just want to get up on your soapbox for six minutes to appeal to your fellow developers, this is your time to be heard.

For those planning on attending Google I/O, we need you to submit and judge lightning talk proposals through a Google Moderator series we've set up. Please go ahead and start submitting your proposals. You only have 250 characters to describe the talk, which may be 110 more characters than you've been used to these days.

Voting is open from now until the moment the session starts. We'll take the eight highest rated talks and will call upon each speaker to take the stage. Remember you only have six minutes. Exceed that, and our security force tackles you off the stage. Thanks and see you all at I/O!


[Gd] Custom Search at Google I/O

| More

Google Custom Search: Custom Search at Google I/O

Posted by: Saksiri Tanphaichitr, Software Engineer

If you're attending the upcoming Google I/O Developer Conference (May 27th and 28th), make sure to attend the sessions we have on tap to discuss the latest Custom Search developments.

There are 2 sessions that will highlight Custom Search:
These sessions, part of the AJAX + Data APIs track, will discuss ways in which you can easily build, embed, and customize a contextual search experience on your website. You will learn how to develop advanced applications using the AJAX Search and Custom Search APIs, create dynamic experiences with Linked Custom Search, and programmatically provision Custom Search for your users. We'll also talk about interesting developer applications, as well as advanced presentation of search results including features that we recently launched: Rich Snippets and Promotions.

Adobe, one of our partners, will join us in discussing their use of Custom Search, and will also show interesting developer applications built on top of the Custom Search platform at the Developer Sandbox.

Here's a sneak peek:

We look forward to seeing you at Google I/O.

[Gd] Beta update: V8 experiment

| More

Google Chrome Releases: Beta update: V8 experiment

Google Chrome has been released to the Beta channel. The changes in this release since 172.27 are
  • complete translations in all languages
  • an experimental change in the V8 JavaScript engine that might improve page load times for pages with a lot of JavaScript.
  • a fix for a crash when using the French spell check dictionary (Issue 8551)
  • a fix for a crash when visiting a site with more than 50 feed links (Issue 12075)
You can join the Beta channel by downloading the Google Chrome Beta channer installer.

--Mark Larson
Google Chrome Program Manager

[Gd] How To Make Maps The Center Of Your UI (And How Not To)

| More

Google Code Blog: How To Make Maps The Center Of Your UI (And How Not To)

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Sasha Aickin, Engineering Manager at Redfin.

The oldest saw in real estate is that the three most important things about a house are location, location, and location, and at Redfin we took that as our user interface mantra as well. We made a decision early on that we were going to build a dynamic AJAX web app where the Google Map wasn't just a feature of the application but was the main driver of user interaction. The map is how users tell us where they want to search and what houses they are interested in buying, and our users tell us time and again that the map is what keeps them coming back.

That being said, we've made a lot of mistakes along the way, and I thought it might be helpful if I shared a few of the lessons we've learned over the last few years about building a map-driven UI:

#1 Always Be Thinking About Speed

Rich web apps that mash up many different APIs can be incredibly powerful, but after a while you'll start to look with a gimlet eye at every new API that comes down the pike. Why? Because every new API you add makes your site vulnerable to slowdowns, and your users will punish you for slowness.

Some of these slowdowns are inevitable, but many can be avoided by clever use of code loading techniques and HTTP caching. My best advice to people who ask me what they need to know before building a fast AJAX site? Follow everything that Steve Souders does. Read his book ("High Performance Web Sites"), follow his blog, and go to every talk of his you have a chance to. You'll learn how to defend your site's speed and delight your users.

#2 Carefully Consider The Full Screen Map

One early design decision you have to make with a map-driven site is whether your site is more like an app or more like a web page. Apps don't have scroll bars, and they resize all their controls when the browser resizes. Google Docs, 280slides, and Redfin are all examples of app-like sites, as is the main Google Maps site. Web pages, on the other hand, feel like documents. You can scroll through them, they often don't resize in a dynamic way, and they remind you more of a Word document than Word the application.

The full screen app style makes a lot of sense for sites like ours that use maps as their main navigation, but you can end up with a lot of user interface issues if you don't think the interaction through carefully. Before you make a full screen map UI, realize that your screen real estate is going to be severely limited, especially on laptops. Know that browser resize code can be buggy and difficult, especially if you have to support IE6. Understand that you will have to cut information you think should be in the interface for lack of space. If you have the time, create some prototypes of both app-style maps and web page-style maps and test them with users before going all-in.

#3 Make It Bookmarkable

This tip goes for all AJAX apps, but it is especially important for map-driven sites. Traditionally, AJAX apps have not been truly bookmarkable, and that has hindered both their shareability and utility. You want your users to share links to your site, and you want those links to always represent the same view on the map. If your users twitter or IM a link to your map-based site and it doesn't show their friends the same results that they are seeing, they're going to be confused at best and angry at worst. Furthermore, their friends aren't going to be exposed to your site, and you're going to miss an opportunity to create new users.

I won't lie, bookmarkability does add complexity to your app, but it's worth it. Pick up any of the many bookmarkability or back button JavaScript libraries and integrate it into your app. Your users will reward you for it.

#4 Decide How To Show Large Result Sets

If you're displaying results on a map, at some point you're going to come up against the problem of displaying many, many results on a map, and you're going to have to consider the problem of pagination vs. regionation.

Let's say you've built the ultimate map-based cafe finder, and someone searches the whole of San Francisco. San Francisco's a city that loves its hipster cafes, so you have 1000 results, but you can't possibly show those all on the map because you will confuse your users. Now you're faced with a choice: paginate or regionate?

Pagination would have you break down the results into groups of, say, 50 and show them one set at a time on the map, much the way that Google Search paginates your results. This is usually relatively easy to implement, but in my opinion it often misleads users. The typical response we've seen to paginated results on a map is that users think that they are seeing everything at once, and they get confused when a result that should show up isn't there.

Regionation, on the other hand, is the process of showing all the results on the map, but clustering them into groups so that the user can get a feel for where the results appear and zoom in to see more detail. Regionation usually provides a better user experience for large result sets but can be more work to implement. Search for "google maps clustering" to get some suggestions on how to start.

These are just a few of things we've learned over the years, and we'd love to discuss more of them with you either at the Google I/O Developer Sandbox or at the Performance Tips for Geo API Mashups session, where we'll be giving a short demo.

P.S. We've talked about Google Maps' speed previously on our developer blog, if you're interested in a little more detail.

Guest Post by Sasha Aickin, Redfin

[Gd] Google I/O 2009: registration is now closed

| More

Google Code Blog: Google I/O 2009: registration is now closed

Google I/O has sold out and general registration is now closed. If you have received a registration code, you can still register here. If you're unable to join us next week, we will post all of the videos and presentations shortly after I/O -- keep an eye out for updates on that. During the event, you can follow us on the @googleio Twitter account and on the Google Code Blog for the latest in-conference updates and announcements. And if you're coming to Google I/O, we look forward to seeing you there!

By Azhar Hashem, Google Developer Team

[Gd] Project Hosting Tricks, part 1

| More

Google Code Blog: Project Hosting Tricks, part 1

If you use Google Code's open source project hosting service, you're probably already familiar with the standard features: the issue tracker, the wiki, the downloads-area, and the browseable version-control repository.

But the project hosting service is also full of cool bells and whistles that you may not have noticed before. We've compiled a fun list of these things which you can show off at your next, um, project hackathon. In this first post, we'll look at some version control gems.

Web-based Code Reviews

  • What: browse a committed change, then make comments right in the browser.
  • Example: here's a brief sample review of a changeset.
  • How to do it: Bring up a changeset in the source browser and click the "start a code review" link in the right-side bubble. Double-click on lines of code to enter comments, then click "publish your comments" when done. An email will be sent to the changeset author, and then they can reply to the comments through the same web interface.

Make Stuff Happen after a Commit

  • What: after a commit, you can automatically fire off a continuous build, make an IRC bot speak... even notify an AppEngine instance!
  • How to do it: Look for the "web hooks" section in the Administer->Source page. If you provide a URL to your server, we'll ping it with commit information after every code change. Follow the links for full details and documentation.

Descriptive Wiki Commit Logs

  • What: The wiki is stored in version control; when saving a wiki page, use a more descriptive commit message than the default "Edited wiki page through web user interface".
  • Example: Here's a wiki change with a useful description.
  • How to do it: When editing a wiki page, expand and fill out the "Commit Log" textfield.

Of course, one of the most exciting new features on our project hosting service is our nascent support for the Mercurial distributed version control system. If you're coming to Google I/O, be sure to come hear our talk about Mercurial on Bigtable!

By Ben Collins-Sussman, Software Engineer, Google Code

Thursday, May 21, 2009

[Gd] We Tweet

| More

AdWords API Blog: We Tweet

For those who consider blogs or discussion groups passé, we wanted to let you know that you can now stay up to date on the latest AdWords API announcements by following @adwordsapi on Twitter.

[Gd] How OpenSocial v0.9 streamlines your app

| More

OpenSocial API Blog: How OpenSocial v0.9 streamlines your app

One of the major updates to OpenSocial in the latest version is a new programming model that allows you to send social data directly from the container to your application's server, where you can use the data to render any content you want to show the user. This model lets you use your existing presentation layer (faster coding!) and reduces the number of requests needed to pass social data between clients, containers, and your app server (faster apps!). Here's a closer look...

Many apps want to combine the social data from the container with the application data that lives on their server. In previous iterations of OpenSocial, many apps did something like the following:
  1. Client requests profile and friend info from the container (via DataRequests)
  2. Container responds with the social data
  3. Client requests application data from a remote server (via makeRequest)
  4. Container proxies request to remote server
  5. Remote server responds to container with application data
  6. Client combines the social and application data and presents it to the user (via JavaScript)
With v0.9's streamlined approach, the container can send social data to a remote server via "data pipelining" and you can combine that social data on your server, using your existing presentation layer, with a technique called "proxied content." The new flow looks like this:
  1. Client requests an application view
  2. The container sends social data to the remote server
  3. The remote server combines social and application data, returning HTML and JavaScript
  4. The container sends the content to the client
Much cleaner! These new features are already live on and will be coming soon to OpenSocial containers everywhere. To learn how to use data pipelining and proxied content in your OpenSocial app, check out this new tutorial.

Happy coding!

Posted by Lane LiaBraaten, OpenSocial Team

[Gd] Gmail for Mobile HTML5 Series: A Common API for Web Storage

| More

Google Code Blog: Gmail for Mobile HTML5 Series: A Common API for Web Storage

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. Over the last few weeks we've talked about how to use the AppCache functionality of HTML5 to launch an application offline. We discussed the impact that AppCache can have on your mobile web applications, as you enable users to launch your app faster in the face of flaky or slow internet connections. This week, I'll talk about how we're using both HTML5 Structured Storage and the Google Gears Database to make devices tolerate flaky network connections.

Although these technologies allow web applications to cache user data on the mobile device and perform data modifications locally, HTML5 Structured Storage uses an asynchronous model, where the Google Gears Database uses a synchronous model. This difference makes it difficult to develop an application on top of both platforms. We dealt with this problem by creating the Web Storage Portability Layer (WSPL) for Gmail. Coming soon under a liberal open source license to, WSPL provides a common API that supports an identical asynchronous programming model for both platforms by using a worker thread in Gears. Let's take a look!

The WSPL consists of a collection of classes that provide asynchronous transactional access to both Gears and HTML5 databases. It can be used to execute nested statements within callbacks, create statement templates, and optionally control the synchronous/asynchronous modes of the Gears Database Wrapper. There are five basic classes.

google.wspl.Statement - A parametrizable SQL statement class
google.wspl.Transaction - Used to execute one or more Statements with ACID properties
google.wspl.ResultSet - Arrays of JavaScript hash objects, where the hash key is the table column name
google.wspl.Database - A connection to the backing database, also provides transaction support
google.wspl.DatabaseFactory - Creates the appropriate HTML5 or Gears database implementation

Let's take a look at how we can use this API to perform a simple query, starting with the creation of a Database. Note that you'll need to provide a URL to the worker file hosted from your domain.

var database = google.wspl.DatabaseFactory.createDatabase('db name', 'http://yourdomain/dbworker.js');

You can then execute SQL statements without worrying about the specifics of HTML5 and Gears. Refer to the recent blog posts about AppCache to find steps you can follow to see your database contents using sqlite3.
var statement = google.wspl.Statement('SELECT col from test_table;');
database.createTransaction(function(tx) {
tx.executeAll([statement], {onSuccess: function(tx, resultSet) {
// Statement succeeded.

for(; resultSet.isValidRow(); {['col']);
}, onFailure: function(error) {
// Statement failed.
}, {onSuccess: function() {
// After transaction commits, before any other starts.
}, onFailure: function(error) {
// After transaction fails, before any other starts.
I've found that using the Gears database asynchronously will nicely split up the JavaScript execution, allowing event handlers and other code to execute between the callbacks. This can improve the responsiveness of your application if you're using long transactions. You can also use SQL triggers to avoid the read-modify-write pattern that causes "ping ponging" between threads -- either the main thread and Gears worker or the main thread and the HTML5 SQL thread.

That's all I'll show you for now, but you can look for more details about the Web Storage Portability Layer at Google I/O, May 27-28 in San Francisco where we'll be presenting a session on the architecture of a generic application using HTML5. We'll also be available at the Developer Sandbox and are looking forward to meeting you in person. Stay tuned for the next post where we'll talk about improving the performance of HTML5-based web applications.

By Matthew Bolohan, Software Engineer, Google Mobile

[Gd] Using the Google Static Maps API and HTTP Geocoder to power Lonely Planet's mobile travel guide

| More

Google Code Blog: Using the Google Static Maps API and HTTP Geocoder to power Lonely Planet's mobile travel guide

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Ken Hoetmer of Lonely Planet.

Lonely Planet has been using Google Geo APIs since 2006 - you can currently find them in use on destination profiles at , in our trip planner application , in our hotel and hostel booking engine , on , and in our mobile site, . I could talk for hours about any of these sites, but in preparation for Google I/O and my talk at the Maps APIs and Mobile session, I'll spend this post discussing our use of the Google Static Maps API and the HTTP geocoding service on

Our mobile site's primary feature is highlighting points of interest (POIs) around you, as selected by Lonely Planet. The site is browser based and targeted at a baseline of devices. This accessibility is great for on the road, but because of this choice, we can't obtain precise user locations via a location API. Instead, we've asked our users to self-select their location by entering it into a free form text field when they first arrive at the site. This location is then posted to our server, geocoded on the back end by forwarding the text to the Google HTTP geocoding API, and then used to either set the user's location or return a list of options for disambiguation.

Knowing the user's position, we then forward the position and a radius in kilometers to our Content API's POI proximity method, returning a list of points within range, in order of proximity. Once we have the POIs, we need to present them on a map, relative to the user's location. This is where the Google Static Maps API comes in. We can't rely on the availability of Flash, JavaScript, and Ajax, but the Static Maps API enables us to serve a JPEG map by simply providing our list of POI geocodes, a few bits about labeling markers, and a height / width (which we calculate per device by querying screen sizes from WURFL) as query parameters to a URL. Below the map we put a few links for switching the map between (road)map, satellite, hybrid, and terrain base maps.

That gives us a basic map, but what if the user wants to look a little farther to the north or east? To enable this, we augmented the map with a lightweight navigation bar (north, south, east, west, zoom in, zoom out), with links to new static maps that represent a pan or zoom action. Here's how we generated the links:

Let's say our page has a static map of width w pixels, height h pixels, centered at (lat,lng) and zoom level z.
$map_link = "{$key}&size={$w}x{$h}&center={$lat},{$lng}&zoom={$z}";
Then, we can generate north, south, east, and west links as follows (this example assumes the existence of a mercator projection class with standard xToLng, yToLat, latToY, lngToX routines):
// a mercator object
$mercator = new mercator();

// we'll pan 1/2 the map height / width in each go

// y pixel coordinate of center lat
$y = $mercator->latToY($lat);

// subtract (north) or add (south) half the height, then turn
back into a latitude
$north = $mercator->yToLat($y - $h/2, $z);
$south = $mercator->yToLat($y + $h/2, $z);

// x pixel coordinate of center lng
$x = $mercator->lngToX($lng);

// subtract (west) or add (east) half the width, then turn back into a longitude
$east = $mercator->xToLng($x + $w/2, $z);
$west = $mercator->xToLng($x - $w/2, $z);
So that our north, south, east, west links are:
$north = "{$key}&size={$w}x{$h}&center={$north},{$lng}&zoom={$z}";
$south = "{$key}&size={$w}x{$h}&center={$south},{$lng}&zoom={$z}";
$east = "{$key}&size={$w}x{$h}&center={$lat},{$east}&zoom={$z}";
$west = "{$key}&size={$w}x{$h}&center={$lat},{$west}&zoom={$z}";
Of course if you're serving a page knowing only a list of points and their geocodes, then you don't have a zoom level value for calculating the map links. Thankfully, mercator projection implementations often offer a 'getBoundsZoomLevel(bounds)' function, which serves this purpose (create your bounds by finding the minimum and maximum latitudes and longitudes of your list of geocodes). If your implementation doesn't provide this function, it's not complicated to write, but I'll leave that to the reader (hint: find difference in x and y values at various zoom levels and compare these to your map width and height).

As mentioned earlier, I'll be joining Susannah Raub and Aaron Jacobs to delve deeper into maps and mobile devices at Google I/O. In addition, Matthew Cashmore (Lonely Planet Ecosystems Manager) and I will be meeting developers and demoing our apps in the Developer Sandbox on Thursday, May 28. We'd love to meet you and we'll be easy to find - simply follow the noise to the jovial Welshman.

Guest Post by Ken Hoetmer, Lonely Planet

[Gd] Stable Update: Google Chrome

| More

Google Chrome Releases: Stable Update: Google Chrome

We're promoting 2.0.172 from Beta to the Stable channel today. 

We've made a lot of changes to stuff you never see, such as a newer version of WebKit for rendering web pages, a new network stack, and improvements to speed up the V8 Javascript engine.

There are some new features like removing Most Visited sites from the New Tab page, form autofill, and full screen mode. 

We're also proud to announce that Google Chrome is now available in 50 languages. We added Bengali, Gujarati, Kannada, Malayalam, Marathi, Oriya (on Windows Vista only), Tamil, and Telugu in this release.

You can read more about it here.

--Mark Larson
Google Chrome Program Manager

[Gd] Scaling JavaScript to Large Web Applications

| More

Chromium Blog: Scaling JavaScript to Large Web Applications

The V8 JavaScript engine has been designed for scalability. What does scalability mean in the context of JavaScript and why is it important for modern web applications?

Web applications are becoming more complex. With the increased complexity comes more JavaScript code and more objects. An increased number of objects puts additional stress on the memory management system of the JavaScript engine, which has to scale to deal efficiently with object allocation and reclamation. If engines do not scale to handle large object heaps, performance will suffer when running large web applications.

In browsers without a multi-process architecture, a simple way to see the effect of an increased working set on JavaScript performance is to log in to GMail in one tab and run JavaScript benchmarks in another. The objects from the two tabs are allocated in the same object heap and therefore the benchmarks are run with a working set that includes the GMail objects.

V8's approach to scalability is to use generational garbage collection. The main observation behind generational garbage collection is that most objects either die very young or are long-lived. There is no need to examine long-lived objects on every garbage collection because they are likely to still be alive. Introducing generations to the garbage collector allows it to only consider newly allocated objects on most garbage collections.

Splay: A Scalability Benchmark

To keep track of how well V8 scales to large object heaps, we have added a new benchmark, Splay, to version 4 of the V8 benchmark suite. The Splay benchmark builds a large splay tree and modifies it by creating new nodes, adding them to the tree, and removing old ones. The benchmark is based on a JavaScript log processing module used by the V8 profiler and it effectively measures how fast the JavaScript engine can allocate nodes and reclaim unused memory. Because of the way splay trees work, the engine also has to deal with a lot of changes to the large tree.

We have measured the impact of running the Splay benchmark with different splay tree sizes to test how well V8 performs when the working set is increased:

The graph shows that V8 scales well to large object heaps, and that increasing the working set by more than a factor of 7 leads to a performance drop of less than 17%. Even though 35 MB is more memory than most web applications use today, it is necessary to support such working sets to enable tomorrow's web applications.

Posted by Mads Ager and Kasper Lund, Software Engineers

[Gd] Web app acceptance test survival techniques, Part 3: Musings

| More

Google Testing Blog: Web app acceptance test survival techniques, Part 3: Musings

By Julian Harty

Part 1 and Part 2 of this series provided how-tos and usefulness tips for creating acceptance tests for Web apps. This final post reflects on some of the broader topics for our acceptance tests.

Aims and drivers of our tests

In my experience and that of my colleagues, there are drivers and aims for acceptance tests. They should act as ‘safety rails’, by analogy similar to crash barriers at the sides of roads, that keep us from straying too far from the right direction. Our tests need to ensure development doesn’t break essential functionality. The tests must also provide early warning, preferably minutes after relevant changes have been made to the code.

My advice for developing acceptance tests for Web applications: start simple, keep them simple, and find ways to build and establish trust in your automation code. One of the maxims I use when assessing the value of a test is to think of ways to fool my test into giving erroneous results. Then I decide whether the test is good enough or whether we need to add safeguards to the test code to make it harder to fool. I’m pragmatic and realise that all my tests are imperfect; I prefer to make tests ‘good enough’ to be useful where essential preconditions are embedded into the test. Preconditions should include checking for things that invalidate assumptions for that test (for example, the logged-in account is assumed to have administrative rights) and checking for the appropriate system state (for example, to confirm the user is starting from the correct homepage and has several items in the shopping basket).

The value of the tests, and their ability to act as safety rails, is directly related to how often failing tests are a "false positive." Too many false positives, and a team loses trust in their acceptance tests entirely.

Acceptance tests aren’t a ‘silver bullet.’ They don’t solve all our problems or provide complete confidence in the system being tested (real life usage generates plenty of humbling experiences). They should be backed up by comprehensive automated unit tests and tests for quality attributes such as performance and security. Typically, unit tests should comprise 70% of our functional tests, integration tests 20%, and acceptance tests the remaining 10%.

We need to be able to justify the benefits of the automated tests and understand both the return on investment (ROI) and Opportunity Cost – the time we spend on creating the automated tests is not available to do other things, so we need to ask whether we could spend our time better. Here, the intent is to consider the effects and costs rather than provide detailed calculations; I typically spend a few minutes thinking about these factors as I’m deciding whether to create or modify an automated test. As code spends the vast majority of time in maintenance mode, living on for a long time after active work has ceased, I recommend assessing most costs and benefits over the life of the software. However, opportunity cost must be considered within the period I’m actively working on the project, as that’s all the time I have available.

Test automation challenges

Unlike testing of traditional web sites, where the contents tend not to change once they have been loaded, tests for web applications need to cope with highly dynamic contents that may change several times a second, sometimes in hard-to-predict ways, caused by factors outside our control.

As web applications are highly dynamic, the tests need to detect relevant changes, wait until the desired behaviour has occurred, and interrogate the application state before the system state changes again. There is a window of opportunity for each test where the system is in an appropriate state to query. The changes can be triggered by many sources, including input, such as a test script clicking a button; clock based, such as a calendar reminder is displayed for 1 minute; and server initiated changes, such as when a new chat message is received.

The tests can simply poll the application, trying to detect relevant changes or timeouts. If the test only looks for expected behaviour, it might spend a long time waiting in the event of problems. We can improve the speed and reliability of the tests by checking for problems, such as error messages.

Browser-based UI tests are relatively heavy-weight, particularly if each test has to start from a clean state, such as the login screen. Individual tests can take seconds to execute. While this is much faster than a human could execute a test, it’s much slower than a unit test (which takes milliseconds). There is a trade-off between optimizing tests by reducing the preliminary steps (such as bypassing the need to log in by using an authentication cookie) and maintaining the independence of the tests – the system or the browser may be affected by earlier tests. Fast tests make for happier developers, unless the test results prove to be erroneous.

As with other software, automated tests need ongoing nurturing to retain their utility, especially when the application code is changed. If each test contains information on how to obtain information, such as an xpath expression to get the count of unread email, then a change to the UI can affect many tests and require each of those tests to be changed and retested. By applying good software design practices, we can encapsulate the ‘how’ from the rest of our tests. That way, if the application changes, we only need to change how we get the email count in one piece of code, instead of having to change it in every piece of code.

Practical tests

Lots of bugs are discovered by means other than automated testing – they might be reported by users, for example. Once these bugs are fixed, the fixes must be tested. The tests must establish whether the problem has been fixed and, where practical, show that the root cause has been addressed. Since we want to make sure the bug doesn’t resurface unnoticed in future releases, having automated tests for the bug seems sensible. Create the acceptance tests first, and make sure they expose the problem; then fix the bug and run the tests again to ensure the fix works. Antony Marcano is one of the pioneers of acceptance tests for bugs.

Although this article focuses on acceptance tests, I’d like to encourage you to consider creating smaller tests when practical. Smaller tests are more focused, run significantly faster, and are more likely to be run sooner and more often. We sweep through our acceptance tests from time to time and replace as many as we can with small or medium tests. The remaining acceptance tests are more likely to be maintained because we know they’re essential, and the overall execution time is reduced – keeping everyone happy!

Further information

A useful tutorial on xpath

Google Test Automation Conference (GTAC) 2008: The value of small tests

GTAC 2008: Taming the Beast - How to Test an AJAX Application

Part 1 of this article contains an additional long list of excellent resources.


Wednesday, May 20, 2009

[Gd] OAuth Playground: Open-sourced

| More

Official Google Data APIs Blog: OAuth Playground: Open-sourced

The OAuth Playground has proven to be an invaluable tool for developers. For one, it's handy for experimenting with the Google Data APIs, but more importantly, it gives developers the ability to debug their own OAuth implementations. Anyone who tinkered with the open protocol knows it has nuances! Many first-timers fall into the same pitfalls, so to help remedy that, I've decided to open-source the Playground in hopes that other OAuth service providers will create similar tools for their own APIs.

A lot has happened in the OAuth space since the Playground's release last fall. Included in that is Google's growing number of OAuth-related features and resources to aid developers. Here are just a few:
  1. 2 legged OAuth for Google Apps administrators
  2. Hybrid (OpenID + OAuth) protocol
  3. Client library OAuth samples in Python, App Engine Python, Java, App Engine Java, PHP
  4. Article: Using OAuth with the Google Data APIs
  5. Article: Using OAuth in the Google Data API Client Libraries

The feedback we have heard is that OAuth is difficult to implement and that it's tough to grasp the interactions between user, consumer and service provider. By open-sourcing the OAuth Playground, we really want to make it easier for developers to understand the OAuth flow and debug their own OAuth applications.

For even more information on OAuth and the OAuth proxy, check out our talk at Google I/O entitled Using Google Data APIs and OAuth to Create an OpenSocial Gadget.

If you have any questions, ask in the forums!

Posted by Eric Bidelman, Google Data APIs Team

[Gd] Dev Channel Update:

| More

Google Chrome Releases: Dev Channel Update:

Google Chrome has been updated to on the dev channel.  This release contains many localization, crash, and ui behavior fixes.

Version Changes:
  • WebKit - 530.11
  • V8 -
  • Google Gears -

  • Fixed a common crash when using a French spell-check dictionary. (Issue: 8551)
  • Fixed a regression where maximizing Chrome turned the tab-background black. (Issue: 11695)
  • Improved remote desktop (RDP) performance by using the standard dotted rectangle when moving a tab out. (Issue: 805)
  • The command line debugger has been replaced by a graphical debugger using the WebKit inspector scripts tab to debug JavaScript running in V8.
  • It is now possible to set proxy setting from the command-line.  See the issue for more information. (Issue: 266)
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] MySpace Open Platform: Connect MySpace users to your site and to your apps

| More

Google Code Blog: MySpace Open Platform: Connect MySpace users to your site and to your apps

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Scott Seely, Architect for the MySpace Open Platform.

MySpace will be talking about two big things at Google I/O this year: MySpaceID and MySpace Apps.

MySpaceID delivers social functionality and experiences by linking MySpace accounts with your site. These services allow users to quickly register using their MySpace credentials as well as post status messages, publish activities into MySpace, discover friends, and view MySpace activity and profile data on your site! The users’ friends see all these updates, which drive traffic to your site and attract new users to register. By leveraging MySpace’s social graph, you add virally to the buzz about your site and increase the number of visitors to it.

For a broad overview of MySpaceID, please watch this video:

We provide SDKs for MySpaceID. You can use the SDKs or directly use our REST endpoints. We have SDKs available for a variety of languages: PHP, Python, Ruby, .NET, Java, and JavaScript. This brings the benefits of MySpaceID to a wide range of developers. The JavaScript SDK runs on the client, all other versions run on your servers. These options allow you to achieve smooth workflows and reduce implementation costs by working with the skills you use as a developer.

MySpaceID supports both OAuth and the OpenID-Auth hybrid—you choose the mechanism that makes the most sense for your scenario. Both options are exposed in our SDKs. Once a user logs in and allows your site to access their data, you have access to a wealth of their MySpace data. The MySpace endpoints support Portable Contacts and OpenSocial 0.9 REST, giving you access to plenty of information.

MySpace Apps provides developers with a canvas to create engaging social applications that are deeply integrated into MySpace. The applications are built using the OpenSocial specification, which we are evolving with partners like Google, and Yahoo!. With OpenSocial 0.9, you will see advances in markup, allowing you to remove much of your JavaScript and instead use OpenSocial Markup Language, OSML, to declare which friends you want loaded. This work all happens on MySpace’s servers, reducing calls for data and greatly improving the application experience. When you do need to contact your own servers, you can send Ajax calls through our proxies to your servers. These calls are all signed by the MySpace infrastructure so that you know the request came from a trusted source. The MySpaceID SDK allows your server to access and set MySpace user data in this scenario. So long as the user has installed your application, your servers can access their data.

These are some of the ways that MySpaceID enables you to leverage MySpace API’s off-site and let users into your site with their social media identity and data. Earlier this year, MySpace was the first social network to allow syndication of its users’ activity streams. We hope you are as excited as we are to be part of this fundamental shift in the portability of user identity and data on the Internet.

MySpace Apps and MySpaceID are a lot more than what we’ve talked about here. We invite you to find out more by attending:
  • “Building a Business with Social Apps” – Gerard Capiel, VP of Product for the MySpace Open Platform, will share his experiences on monetization of apps.
  • Developer Sandbox – Come by and see actual apps in action, try building an app on the spot, and talk to our developers.
  • Fireside Chat - Ask those hard questions, discuss approaches to problems, and think about the future with MySpace developers and the OpenSocial engineering team
We hope that you will come away convinced that MySpace is focused on empowering app owners and web site owners with the tools to succeed. See you at Google I/O!

Guest Post by Scott Seely, Architect for the MySpace Open Platform

[Gd] AdWords API on App Engine (Python)

| More

AdWords API Blog: AdWords API on App Engine (Python)

Most of you have probably heard about Google App Engine, which lets you write web applications that run on Google's infrastructure. But did you know that the code which you develop using the AdWords API can be easily hosted on App Engine, thus making it many times easier to build, maintain, and scale your application as your traffic grows?

Today, we'd like to release a demo application that can be hosted on App Engine and is uses the AdWords API to communicate with the Sandbox environment (it is just as easy to access production AdWords accounts). In this demo, we access a given Sandbox account using the AdWords API and illustrate the following operations and features:
  • Retrieve existing campaigns.
  • Retrieve stats for each campaign.
  • Add new campaigns.
  • Update a campaign's budget.
  • Retrieve existing ad groups.
  • Add new ad groups.
  • Keep track of API usage for each user in a datastore.

We hope this demo will start you off in creating innovative and cool applications that take advantage of the AdWords API's ease of use and Google's infrastructure.

-- Stan Grinberg, AdWords API Team

[Gd] Guice Deuce

| More

Google Code Blog: Guice Deuce

Two years ago, Bob Lee and Kevin Bourrillion open sourced Google Guice 1.0, a lightweight Java dependency injection framework. Guice takes the pain out of writing and maintaining Java applications big and small. Guice has gained a great deal of traction both inside and outside of Google. Almost every Java-based application at Google is also a Guice-based application; the list includes AdWords, Google Docs, Gmail, and even YouTube. Open source users run Guice in everything from file-sharing software to ATMs. They've even written two books about this Jolt-award-winning framework.

Today, we're releasing Guice 2. The minimally-sized API extensions introduced by Guice 2 will have a majorly positive impact on the size and maintainability of your code. We closely scrutinized each addition, carefully balancing maintainability and flexibility. Here are a few of my favorite new features:
  • Provider methods eliminate the boilerplate of manually-constructed dependencies.
  • Module overrides allow you to tweak a production module for a unit test or QA deployment.
  • Private modules enable compartmentalized configuration, simplifying module reuse.
Guice works with Java SE, Java EE, Google App Engine, Android, and even Google Web Toolkit (via GIN).

Guice 2.0 Release Notes
User's Guide

By Jesse Wilson, Google Developer Team

[Gd] Previews of I/O Sessions: Brian Fitzpatrick and Ben Collins-Sussman

| More

Google Code Blog: Previews of I/O Sessions: Brian Fitzpatrick and Ben Collins-Sussman

You have seen the previews for I/O sessions that we have published so far (First set, Second set). This time, we have something a little different for you.

In this preview, Brian and Ben track down the elusive Genius programmer in the preview for their session, "The Myth of the Genius Programmer". Will they succeed in their quest? Will they live to tell the tale? Watch the preview to find out.

The Myth of the Genius Programmer - Brian Fitzpatrick & Ben Collins-Sussman

Keep an eye out for more previews on the other sessions at I/O in the coming soon. We can't wait to meet a bunch of talented developers and have some fun at Google I/O, on May 27-28!

By Neel Kshetramade, Google Developer Programs

[Gd] Sao Paulo, Brazil: Google Developer Day Registration now open

| More

Google Code Blog: Sao Paulo, Brazil: Google Developer Day Registration now open

We are excited to open registration for our third Google Developer Day event this year, to be held on June 29th in Sao Paulo, Brazil.

In the heart of Sao Paulo, you will learn about the latest with our APIs and developer tools, including Android, Google Chrome, App Engine, AJAX APIs, Maps and more. The topics will vary so you can be sure to discover new and interesting ways to use our applications. And don't forget to take part in the time set aside to socialize with fellow developers and Google engineers - it is a great networking opportunity.

By Alyssa Sachs, Google Developer Programs

Tuesday, May 19, 2009

[Gd] Custom Search promotions made easier

| More

Google Custom Search: Custom Search promotions made easier

Posted by: Bartlomiej Niechwiej and Nicholas Weininger, Software Engineers

Last year, we made it easier to promote relevant information to the top of your search results for specific queries, but there were still a couple of steps you had to take to make this happen. So now, we've made it easier than ever to create promotions in Custom Search. You can quickly configure specific webpages or information to display above your search results for specific queries, allowing you to highlight key events, announcements, services or products.

We've added a new Promotions tab to the Custom Search control panel to help you manage all your promotions.

Creating a promotion is easy - decide on the queries that should trigger a specific promotion, select a title and URL for your promotion, and add optional information, such as description and image thumbnail. The promotion edit pane also shows a preview of your promotion.

When you're done, promotions will display in your search results for the queries that match your trigger list. You can test a promotion by issuing one of the trigger queries in the control panel results preview.

A few pointers:
  • you can control the look and feel of the promotions to distinguish them from regular search results (through Promotion Design Settings)
  • you may want to create promotions to highlight information for popular queries on your search engine (use search statistics to identify them)
  • you should delete promotions when they are no longer relevant
  • our updated developer documentation includes more information on promotions

We hope to see useful promotions popping up in custom search results all over the web.

Don't miss the promotions when you search on the Custom Search website! We'd love to get your feedback on how we can make this feature even more useful.

[Gd] Register Now! San Francisco DevJam - Tuesday, May 26th

| More

OpenSocial API Blog: Register Now! San Francisco DevJam - Tuesday, May 26th

Greetings Developers!

The MySpace Open Platform would like to invite you to the MySpace San Francisco DevJam.

This DevJam covers everything you’ll need to know about how to build great apps using MySpace Open Platform. It will begin with the State of the Platform, and tell you all about what’s happening with the container and things to come. It’ll cover everything from porting apps to MySpace, leveraging messaging channels, OpenSocial 0.9, OSML, using OpenSocial outside the container, and everything in between. You won’t want to miss this DevJam event!

If you can’t attend in person, don’t worry! We plan to livestream the event, stay tuned on that front for more details…

Guest Speakers include:
  • Jason Oberfest, General Manager of the MySpace Open Platform and SVP of Business Development
  • Gerardo Capiel, VP of Product for the MySpace Open Platform
  • Dan Yue, Co-Founder of Playdom
  • Sebastien de Halleux, Chief Operating Officer and Co-Founder of Playfish
  • Max Newbould, Product Lead for MySpace Open Platform’s OpenSocial container
  • Max Engel, Product Lead for MySpaceID
And many more!

Space is limited, so click below to see the full agenda and to register now!

Hope to see you there!!

Posted by MySpace Open Platform Team

[Gd] Google I/O Pass

| More

YouTube API Blog: Google I/O Pass

Google I/O, our largest developer conference in San Francisco, CA, is just around the corner, and we'd love to see more YouTube developers there. We'll have two formal sessions, as well as office hours and lots of demos at the Developer Sandbox.

Kuan, our Product Manager, will be giving a session about writing great, monetizable apps, and Jeff Fisher and Jochen Hartmann will be giving a session on the new social feeds.

Check out the rest of the great sessions and the schedule.

We have one free pass ($400 value) to give away, so if you'll be in the area, tell us why you want to go in this forum thread. We'll pick the worthiest person by the end of the week (hint: Jeff really likes Haikus :).

Posted by Stephanie Liu, YouTube APIs and Tools Team

Monday, May 18, 2009

[Gd] Who's @ Google I/O - spotlight on the Social Web

| More

Google Code Blog: Who's @ Google I/O - spotlight on the Social Web

Google is making the web a more sociable place by contributing to new standards and releasing new products that make it easy to integrate your website with the social web. We've invited a few friends that are helping build the social web to Google I/O so you can learn what's coming next and what it means for you.

Learn from successful developers
Social apps can grow up fast, and some have attracted tens of millions of users. We're planning sessions to help you understand the business side of social apps, and we'll have a panel where you can pick the brains of some of the biggest social app developers in the world.

Make some new friends
There's more to a successful social app than just a creative idea. From analytics to payment processing, there's a lot of code to write beyond the core functionality of an app. Luckily, companies have been springing up to fill the needs of this ecosystem. You can meet some of these new companies in the Developer Sandbox and see how their products can make your app better (and your life easier).

Meet the containers
One of the key benefits of OpenSocial is the incredible distribution it provides to app developers. Building your app on OpenSocial makes it possible to reach hundred of millions of users around the world. We've got sessions planned to let you meet the folks building OpenSocial platforms and learn more about what kind of apps work well in different social environments.

The next generation
IBM,, Oracle, eXoPlatform, SAP, Atlassian - not who you'd expect to be speaking on an OpenSocial session. Speakers from these companies will come together to talk about how the enterprise software development community is bringing social concepts and technology like OpenSocial into the enterprise.

To see all the sessions we've got planned to help you learn about the social web, go to, and search for 'social'.

*Keep up with the latest I/O updates: @googleio.

By Lane LiaBraaten, OpenSocial team