Google Code Blog

Sidebar Gadgets: Coming soon to a Calendar near you

2009-07-14T09:40:00.000-07:00

We've always believed users should have open and unencumbered access to their data, and Google Calendar is no exception. Whether through iCalendar, CalDAV, or the Calendar Data API, there are a multitude of options to access Calendar from other applications. However, developers have been asking for a way to extend the Google Calendar interface itself, and we've been listening.

Today, as part of Google Calendar Labs, we're opening up Google Calendar as a gadget container.

Gadget developers will already be familiar with most of this environment, complete with features such as OpenSocial for social networking and OAuth for working with third-party services. However, for the first time we're also providing an API to control and interact with the Calendar user interface. This means that even though your gadgets are running inside a sandbox, they are first-class elements of the Calendar user experience. In fact, many of the experiments we've made available through Calendar Labs were written using the publicly available gadget API.

We hope you'll share our excitement in opening up the Google Calendar interface. To get you started, take a look at the Sidebar Gadget documentation and sample code. If you have any questions or ideas for improvement, feel free to visit the Calendar API help group and let us know!

By Trevor Johns, Google Developer Team

My Location on Google Maps

2009-07-08T18:49:00.000-07:00

We've blogged before about how much we like location-based services and at Google we want all developers to be able to build these cool applications. That's why we're so excited about the W3C Geolocation API, a browser API that provides a really easy way for web applications to get the user's location.

Today we're announcing the launch of My Location on Google Maps, the first major Google web application to make use of the Geolocation API. My Location on Google Maps offers the same functionality you're probably familiar with from Google Maps for Mobile - simply click a button and your location is shown on the map with a blue dot.

Until recently, providing this kind of functionality usually meant writing a native application, which is hard work if you want to deploy on lots of different platforms. What's great about the Geolocation API is that it can be used by any web application, in any web browser that supports it, in a totally cross-platform way. Both Google Chrome and Firefox 3.5 already provide geolocation in the browser, Opera 10 will soon add support and we're looking forward to other major browsers adding support soon. As an interim solution, Gears also provides an equivalent Geolocation API and can be installed on other browsers such as Internet Explorer.

We look forward to seeing lots more cool web applications make use of the Geolocation API!

By Steve Block, Software Engineer and Jonathan McPhie, Associate Product Manager

Native Client Security Contest: The results are in!

2009-07-07T15:57:00.000-07:00

A few months ago, we challenged you to discover exploits in the Native Client system and more than 600 of you decided to take us up on our invitation. We're very pleased with the results: participants found bugs that enabled some really clever exploits, but nothing that pointed to a fundamental flaw in the design of Native Client. Our judges reviewed all entries very carefully and have selected five teams as the winners of the Native Client Security Contest.

The big winner of the contest was the team "Beached As", consisting of IBM researcher Mark Dowd and independent researcher Ben Hawkes. "Beached As" reported 12 valid issues, including vulnerabilities in the validator and multiple type-confusion attacks. The team "CJETM" (Chris Rohlf, Jason Carpenter, Eric Monti — all security professionals with Matasano Security) came in second by reporting three issues with a common theme of memory related defects, including an uninitialized vtable entry, an exception condition during new(), and a double delete bug. Gabriel Campana from Sogeti ESEC R&D Labs was selected as the third place, while for the fourth and fifth place we had a tie between independent researcher Daiki Fukumori and Rensselaer Polytechnic Institute student Alex Radocea. You can find a listing of all the issues the teams submitted at the Native Client Security Contest site.

The winners of the Native Client Security Contest, Team "Beached As"
Mark Dowd (left) and Ben Hawkes (right)

Winning teams were attracted to the contest by the potential of the Native Client technology. Mark Dowd, member of the winning team "Beached As", commented, "When I saw the press release announcing the product, I was intrigued by some of the ideas mentioned in the article. After reviewing the architecture a little, I thought the project adopted a novel approach to solving the problem of running native code securely, and was keen to take a closer look." Curiosity about what the technology could achieve also motivated the CJETM team, according to Chris Rohlf.

The real-world relevance of Native Client made this contest more interesting and challenging for participants. Contestant Alex Radocea stated, "Unlike most security challenges out there, the set of problems were not crafted. The tasks at hand were real and complex, as the real world is. I have no doubt that many unknown people eyed the code or attacked the applications and, frustratingly, found absolutely nothing wrong." Mark Dowd agreed: "Our goal was to create a convincing lead, to try and take the victory, and I think we did that. Having said that, the field was not soft. There were some tough contestants who were able to uncover a variety of interesting vulnerabilities."

We would like to thank all the contestants, the jury chair Ed Felten and all the security experts that judged the contest for helping us improve the security of our system. This contest helped us discover implementation errors in Native Client and some areas of our codebase we need to spend more time reviewing. More importantly, that no major architectural flaws were found provides evidence that Native Client can be made safe enough for widespread use. Toward that end, we're implementing additional security measures, such as an outer sandbox, but you can help by continuing to file bugs in Native Client. Community support and scrutiny has helped and will continue to help make Native Client more useful and more secure.

By Henry Bridge and Brad Chen, Native Client Team

Google I/O Scavenger Hunt Winners

2009-07-06T10:13:00.000-07:00

The astute conference attendee would have noticed hidden QR codes around the conference, as well as the scannable QR codes on everyone's badge. We wanted to find a fun way for people to bond with their new phones, as well as network with other attendees, so we set about creating a scavenger hunt game using Google App Engine & Friend Connect. The app handled game logistics (a leaderboard, URL endpoints), and we printed up a bunch of custom QR code stickers that pointed to game URLs.

App Engine made writing the scavenger hunt app much easier than it otherwise would have been. The initial version of the app took one developer less than a day to turn out, and we continued to add functionality and tweak it as I/O approached and we tested it in real-world situations. The versioning deployment made it very easy to test and push out new versions without disrupting existing users.

The overall structure of the app was very straightforward: every QR-code had a unique URL, which was embedded into the generated QR code. A URL was associated with a number of points to be awarded and a destination URL (such as the user's profile information, in the case of a user's badge QR code). Users were signed in using Friend Connect, which allowed us to avoid concerns of authenticating users and managing sessions.

When a user visited a URL for the first time, we recorded that fact so they couldn't try and get extra points with repeat visits, then sent them to the destination URL. We also kept a running count of the user's score against the User entity, so as to not have to count up their points on every request. Generating the leaderboard was a simple matter of querying for the users with the most points and displaying them.

QR codes were generated using the Chart API, which simply takes a string of text and a few other parameters, and returns a fully formed QR code.

The three resourceful and persistent folks below beat out the competition to rise to the top of the scavenger hunt ranks - going to great lengths, including swag bribery, to gain points. A hearty (if belated) congratulations to the winners of the Google I/O mobile scavenger hunt!

1st Place - Abraham Williams
2nd Place - Waylon Flinn
3rd Place - Pete Richards

We hope everyone that participated learned how to use their Android phones a little better, met people they otherwise wouldn't have, and had some fun :)

By Stephanie Liu, Google Developer Programs

Gmail for Mobile HTML5 Series: Using Timers Effectively

2009-07-02T12:20:00.000-07:00

Javascript Timer API

Timers provide a way to schedule a function to run at some later point in time. The two functions used to create timers are:

var id = setTimeout(fn, delay) creates a timer which calls the specified function once after the given delay.
var id = setInterval(fn, delay) is similar, but the function is called continually until the timer is canceled.

Each type of timer has a corresponding clear method (e.g., clearTimeout(id)) that stops a timer while it is running.

There are many great resources online already that document the nitty-gritty details of this API. That's not our focus here. Instead, I want to talk about specific ways in which you can put these timers to work for you in your web application.

Let's Do the Time Warp Again

It's important to keep in mind that just because you ask for a timer with a certain delay doesn't mean it will fire precisely that many milliseconds later. On current browsers, all Javascript code executes within a single thread. This means all your timers have to contend for execution time not only with each other, but also with all the other Javascript code in your application. If another block of code is in the middle of executing when a timer should fire, the timer will be delayed until that block of code is done. (Help is on the way: HTML5's Web Workers will allow web applications to spawn workers that run scripts in parallel.)

Let's look at a concrete example of what this means in practice. I added a timer to Gmail for mobile that is supposed to fire every 200 ms. Each time it fires, it records the time between consecutive timer ticks. Here are the results after 100 ticks:

The dashed blue line represents the requested timer interval, 200 ms. Notice that the median was almost 50% higher than requested, at 276 ms; the time between ticks varied from 98 ms to almost 4 seconds, with an average delay of 493 ms.

This highlights the fact that the interval at which your timer actually fires may differ greatly from the requested delay. In fact, the time between ticks is typically highly variable. It will fluctuate based on what else is happening in your application and on the device. Don't rely on your timer being precise!

Buy One Timer, Get One Free?

When I first started working on the new version of Gmail for mobile, the application used only a couple of timers. As we continued adding more and more features, the number of timers grew. We were curious about the performance implications: would 10 concurrent timers make the app feel slow? How about 100? How would the performance of many low-frequency timers compare to a single high-frequency timer?

To answer these questions, we conducted a few experiments. We injected some extra code into a development build of Gmail that created a lot of different timers, each of which just performed some simple calculations. Then we fired up the app on an iPhone 3G and Android G1 (both running the latest version of their respective firmware) and observed the performance. Note that although we could have just created a separate test page for this, we chose to inject the code right into our app so we could see how fast it would be to read and process mail with all those timers running.

Here's what we learned. With low-frequency timers — timers with a delay of one second or more — we could create many timers without significantly degrading performance on either device. Even with 100 timers scheduled, our app was not noticeably less responsive. With high-frequency timers, however, the story was exactly the opposite. A few timers firing every 100-200 ms was sufficient to make our UI feel sluggish.

This led us to take a mixed approach with the timers we use in our application. For timers that have a reasonably long delay, we just freely create new timers wherever they are needed. However, for timers that need to execute many times each second, we consolidate all of the work into a single global high-frequency timer.

One High-Frequency Timer to Rule Them All

A global high-frequency timer strikes a balance between needing several different functions to execute frequently and application performance. The idea is simple: create a single timer in a central class that calls as many functions as required. Ours looks something like this:


var highFrequencyTimerId_ = window.setInterval(globalTimerCallback, 100);

globalTimerCallback = function() {
navigationManager.checkHash();
spinnerManager.spin();
detectWakeFromSleep_();
};

Why did we choose to hardcode the various function calls in globalTimerCallback() rather than implementing a more generic callback registration interface? Keep in mind that this code is going to execute many times every second. Looping over an array of registered callbacks might be slightly "cleaner" code, but it's critical that this function execute as quickly as possible. Hardcoding the function calls also makes it really easy to keep track of all the work that is being done within the timer.

To Die, To Sleep; To Sleep, Perchance to Tick

One neat application of a high-frequency timer is to detect when the device has been woken from sleep. When your application is put to sleep — either because the device is put into sleep mode or because the user has navigated away from the browser to another application — time, as perceived by your app, pauses. No timers fire until the user navigates back to your app and it wakes up. By keeping a close eye on the actual time that elapses between high-frequency timer ticks, you can detect when the app wakes from sleep.

First, create a high-frequency timer, as described above. In your timer, call a function that keeps track of the time between ticks:


// The time, in ms, that must be "missed" before we
// assume the app was put to sleep.
var THRESHOLD = 10000;

var lastTick_;
detectWakeFromSleep_ = function() {
var now = new Date().getTime();
var delta = now - this.lastTick_;
if (delta > THRESHOLD) {
  // The app probably just woke up after being asleep.
  fetchUpdatedData();
}
lastTick_ = now;
};

Now your users will always have the latest data available when they return to your app without having to manually perform a refresh!

I hope this helps you make the most of timers in your web application. Stay tuned for the next post, where we'll discuss some cool tricks to spice up the text areas on your forms.

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

By Neil Thomas, Software Engineering Intern, Google Mobile

Enabling Public Service: All for Good and Google App Engine

2009-07-01T14:09:00.000-07:00

You may have seen the post on the Google Blog about All for Good, the new site that makes it easy to find and share volunteer activities within the United States. The site was built collaboratively by Google and several partners. We're especially proud that it was built using 100% open source Python code. All for Good's first release includes both gadgets and a free API, making it even easier for casual developers to build applications and embed All for Good listings in their own apps and sites.

If you're interested in seeing your software talents dedicated to community service, check out the API documentation, our Getting Started Guide and the complete source code for the core engine. We're especially looking forward to see what applications the developer community will create for mobile platforms and for Facebook. Happy Hacking!

by Guido van Rossum, Software Engineering Team

Follow us on @GoogleCode

2009-07-01T10:09:00.000-07:00

Google Code now has a home on Twitter - introducing @GoogleCode! Expect our tweets to be a nice mix of developer product announcements, Code Blog coverage, coding tips and tricks, interesting tech news and commentary, developer events, and more.

If you have any suggestions for what you want to see, feel free to send an @reply. We can't guarantee to respond to everyone, but we'd like to hear your feedback and suggestions for @GoogleCode or our developer products.

By Christine Tsai, Google Developer Programs

O3D update: New capabilities and expanded compatibility

2009-06-29T15:06:00.000-07:00

We're happy to announce that today we shipped a substantial update to O3D, an API for creating rich 3D applications in a web browser. With today's release, we focused on addressing a theme we heard in the requests and feedback from the community: that O3D should run as well as possible on many different types of hardware. Toward that end, we're releasing two new additions: software rendering and feature requirements. If you've already installed the O3D plugin, you should receive these additions automatically.

Software rendering allows O3D to use the main processor to render 3D images if the machine running the app doesn't have supported graphics hardware. While the hardware O3D requires to run in hardware-accelerated mode is fairly modest by today's standards (a DirectX 9, Pixel Shader 2.0 capable graphics card), there are nonetheless PCs that don't meet these requirements, and we think it's important for web apps to run on all machines, regardless of hardware.

Because software rendering is significantly slower than hardware-accelerated rendering, we're also introducing a concept called "feature requirements" that will help minimize how often O3D will have to fall back to software rendering. Feature requirements allow developers to state upfront that their app will require certain hardware capabilities to render properly. If the machine running the app supports those features, O3D will run it fully hardware accelerated; if however, it is lacking any of the required capabilities, O3D will drop into a software rendered mode. Anecdotally, we found that this tiering allows 45 of our 48 samples to now run in hardware-accelerated mode with less capable graphics cards.

Finally, while it has nothing to do with extending hardware support, we're also adding a couple other goodies: a full-screen mode to make O3D apps more absorbing and a community gallery to feature cool demos that use O3D (like Infinite Journey, the first game developed outside Google using O3D). If you've developed an application or sample that would be useful to the O3D community, please be sure to submit it for our team to review for inclusion in the gallery using this form.

By Henry Bridge, Product Manager

Gmail for Mobile HTML5 Series : Cache Pattern For Offline HTML5 Web Applications

2009-06-25T17:14:00.000-07:00

I recently gave a talk (preserved YouTube here) about the cache pattern and the Web Storage Portability Layer (WSPL) at Google I/O. It was exciting getting to give a talk at the Moscone Center as previously I had only ever been one of the audience members. The conference seemed to go by in a blur for me as I was sleep-deprived from getting the WSPL to "just good enough" to actually be released. (And some ofyou have already pointed out that I missed several bugs.) In my talk, I provided a general overview of the cache pattern and this post expands on the handling of hit determination and merging server and local changes.

The cache pattern is a design pattern for building an offline-capable web application. We implemented the cache pattern to make Gmail for Mobile tolerant of flaky wireless connections but the approach is generally applicable. Here's how it works. Consider a typical AJAX application. As shown in the diagram, we have a web application with a local model, view and controllers. The user interacts with theapplication and the controller dispatches XmlHttpRequests (XHRs for short) to the server. The server sends asynchronous requests to the application which it inserts into the model.

As shown in this next diagram, in the cache pattern, we insert a cache between the application and the server. Having done so, many requests that would otherwise require a round-trip to the network.

A software cache like this one shares a great deal conceptually with hardware caches. When designing the cache used in Gmail for mobile, we used this similarity to guide our design. For example, to keep our cache as simple as possible, we implemented a software equivalent to a write-through cache with early forwarding and LRU eviction. The cache pattern in general (and consequently our implementation) has four important data flows as shown in the diagram.

Cached content bound for the UI.
Changes made to the cache by the user in the UI. These need to be both reliably sent to the server and updated locally in the cache so that reads from the cache for UI updates show the state including user changes.
The changes recorded in the cache need to be sent upstream to the server as the network connection is available.
Changes made to the server (like email delivery in the case of Gmail) need to be merged into the contents of the cache.

As shown in the diagram we also need a place to actually write the data. We use the WSPL library to write a cache implementation portable across both Gears and HTML5 databases.

To actually implement these four data flows, we need to decide on a hit determination mechanism, a coherency strategy and a refresh approach.

Hit Determination

At its heart, a cache is a mapping from keys to values: the UI invokes the cache with a key and the cache returns the corresponding element. While this sounds pretty simple, there is an additional source of complexity if the application wants to provide the user with summary listings of some subset of all values available from the server. To provide this feature, the cache needs to contain not only "real" data values but additional "index" values that list the keys (and possibly user-visible summaries) for "data" values. For example, in Gmail for mobile, the cache stores conversations as its "real" data values and lists of conversations (such as the Inbox in Gmail for Mobile) as its "index" values. Keys for index values are computed specially to record what subset of the complete index is cached locally. For example, in Gmail for Mobile, while a user's Inbox may contain thousands of conversations, the cache might contain an index entry whose data values lists metadata for only conversations 1000 through 1100. Consequently, Gmail for Mobile's cache extends keys with the cached range so that a request for metadata for conversations 1101 through1110 would be considered a cache miss.

Coherency and Refresh

Perhaps the most complex aspect of the cache implementation is deciding how to get updated content from the server and how to merge server updates with changes made locally. A traditional hardware cache resolves this problem by only letting one processor modify its a cache at a time and have the memory broadcast any changes to all the other caches in the system. This approach cannot work here because the Gmail server can't connect to all of its clients and update their state. Instead, the approach we took for Gmail for Mobile was for the client device regularly poll the server for alterations.

Polling the server for changes such as new email or the archiving of email by the same user from a different device implies a mechanism for merging local changes with server side changes. As mentioned above, Gmail for Mobile is a write-through cache. By keeping all of the modifications to the cache in a separate queue until they have been acknowledged, they can be played back against updates delivered from the server so that the cache contains the merge of changes from the server and the local user. The following diagram shows the basic idea:

The green box in the diagram shows the contents of the cache's write buffer changing over time and the cloud corresponds to the requests in-flight to the server with time advancing from left to right in the diagram. The function names shown in the diagram are from the simplenotes.js

example file in the Web Storage Portability Layer distribution. Here, the user has applied some change [1] and the cache has written it to the write buffer and has then requested new content resulting in query [Q]. The cache prefixes the outstanding actions from the write buffer to the query. Action [1] is marked as needing a resend on some sort of network failure.

Later, the user makes change [2] to the UI which causes the cache to append it to the write buffer in the applyUIChange call. Later still, another query is made and so, the cache sends [1][2][Q] to the server. In the mean time, the user makes yet another change [3]. This is written to the write buffer. Once changes [1] and [2] are acknowledged by the server along with the new cache contents for query [Q], changes [1] and [2] are removed from the write buffer. However, to keep the cache's state reflecting the user's changes, change [3] is applied (again) over top of the result for [Q].

Simplifying the implementation of this reapplication stage is the most important benefit of implementing a write-through cache. By separating the changes from the state, it becomes much easier to reapply the changes to the cache once the server has delivered new content to the cache. As discussed in a previous post, the use of SQL triggers can greatly improve database performance. Whether updating or re-updating, triggers are a great way to make the application of changes to the cache much more efficient.

Cached Content To the UI

The first of the four data flows is delivering content to the UI is reasonably easy: query the cache for the desired content and when the query completes, forward the request to the UI. If you look at the getNoteList_ function from the simplenotes.js example code included in the WSPL distribution, you'll see that the delivering cached content to the UI has the following basic steps:

perform hit determination: deciding if the requested cache contents are actually in the cache.

create a database transaction, and while in the transaction

query the database for the desired key
accumulate the results

then outside of the transaction, return the result to the UI.

Changes From The UI

The second flow (applyUiChange) is recording changes made by the user to the write buffer. It has a very similar structure

create a database transaction, and while in the transacation

write the change to the write buffer
wait for a trigger to update the state of the cache.

Updates Bound For The Server

As discussed above, once the changes have been written to the write buffer, they still have to be sent to the server. This happens by prepending them to queries bound for the server. The fetchFromServer from the example is responsible for this. As might be familiar by now, the flow is

create a database transaction and while in the transaction

query the write buffer for all the entries that need to be sent to the server
accumulate the entries

then outside the transaction, send the combination of changes and query to the server

Changes From The Server

Finally, we need to merge the changes from the server into the cache as is done in the insertUpdate method from the example. Here the flow is as follows:

create a database transaction and while in the transaction

update the directory
write the new content into the cache
touch the changes in the write buffer that need to be re-applied to the cache
wait for the trigger to complete its update

then, outside of the transaction, send the response to the UI if it was satisfying a cache miss.

That's a brief intro to the cache architecture as found in Gmail for mobile. We're continuing to improve our implementation of this basic architecture to improve both the performance and robustness of Gmail for mobile. Please stay tuned for follow on blog posts.

AdSense for Mobile Applications Beta

2009-06-24T18:33:00.000-07:00

Are you developing free iPhone or Android applications? With our new beta product - AdSense for Mobile Applications, you can monetize your mobile applications by showing contextually targeted ads and/or placement targeted ads alongside your application content. We provide you with iPhone and Android SDKs and example applications that request and display AdSense ads. Our SDKs also support DoubleClick ads.

You can show 320x50 text and image ads linked to HTML webpages in your application. These ads are targeted to the keywords that you send us in the AdSense (or DoubleClick) ad request. The keywords must be relevant to your application content. If your application content is loaded from a webpage that is customized for iPhones and Android handsets, then you can also send us the webpage URL for us to target ads. The ads may also be placement targeted which means an advertiser can specifically target to your application.

Our iPhone SDK is compatible with iPhone OS 3.0, and our Android SDK is compatible with Android 1.5 SDK. The SDKs include a library that can be linked in to your application which exposes methods to fetch and show ads. You must place a maximum of one ad per screen at the top or bottom (see the screenshot from the Backgrounds iPhone application). When a user clicks on the ad in your application, you can choose whether the user should view the advertiser's website in iPhone Safari or a full-screen UIWebView on the iPhone. For Android applications, our API defaults to opening the advertiser's website in the native browser.

To get started with monetizing your iPhone or Android application, sign up today on the AdSense for Mobile Applications website. We can't wait to have you join our beta network!

By Jennifer Lin, Software Engineer, Google Mobile Team

Let's make the web faster

2009-06-23T15:40:00.000-07:00

From building data centers in different parts of the world to designing highly efficient user interfaces, we at Google always strive to make our services faster. We focus on speed as a key requirement in product and infrastructure development, because our research indicates that people prefer faster, more responsive apps. Over the years, through continuous experimentation, we've identified some performance best practices that we'd like to share with the web community on code.google.com/speed, a new site for web developers, with tutorials, tips and performance tools.

We are excited to discuss what we've learned about web performance with the Internet community. However, to optimize the speed of web applications and make browsing the web as fast as turning the pages of a magazine, we need to work together as a community, to tackle some larger challenges that keep the web slow and prevent it from delivering its full potential:

Many protocols that power the Internet and the web were developed when broadband and rich interactive web apps were in their infancy. Networks have become much faster in the past 20 years, and by collaborating to update protocols such as HTML and TCP/IP we can create a better web experience for everyone. A great example of the community working together is HTML5. With HTML5 features such as AppCache, developers are now able to write JavaScript-heavy web apps that run instantly and work and feel like desktop applications.

In the last decade, we have seen close to a 100x improvement in JavaScript speed. Browser developers and the communities around them need to maintain this recent focus on performance improvement in order for the browser to become the platform of choice for more feature-rich and computationally-complex applications.

Many websites can become faster with little effort, and collective attention to performance can speed up the entire web. Tools such as Yahoo!'s YSlow and our own recently launched Page Speed help web developers create faster, more responsive web apps. As a community, we need to invest further in developing a new generation of tools for performance measurement, diagnostics, and optimization that work at the click of a button.

While there are now more than 400 million broadband subscribers worldwide, broadband penetration is still relatively low in many areas of the world. Steps have been taken to bring the benefits of broadband to more people, such as the FCC's decision to open up the white spaces spectrum, for which the Internet community, including Google, was a strong champion. Bringing the benefits of cheap reliable broadband access around the world should be one of the primary goals of our industry.

To find out what Googlers think about making the web faster, see the video below. If you have ideas on how to speed up the web, please share them with the rest of the community. Let's all work together to make the web faster!

Posted by Urs Hoelzle, SVP, Operations and Bill Coughran, SVP, Engineering

(Cross-posted on the Official Google Blog, and the Google Webmaster Central Blog)

Introducing the Virtual Keyboard API

2009-06-22T12:29:00.000-07:00

Inability to input text in native language has been a problem for many non-latin script based languages. This may happen for many reasons. Sometimes, users do not have the keyboard layout for their native language installed in the system they happen to be using (for example, a tourist using an internet cafe in a foreign country). Sometimes, such a keyboard layout is not well developed or not widely available. It is worse for web developers because there is no way they can ensure that their users have access to this very basic input technology.

To address this issue, today, we added Virtual Keyboard API into the Google AJAX Language API. With this API, developers can help their users to input text, regardless if they have the native keyboard layout installed in their Operating Systems or not.

Pic 1: Russian Virtual Keyboard layout

Another advantage is the ability to provide a better user experience for multilingual web sites. For example, on a Russian/Thai bilingual dictionary editing web site, users would type in Russian in the header, and then see a Thai description. With the Virtual keyboard API, developers can load a Russian virtual keyboard layout and bind with all the Russian text fields, and load a Thai virtual keyboard layout and bind them to Thai fields. The Virtual Keyboard API then will automatically swap to the corresponding keyboard layout depending upon the user action.

Sometimes users may not be familiar with the key assignment of their keyboard layout. Virtual keyboard also shows the key assignment inside the page to allow users to input text by either pressing key or by clicking mouse on the virtual onscreen layout.

With this initial release, we are launching 5 language layouts. These are: Arabic, Hindi, Polish, Russian, and Thai.

We plan to roll out support for more keyboard layouts in the future. You can find more details by reading through the class reference and trying the Code Playground samples. Feedback is always welcome in our support forum and IRC channel.

By Manish Bhargava and Frank Tang, Google Internationalization Team

Google Technology User Groups

2009-06-11T17:11:00.000-07:00

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

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

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

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

Europe
Paris GTUG - http://groups.google.com/group/paris-gtug
Hamburg GTUG - http://www.hamburg-gtug.org
GTUG Munich - http://gtug-muc.org
Istanbul GTUG - http://www.istanbul-gtug.org/
Polish GTUG - http://www.gtug.pl

North America
Tri-Valley California GTUG - http://groups.google.com/group/tv-gtug
Berkeley GTUG - http://www.meetup.com/Berkeley-GTUG/
San Diego GTUG - http://www.meetup.com/sd-gtug/
NYC GTUG - http://sites.google.com/site/nycgtug
New Jersey GTUG - http://nj-gtug.org/
Philly/Delaware GTUG - http://sites.google.com/site/phillygtug/
Boston GTUG - http://groups.google.com/group/boston-gtug
Denver GTUG - http://groups.google.com/group/denver-gtug
Twin Cities GTUG - tc-gtug.org
Austin GTUG - http://sites.google.com/site/austingtug/
Michigan GTUG - http://groups.google.com/group/mi-gtug

MadGTUG - http://madgtug.org
Cleveland GTUG - http://groups.google.com/group/cleveland-gtug

Utah GTUG - http://utahgtug.blogspot.com/
Laguna GTUG - www.laguna-gtug.org
Quebec GTUG - http://groups.google.com/group/gtug-quebec/?pli=1

South America
Chile GTUG - http://groups.google.com/group/gtug-cl
Argentina GTUG - http://groups.google.com/group/gtug-ar

Asia
Kuala Lumpur GTUG - http://sites.google.com/site/gtugkl/
Hyderabad GTUG - http://sites.google.com/site/hydgtug/

Also a big shout-out to our existing chapters:

Silicon Valley GTUG - http://www.meetup.com/sv-gtug (watch the organizers, Kevin and Van, talk about GTUGs at Google I/O)
Pune GTUG - http://pune-gtug.blogspot.com/
Chico GTUG http://www.chico-gtug.org
Berlin GTUG - http://www.berlin-gtug.org
Tokyo GTUG - http://tokyo-gtug.org/

View GTUGs in a larger map

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

By Stephanie Liu, Google Developer Programs

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

2009-06-10T14:00:00.000-07:00

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

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

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

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

By Roman Nurik, Developer Programs Engineer

Gmail for Mobile HTML5 Series: Suggestions for Better Performance

2009-06-10T11:50:00.000-07:00

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

Optimizing Database Performance

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

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

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

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

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

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

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

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

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

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

Problem: Multiple updates is slow!

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

CREATE TRIGGER IF NOT EXISTS RemoveAuthor
AFTER DELETE ON Books
BEGIN
  DELETE FROM Authors
  WHERE Author NOT IN
    (SELECT Author
     FROM Books);
END;

We'll get into more detail on triggers and how to use them in another performance post to come.

Optimizing AppCache Performance

Problem: Logging in is slow!

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

Problem: AppCache reloading causes my app to be slow!

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

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

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

By Derek Phillips, Software Engineer, Google Mobile

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

Another Round of Deprecation Policies for Labs Graduates

2009-06-10T07:00:00.000-07:00

We recently published deprecation policies for a number of APIs that graduated from Google Code Labs. They state how long we'll support each version from when it's deprecated or a newer version is introduced. It will be 3 years for most, but the time period varies a bit from product to product.

AdWords API terms
AdSense API terms
AJAX Feed API terms
AJAX Language API terms
AJAX Libraries API terms
AJAX Search API terms
Apps APIs terms
Calendar Data API terms
Chart API terms
Health API terms
Geo APIs terms (Earth API, Mapplets, Maps API, Maps API for Flash, and Static Maps API)
Secure Data Connector terms

We still need to update the terms for a couple remaining graduates, but should have them all done within the next couple weeks.

By Neel Kshetramade, Google Developer Programs

Nicholas C. Zakas: Speed Up Your JavaScript

2009-06-09T15:14:00.000-07:00

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

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

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

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

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

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


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

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

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

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

By Steve Souders, Performance Evangelist

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

Google I/O: Session videos on building apps using the AJAX and Data APIs

2009-06-09T12:00:00.000-07:00

One of the best things about attending Google I/O is the chance to meet developers who are using our APIs and interacting with Google technology in ways we could never imagine. Not only was it amazing to see exciting examples of apps built on the AJAX and Data APIs being demoed at the developer sandbox, but it was also interesting to meet other developers who are just starting to use many of our APIs for their specific needs and cool ideas. Hopefully, by making all of our sessions available for free to watch on your own time, many of you who are interested in Google's APIs will get a better understanding of the ways we are making our API offerings easier to use, more efficient and much more feature rich.

Big Announcements & More

One of the most exciting announcements at this year's I/O was the developer preview of Google Wave. After its introduction during the Day 2 keynote, there were three sessions devoted to the Google Wave APIs: Programming With and For Google Wave, Google Wave: Powered by GWT, and Google Wave: Under the hood. We hope you're as excited as we are, and can't wait to see how you use these tools.

Another new product announcement this year was Google Web Elements, which allow you to easily add your favorite Google products onto your own website. There are elements for Google News, Maps, Spreadsheets, YouTube and others, with more to come. Be sure to check out the Day 1 keynote for a complete introduction to the simple copy and paste power of Google Web Elements.

Keeping webmasters in mind, two sessions were all about optimizing your site for search. In one talk, Matt Cutts reviewed real sites that *you* submitted. talking through real-life issues that effect developers when it comes to optimizing their app for search. The other session focused on how to maximize your site, your content, and your application's exposure to search engines.

Javascript & Google AJAX APIs

The session on Custom Search Engines focused on helping your users search the sites and topics that are relevant to you. Nick Weininger discussed some of the ways to embed search and ads onto your site (including the new Custom Search element), then customize the look and feel of the results. Adobe was on hand to show how they're using Custom Search Engines to enhance their products and insert contextual search into the developer's programming workflow. We also announced the launch of the Custom Search gadget for Blogger which gives your blog's visitors the ability to search not just your posts, but web pages linked from your blog, your blog lists, and link lists.

In the session Implementing your Own Visualization Datasource, attendees learned about building a server-side data source compatible with the Google Visualization API, including hearing about the experience from a Salesforce.com expert. Itai Raz also gave a great session on using the Visualization API with GWT and treated the audience to advanced Javascript tricks such as wrapping visualizations as gadgets.

Ben Lisbakken's session detailed some advanced Javascript techniques and then delved into some of great tips and tracks he learned while creating the Code Playground, a tool which can help developers learn about and experiment with many of Google's APIs. Some of the highlights include increasing the security and performance of applications and learning why App Engine is so easy on which to develop.

Jon Kragh of VastRank showed off some neat ways he's Using AJAX APIs to Navigate User-Generated Content, including using Google Maps to display nearby colleges and translating reviews into the viewer's language. Also, Michael Thompson explored the idea of Building a Business with Google's free APIs using example Google Gadgets, Google Gadget Ads, Mapplets, and the Maps API.

Google Data APIs

Jeff Fisher and Jochen Hartmann spoke on the future direction of the YouTube API as it becomes increasingly social. They used two sample applications to demonstrate the use of the activity feeds as well as the new "SUP" feed that allows high traffic websites to monitor YouTube for activity in a scalable manner.

The session about writing monetizable YouTube apps focused on creating applications that allowed access to YouTube videos in creative ways. In the talk, Kuan Yong showed how to expertly navigate through the YouTube API terms of service in order to avoid business pitfalls so that developers can monetize their own apps.

Eric Bidelman and Anil Sabharwal discussed the Document List Data API in detail, highlighting common enterprise use cases such as sync, migration, sharing, and legal discovery. Partners Syncplicity, OffiSync, and gDocsBar showed off compelling demos.

In the talk on the evolution of the Google Data protocol, Sven Mawson outlined all of the new features in the Google Data APIs that will help in the creation of more efficient applications. Two of the new additions included a compact and customizable JSON output and the option to retrieve only the parts of a feed that you want using partial GET.

Monsur Hossain and Eric Bidelman showed how to build a read/write gadget using OAuth and the Google Data JavaScript library. They went through a step by step set of instructions that explained how to set up the gadget code, how to get a token using the OAuth proxy, and how to read and write data to Blogger using the JavaScript library inside of an iGoogle gadget.

Google Geo APIs

Mano Marks and Pamela Fox started with a grab bag session covering the vast spectrum of Geo APIs, discussing touring and HTML 5 in KML, the Sketchup Ruby API (with an awesome physics demo), driving directions (did you know you can solve the Traveling Salesman Problem in Javascript?), desktop AIR applications, reverse geocoding, user location, and monetization using the Maps Ad Unit and GoogleBar. Pamela finished by sneak previewing an upcoming feature in the Flash API: 3d perspective view.

In the session on performance tips for Maps API mashups, Marcelo Camelo announced Google Maps API v3, a latency-oriented rewrite of our popular JS Maps API. Also see Susannah Raub's more in-depth talk about Maps API v3. Then Pamela gave advice on how to load many markers (by using a lightweight marker class, clustering, or rendering a clickable tile layer) and on how to load many polys (by using a lightweight poly class, simplifying, encoding, or rendering tiles). Sascha Aickin, an engineer at Redfin, showed how they were able to display 500 housing results on their real estate search site by creating the "SuperMarker" class.

Mano and Keith presented various ways of hosting geo data on Google infrastructure: Google Base API, Google App Engine, and the just-released Google Maps data API. Jeffrey Sambells showed how ConnectorLocal used the API (and their own custom PHP wrapper) for storing user data.

On the same day as announcing better integration between the Google Earth and Google Maps JS APIs, Roman Nurik presented on advanced Earth API topics, and released a utility library for making that advanced stuff simple.

By Adam Feldman and Brandon Bilinski, Google Developer Team

Everybody's talking: the Social track at Google I/O

2009-06-09T11:00:00.000-07:00

I had a great time at Google I/O -- meeting lots of developers from around the world who are interested in developing applications that use social data. In addition to building web applications for traditional social networks like orkut, MySpace and hi5, developers are also looking at enterprise and mobile applications which take advantage of the social graph, gadgets for Google's platforms like iGoogle, Google Calendar and Gmail, and gadgets for the 5 million websites and blogs powered by Google Friend Connect. We had some important questions raised in many of the sessions and also in the fireside chats with containers and app developers. It was exciting to see the whole OpenSocial ecosystem come together to discuss the current status and progress of social technologies, as exemplified by the I/O Developer Sandbox.

All the sessions at Google I/O were recorded, and videos and presentation materials are now available on the Google I/O website. Here's a little more info about the sessions in the social track:

Google and the Social Web
Daniel Holevoet outlined all the ways Google uses social technologies, highlighting those services which allow developers to extend them using the OpenSocial APIs. During his talk, Dan announced the new support for OpenSocial gadgets in Google Calendar, which include hooks into a calendar-specific API for accessing the currently-selected date range. Dan demonstrated the Quartermile OpenSocial application he wrote along with Arne Rooman-Kurrik and showed how the app could be used for different purposes across iGoogle, Gmail and Google Calendar and talked about how it could be used on any website via Google Friend Connect or on traditional social networks supporting the OpenSocial APIs. Of course, Dan didn't get to cover all the exciting news about Google's social initiatives during this talk-- a real-time gadgets API was announced during the Developer Sandbox!

Google Friend Connect Gadgets: Best Practices in Code and Interaction Design
Jonathan Terleski (lead designer on Google Friend Connect) and I presented this session on best practices for building Google Friend Connect (GFC) gadgets for the millions of websites and blogs using GFC today. We gave a brief overview of OpenSocial, followed by some design principles and a basic framework to think about when building GFC gadgets: what are the social objects, how do users contribute them, and how to users consume them? In the last part of the talk, I discussed how to use page context in your gadgets for content, skinning and language while showing some small bits of code to accomplish each. Most importantly, we announced the opening of submissions to the Google Friend Connect gadget directory and support for OpenSocial 0.9 in GFC gadgets.

Beyond Cut and Paste - Deep integrations with Google Friend Connect
In this talk, Arne Roomann-Kurrik and Chris Schalk talked about how they built the Plane Crazy site for flying enthusiasts and the Chow Down site for restaurant connoisseurs as example sites demonstrating how to integrate Google Friend Connect with existing login systems and add social functionality using the REST and RPC APIs. While these sites were built on top of Google App Engine (using Java and PHP), they talked about the other client libraries and raw protocols available for similar integrations. The Chow Down site is already open-sourced, and the Plane Crazy site will be shortly.

Google Friend Connect and the Real World
Patrick Chanezon led this session along with Shivani York, Henry Chan and Srivaths Lakshmi of TIME.com and Paul Berry of HuffingtonPost talking about how they integrated Google Friend Connect into their sites. Both TIME.com and HuffingtonPost used Google Friend Connect to create social lists where you rank the top items from the news, such as "Top 10 Movie Catchphrases" and "The World's Most Famous Swimsuits." Khris Loux, of JS-Kit, concluded the session by addressing why it's a good idea to integrate with Google Friend Connect and how the web is enhanced by having open API access to social data.

Building a Business with Social Apps
Shawn Shen and Chewy Trewhalla, Developer Advocates at Google, and Gerardo Capiel, VP of Product Management for the MySpace Open Platform, led this session showing how developers can make a living by building social apps. Virtual currencies, the recent OpenSocial extension proposal for a virtual currency spec and implementations on hi5, 51.com and other networks were discussed. In talking with a wide variety of developers and preparing this session content, our team learned even more about this industry, and we hope you can too.

Designing OpenSocial Apps for Speed and Scale
How do you use standard web optimization techniques in combination with existing and new features of OpenSocial 0.9 to develop a fast social application which scales efficiently? Arne Rooman-Kurrik and Chris Chabot examined this question in great depth. They took the Quartermile application which they developed and dived into the bandwidth, cpu and monetary savings achieved by applying a variety of optimizations--from image spriting, to data pipelining and proxied content. From the naive implementation to the optimized implementation, they showed how you could improve latency by nearly 70% and drastically reduce the cost of hosting a social application.

The Social Web: An Implementer's Guide
Joseph Smarr, Chief Platform Architect at Plaxo, led this standing-room-only session about the current state of the social web and how "The Web is now social... and the Social Web is now open." He recapped progress made in the last year, with the emergence and increasing adoption of a variety of technologies which make up the Open Stack: Open ID, XRDS-Simple, OAuth, Portable Contacts, OpenSocial. He gave many demos, including demonstrating the death of the "password anti-pattern" leading to a 92% conversion rate on users importing their contacts from sites supporting OpenID+OAuth and Portable Contacts.

Powering Mobile Apps with Social Data
Many people today have a mobile device which has internet access, and they probably use those devices as much (if not more!) than they use their computers. I explored the different ways to use social data from the web to enhance the experience users have with their mobile devices. I demonstrated and dove into the code of three different types of apps -- pure web apps targeted at mobile devices, a web app which uses some native GPS functionality via Google Gears and adding a social scoreboard to the "Divide and Conquer" open source native Android application. I then spoke a bit about the future of mobile development and how the features available between native applications and web applications are beginning to merge with the new HTML5 and W3C standards which provide access to native functionality such as databases, app caches and GPS location data.

OpenSocial in the Enterprise
Social networks are typically thought of as tools for personal communication, but they've increasingly become important in the enterprise world as well. Chris Schalk of Google led this panel along with representatives from IBM, Salesforce.com, Oracle, eXo, SAP and Atlassian to share the ways enterprises have used OpenSocial technology outside of and behind the firewall.

There's a wealth of new information in these presentations which were all prepared especially for Google I/O, including several new announcements. The presenters also developed quite a bit of code for Google I/O, which we'll be releasing as Apache-licensed open source projects over the next couple weeks. Stay tuned to the OpenSocial blog for those releases.

By Ryan Boyd, OpenSocial Team

Google App Engine @ I/O: Java, offline processing, great partners. and more

2009-06-08T13:00:00.000-07:00

2009 has been a busy year for the App Engine team, but all along we've looked forward to Google I/O and the excitement it brings to Google's developer community. At I/O last year, App Engine was brand new and many attendees were just getting familiar with the project. Well, what a difference a year makes - this year, in addition to sharing new information about our project, we got to learn about an amazing host of App Engine projects from you, our developers!

First, the big news - we are excited to announce open signups for our Java language runtime. During Wednesday's keynote, Engineering Manager Kevin Gibbs and Product Manager Andrew Bowers demoed the combined power of App Engine and GWT, all with easy deployment from the Eclipse IDE. If you've not tried our new language yet, please head over to the Admin Console to signup, then download the SDK and get programming.

The engineers behind Google App Engine for Java presented two sessions. First, Toby Reyelts and Don Schwarz introduced the new runtime with App Engine: Now Serving Java, including details of how our Java language layer exposes the power of Google's infrastructure. Be sure to check out the interactive game they demo'd with audience participation! Digging a bit deeper, Max Ross showed us The Softer Side of Schemas - how he mapped Java Persistence Standards to App Engine's datastore.

In addition to the new Java runtime, App Engine developer Brett Slatkin previewed some eagerly anticipated functionality: offline tasks. In his talk Offline Processing on App Engine: a Look Ahead, Brett revealed the first few milestones of App Engine's plan for offline processing with our upcoming Task Queue API. Leveraging the power of a web hook (an HTTP request body and URL) as the fundamental unit of execution on the web, this new API will allow you to organize and enqueue tasks for efficient background processing. Stay tuned to the App Engine blog for this feature's launch.

The App Engine team is always eager to share information about our infrastructure and how things work under the hood. Alon Levi kicked things off Wednesday morning with From Spark Plug to Drive Train: Life of an App Engine Request, in which he showed new information about how an application's incoming requests are received, scheduled, and executed by App Engine. Ryan Barrett presented some of the theoretical, yet practical challenges faced by the App Engine team with Transactions Across Datacenters (and Other Weekend Projects). Finally, Brett Slatkin took the stage once again, with Building Scalable, Complex Apps on App Engine, to give you insights on advanced data structures and algorithms.

In addition to the App Engine team, we were thrilled to have App Engine customers and partners present about their experience with the platform:

The Walk Score team shared their experience combining App Engine with other products in App Engine Nitty-Gritty: Scalability, Fault Tolerance, and Integrating Amazon EC2.
Ola Bini gave a language implementor's view of our new Java runtime with JRuby and Ioke on Google App Engine for Java.
Daniel Wilkerson presented distributed database theory in A Design for a Distributed Transaction Layer for Google App Engine.
Guillaume Laforge from SpringSource did a rapid walkthrough of Groovy and how to write Groovy applications for App Engine with Groovy and Grails in App Engine

Last but not least, more partners joined our Developer Sandbox to share their experience building projects on Google App Engine: 3scale, Best Buy, BuddyPoke, EZAsset, Gigapan, LifeAware, Salesforce.com, SpringSource, and ThoughtWorks.

Thanks for making this year's Google I/O a fantastic success! We have much more in store for 2009, so be sure to watch the App Engine blog for updates!

By Mike Repass, App Engine Team

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

Google I/O: Reflections on the Enterprise Track

2009-06-08T11:50:00.000-07:00

The Google Enterprise team was really energized to see the strong turnout for the 8 enterprise-track sessions at Google I/O last week. It was a treat to meet developers face to face and share stories about how things like Google App Engine, gadgets, GWT, Enterprise Search, and HTML 5 are impacting the industry's move to cloud computing. We were also pleased to announce Google Apps Script, a new feature that allows customization and automation in Google Apps, starting with spreadsheets, and to see the positive press coverage it has received.

The reality is that despite a formal "enterprise" track, the majority of the sessions were interesting and relevant to commercial developers, particularly Google Apps developers, who are rapidly uncovering a diverse set of commercial opportunities using these developer tools. This is something we want to continue to spread the word about!

The Google I/O team is busy uploading content from the event to the Google I/O site, and today we're happy to share a few highlights from last week:

Practical Standards-based Security and Identity in the Enterprise: Eric Sachs gave an overview of how Google is incorporating today's open identity and authorization standards into both consumer applications as well as enterprise software. Eric demonstrated inter-service communication using OAuth: from extranet to intranet, from platform to platform, and even from Google App Engine to Google App Engine.

Growing a SaaS-based services business around Google Apps: Jeff Ragusa of Google and Daniel Jefferies of Newmind Group gave a talk on how system integrators and developers can partner with Google to build a strong business reselling Google Apps and complementary services. Jeff highlighted the the myriad opportunities that emerge when the money spent on licenses, maintenance and upgrades can instead be spent on solving specific business problems and building custom apps an gadgets. Daniel, a Google Apps Authorized Reseller, talked about his experience bringing cloud computing to his customers.

Building Scalable, Complex Apps on App Engine: Brett Slatkin gave an informative presentation on the advanced techniques and data structures developers can leverage to build complex apps with App Engine. Areas of discussion included list properties and merge-joins, and how developers can use these tools to maximize performance of their apps.

Salesforce, Appirio and ThoughtWorks on App Engine for Java: Ron Hess of Salesforce and Iein Valdez of Appirio presented Connecting The Clouds: Integrating Google App Engine for Java with Force.com, and announced a new open source SOAP library for App Engine that helps connect App Engine apps to Force.com apps. Martin Fowler and Rebecca Parsons presented a session titled ThoughtWorks on App Engine for Java: An Enterprise Cumulonimbus?, which provided an overview of App Engine and the move to cloud computing from the perspective of larger enterprises.

Using the Google Secure Data Connector to Access Behind-the-Firewall Data from Google's Cloud: In this session, Jun Yang of Google showed how enterprises can bring a behind-the-firewall relational database into Google Apps using the Google Secure Data Connector and Google Feed Server. Jun demonstrated how developers can do this without the need for special code to access the SQL data or complex firewall configuration.

We hosted a mixer for enterprise developers and IT decision makers on the first day of I/O, and were thrilled at the turnout. The event was our first face to face outreach to commercial developers, covering all Enterprise product lines and touching on several recent developer announcements like Google Apps Script and the Google Apps Reseller program.

No, this is not people queuing up for free Android phones, just the line for the Enterprise Mixer.

All told, a great two days thanks to all of you. Since we're just getting started with tools and topics of interest to enterprise developers, please stay in touch. We have more tools and APIs on the way. The easiest way to do that is to subscribe to our Solution Provider announcements, and if you're tweeting, follow us on Twitter at GoogleAtWork.

By Scott McMullan, Google Apps Team

Google Web Toolkit at Google I/O

2009-06-08T11:18:00.000-07:00

Another Google I/O has come and gone, and speaking personally I think it's going to be hard to top this year's conference. Free Android unlocked developer devices and the unveiling of a very cool new product built with developers in mind? I already don't envy the planning team taking on next year.

There was a ton of Google Web Toolkit (GWT) related content this year, including an incredibly nice shout-out from Lars Rasmussen during the Google Wave keynote - if you haven't heard, Google Wave is built using GWT so if you want some inspiration as to what's possible, check out the keynote.

The GWT-related sessions have now been posted, so if you missed one you'll be able to catch it here. Here's a quick overview of the many sessions:

GWT Can Do What? A Preview of Google Web Toolkit 2.0: Start thinking about how you will take advantage of new features like runAsyc in the next version of Google Web Toolkit. Bruce Johnson, Co-creator of GWT, goes into the details of what's coming and the philosophy behind the new features.

Google Wave - Powered by GWT: This one's for the skeptics in your engineering department. As an adept JavaScript developer, Adam Schuck, Google Wave's Client Lead was initially skeptical about using Google Web Toolkit. Many lines of code later, he will openly tell you he's changed his mind about that. In this session, Adam discusses the Wave team's decision to use GWT and other facets of their client-side code.

Google Web Toolkit Architecture: Best Practices for Architecting your GWT App: A common question people ask is how to architect a GWT app. Ray Ryan discusses real-world learnings and patterns from the Google AdWords team and elsewhere which you can use in your apps.

Measure in Milliseconds: Performance Tips for Google Web Toolkit: Want some best practices for speeding up your app? Kelly Norton shares a few concrete issues and how to solve them.

Effective GWT: Developing a Complex, High- performance App with Google Web Toolkit: Alex Moffat and Damon Lundin from Lombardi are back again for a second year at Google I/O. Similar in theme to Ray Ryan's talk above, but with additional perspective and content, they'll take you through how they've successfully architected Lombardi Blueprint. I recommend watching both if you are laying out a new GWT app, or refactoring an existing one.

The Story of your Compile: Reading the Tea Leaves of the GWT Compiler for an Optimized Future: What if your app isn't as fast as you like it to be? While GWT tries to make your app as optimized as possible when you drive it off the lot, applications sometimes need to be tuned for racing by the developers themselves. Lex Spoon and Bruce Johnson talk about tools and techniques for understanding what's going on with your code and how to use that information to optimize your app.

Progressively Enhance AJAX Applications with Google Web Toolkit and GQuery: Ray Cromwell, from Timefire is one of my personal favorite speakers and commentators on GWT and web development. When he broke out his horse race demo in this session to measure performance deltas between different JS libraries, I knew why. Ray takes JQuery's power approach to manipulation and implements it in GWT. Learn about Ray's tool and how you can use this in your own projects to give designer's tools they can use directly in the HTML, without coding Java.

Building Applications with Google APIs: Did I mention Ray is an entertaining technical speaker? The title of this session, as Ray noted, doesn't do it justice. Related to GWT, this session outlines how he's used Google APIs and tools together to create an amazing integrated experience at Timefire. His demonstration of the interactive graph that syncs with the YouTube video is very compelling. Want to dispute Al Gore's claim of carbon emissions? Add your own dataset to the graph via a comment. Impressive.

We had a great time meeting many of you at I/O. Many of us were on hand, and talked to a lot of 'familiar email addresses' - it's nice to make that familiar faces. For those of you who didn't make it to I/O or want to revisit the GWT sessions, we hope you enjoy the session videos and presentations!

By Andrew Bowers, Google Web Toolkit Team

The Developer Sandbox, now with Video Interviews!

2009-06-05T15:00:00.000-07:00

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

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

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

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

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

By Neel Kshetramade, Google Developer Programs

Tech Talk Videos from Google I/O

2009-06-05T13:00:00.000-07:00

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

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

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

Update: David actually used a brush, not a pen. We thought adding a thumbnail of his work would help him forgive our mistake :)

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

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

By Min Li Chan, Google Developer Products

Introducing Page Speed

2009-06-04T13:57:00.000-07:00

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

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

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

We hope you give Page Speed a try.

By Richard Rabbat and Bryan McQuade, Page Speed Team