Enlist in BootCamp for Google I/O

This year, we're introducing I/O BootCamp, a new event happening the day before Google I/O. BootCamp is an opportunity for attendees to get a crash course in our major development platforms and tools before they head into Google I/O. BootCamp will feature introductory "101" content, hands-on lab sessions, and community-led discussions.

BootCamp is only available to those who are registered to attend Google I/O. Since space is limited, we ask that interested Google I/O attendees please register at our BootCamp site.

To register for Google I/O, please visit code.google.com/io.

By Stephanie Liu, Google Developer Team

Flashy New Authentication: AuthSub Adds Support for ActionScript

Today, we are happy to announce the launch of AuthSub for ActionScript, a new component of the well-known AuthSub authentication interface for the Google Data Protocol. This new feature enables Flash and Silverlight applications to access data securely on behalf of a user, without the application ever seeing the user’s private login credentials.

To use AuthSub for Actionscript (or as we’re calling it, AuthSubAS), first ensure that the API you are accessing offers cross-domain support. To do this, simply check for a crossdomain.xml file like those offered by the Picasa Web Albums Data API and the YouTube Data API. Then, if the API supports cross-domain scripting, you can simply point your Flash app to https://accounts.googleapis.com/accounts/AuthSub{Request,SessionToken} and authenticate. If you’re familiar with how AuthSub for JavaScript works, AuthSubAS works in much the same way. For more information, see the AuthSub for ActionScript guide and check out this code sample.

Currently, cross-domain requests are only supported by the Picasa Web Albums Data API and the YouTube Data API.  However, as more APIs offer cross-domain scripting through an open crossdomain.xml file, the AuthSubAS authentication will work automatically. For questions about a specific API or to encourage your API to provide AuthSubAS support sooner, visit your API’s support group in Google Groups.

By Joseph Schorr and Zach Maier, Google Data Protocol Team

A proposal to extend the DNS protocol

Today a group of DNS and content providers, including Neustar/UltraDNS and Google are publishing a proposal to extend the DNS protocol. DNS is the system that translates an easy-to-remember name like www.google.com to a numeric address like 74.125.45.104. These are the IP addresses that computers use to communicate with one another on the Internet.

By returning different addresses to requests coming from different places, DNS can be used to load balance traffic and send users to a nearby server. For example, if you look up www.google.com from a computer in New York, it may resolve to an IP address pointing to a server in New York City. If you look up www.google.com from the Netherlands, the result could be an IP address pointing to a server in the Netherlands. Sending you to a nearby server improves speed, latency, and network utilization.

Currently, to determine your location, authoritative nameservers look at the source IP address of the incoming request, which is the IP address of your DNS resolver, rather than your IP address. This DNS resolver is often managed by your ISP or alternately is a third-party resolver like Google Public DNS. In most cases the resolver is close to its users, in which case the authoritative nameservers will be able to find the nearest server. However, some DNS resolvers serve many users over a wider area. In these cases, your lookup for www.google.com may return the IP address of a server several countries away from you. If the authoritative nameserver could detect where you were, a closer server might have been available.

Our proposed DNS protocol extension lets recursive DNS resolvers include part of your IP address in the request sent to authoritative nameservers. Only the first three octets, or top 24 bits, are sent providing enough information to the authoritative nameserver to determine your network location, without affecting your privacy.

The Internet-Draft was posted to the dnsext mailing list today, and over the next few months our group hopes to see this proposal accepted as an official Internet standard. We plan to continue working with all interested parties on implementing this solution and are looking forward to a healthy discussion on the dnsext mailing list.

(Updated 24 Jan 2011 to fix broken links)

By Wilmer van der Gaast and Carlo Contavalli on behalf of the Google Public DNS team

Create and share Google Sites with new Sites Data API features

Several months ago we launched the Google Sites Data API. Since then, we've worked hard to respond to your top feature requests: the ability to list a user's sites, create new sites, copy existing sites, and manage sharing permissions. Today, we are very excited to announce the release of the Site and Access Control List feeds that make these new features possible.

The Site feed allows your client to list sites and update their properties, such as the title or the theme of the site. Google Apps users can also create new sites. Because creating new sites often involves copying existing ones (perhaps using a site template), we've enabled that feature too.

Here's an example of the kinds of applications you can build with those features. Let's say you're a professor at a university and you'd like to create a Google Site for each of the courses you teach. The Site feed makes it possible for you to create a site course template, use the site feed to create several course sites, and personalize them with the content feed.

But what if you want to restrict access to your sites to just the students taking those courses? With the ACL (Access Control List) feed, you can manage sharing permissions. Everything you can do in the Google Sites admin panel, you can do with the API.

To get the full scoop, review the documentation and change log. We've loaded the Java client library and Python client library with the new features, and offer updated developer guides for both.

Visit us in our new developer forum if you have questions!


By Laurent Tu & Eric Bidelman - Google Sites API Team

Extensibility + new HTML and JavaScript APIs for Google Chrome

Today's new stable release of Google Chrome for Windows includes a bundle of browser goodness, including extensions and new HTML and JavaScript APIs.

Extensions -- previously available on Google Chrome for Windows on the beta channel -- and are now available to all users. Extensions enable you to provide additional functionality not just on your site, but to bring content and functionality from your site into the browser regardless of what sites the user has open. Google Chrome extensions use the same multiprocess technology that makes the browser fast and more secure, so that extensions won't crash or slow down your browser.


In addition, we're excited to introduce a number of new HTML and JavaScript APIs in Google Chrome, including the Web Storage and Web SQL Database APIs, WebSockets, and more. For more details about these APIs, read further on the Chromium Blog.

If you have questions about the extensions APIs, the extensions discussion group continues to be the best place to get answers. For the new HTML and JavaScript APIs, check out the newly created Chromium HTML5 group. And for those of you who are interested in attending Google I/O, check out the current list of Google Chrome sessions.

By Ian Fette, Product Manager, Google Chrome

​Documents List API: Upload any file type and more!

As just announced over on the Enterprise blog, Google Docs now allows users to upload any type of file! Over the next couple of weeks we’ll be rolling out the same feature in the Documents List Data API. For now, uploading arbitrary files via the API will be restricted to Google Apps Premier domains. For starters, each user gets 1GB of storage with a maximum size of 250 MB per file.

Combined with the shared folders feature of Google Docs, we think this new feature is a great way to build collaborative applications for exchanging files with coworkers and external parties. No more email attachments!

In addition to arbitrary file upload, we’re launching several top features requested by developers:

• Copy a document - Make a duplicate of a document in a single call


• Publishing documents - Programmatically publish a document to the world.


• Change the owner of a document - While ACLs and sharing have been in the API for quite some time, you can now change the ‘owner’ of a document.


• Resumable uploads - Offers the ability to pause/resume an upload. It’s ideal for large file sizes.

Look for resumable upload support in the Java, Python, and Objective-C client libraries in the near future. As always, if you have any questions, please visit us in our new developer forum.

Issues resolved in this release: 72, 1040, 1675, 1260, 1741, 1127

By ​Eric Bidelman, Google Docs Team

Google I/O 2010: Now open for registration

I'm excited to announce that registration for Google I/O is now open at code.google.com/io. Our third annual developer conference will return to Moscone West in San Francisco on May 19-20, 2010. We expect thousands of web, mobile, and enterprise developers to be in attendance.

I/O 2010 will be focused on building the next generation of applications in the cloud and will feature the latest on Google products and technologies like Android, Google Chrome, App Engine, Google Web Toolkit, Google APIs, and more. Members of our engineering teams and other web development experts will lead more than 80 technical sessions. We'll also bring back the Developer Sandbox, which we introduced at I/O 2009, where developers from more than 100 companies will be on hand to demo their apps, answer questions and exchange ideas.

We'll be regularly adding more sessions, speakers and companies on the event website, and today we're happy to give you a preview of what's to come. Over half of all sessions are already listed, covering a range of products and technologies, as well as speaker bios. We've also included a short list of companies that will be participating in the Developer Sandbox. For the latest I/O updates, follow us (@googleio) on Twitter.

Today's registration opens with an early bird rate of $400, which applies through April 16 ($500 after April 16). Faculty and students can register at the discounted Academia rate of $100 (this discounted rate is limited and available on a first come, first serve basis).

Last year's I/O sold out before the start of the conference, so we encourage you to sign up in advance.

Google I/O
May 19-20, 2010
Moscone West, San Francisco

To learn more and sign up, visit code.google.com/io.

We hope to see you in May!

(Cross-posted with the Official Google Blog)

By David Glazer, Engineering Director

A look back on 2009

2009 was a remarkable year for developers. Vic Gundotra, VP of our developer team declared at Google I/O, "The web has won!" and this year was full of launches and announcements that remind us how the web has become the platform of our day. We found lots of inspiration from the developers at Google I/O in San Francisco and at our Google Developer Days in Japan, China, Brazil, Russia and the Czech Republic.



Here's a look back at some of our favorite highlights from 2009:

• Faster Apps Faster - the theme for the recent Campfire One event letting developers know how GWT 2.0 decreases development time (it's being used by Google Wave & Adwords for this reason) and how Speed Tracer gives you new insight into speeding up your apps


• Make the Web faster - as part of an effort to Make the web faster we launched tools like Page-Speed and our DNS resolution service. We also made our internal JavaScript tools available, called Closure Tools, so you can rev up your js like the guys on Gmail. With PubSubHubbub all your feeds can be real-time streams.


• A faster browser - A few weeks ago we launched Google Chrome for Mac and Linux, along with an extension framework for Chrome and a gallery for developers to distribute their extensions -- there are over 900 to check out already! Chrome has a set of developer tools built on WebKit to help optimize your code. Plus, we released details of Chrome OS...a netbook operating system for speed freaks. Along the way, we've worked with the larger web community contributing to the exciting future of the web with HTML5.


• Mobile - Android launched on one device in one country on one carrier in 2008. This year, 20 devices in 26 countries on 32 carriers have been launched or announced. Developers have created over 16,000 apps in the Android Marketplace. Some were winners of our second Android Developer Challenge. We launched new mobile versions of gmail and calendar using HTML5. You can take a picture to search using Google Goggles and get turn-by-turn navigation with Google maps. Plus, we recently announced our mobile lab for Android hardware.


• Hosting - App Engine apps were allowed to scale beyond free quotas and Java developers were invited to try it out at Campfire 1 in April. Developers responded, with over 100K apps  built on App Engine. Open source developers using Project Hosting were able to host projects on Mercurial, in addition to Subversion.


• New APIs - Google Wave was released early to developers at Google I/O in May. Wave is "equal parts conversation and document" and showcases what is possible in the browser. Developers can build robot extensions to automate common tasks or build gadget extensions to provide a new way for users to interact. Google Maps released v3, Friend Connect got more personalized and then got cozy w/ Twitter, Google Analytics released an API and then added asynchronous tracking.


• Google Web Elements - From maps to search to translate and more, Google Web Elements made it even easier than ever to add Google products to your site.


• Labs - Google Code Labs was created to let developers know which APIs and products are cutting edge labs "experiments" and which we are committed to supporting for the long term.

It is a very exciting time to be a developer...we are just starting to see what is possible with the web as the platform. It will be a lot of fun to see where all of us, together, can take the web in 2010!

Happy Holidays from the Google Developer Team!

By Mike Marchak, on behalf of the Google Developer Team

Google Analytics API v2 Python Client Library

We know it's easier for developers to program in the languages they know. So we updated the Google Analytics API Python Client library with all the new API version 2 features and added reference exampels for both the Account Feed and Data Feed. Now it's easier than ever to automate your analysis workflow using our API.

Taking The Library For a Spin

With the updated library, we thought it would be a great time to highlight the power of the new v2 features. So we created a sample application to do just that. The application uses the new Google Analytics Python client library to retrieve metrics for a series of segments. It then performs some calculations on the data and creates bar charts using the GChartWrapper package, an open source Python wrapper for the Google Charts API. Finally, it uses the Python Imaging Library to add a title and legend, and stitches all the charts together into a single image. We decided to release this application as open source so you can create visualizations with your own data.

Solving Business Problems

With social media all the rage, we wanted to use this new application to help Avinash Kaushik, our Analytics Evangelist, to measure "engagement" on his popular Occam's Razor blog. We also wanted to determine if the time he spends participating in social media sites is valuable and sends new readers to his blog.

First we created segments to pull all the referrals from Facebook and Twitter. Second, we chose five calculations and corresponding metrics to compare the performance of thee two segments. We then compared the segments to each other and, for context, to all the visits to the site as a control.

They say a picture is worth a thousand words, here are the results:



Let's Analyze

Some interesting observations become apparent.

• Far more visits originate from Twitter (3.6x) when compared to Facebook, perhaps not surprising given Avinash's Twitter followers (~16,120)
• Visitors from Twitter tend to be new visitors, a good thing, but they view fewer pages and spend significantly less time on the blog.
• On the other hand Facebook delivers an audience that is loyal. These visitors come back to the site more often and spend a significant time on the blog (compared to Twitter and all other visitors).

The bottom line? Even though social networking sites are all the rage, they actually contribute very little to Avinash's blog. If this blog were a company, it would be wise to ensure the time and effort put into driving traffic from social media is proportionate to the actual volume of traffic and goal conversions from those sites.

Hopefully this example shows how powerful our new features can be.

If you're interested in running this report against your own data, the application is free and open sourced. Additionally, we made it really easy to change the metrics, segments, calculations and all the other visual properties to power your own visualizations. So please download it here and give it a whirl, we would love to hear your feedback.

By Nick Mihailovski, Google Analytics API Team

Introducing Google Browser Size

When I started work at Google, I visited the Google Earth team, hoping to find a 20% project on my favorite Google product. There I met Bruno Bowden, who introduced me to a problem I had never thought much about: how to take browser sizes into account when designing a page.

Bruno had noticed that many people who visit the “Download Google Earth” page never actually download, even though, as you can see, the button is pretty hard to miss:



He wondered if a significant number of users might have their browser windows too small to see the button:



To analyze this, Bruno looked at how large people's browser windows were when they visited this page. His first key idea was to measure not the entire browser window, but just the client area -- no toolbars, status bars, or other chrome.

Bruno's second key idea was to render several weeks' worth of page visitor browser sizes in a contour visualization:



Using this visualization, Bruno confirmed that about 10% of users couldn't see the download button without scrolling, and thus never noticed it. 10% may not sound like a lot, but in this context it turns out to mean a significant number of people weren't downloading Google Earth. Using this data, the team was able to redesign the page to good effect.

Bruno and I realized that Web designers might benefit from this information if it could be made more generally available. We constructed a page that could overlay a DIV containing the contour visualization atop an IFRAME containing any other Web page:



This turned out to be a good way to see which controls were and weren't visible at typical browser sizes. The only problem was, the overlay DIV prevented mouse events from getting to the page IFRAME, so it wasn't possible to interact with the page.

To solve this, we split the overlay DIV into four:



Each of the outlines above (red, yellow, blue, green) represents a separate DIV. As the mouse pointer moves, we resize and reposition the DIVs to leave a small window of blank space around the pointer, and adjust background offsets for each DIV to make the overlay look like one seamless graphic. (We originally did this on a timer, but we found a simpler way: when the mouse touches any of the DIVs, resize/reposition all of the DIVs.) End result: a designer can click and otherwise interact with the page with the mouse, and thus interact with the site normally instead of repeatedly typing in URLs.

We are now making this tool available to the public on Google Labs. To try it, simply visit browsersize.googlelabs.com and enter the URL of a page you'd like to examine. The size overlay you see is using latest data from visitors to google.com, so this should give you a pretty good indication of what parts of your UI are generally visible and what aren't.

We look forward to receiving your comments at browser-size-external-feedback!

By Arthur Blume on behalf of the Google Browser Size team