Google Data » DeWitt Clinton

Introducing the Google Buzz API

DeWitt Clinton — Wed, 19 May 2010 20:45:00 +0000

With Google I/O 2010 finally upon us, what better time to introduce developers to the latest updates to the Google Buzz API?

As announced at the launch of Google Buzz, the Google Buzz API aligns itself with the ever-growing family of freely available and community-developed protocols, formats, and standards for sharing and consuming social content on the web, including ActivityStreams, Atom, AtomPub, JSON, OAuth, PubSubHubbub, MediaRSS, PortableContacts, and more.

The Google Buzz API, a member of the Google Code Labs, is very much a work in progress — we intend to continue to iterate out in the open as we go along — and we hope the features we are making available today will help inspire developers and provide a solid foundation for new applications to be built.

We are already excited to see developers who were helping us test the API deliver terrific applications. Today you'll start seeing the following sites and services integrate with Google Buzz:

End-users opt into using applications built with the Google Buzz API via an interstitial confirmation screen outlining the application's requested access scope (read-only, read/write, etc.). They can see which apps have access to their data and can disable access at any time from the Google Accounts page, the Google Dashboard, the “Buzz" tab in Gmail Settings, or from the app itself.

This initial iteration of the API includes support for fetching public per-user activity feeds, fetching authorized and authenticated per-user activity feeds (both what the user creates, and what they see), searching over public updates (by keyword, by author, and by location), posting new updates (including text, html, images, and more), posting comments, liking updates, retrieving and updating profiles and social graphs, and more. The best way to get started is to dive right in and begin reading the Google Buzz API developer documentation.

There’s a lot more to come, and we expect to keep moving quickly from here. But none of this would be possible without the hard work of everyone participating in creating the protocols upon which Google Buzz is built, so we ask and encourage developers to get involved with the communities behind ActivityStreams, OAuth, and the countless others that we depend on.

And as with any young API, there will undoubtedly be bugs and issues and places where we’ve deviated from what the specifications say, or with what developers may expect. When you see something amiss, get confused by an approach we’ve taken, or just want to comment on our progress, we invite you to update the Buzz API issue tracker and please join the conversation on the developer forum.

With that, we’d like to welcome everyone to the first version of the Google Buzz API. We can’t wait to see what else we can build together.

By DeWitt Clinton, Google Developer Team

Join the Conversation Around Google Buzz

DeWitt Clinton — Tue, 09 Feb 2010 19:03:00 +0000

This morning we announced Google Buzz, a new way to share updates, photos, videos and more, and start conversations about the things you find interesting.

We'd like to take this opportunity to invite developers to join us as we prepare the Google Buzz API for public launch. Our goal is to help create a more social web for everyone, so our plan for the Buzz API is a bit unconventional: we'd like to finalize this work out in the open, and we ask for your participation. By building the Google Buzz API exclusively around freely available and open protocols rather than by inventing new proprietary technologies, we believe that we can work together to build a foundation for generations of sites to come. We're ready to open the doors and share what we've been working on, and we'd like for you to join us in reaching this goal.

Please visit the Buzz API site on Google Code, subscribe to the Social Web Blog, and most importantly, join us on the Buzz API mailing list.

We'll have advanced sessions on Buzz APIs at Google I/O, our annual developer conference in May. To learn more about and register for I/O, visit code.google.com/io.

Update: Fixed typo in the first sentence.

By Brian Stoler, Tech Lead, Google Buzz

Introducing Google Web Elements

DeWitt Clinton — Wed, 27 May 2009 18:39:00 +0000

Inspired by the convenience of embeddable YouTube videos, Google Web Elements build on favorite products like Google Custom Search (a Google-powered search engine that automatically tailors itself to your site), Google Docs, and Google News to easily add richness and interactivity to your website with the simplicity of copy and paste. Each element is designed to help you get started quickly without spending time on the deep technical details. Yet behind it all, Google Web Elements are powered by Google's scalable and flexible developer APIs, offering a world of customization just beneath the surface, keeping up with your site as it grows.

Adding Google Web Elements to your website is as easy as visiting the homepage, choosing the ones you like, and customizing them to fit your page. For example, the News element adds headline news about the topics you choose to any page. Just go to the News element page and use the wizard to update the live preview as you change the topics and pick the best size for your site. When you like what you see, simply copy the short embed code and paste it into the HTML of your page.

The Conversation element, powered by Google Friend Connect, makes it easy to start a discussion about nearly any topic. Without writing a single line of code, you can add the Conversation element and visitors to your site can share comments and videos with each other. You can also choose to open the conversation up to the whole world, where every page discussing the same topic will participate in a truly global conversation.

The Conversation and News elements are just two of the Google Web Elements available today. Also available are Google Web Elements for Google Calendar, Google Custom Search, YouTube Video News, Google Maps, and more. To get started, visit the Google Web Elements homepage. and please be sure to let us know what you'd like to see us work on next.

By DeWitt Clinton, Google Developer Team

Steve Souders: Life’s Too Short, Write Fast Code (part 2)

DeWitt Clinton — Tue, 10 Mar 2009 20:04:00 +0000

By Steve Souders, Member of Technical Staff

I've been working on a follow-up book to High Performance Web Sites called Even Faster Web Sites. As I finish chapters, I talk about the findings at conferences and tech talks. The first three chapters are Split the Initial Payload, Load Scripts Without Blocking, and Don't Scatter Inline Scripts. You can hear about those best practices in my video from Google I/O.

This talk presents the next three chapters: Couple Asynchronous Scripts, Use Iframes Sparingly, and Flush the Document Early.

The adoption of JavaScript is growing, but the blocking behavior of external scripts is well known. That's why it's important to use one of the techniques to load scripts without blocking (see the Google I/O talk). But loading scripts asynchronously means that inlined code that uses symbols from the script must be coupled in some way. Without this coupling, undefined symbol errors occur when the inlined code is executed before the external script arrives.

There are five techniques for coupling asynchronous scripts: hardcoded callback, window onload, timer, script onload, and degrading script tags. All of the techniques work. Degrading scripts tags is the most elegant, but isn't well known. Script onload is the most versatile technique and is the one I recommend people use. In the talk, I then go into detail, including many code examples, on how to load scripts asynchronously and use these coupling techniques to speed up your web page.

Iframes have a negative impact on web pages. They are the most expensive DOM element to create. They block the parent's onload event (although there's a workaround to this problem in Safari and Chrome). Also, the main page can block resources in the iframe. It's important to understand these interactions if you use iframes in your page.

Flushing the document early allows the browser to start rendering the page and downloading resources in the page, even before the entire HTML document has arrived. But getting flushing to work can feel like trying to get the stars to align. You need to understand PHP's output_buffering, HTTP/1.1's chunked encoding, Apache's DeflateBufferSize, the impact of proxies, minimum HTML size requirements in Safari and Chrome, and the need for domain sharding to avoid having the HTML document block other downloads.

If your company wants a better user experience, increased revenues, and reduced operating costs, the key is to create even faster web sites. For more information on these best practices, watch the video below and read the slides.

Check out other talks in this tech speaker series:

Doug Crockford: JavaScript: The Good Parts
John Resig: Drop-in JavaScript Performance

Doug Crockford: JavaScript: The Good Parts

DeWitt Clinton — Tue, 03 Mar 2009 00:13:00 +0000

By Steve Souders, Member of Technical Staff

Doug Crockford, from "The Yahoo!" (his words), gave a talk at "The Google" (again, his words) last week. The talk is based on his recent book of the same name, JavaScript: The Good Parts. Doug is a, perhaps the, JavaScript guru who has undertaken responsibility for helping the world's web developers embrace JavaScript and use it successfully to build clean, fast web applications. He is the creator of JSLint, JSMin, and JSON. (Notice a theme?)

Doug was hitting on all cylinders. I've heard him deliver this talk before, but this rendition was off the scale in terms of clarity, humor, and takeaways. He flowed effortlessly from broad observations to detail-oriented code samples.

He begins with the observation that JavaScript is one of today's most used languages, so it obviously has gotten something right. Despite this success, JavaScript has plenty of bad parts: global variables, semicolon insertion, with and eval, and more. There's confusion with false values. Consider this example:

'' == 0
0 == '0'
'' != '0'

In JavaScript, all three of these statements return true. Doug highlights other traps that are easy to fall into using for..in, ++, and typeof.

He delivers a clear, concise tutorial on object-oriented JavaScript and closures. The most satisfying piece to me was his clear explanation of why right-curlies ("block {" all on the same line) is the only acceptable style in JavaScript.

Tune in to the video below, and follow along with the presentation. It's enjoyable and enlightening. What a great combination. Thanks, Doug!

Developer Preview Releases for the Visualization API

DeWitt Clinton — Fri, 20 Feb 2009 23:13:00 +0000

By Nir Bar-Lev, Google Product Management

We are now offering Visualization API developers an opportunity to preview upcoming release candidates. Developers can opt in to these bleeding-edge builds simply by changing one line of code when loading the Visualization library.

Developers can use these release candidates as an opportunity to see what new features being developed, test upcoming changes in their applications in advance, and provide the Google team with valuable feedback on the Visualization API discussion group.

More details of the new process can be found in our Release Notes documentation. And please be sure to check out all the available visualizations and new Tools Gallery while you're there.

We hope to see you at Google I/O in May where we will be hosting several sessions to teach you how to be more productive than ever with the Visualization API.

Changes for Jaiku and Farewell to Dodgeball and Mashup Editor

DeWitt Clinton — Thu, 15 Jan 2009 03:00:00 +0000

By Vic Gundotra, Vice President, Engineering

Google has long believed that thoughtful iteration is the best way to build useful products for our users. As part of that process, we are always looking for ways to better focus our teams on the products that can have the most impact.

As we mentioned last April, we are in the process of porting Jaiku over to Google App Engine. After the migration is complete, we will release the new open source Jaiku Engine project on Google Code under the Apache License. While Google will no longer actively develop the Jaiku codebase, the service itself will live on thanks to a dedicated and passionate volunteer team of Googlers.

With the open source Jaiku Engine project, organizations, groups and individuals will be able to roll-their-own microblogging services and deploy them on Google App Engine. The new Jaiku Engine will include support for OAuth, and we're excited about developers using this proven code as a starting point in creating a freely available and federated, open source microblogging platform.

Some of you may also be familiar with Dodgeball.com, a mobile social networking service that lets you share your location with friends via text message. We have decided to discontinue Dodgeball.com in the next couple of months, after which this service will no longer be available. We will communicate the exact time-frame shortly.

Finally, in the spirit of onward and upward, we have decided to shut down the Mashup Editor, currently in limited private beta, in favor of the more powerful App Engine infrastructure. Existing Mashup Editor applications will stop receiving traffic in six months, and we hope you will join our team in making the exciting transition to App Engine.

Native Client: A Technology for Running Native Code on the Web

DeWitt Clinton — Mon, 08 Dec 2008 19:58:00 +0000

By Brad Chen, Native Client Team

Modern PCs can execute billions of instructions per second, but today's web applications can access only a small fraction of this computational power. If web developers could use all of this power, just imagine the rich, dynamic experiences they could create. At Google we're always trying to make the web a better platform. That's why we're working on Native Client, a technology that aims to give web developers access to the full power of the client's CPU while maintaining the browser neutrality, OS portability and safety that people expect from web applications. Today, we're sharing our technology with the research and security communities in the hopes that they will help us make this technology more useful and more secure.

At its core, our release consists of a runtime, a browser plugin, and a set of GCC-based compilation tools. Together, these components make it possible to build applications that run in a web browser but incorporate native code modules. To help protect users from malware and to maintain portability, we have defined strict rules for valid modules. At a high level, these rules specify 1) that all modules meet a set of structural criteria that make it possible to reliably disassemble them into instructions and 2) that modules may not contain certain instruction sequences. This framework aims to enable our runtime to detect and prevent potentially dangerous code from running and spreading. We realize that making this technology safe is a considerable challenge. That's why we are open sourcing it at an early stage: we believe that peer review, community feedback, and public scrutiny greatly improve the quality of security technologies like this one.

While it's a big challenge to secure Native Client, we believe that the ability to safely run fast native code in a browser has the potential to provide benefits to users and developers. For example, imagine that you run a photo-sharing website and want to let your users touch up their photos without leaving your site. Today, you could provide this feature using a combination of JavaScript and server side processing. This approach, however, would cause huge amounts of image data to be transferred between browser and the server, leading to an experience that would probably be painfully slow for users who just want to make a few simple changes. With the ability to seamlessly run native code on the user's machine, you could instead perform the actual image processing on the desktop CPU, resulting in a much more responsive application by minimizing data transfer and latency.

To learn more and help test Native Client, please visit our developer site. There you can read our documentation and the Native Client research paper, browse the source code, and download the research release. The release contains the experimental compilation tools and runtime so that you can write and run portable code modules that will work in Firefox, Safari, Opera, and Google Chrome on any modern Windows, Mac, or Linux system that has an x86 processor. We're working on supporting other CPU architectures (such as ARM and PPC) to make this technology work on the many types of devices that connect to the web today.

Once you've gotten your bearings, please report any bugs you find (especially security bugs) using our issue tracker, and join our Google Group to share your thoughts on the technology. We look forward to your feedback!

User Experience in the Identity Community

DeWitt Clinton — Tue, 02 Dec 2008 16:45:00 +0000

By Eric Sachs and Ben Laurie, Google Security Team

One of the major conferences on Internet identity standards is the Internet Identity Workshop(IIW), a semiannual 'un-conference' where the sessions are not determined ahead of time. It is attended by a large set of people who work on Internet security and identity standards such as OAuth, OpenID, SAML, InfoCards, etc. A major theme within the identity community this year has been about improving the user experience and growing the adoption of these technologies. The OpenID community is making great progress on user experience, with Yahoo, AOL, and Google quickly improving the support they provide (read summary from Joseph Smarr of Plaxo). Similarly, the InfoCard community has been working on simplifying the user experience of InfoCard technology, including the updated CardSpace selector from Microsoft.

Another hot topic at IIW centered around how to improve the user experience when testing alternatives and enhancements to passwords to make them less susceptible to phishing attacks. Many websites and enterprises have tried these password enhancements/alternatives, but they found that people complained that they were hard to use, or that they weren't portable enough for people who use multiple computers, including web cafes and smart phones. We have published an article summarizing some of the community's current ideas for how to deploy these new authentication mechanisms using a multi-layered approach that minimizes additional work required by users. We have also pulled together a set of videos showing how a number of these different approaches work with both web-based and desktop applications. We hope this information will be helpful to other websites and enterprises who are concerned about phishing.

[Also posted on the Google Online Security Blog.]

Moving another step closer to single-sign on

DeWitt Clinton — Thu, 30 Oct 2008 19:18:00 +0000

By Eric Sachs, Google Security Team

Yesterday we announced one step we took to help increase adoption of single-sign on across websites on the Internet. For more details, you can watch today's episode of thesocialweb.tv which covers the launch. While we announced that we would initially provide limited access to our OpenID IDP to make sure it was working properly, we were delighted to see that the number of sites that registered to receive access was significantly more than we had expected. So instead of having our engineers spend time manually maintaining that list of registered sites, we are now taking another step further and removing that restriction so any site can use the API.

That registration requirement also led to some confusion because users wanted to be able to use existing websites that accept OpenID 2.0 compliant logins by simply entering "gmail.com" (or in some cases their full E-mail address) into the login boxes on those websites. Normally what would happen after a user typed gmail.com is that the relying party website would look for a special type of file (XRDS) on the gmail.com servers that would check if Gmail run an OpenID identity provider. For yesterday's launch, we specifically chose not to publish that special XRDS file on gmail.com because if we had published the file, users would have received an error at Google if the website they were trying to log into had not registered with us. Now that we have removed the registration requirement, we will work on pushing that XRDS file as quickly as possible. Once the XRDS file is live, end-users should be able to use the service by typing gmail.com in the OpenID field of any login box that supports OpenID 2.0, similar to how Yahoo users can type yahoo.com or their Yahoo E-mail address. (In the meantime, if you feel really geeky, you can type "https://www.google.com/accounts/o8/id" into an OpenID 2.0 compliant login box and see the directed identity workflow in action.)

However, as we we noted in the Designing a Login User Interface section of our documentation, we do not place any requirements on the design of a federated login box on a relying party website. There are many approaches used by websites today, and the community is still experimenting with new approaches.

One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.

Google is committed to working on this problem. If community members also want to help in this area, please take a look at our research on combining rich-client apps with federated login which was discussed at the recent UX summit and discussed further in a blog post here. A key thing to notice is that this research is about another open source technology called OAuth, and is agnostic to the particular federated login technology used, i.e. SAML or OpenID. It is also agnostic to the type of strong authentication method (if any) that is used to authenticate the user.

To further increase the adoption of federated login, we need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If the community works together to build these components, they will be useful not only to Google, but also to any other relying parties that have rich-client apps or that expose APIs, and it will also help enterprise SaaS vendors like Salesforce.

If you want to help further these efforts, join the OpenID and OAuth mailing lists and tell people which platform you are targeting in case others want to help. For example, Mike Malone from Pownce did some work a few months ago to use OAuth on an iPhone and described how he got it working. And just yesterday another member of the open source community, Sean Sullivan, built a working OAuth enabled rich-client app for Android and posted the open source code.

Introducing the Gears Geolocation API for all laptop WiFi users

DeWitt Clinton — Tue, 21 Oct 2008 08:00:00 +0000

By Charles Wiles, Product Manager, Google Mobile Team

I am thrilled to announce that today we have enhanced the Gears Geolocation API so that developers can now securely locate users to within 200m accuracy in major desktop browsers in hundreds of cities around the world. Whether your users are Chrome, Internet Explorer, Safari, Firefox or (soon) Opera users, you can now automatically deliver an experience that is tailored to their current location. For example, lastminute.com's new Radar application allows users to find nearby hotels, ITN's Google Earth mash up in Firefox allows users to see nearby news stories and Rummble's social discovery site allows users to automatically set their current location for friends to see.

When we originally proposed the Gears Geolocation API our goal was to make it easy for developers to deliver location enabled web sites on mobile phones. However we realized laptop users would benefit from location enabled web sites too. Today we are adding WiFi signals to the Geolocation API so that laptop users can benefit from location enabled web sites for the first time and mobile users from the increased accuracy. And because the Geolocation API is the same for developers in both desktop and mobile browsers you can even use the same code on both platforms!

In Chrome and Android, with Gears built in, you can deliver a location enabled web site without requiring your users to install a plug-in, but in other browsers they will need to go through a simple plug-in install process. We also submitted a simplified version of the Geolocation API as a WC3 specification and the upcoming Firefox 3.1 plans to support the W3C version directly. The Gears Geolocation API is completely free to developers and users through the default Google location provider.

To protect user privacy, the Gears Geolocation API server does not record user location. However, third party sites may do so, and we recommend that users only allow web sites they trust to access their location. Gears will always tell a user when your site wants to access their location for the first time and the user can either allow or deny your site permission. We recommend users check the privacy policy of your web site if they are in doubt as to how your site may use location information.

iGoogle launches canvas view

DeWitt Clinton — Thu, 16 Oct 2008 17:00:00 +0000

By Dan Holevoet, Developer Programs

We're happy to announce the launch of the canvas view feature to iGoogle users in the U.S., rolling out over the course of the day. The canvas view feature allows gadget developers to build richer content, games, and UI for iGoogle's tens of millions of users by allowing them to build powerful full-page applications. In addition, canvas view provides developers with the opportunity to monetize their gadgets.

To get started, check out the documentation and examples on the iGoogle developer website. The site includes detailed information about iGoogle as well as information on upcoming OpenSocial functionality.

Try out the updated version of iGoogle and check out some of the great canvas view gadgets developers have already built.

A new era for Book Search begins with new APIs

DeWitt Clinton — Mon, 22 Sep 2008 16:04:00 +0000

By Venu Vemula, Google Book Search Team

Since I joined Google, I've been working on Book Search, our project to help users discover what's inside all the world's books.

Today we are happy to include the developer community in this historic effort with the announcement of two new APIs:

An Embedded Viewer API, which allows you to embed book previews on your site and control them programmatically using JavaScript.
A robust Data API, which allows you to access full-text search results and access with users' book reviews, ratings, and individual My Library collections.

By allowing anyone to integrate with the complete Google Book Search index, we hope this broader community will find new ways to connect users with books that are interesting and relevant to them.

To learn more about the sites already using these APIs — including Books-A-Million, Worldcat, and GoodReads — check out our post on the Book Search Blog.

Or, if you want to dig right in, go straight to our newly revamped developer site.

Google Developer Day Israel: Registration now open

DeWitt Clinton — Mon, 22 Sep 2008 13:01:00 +0000

By Alyssa England, Google Developer Programs

We are excited to open registration for one last Google Developer Day this year, to be held on November 2 in Tel Aviv, Israel.

At this Google Developer Day, developers will learn about the latest with our APIs and developer tools, ranging from App Engine and OpenSocial to Google Chrome, plus more. The topics will vary so you can be sure to discover new and interesting best practices. And don't forget to socialize with fellow developers and Google engineers.

If you are in Europe, registration for some of the October Google Developer Days is still open, including Italy and Czech Republic, though space is running out fast. We hope you can join us for one of our upcoming events.

Usability Research on Federated Login

DeWitt Clinton — Fri, 19 Sep 2008 15:30:00 +0000

By Eric Sachs, Product Manager, Google Security

Federated login has been a goal of the Internet community for a long time, but its usage is still quite low, especially in the consumer space. This has led to the constant need for users to create yet another account to log in to a new website, and most consumers use the same password across websites even though they realize this is a poor security practice. In the enterprise space, many software-as-a-service vendors such as Salesforce.com and Google Apps for Your Domain do support federated login, but even those vendors encounter usability problems.

On September 12 the OpenID Foundation held a meeting to gather feedback on how to evolve the best practices for using OpenID so that it might be used by websites in a larger number of market segments. The meeting included representatives from many mainstream websites including The New York Times, BBC, AARP, Time Inc., and NPR. Google has been researching federated login techniques, and at the meeting we showed how a traditional login box might evolve (see below) to a new style of login box that better supports federated login.

We also shared a summary of our usability research that explains how this helps a website add support for federated login for some users without hurting usability for the rest of the website's user base. We hope that industry groups, such as this committee in the OpenID Foundation, will continue to share ideas and experiences so we can develop a model for federated login that can be broadly deployed by websites and broadly used by consumers. If your company has experience or research that you can share, we hope you will get involved with the OpenID community and join the further discussions on this topic.

Picasa Web Albums Enables Video Uploads Via API

DeWitt Clinton — Tue, 09 Sep 2008 22:44:00 +0000

By Detlev Schwabe, Software Engineer

Many developers and partners use the Picasa Web Albums Data API to enable users to upload photos to Picasa from web sites and desktop applications. Now, we are excited to announce the same PWA Data API can be used to upload videos to Picasa Web Albums as well!

The API commands for uploading videos are similar to those you may already use to upload photos. You can upload videos up to 100MB in AVI, QuickTime, MPEG4, WMV and other formats. The system will automatically create a thumbnail image to represent the video, or you can choose one yourself at any time.

There are many ways you can use video uploading, including enabling users to upload all the content from their cameras — including still images as well as videos — all to Picasa Web Albums at the same time. And, of course, the Video Uploader API is the perfect way to integrate dedicated webcams with Picasa!

The Video Uploader API is part of the standard Picasa Web Albums Data API. You can find the updated documentation here.

Google Visualization API now in PHP

DeWitt Clinton — Tue, 19 Aug 2008 17:16:00 +0000

By Nir Bar-Lev, Product Management

Here at the Google Visualization HQ we focus hard on making the Visualization API the easiest and simplest platform for visualizing and reporting data on the web. We're always excited to see the community uptake and develop our product, making it even more useful and accessible to other developers. One such initiative is the PHP wrapper class that Thomas Schaefer wrote for the Visualization API.

The class wraps the API and enables PHP application developers to quickly integrate visualizations into their code. Thomas even published reference applications that enable you to get started even quicker.

We love your work Thomas, keep it up!

More materials on Google Code University

DeWitt Clinton — Thu, 14 Aug 2008 17:12:00 +0000

By Dan Peterson, Product Manager

With the fall semester rapidly approaching at universities all over, we're happy to share that we've recently made more content available on Google Code University. In case you're not familiar, Google Code University is a repository of educational material including tutorials, lecture slides, and videos focused entirely on computer science. Not only is it a collection of high-quality educational materials, but most of the course materials are Creative Commons licensed, to enable reuse and modification by educators and students alike.

This recent update includes materials covering:

Intro to CS Algorithms from Princeton and Stanford
More content about the foundations of web security
New Distributed systems materials from the University of Waterloo, Swarthmore, and Rutgers University
A broad set of additional resources for teaching CS

We hope you find these new materials interesting and useful. If you have suggestions or materials you'd like to share, please discuss on the forum.

Introducing Content Licenses on Google Code

DeWitt Clinton — Wed, 23 Jul 2008 20:04:00 +0000

By DeWitt Clinton, Google Developer Programs

The Google Code team is pleased to announce the availability of content licenses for projects hosted on code.google.com. Projects owners may now select from either the Creative Commons Attribution license or the Creative Commons Attribution-Share Alike license to indicate the terms under which their non-source code materials may be distributed.

While this may seem like a minor change, it reflects the continued evolution of our mission to support best practices in open source software development. As the open web increasingly relies on protocols and formats that reach beyond source code, we encourage authors to apply an explicit copyright license to the data, documentation, and related media that complements their work.

Please join us in the project hosting discussion group if you have any questions.

OAuth Available for Google Data APIs

DeWitt Clinton — Fri, 27 Jun 2008 23:04:00 +0000

By Jackie Bodine, Google Data APIs Team

We love open standards, and we've just added support for a new one: OAuth is now supported on all of the Google Data APIs.

OAuth is an open standard for authentication that allows applications to authenticate users without ever directly handling usernames and passwords. Because OAuth is a standard, you can use the same authentication code for any of the Google Data APIs and for APIs from other providers who support OAuth.

To learn more, see the announcement on the Google Data APIs blog.

A Google Data API for Google Finance

DeWitt Clinton — Fri, 27 Jun 2008 00:33:00 +0000

By Steven Soneff and Casey Ho, Google Finance Team

In case you haven't seen the announcement on the Google Data API blog, there is a new API available for Google Finance Portfolios.

The Google Finance API makes it easy to create and access investment data for your users -- ranging from updating their investment holdings and watchlists to retrieving current portfolio value and performance. With your applications, users can monitor their portfolios and transactions and keep positions up-to-date and in-sync. If you have a great idea for a portfolio application, give the new API a try!

Registration Open for "Powered By YouTube"

DeWitt Clinton — Thu, 12 Jun 2008 22:24:00 +0000

By Stephanie Liu, YouTube APIs and Tools Team

The YouTube APIs team had so much fun at Google I/O that we thought it was about time to have our own event at our office in San Bruno. (Check out the announcement on the YouTube API Blog for a video of the office.) This will be all YouTube APIs, all the time! The agenda is still being finalized, but we'll have "bigger picture" sessions as well as nitty gritty hacking time to get started and learn best practices. You'll have time to mingle with a diverse set of developers from different companies and the YouTube engineers and product managers.

If you're interested, here are all the details:

Thursday, July 10, 2008
10:30am - 5:00pm (tentative)
YouTube HQ @ 901 Cherry Ave. San Bruno, CA 94066
Cost: Free

Please reserve your spot and register early at Powered By YouTube.

Already have questions, comments, or session suggestions? Let us know in the forum. Hope to see you here next month!

Check out the Custom Search API

DeWitt Clinton — Thu, 12 Jun 2008 18:47:00 +0000

By Kevin "Grendelzilla" Lim, Custom Search Team

Have you ever wished that you could harness the power of Google to create a customized search engine for your website or a collection of websites? Custom Search lets you do that in under five minutes—and that includes time for a tea break. Pretty sweet, eh? If you have more time, you could take the customization to the next level. You can select websites to include, ignore, or prioritize in your search engine. You can even tweak the ranking of your search results and change the look and feel of your results page, among other things.

If you are curious about how tricked-out custom search engines work, you don't have to look further than the Custom Search API page on Google Code. Go ahead, try out some search queries and be sure to visit the Custom Search Directory, which showcases some popular custom search engines. And close to home, we use a combination of the Custom Search API and the AJAX Search API to power search on Google Code.

To learn more about this API, see the developer guide and join us over in the discussion group.

Updated Themes API for iGoogle

DeWitt Clinton — Wed, 11 Jun 2008 20:55:00 +0000

By Kathleen Ko, iGoogle Team

We are excited to open up an updated Themes API for developers to customize new features coming to iGoogle. Features you can modify include the left navigation and UI updates introduced in the iGoogle developer sandbox in April, as well as the chat feature that was released to the sandbox last week. If you have already created one of the 800 themes in the iGoogle directory, make sure to update your theme with the latest attributes and resubmit.

You can more details in the updated developer's guide. We're hoping these feature additions will allow for developers to customize even more of iGoogle.

As always, questions and feedback are welcome in the Google Themes API group.

Introducing the Google Health Data API

DeWitt Clinton — Sat, 31 May 2008 02:46:00 +0000

By Christian Sonntag, Google Health Team

With the recent launch of Google Health, we also launched the Google Health Data API, which we hope will further contribute to the goal of making personal health management easier for people. The API can be used to create new medical records, request a list of medical records, and query for medical records that match particular criteria.

Learn the details from this announcement post on the Google Data APIs blog, and join the conversation in our discussion group. We look forward to seeing the apps you create with this new API!

Google Visualization API Expanding Beyond Google Spreadsheets

DeWitt Clinton — Fri, 30 May 2008 01:40:00 +0000

By Nir Bar-Lev, Product Manager

We are excited to announce that we are opening up the Google Visualization API beyond Google Spreadsheets and adding more capabilities for developers. Earlier at the Google I/O developer conference, we launched several new features of the Google Visualization API:

A JavaScript interface to create add-hoc data tables on the client. This way, visualizations are not limited to server-side data sources living on the Google cloud. Data from any source can now be visualized using the visualizations created by Google and the community.

The new interface allows developers to create non Gadget-ized visualizations. With this new option, developers can embed visualizations directly into a web page and have those interact with the page. Of-course, Gadgets have significant advantages related to syndication. They are also the option of choice when looking to include visualizations in popular “containers”, such as Google Spreadsheets, iGoogle, etc. The Google Visualization API will continue to support both flavors of its API going forward. Visualizations can easily be created and then be wrapped by a thin Gadget wrapper. This allows for maximal exposure and use of the visualization in as many use cases as possible.

The AJAX API introduces another cool new capability: we are introducing a common event model to allow for visualizations to communicate with their host web-page and with other visualizations. With this event model web page authors and developers can create complex dashboards from several visualizations, all associated and context-aware.

As part of the event model, we are introducing a generic select event. Developers can introduce their own events for their visualizations. We plan on adding more generic events that the community chooses and aligns around – ultimately creating a robust event model for visualizations and dashboards.

You can read more about these cool new additions on the Visualization API website. Browse the new visualization gallery to see the visualizations we have already posted over the new JavaScript interface and and take look at code examples to get started with your own.

We would love to hear more from you on these new additions. Tell us what you think and engage with the rest of the community on the API’s community group page.

How the bar chart was reinvented to renewed notoriety

DeWitt Clinton — Thu, 22 May 2008 00:00:00 +0000

By Nir Bar-Lev, Product Manager

When we launched the Visualization API we wondered, which new visualization types will the developers out there come up with? Which one will be successful? Will we quickly see the long tail of visualizations being developed?

Visualizations, as with many other things, follow a rule we know very well at Google: Their distribution is such that there are a few visualizations at the 'head', which get the majority of usages, and then there is a long tail of special visualizations, that by virtue of their subject matter or type, get little overall use.

Take for example the ubiquitous line chart vs the radar chart:

Line charts are extremely useful in visualizing continuous changes over time or other factors, and as such are used for data sets ranging from displaying financial results, to the growth of germs on petry-dishes to following presidential candidates' accumulation of votes. You'll find line charts in almost every type of presentation, even in cartoons:

On the other hand, radar charts are relatively rare and most people have never encountered one, unless they happened to have taken an advanced university course in Marketing, for example.

Obviously there are highly specialized visualizations that are extremely common. For example, the 2-hands clock view, is one of the most wide-spread used visualization to display time. Yet, many visualizations have been developed for specific use in specialized fields of study, or work.

As such, you can imagine we had a fun time betting on which visualization will come out and which will catch on. Some of the bets in the team were made on us first seeing specialized visualizations. Perhaps a network diagram. Others, had bet on seeing new, high end, pivoting and data drill-down, slice-and-dice wizardry. Who won? Apparently we all lost our bets.

It seems the common straightforward visualizations can be reinvented with a just few simple changes to make them immensely powerful - and fun - as visual tools. Enter, the Bar (or Column) Chart and the Piles of Money visualization:

By altering the standard visual design of the bars (or columns) as wide lines, or rectangles and simply converting them to an image of a growing pile of money, the Piles of Money chart has rocketed to the top five most popular visualizations used over the Visualization API. This simple change can provide the same insight as any bar chart, yet when used on data sets related to cost, revenue or any other financial measurement, it becomes a fun, engaging chart, not derogating in any way from its original purpose and actually adding additional emphasis that the subject matter is money.

The Bars of Stuff chart was added just after Piles of Money, and provides the same treatment to the horizontal bar chart as Piles of Money did to the vertical bar chart. Users can choose on of several cool visual designs, like chocolate, cute worms, etc to be used instead of the bars.

I can't wait to see someone take the idea behind Piles of Money and advance it to the next step: create a visualization in which the user can visualize bars of anything they want by choosing the image to be integrated into the visualization: Piles of Boxes, Piles of Shoes, Bars of Soap.

To see all of the Visualization API's current list of visualizations by Google and the community, check out our gallery.

How Google Friend Connect Works

DeWitt Clinton — Sat, 17 May 2008 17:30:00 +0000

By Peter Chane, Sami Shalabi, Mussie Shore

We figured you might be tracking the conversations about Google Friend Connect and Facebook. We want to help you understand a bit more about how it works on the Friend Connect side with respect to users' information.

People find the relationships they've built on social networks really valuable, and they want the option of bringing those friends with them elsewhere on the web. Google Friend Connect is designed to keep users fully in control of their information at all times. Users choose what social networks to link to their Friend Connect account. (They can just as easily unlink them.) We never handle passwords from other sites, we never store social graph data from other sites, and we never pass users' social network IDs to Friend Connected sites or applications.

The only user information that we pass from a social networking site to third-party applications is the user's public photo, and even that is under user control.

That's the high-level view. But what about the details? Here is more information on exactly how Friend Connect interacts with third-party social networks and applications.

Google Friend Connect puts users in control over whether they're connected to their data on Facebook.
Google Friend Connect only reads a small amount of user data from Facebook, and does so using Facebook's public APIs. We read the Facebook numeric id, friendly name, and public photo URLs of the user and their friends. We read no other information.
The only user information that we pass from Facebook to third-party applications is the URL of the user's public photo.
Google Friend Connect does not permanently store any user data retrieved from Facebook.

1) Google Friend Connect puts users in control over whether they're connected to their data on Facebook.

We behave like any other caller of the Facebook API. (See the Facebook developer api documentation for details.) When a user links their Facebook account with Google Friend Connect they must consent to this on Facebook itself. Here is the set of screens a user goes through:

First, the user must click "Link in Facebook friends":

Next a user sees this screen. This screen is from Facebook (notice the URL of the page shows facebook.com):

The user is then asked for their Facebook username and password on Facebook. (Note that Google Friend Connect does not have access to the user's Facebook username and password.) If the user logs in successfully, Facebook returns a session key to Google Friend Connect, and the user sees this screen:

This screen also comes from Facebook. On this screen the user is asked to consent to allowing Google Friend Connect to access some of their personal information. The user can choose to allow this access or not.

The user can easily unlink their Facebook account from Friend Connect. This can be accomplished in two ways:

From the Friend Connect settings dialog:

And from within Facebook's own Applications Privacy screen:

2) Google Friend Connect only reads a small amount of user data from Facebook, and does so using Facebook's public APIs. We read the Facebook numeric id, friendly name, and public photo URLs of the user and their friends. We read no other information.

If a user decides to link their Facebook account to Google Friend Connect, we ask Facebook for a small amount of user information. Here's an example of what might be returned:

Example data retrieved from Facebook (NOT passed to third-party apps):

  500013789
  31415926535
  Peter Chane
  http://profile.ak.facebook.com/profile5/1038/101/s500013789_4207.jpg
  694454023
  Mussie Shore
  http://profile.ak.facebook.com/profile6/1933/85/s694454023_4271.jpg
  709611
  Sami Shalabi
  http://profile.ak.facebook.com/profile5/657/87/n709611_9673.jpg

This data is made up of the following fields:

A Facebook user ID (e.g. 500013789) that is used when Google Friend Connect communicates with Facebook. The unique ID is a number assigned by Facebook -- it is NOT the user's username or their phone number. The unique ID contains no personal information.
A session-key (e.g. 31415926535) which is a unique number provided by Facebook, that Facebook uses to track and control what data is exposed to Google Friend Connect for the logged-in user.
The user's friendly name as they entered it in Facebook (e.g. "Peter Chane"). This is typically a first and last name.
A URL to the user's public Facebook picture (e.g. http://profile.ak.facebook.com/profile5/1038/101/s500013789_4207.jpg). If the user set their picture to be private on Facebook then Google Friend Connect does not receive the picture. Again the picture used by Google Friend Connect is public and is easily viewed by anyone on the web.
A list of Facebook user IDs for each of the user's friends on Facebook. For each friend, Google Friend Connect retrieves the friend's Facebook picture-URL and name.

3) The only user information that we pass from Facebook to third-party applications is the URL of the user's public photo.

Applications that run on Friend Connect sites (e.g. the iLike application that runs on www.ingridmichaelson.com) have access to a subset of the information that is requested by Friend Connect from social networks such as Facebook. Applications are passed the following data from Friend Connect:

Your Google Friend Connect ID. This is a number. It is not a name, and it is not your ID from Facebook or any other social network.
Your nickname that you entered in Friend Connect. (NOT your friendly name from Facebook or any other social network.)
The URL to your public photo from Facebook or another social network. And only if you've chosen to make that photo public on the social network. (Note that Facebook includes the user's Facebook ID in the URL of their profile photo. We intend to obfuscate this URL in a future release of Friend Connect.)
The Google Friend Connect IDs (and Friend Connect nicknames, and photo URLs from linked social networks) of any of your friends who are also members of this site. (Not all of your social network friends. Not their social network IDs.)

That's it. These apps have no access to additional profile data -- yours or your friends. The apps have no idea who else is on your friends list on your social network(s).

4) Google Friend Connect does not permanently store any user data retrieved from Facebook.

Google Friend Connect purges all of the data it receives from Facebook frequently. The Facebook terms state that application developers should do this every 24 hours; we do it more often (currently every 30 minutes) because we don't want to store this data any longer than we absolutely need it.

Thanks for your interest in Friend Connect!

Regards,

Peter, Sami, Mussie

Introducing Google Doctype

DeWitt Clinton — Wed, 14 May 2008 16:45:00 +0000

By Mark Pilgrim, Google Code Team

The open web is the web built on open standards: HTML, JavaScript, CSS, and more. The open web is a beautiful soup of barely compatible clients and servers. It comprises billions of pages, millions of users, and thousands of browser-based applications. You can access the open web with open source and proprietary browsers, on open source and proprietary operating systems, on open source and proprietary hardware.

Google has built its business here, on the open web, and we want to help you build here too. To that end, we are happy to announce the formation of an encyclopedia for web developers, by web developers: Google Doctype.

In its current (beta) form, Google Doctype contains dozens of articles written by top Googlers on topics important to all web developers: security, performance, caching, DOM manipulation, CSS styling, and more. It contains over 8,000 lines of JavaScript code: Google's own battle-tested JavaScript library, released today under a liberal open source license. And it contains the beginnings of a test-driven reference of the open web: a reference of every element, every attribute, every DOM method, every CSS property, all backed up by test cases.

Well, not quite every property; at least, not yet. We're still working on filling in a few of the details about the world's largest development platform ever, and we need your help. And so we humbly offer this fledgling encyclopedia under a Creative Commons Attribution license, and we invite the web developers of the world to contribute to it. Sign in with your Google account and edit any page, any article, anywhere. Create new ones, update old ones, and help expand the world's understanding of the open web.

The Future of Web Performance at Google I/O: JavaScript

DeWitt Clinton — Thu, 08 May 2008 20:52:00 +0000

By Steve Souders, Member of Technical Staff

This post is one in a series that previews Google I/O, our biggest developer event in San Francisco, May 28-29. Over the next month, we'll be highlighting sessions and speakers to give Google Code Blog readers a better sense of what's in store for you at the event. - Ed.

In April I announced that I'm starting another book. The working title is High Performance Web Sites, Part 2. This book contains the next set of web performance best practices that goes beyond my first book and YSlow. Here are the rules I have so far:

Split the initial payload
Load scripts without blocking
Don't scatter scripts
Split dominant content domains
Make static content cookie-free
Reduce cookie weight
Minify CSS
Optimize images
Use iframes sparingly
To www or not to www

I'm most excited about the best practices for improving JavaScript performance (rules 1-3). Web sites that are serious about performance are making progress on the first set of rules, but there's still a lot of room for improving JavaScript performance. Across the ten top U.S. sites approximately 40% of the time to load the page is spent downloading and executing JavaScript, and only 26% of the JavaScript functionality downloaded is used before the onload event.

In my session at Google I/O I'll present the research behind rules 1-3, talk about how the ten top U.S. web sites perform, demonstrate Cuzillion, and give several takeaways that you can use to make your web site faster.

Google App Engine Hack-a-thon coming to your coast!

DeWitt Clinton — Thu, 24 Apr 2008 21:56:00 +0000

By Amanda Surya, Google Developer Programs

In May, we'll be holding two Google App Engine Hack-a-thons at Google's offices. The first one will be in New York, May 7th, from 10am - 6pm, and the second one in San Francisco, May 16th, 10am - 10pm. This is a great opportunity to get started on Google App Engine. You can code along with us in building an app from start to finish or you can bring your existing apps and get some help and guidance from Google engineers.

Check out the full details of these events and RSVP for either the New York Hack-a-thon or the San Francisco Hack-a-thon. Or both, if you have the frequent flier miles to spare.

Google Developer Days 2008: expanding to thirteen locations

DeWitt Clinton — Tue, 22 Apr 2008 04:20:00 +0000

By Elizabeth Yin, Google Developer Programs

Google Developer Days 2008, a set of one-day developer events, are back and will take place in locations around the world. We've designed these events for developers with strong coding backgrounds, so that we can discuss our APIs, developer tools and applications.

We'll host Google Developer Day in these locations:

Yokohama, Japan (June 10)
Beijing, China (June 12)
Taipei, Taiwan (June 14)
Sydney, Australia (June 18)
Mexico City, Mexico (June 23)
Sao Paulo, Brazil (June 27)
London, UK (Sept 16)
Paris, France (Sept 18)
Munich, Germany (Sept 23)
Madrid, Spain (Sept 25)
Milan, Italy (Oct 21)
Prague, Czech (Oct 23)
Moscow, Russia (Oct 28)

If you're based in the US, we encourage you to come to Google I/O, on May 28-29 in San Francisco.

At Google Developer Day, our engineers will share their inside knowledge on our developer tools and APIs, including Android, OpenSocial, and AppEngine. In many locations we'll do deep dives into code and conduct hands-on codelabs.

We've posted detailed information for our early dates and will be adding more information for other locations soon. If you're a developer, we encourage you to sign-up for a Google Developer Day at a nearby location. Hope to see you there.

Update: Corrected the September 23rd event location from Hamburg, Germany to Munich, Germany.

Developer sandbox for iGoogle launches

DeWitt Clinton — Mon, 21 Apr 2008 16:45:00 +0000

By Saurabh Mathur, iGoogle Team

Today, we're excited to open up a developer sandbox for iGoogle. The sandbox includes support for OpenSocial, a common API designed to let you easily build social applications that run on a growing number of web containers. The iGoogle OpenSocial container also supports canvas view, allowing developers to build powerful and feature-rich full-page applications for iGoogle's tens of millions of users.

To get started, please begin with the documentation and examples on the iGoogle developer website. The site includes detailed information about iGoogle and a guide to incorporating the new social features.

Watch as Jake walks us through the sandbox and shows how to build a basic gadget.

Sign up for access to the developer sandbox and keep up-to-date with our new iGoogle Developer Blog.

Happy coding!

新增！Novo! Новинка! ¡Nuevo! 新しい!

DeWitt Clinton — Thu, 17 Apr 2008 00:40:00 +0000

By Naomi Bilodeau, Google Code Team

Developers speak lots of languages, not just English and C++. We know that you use Google Code from all over the world, and we understand that the love of a good API is universal.

We're excited to announce that developer content on Google Code is now available in five new languages: Chinese, Japanese, Portuguese, Russian, and Spanish. Many of our pages, such as the site directory and landing pages for the various APIs have already been translated. You will also find that some of the deeper technical documentation, such as the Chart API and Maps API, has also been translated where appropriate. Where we haven't translated the content yet, you will continue to see the English version of the site.

We'll be working to keeping this content up-to-date, and we're looking forward to adding more support for languages and APIs throughout the year.

Update: Corrected to read "in five new languages." The sixth language, of course, is English.

A patent license just for you

DeWitt Clinton — Tue, 01 Apr 2008 20:32:00 +0000

By Jackie Bodine, Google Data APIs Team

The goal of the Google Data APIs is to give developers a consistent (and familiar) way to integrate with Google products. At their heart is Atom and the Atom Publishing Protocol, and we've created extensions on top of those open standards to add features like specifying a calendar schema or authentication protocol.

We've always intended for the Google Data APIs to be open and reusable, and today we've taken an extra step to make that intention clearer. We're giving a no-charge, royalty-free license to any patents we have that you would need to implement Atom, AtomPub, or any of our extensions. The official way to do this was via an intellectual property disclosure to the IETF and the patent license now linked from the Google Data APIs docs.

We hope this will encourage sites who want to expose APIs for things like photos, videos, calendar, or contacts to reuse our schemas where they can, rather than reinventing the wheel. Doing so will make it easier for developers who are integrating with multiple sites or porting over an existing app to a new site.

To learn more, check out the Google Data APIs Blog or dive into the patent license itself. Also, be sure to register for the Google I/O conference. I'll be giving a talk there about Google Data APIs, and there will be opportunities for deeper discussions and direct interaction with the engineering team.

Silicon Valley Google Technology User Group to host maps meeting

DeWitt Clinton — Fri, 28 Mar 2008 15:35:00 +0000

By guest author, Michael "Van" Riper, Silicon Valley Google Technology User Group

Ever wondered how to create maps like this Primary Election Results Map, created by Michael Geary? If so, please join us in at the Googleplex (Bldg 43, main campus, room Tunis) on the evening of April 2nd. Michael will be on hand to show you how. This gathering is being co-hosted by the Google GEO Developer Series and the recently formed Silicon Valley Google Technology User Group (which is not affiliated with Google). A networking hour with food and drinks starting at 5:30pm will be followed by Michael's talk at 6:30pm. Although this is a free event open to all, we do ask that you register in advance.

During the evening, we're also inviting community members to come forward and do short (no more than 5 minutes) demos of their own Google GEO applications during the networking hour. If you would like to participate in that way, please contact me. I'll be coordinating the networking hour demos. That's all, folks.

Add your own buttons to Picasa, upload photos all over the Web

DeWitt Clinton — Thu, 27 Mar 2008 00:00:00 +0000

By Michael Herf, Photos Team

If you've ever wanted to make your favorite software or website work with Google's Picasa software, there's a new Picasa Button API that lets you add your own buttons to the desktop interface.

The BlogThis! button in Picasa uses these APIs.

These buttons can send files to other applications on your PC, -- this tutorial (.zip) shows how to send files to Adobe Photoshop CS3 -- and they can also upload photos and movies to websites of your choice.

I'm most excited about our Web Uploader API. It uses a protocol we developed for posting photos to Blogger a couple years ago, and it shows a web-based preview of what you're going to upload before you send it. Using the web uploader, you can make user interfaces that feel more like sending an email and less like "Wait an hour to upload..." Picasa can also resize files before sending, saving time. There's some sample PHP code (.zip) to try out.

Also because these new buttons can be made by anyone, it means that there's no job too small for a Picasa button. You could make a button for your personal blog or for your major photo hosting service. See our demo video, which features Smugmug.

If you live near Mountain View, California, come out for Thursday's Youtube/Picasa Hackathon. We'll be showing off examples of these APIs, and answering questions to help you get started with them.

An OpenSocial Foundation

DeWitt Clinton — Tue, 25 Mar 2008 14:00:00 +0000

By DeWitt Clinton, Google Developer Programs

Today we are pleased to announce that Google is joining together with Yahoo! and MySpace in the creation of a non-profit foundation for the open and transparent governance of the OpenSocial specifications and intellectual property. This foundation, modeled after the community-led and industry-supported OpenID Foundation, will seek to ensure that the technology behind OpenSocial remains implementable by all, freely and without restriction, in perpetuity. The establishment of the foundation is a necessary and exciting next step toward an open model for application syndication via an increasingly socially-enabled Internet, and we invite and encourage your involvement as we complete this process over the next several months.

Additionally we are pleased to be a part of the launch of opensocial.org, the new official home for the OpenSocial specifications and developer community. While we are still in the early stages of putting the new site together, we wanted to open the site and the process immediately for community feedback and review.

So please join us, Yahoo!, MySpace, and all of the other OpenSocial containers and application providers, in extending a warm welcome to the community in a spirit of collaboration and rapid iteration, as we move forward with the establishment of the OpenSocial Foundation and look ahead to the continued growth of the social web.

New features for the Google Chart API

DeWitt Clinton — Thu, 20 Mar 2008 20:45:00 +0000

By Marcus Boerger, Software Engineer, Chart API team

Many of the features you've requested via Google Chart API forum are now live in the Google Chart API:

Easily create Sparklines (&cht=ls) without having to manipulate other kinds of graphs.
Support for Radar charts (&cht=r or &cht=rs) to display data in a polar coordinate system.
A new Map chart type (&cht=t) which makes it easy to colour countries and regions according to your data.

Some other changes we've made:

Added scaling for text encoded data
Added support for negative numbers on bar charts
Added ability to draw data lines on bar charts

You can read more about all of this -- plus the fact that we've lifted the 50,000 queries per day limit -- on the Chart API site. And special thanks to our Technical Writer Lesley Burr, who put together this documentation in her 20% time.

Introducing the Google Visualization API

DeWitt Clinton — Wed, 19 Mar 2008 15:55:00 +0000

By Nir Bar-Lev, Product Manager

We spend a fair amount of time on data display and visualization projects at Google, and we have found that the "last mile" of these projects tend to become full projects in and of themselves.

Thus when we acquired Gapminder last year, we were excited by the opportunity to use Gapminder's powerful visualization techniques to bring new life and usefulness to Google datasets. And we were not alone -- the web is home to a vibrant community of developers who build amazing visualization applications.

With the community in mind, we're please to introduce the Google Visualization API, which is designed to make it easier for a wide audience to make use of advanced visualization technology, and do so in a way that makes it quick and easy to integrate with new visualizations.

There are a two key elements here: simplicity and ubiquity. We hope we nailed the first, but of course we want to hear your feedback on that. The second will take more time, but we hope we're on the right path. We're releasing this API at an early stage so we can get continuous feedback and be sure we're building it the right way.

This launch is in tandem and in cooperation with the Google Docs team, who just announced support for gadgets and the Visualization API in spreadsheets. This includes a set of gadgets created by Google and several other companies, including some that add pivoting, grouping, and other new functionality to your spreadsheets. You can see all of those in our 'featured' list within the visualization gallery, which includes the Gapminder Motion Chart that has proven especially popular among within Google.

We hope you're as excited about the Google Visualization API as we are -- please be sure to tell us what you think. We'll also be at Google I/O on May 28-29 for deeper discussions about the API or visualization techniques in general.

Google Code University: CS Educational Materials

DeWitt Clinton — Tue, 18 Mar 2008 20:29:00 +0000

By Noel Gorelick, Software Engineer

Last summer we launched a site aimed to help educators and students alike become more familiar with the technology behind Google and the massive internet in general. Recently, we've redesigned that site and given it a fresh name: welcome Google Code University.

Google Code University is a growing repository of computer science educational material including tutorials, lecture slides, and videos. Since the initial launch last summer, we've added a lot of new content -- for example, a few months ago we blogged about course material that the University of Washington developed with us on large-scale distributed computing. Recently, we've added tutorials on MySQL and Subversion. And there's a new series of lectures from an introductory web programming class taught at the University of Washington. The site's still growing, and we'll keep adding more content in the coming months.

Most importantly, most of the course materials are Creative Commons licensed, so we encourage educators and students to reuse and build upon them. If you have questions, comments, or materials you'd like to share, please visit the forum. We'd love to hear your feedback and have you contribute to the site.

Lifting the limit on calls to the Google Chart API

DeWitt Clinton — Tue, 18 Mar 2008 17:45:00 +0000

By Sebastian Wilhelmi, Google Chart API SRE

We got a lot of feedback after releasing the Google Chart API in early December. By far the most questions were about the limit of 50,000 queries per user per day. Some of you who are webmasters of larger sites are afraid of overstepping this limit. We've heard your concerns, and have decided to drop that limit altogether.

However, should you expect to regularly cause more than 250,000 queries per day to the Google Chart API, we'd like you to let us know by mailing chart-api-notifications@google.com so that we can plan for the demand.

And with that said, from now on, if your site can't handle the Slashdot effect, it shouldn't be because of the Google Chart API. ;)

But why did we impose a query limit to start with? It was there to ensure that we could provide a reliable service for all legitimate users because we were able to lock out malicious users.

We work hard to provide reliable services, and even have a specific team of site reliability engineers (SRE) dedicated to keeping our services up and running (as well as fast). I cover the Chart API for SRE. A very important part of an SRE's work is capacity planning, because only a service with sufficient capacity can serve reliably and with low latency. For a new service, planning the capacity is naturally very hard, because there are a lot of unknown contributing variables. That's why we started with a quite conservative query limit. Now, that we've had the public API running for some time, we've collected enough experience to feel comfortable raising that limit without jeopardizing the service's reliability.

By the way, there's a lot more to what an SRE does. We also run, debug, optimize and troubleshoot very large scale distributed systems. If you're interested, come join Google SRE -- for instance the Zürich SRE team, where I work.

YouTube / Picasa Web Albums APIs Hackathon at the ‘plex

DeWitt Clinton — Tue, 18 Mar 2008 01:59:00 +0000

By Stephanie Liu, YouTube APIs and Tools Team

As promised in my last post announcing the new YouTube developer offerings, we're hosting a hackathon for the YouTube and Picasa Web Albums APIs at the Googleplex on March 27th, 2008.

We'll give overviews of both APIs, go over new features, and run some codelabs to get you started. If you're already familiar with both the APIs, stop by to meet the teams, ask questions, and find other developers to work on projects with.

There will be two sessions -- one from 3PM - 6:30PM and another from 6:30PM - 10PM. Feel free to stay the whole day, or just come for the session you have time for. Don't worry about food and caffeine -- we've got you covered.

Interested? Please RSVP and let us know.

Hope to see you there!

YouTube APIs for developers and for… iguana enthusiasts

DeWitt Clinton — Wed, 12 Mar 2008 06:28:00 +0000

By Stephanie Liu, YouTube APIs and Tools Team

Ever wanted to get in on the online video craze? Now's a good time! We've just added upload, write, and authentication functionality to the YouTube Data API. Brand new player APIs and tools are also now available.

That means that if, for example, you run a site just for iguana enthusiasts, your users can upload videos of JubJub to their YouTube accounts, post comments, create iguana playlists, and more, all without leaving your site. And with the new player APIs and the new chromeless player, you can completely customize and skin the YouTube embedded player to match the look and feel of your site (a green theme, buttons that look like scales?).

So excited that you can't decide what to do next? Read more details over at the YouTube API blog, watch our engineers talk about the new features (on YouTube, where else?), check out the docs, then join the forum.

You can also mark your calendars -- we'll be holding a YouTube / Picasa hackathon on March 27th at the Googleplex in Mountain View. Stay tuned for more info.

Introducing the Google Contacts Data API

DeWitt Clinton — Thu, 06 Mar 2008 01:43:00 +0000

By DeWitt Clinton, Google Developer Programs

A common contact list has helped power applications like Gmail, Google Reader, and Google Calendar. And now, with the launch of the Google Contacts Data API, we're opening up this contact list to your applications as well.

Based on AtomPub, the Contacts API can be used to safely read, create, edit, and delete contact information stored with Google, all while keeping users' passwords private via delegated authentication and authorization. Learn the details from Sebastian Kanthak in his announcement post on the Google Data APIs blog, and join the conversation on the Contacts API Group.

Power up your mobile web applications

DeWitt Clinton — Tue, 04 Mar 2008 07:02:00 +0000

By Charles Wiles, Product Manager, Google Mobile Team

It's a mobile zoo out there. If you've ever tried coding up a mobile client application, you've probably noticed that the huge variety of mobile operating systems makes it tough to build rich applications that work on every device. We face the same challenges. But what if developers could deploy applications directly to mobile browsers rather than develop native applications? That would simplify the development process, as developers could use the same coding skills to create mobile applications. Even better, if these mobile web applications could work offline, users would be able to use them when they are disconnected from the network.

Developers, look no further. Today we're announcing the launch of Google Gears for mobile, a mobile browser extension for creating rich web applications for mobile devices. The first version is now available for Internet Explorer Mobile on Windows Mobile 5 and 6. It's a fully functional port of Google Gears v0.2 that can be used to develop offline capability into your mobile web applications. You can also create slick and responsive applications by hiding latency issues through controlled caching of data and storage of information between sessions. We're also working to bring Google Gears for mobile to Android and other mobile platforms with capable web browsers.

There are already a handful of Windows Mobile web apps that use Google Gears for mobile, such as the personal finance service Buxfer and online applications provider Zoho. Read more about these applications and how they use Google Gears for mobile on the Google mobile blog.

For more on the vision for Google Gears for mobile and its origins, watch this video.

Calling all JavaScript developers: Hack the Day Away with Google

DeWitt Clinton — Wed, 20 Feb 2008 00:15:00 +0000

By Ben Lisbakken, Google Developer Programs

On Friday, February 29th, Google will be holding a developer hackathon to get you started on our JavaScript APIs. We will be doing short introductions of the APIs and then breaking up into groups for coding and camaraderie. There will be plenty of Google engineers present to ask questions and get help from. Food will be provided and there will be prizes.

The event is open to anyone in the community that wants to learn about some Google API's, do some coding, or ask some questions. So please bring your laptops and come hang out at Google.

We'll be covering the following APIs:

The event will be held in two sessions, the first from 2:00PM - 5:30PM and another from 6:00PM - 10:00PM. You are welcome to stay for both.

Seville Tech Talk
Google Campus
1600 Amphitheatre Pkwy
Mountain View, CA94043

Friday, February 29th
2:00PM - 5:30PM
6:00PM - 10:00PM

To attend, all you need to do is RSVP and let us know you can make it, and be sure to add the event to your calendar.

Hope to see you there!

IETF Applications Area Architecture Workshop

DeWitt Clinton — Fri, 15 Feb 2008 18:43:00 +0000

Post by Joe Gregorio, Google Developer Programs

On February 11 and 12 Google hosted the Internet Engineering Task Force (IETF) Application Area Architecture Workshop. This was a chance for people active in the IETF Applications Area to get together and work on architectural issues, topics that span many specific groups in the Applications area.

The Applications Area is the part of the IETF that deals with applications

"...that is, things that are not security (part of the security area), nor networks (most of the other areas), but rather things that use the networks and security services to provide things of benefit to the end-user."

This was of particular interest to me since that includes specifications like the Atom Syndication Format and the Atom Publishing Protocol, which we use extensively at Google. From the call for participation:

"These should be a few pages of text on some topic related to Applications area architectural issues. Since the group of attendees is expected to span HTTP and AtomPub, email, IM, calendaring, directories and more, issues should be of interest to more than one of these groups. Some existing Applications architecture "modules" that already are reused include SASL, URLs, MIME types, XML and XML schemas and namespaces, HTTP as a substrate, TLS, ABNF, BEEP."

We had around 20 attendees and the breakout sessions ranged over all the topics listed above and many more. There were two days of great conversation and everyone had a good time.

"Thank you for the high quality hosting and convenience of location and food!"

-Lisa Dusseault (Apps Area Director)

Go Go Gadgets in Asia

DeWitt Clinton — Tue, 12 Feb 2008 15:30:00 +0000

By Min Li Chan, Google Developer Programs - APAC

It's cold and cloudy in Hong Kong and Taiwan this week, as our trusty weather gadgets indicate. At the Googleplex, where a quintessentially Californian winter is holding up, we had the distinct honor of hosting our Taiwan and Hong Kong gadget developer contest winners -- Hu Chih-Pao flew in from Taipei to tour our campus in December (see photos from his visit on his blog), while Alex Ng and Liu Chun-Yu visited us from Hong Kong two weeks ago.

Of the 190 submissions for the gadget contest in Taiwan, Chih-Pao produced a whopping 43 entries, including a real-time Taiwan Train Timetable gadget and a gadget for the Taiwanese traditional worship of the Buddha of Mercy:

Alex and Chun-Yu's innovative use of gadget technology caught our eye, with their real-time local Hong Kong TV program guide with keyword-activated YouTube views, as well as their Feng Shui gadget:

Japan's gadget awards last year also showcased great gadgets from a pool of 178 submissions, including:

The Earthquake information gadget:

The QR code generator gadget from our Grand Prix winner, kilo:

(QR codes are widely used in Japan to store and display information, particularly URLs, which can be scanned and launched from a browser-enabled camera phone equipped with QR reader software).

We hosted our illustrious Japanese gadget contest winners last year at our office in Tokyo -- check out our interviews with them here.

We're thrilled to experience the creative, inspired, and locally relevant ways that developers are using gadgets and Google APIs here in Asia. As a quick sampler, take a look at the submitted contest gadgets for Japan, Taiwan, and Hong Kong on iGoogle in Japan, Taiwan, and Hong Kong.

URLs are People, Too

DeWitt Clinton — Fri, 01 Feb 2008 17:55:00 +0000

By Brad Fitzpatrick, Software Engineer

So you've just built a totally sweet new social app and you can't wait for people to start using it, but there's a problem: when people join they don't have any friends on your site. They're lonely, and the experience isn't good because they can't use the app with people they know. You could ask them to search for and add all their friends, but you know that every other app is asking them to do the same thing and they're getting sick of it. Or they tried address book import, but that didn't totally work, because they don't even have all their friends' email addresses (especially if they only know them from another social networking site!). What's a developer to do?

One option is the new Social Graph API, which makes information about the public connections between people on the Web easily available and useful. You can make it easy for users to bring their existing social connections into a new website and as a result, users will spend less time rebuilding their social networks and more time giving your app the love it deserves.

Here's how it works: we crawl the Web to find publicly declared relationships between people's accounts, just like Google crawls the Web for links between pages. But instead of returning links to HTML documents, the API returns JSON data structures representing the social relationships we discovered from all the XFN and FOAF. When a user signs up for your app, you can use the API to remind them who they've said they're friends with on other sites and ask them if they want to be friends on your new site.

The video below can walk you through the API in detail, but if you're eager to get started check out the Social Graph API homepage and the developer documentation. And let us know what you think in the Social Graph API Group.

iGoogle Themes API

DeWitt Clinton — Wed, 16 Jan 2008 14:00:00 +0000

By Jesse Shieh, Software Engineer

Recently, on a trip to Shanghai, I snapped a bunch of incredible street photos for my friends and family back home. When I logged into my iGoogle page and was greeted by my iGoogle theme, I suddenly wished I could create my own theme out of my Shanghai pictures and share it with my friends - wouldn't that be a great way to personalize iGoogle even further? It turns out that many of you have been asking for this feature for a while too, and we've listened to your requests. I'm excited to announce that after today's launch of the iGoogle Themes API, we can all get started on making and sharing our own themes.

Creating your own theme isn't rocket science. If you can create a webpage, then you can create a theme. There are only three steps involved: designing images for the header and footer, entering metadata and color information in an XML file, and submitting the theme. To find out more about the API, start with the developer guide. You can also take a look at the terrific example themes (shown below) built by designers Yves Behar, Mark Frauenfelder, Troy Lee, and John Maeda that showcase different parts of the API. These themes, along with themes you submit, will be available in the new themes directory for the millions of iGoogle users. So try it out and let us know what you think!

Earth-light by Yves Behar, founder of the San Francisco design studio fuseproject:

Adventures in Lollipopland by Mark Frauenfelder, writer, illustrator, co-founder of Boing Boing, and editor-in-chief of Make Magazine:

Supermoto Mayhem by Troy Lee, designer and founder of Troy Lee Designs:

Simplicity is Complex by John Maeda, graphic designer, artist, Associate Director of Research at the MIT Media Laboratory, and recently named as the next President of the Rhode Island School of Design (RISD):

Wednesday in San Francisco: OpenSocial Hackathon at Six Apart

DeWitt Clinton — Wed, 16 Jan 2008 00:17:00 +0000

By Dan Peterson, Product Manager

On Wednesday (tomorrow!) Six Apart will be hosting an OpenSocial Hackathon at their office in San Francisco to let people get their hands dirty with OpenSocial, Shindig, and Caja. In addition to the Googlers working on OpenSocial, you'll be able to chat with engineers from at least hi5, MySpace, Oracle, Orkut, and Plaxo. The event starts at 4pm PST and will be going deep into the night -- so it's okay if you can't make it right on time. The office is conveniently located near Macworld, not to mention Caltrain, BART, and MUNI.

We'd love it if you could RSVP on Upcoming, though it isn't formally required. Be sure to bring your laptop and perhaps a few friends.

Of course, there will be copious beer and pizza.

ChartMaker: A tool for the Google Chart API

DeWitt Clinton — Tue, 08 Jan 2008 00:26:00 +0000

By DeWitt Clinton, Google Developer Programs

Since we launched the Google Chart API last month we've been thrilled to see so many creative tools written to use it. From Ruby, to Python, to Groovy, it looks like languages are being covered one by one.

Even our own Dion Almaer stepped into the fray with his new ChartMaker tool. ChartMaker, the source code for which is available on Google Code, is an Ajax-based application that makes it easy to experiment with and customize Google Charts.

Have you been building something interesting with the Google Chart API? Please let us know in the comments and join us in the discussion group.

Thanks to you

DeWitt Clinton — Thu, 03 Jan 2008 03:57:00 +0000

By Brad Neuberg, Google Gears Team

Many thanks to all of our users and developers for helping to make Google Gears one of PC World's 25 Most Innovative Products of the Year! And congrats to everyone else who made the list. It's been quite an exciting ride for Gears since its launch at Developer Day in May, and we've had tons of fun seeing what has already been created. Thanks for making 2007 such a great year, and we look forward to seeing all the cool stuff the community comes up with next.

To learn more, check out the documentation and the Gears Blog. And, of course, let us know what you think.

Our new Developer Community Calendar: View it, Map it, Add to it!

DeWitt Clinton — Mon, 17 Dec 2007 16:11:00 +0000

By Pamela Fox, Google Developer Programs

I was scheduling a trip to New York City last month to visit some friends and thought, "Well, it'd be nice to take in a conference or two." I proceeded to search online for hours -- including queries like "new york city ajax," "conferences new york," "user group new york" -- and came up basically empty handed. Frustrated, I cornered my co-worker Austin Chau, and we did what us geeks tend to do when we want something: we hacked it up ourselves!

Google's 'Developer Events Calendar' has always listed Google-sponsored and/or Google-attended events, but today we're launching a second calendar for the developer community at large. You can view both calendars side-by-side in either calendar view or map view, and with a Google Calendar account, you can add your own meetup to the list. (If you're keen on the project's technical specs, we'll be writing about the code itself shortly, so check back soon for an article and source links.)

We hope you find the calendars useful, and we look forward to your feedback. Try it out now: add your upcoming conference, user group, or party. (Yes, we developers know how to party. If you don't know how, I'll graciously volunteer to show you).

Embed charts in webpages with one of our simplest APIs yet

DeWitt Clinton — Thu, 06 Dec 2007 16:20:00 +0000

By Steve Crossan, Chart API Team

Today we're launching the Google Chart API, a really simple tool for creating charts and graphs that are perfect for websites.

Let's get straight in with an example. This URL:

http://chart.apis.google.com/chart?cht=p3&chd=s:hW&chs=250x100&chl=Hello|World

Creates this image:

That's it - no state, no calls, just send your data in an http request and get a png image graph back. Embed the request in an img tag and you're done. We currently support line charts, bar charts, pie charts, scatter plots, and sparklines.

We actually built this originally to use internally - we use it on Google Video and Google Finance for example. It seemed like it would be a good thing to open up to other users too. You can find out all about it at on the Google Chart API homepage and there's a Google Chart API group for questions and support.

The Google Chart API started out as a 20% time project here in Zurich, and we're really happy to be launching it to the world today. Let the charting begin!

Each and every email

DeWitt Clinton — Thu, 15 Nov 2007 22:52:00 +0000

By Ryan Propper, Google Apps Team

With hundreds (if not thousands) of popular email clients and mail servers out there, importing email into another service can be challenge, especially when you consider the troves of old email most people save. To ease this pain, we created the Google Apps Email Migration API.

This new API is available in Google Apps Premier, Partner, and Education Editions, and you can use it to migrate your existing email from anywhere into Google Apps. Let's say, for example, you want to import email from your Obscurix Email Server v2.0001715. Just write some parsing code and use our simple API to upload that email into the desired mailbox. For convenience, you can authenticate to the API not only as the end user of the destination mailbox, but also as a Google Apps administrator, and target any mailbox in the domain. This API uses the Google data API protocol, which means there are a host of client libraries to make importing even easier.

LimitNone (one of our Enterprise Professional partners) has already built a migration utility that works with calendars, email and contacts.

For more info, check out the Google Enterprise Blog, or just dive right into the developer's guide. And please, let us know what you think!

My How We’ve Grown

DeWitt Clinton — Thu, 01 Nov 2007 16:00:00 +0000

By DeWitt Clinton, Google Developer Programs

In 2005 we launched Google Code to provide a home for our developer and open source programs. Two years, dozens of new products and new programs, and one major redesign later, Google Code is bigger and more dynamic than ever. With today's relaunch we've added a new search auto-complete feature (to help you find your favorite products with a keystroke or two in the search box), an expanded and improved search results page, a cleaner and more comprehensive site directory, new blog and group gadgets, and a simplified and unified look and feel for product documentation.

To get a sense of how far things have come you can take a look at the first version of Google Code, back when the whole site almost fit on one page. Today we have thousands and thousands of pages of content on Google Code, and we've added the new site directory and new search features to help you navigate them.

One of the most exciting things about the redesign is that everything you see here was built using technology and APIs that are available to everyone. The pages we're serving don't rely on any secret back-end tricks; the site is built on plain HTML, JavaScript and CSS, each using our public APIs. In fact, all of the techniques used on Google Code can be duplicated on your own site.

For example, the search results pages use a combination of the AJAX Search API and Custom Search Engines. The homepage gadgets use the AJAX Feed API and Google Reader feeds. The videos are powered by the YouTube API, the blogs by the Blogger API, the events powered by the Google Calendar API, the metrics by Google Analytics, the forums by Google Groups, etc., etc.. And we're pleased to use jQuery, the wonderful open source JavaScript library (not ours, we're just fans), to help power each page. Stay tuned -- over the upcoming weeks we'll offer detailed articles and tutorials about how we built the various parts of Google Code using open technologies.

But the best thing about Google Code hasn't changed: And that's you, the developer, our never-ending source of inspiration. Your projects provide countless examples for the Featured Projects feeds, your words and wisdom power the developer groups, and your accomplishments and ideas never cease to amaze us with the possibilities and potential for a better web. This redesign was for you, and I want to personally thank all of you for being such an integral part of Google Code. Together we're capable of doing something very special.

Please join us on the Google Code Blog, (where we'll be enabling comments for this and future posts), and let us know where you're headed and how we can help you get there.

Podcast with Bruce Johnson and Joel Webber

DeWitt Clinton — Thu, 25 Oct 2007 23:20:00 +0000

By Jimmy Caputo, Product Marketing

Last week the folks at Pearson Education sat down with Bruce Johnson and Joel Webber to discuss the creation of Google Web Toolkit and Pearson's December conference Voices that Matter: Google Web Toolkit. Listen to the podcasts to hear Bruce and Joel explain the history of GWT and the challenges of building a cross-browser Java-to-Javascript compiler. They also talk about the sessions that they are most looking forward to attending at the conference, and their upcoming book on GWT. Thanks to Bruce and Joel for sharing their thoughts and to Barbara and Greg at Pearson for putting this together.

Registration for the Pearson conference is still open, but be sure to register before October 27th (this Saturday) to receive the early bird pricing discount. You can review the complete list of sessions and speakers on the conference website.

UW and Google: Teaching in Parallel

DeWitt Clinton — Thu, 13 Sep 2007 23:05:00 +0000

By Sierra Michels-Slettvet, Engineering Intern

Earlier this year, the University of Washington partnered with Google to develop and implement a course to teach large-scale distributed computing based on MapReduce and the Google File System (GFS). The goal of developing the course was to expose students to the methods needed to address the problems associated with hundreds (or thousands) of computers processing huge datasets ranging into terabytes. I was excited to take the first version of the class, and stoked to serve as a TA in the second round.

But you can't program air, so Google provided a cluster computing environment to get us started. And since computers can't program themselves (yet?), UW provided the most essential component: students with sweet ideas for a huge cluster. After learning the ropes with these new tools, students finished the course by producing an impressive array of final projects, including an n-body simulator, a bot to perform Bayesian analysis on Wikipedia edits to search for spam, and an RSS aggregator that clustered news articles by geographic location and displayed them using the Google Maps API. Check out Geozette.

We are looking at ways to encourage other universities to get similar classes going, so we've also published the course material that was used at the University of Washington on Google Code for Educators. You're more than welcome to check out the Google Summer Intern video lectures on MapReduce, GFS, and parallelizing algorithms for large scale data processing. This summer I've been working on exposing these educational resources and other tools so that anyone can work on and think about cool distributed computing problems without the overhead of installing his or her own cluster. In that vein, we've released a virtual machine containing a pre-configured single node instance of Hadoop that has the same interface as a full cluster without any of the overhead. Feel free to give it a whirl.

We're happy to be able to expose students and researchers to the tools Googlers use everyday to tackle enormous computing challenges, and we hope that this work will encourage others to take advantage of the incredible potential of modern, highly parallel computing. Virtually all of this material is Creative Commons licensed, and we encourage educators to remix it, build upon it, and discuss it in the Google Code for Educators Forum.

Lastly, a quick shout out to the other interns who helped out on our team this summer: Aaron Kimball, Christophe Taton, Kuang Chen, and Kat Townsend. I'll miss you guys!