Friday, May 21, 2010

[Gd] MicroApps from The Guardian and Google AppEngine - Both ready for business

| More

Google App Engine Blog: MicroApps from The Guardian and Google AppEngine - Both ready for business

This post is another entry in our on-going series of guest posts from App Engine developers. Today we have the Guardian reporting in on how they're using App Engine as part of their Open Platform.

There has been a lot of debate recently about the future of news online, some people like The Times of London and New York Times think paywalls are the answer, others are not so sure. At The Guardian we have a clear alternative and vision, we call it mutualisation. It's all about reducing the barriers between our journalists and readers and between our organisation and our partners. For software developers and online businesses we have a product sitting just in this space which we call the Open Platform.

The Open Platform has been in beta for the last year and now, today it is officially "Open for Business". Open for developers to take and co-monetize our content with us, building new applications for distributing and consuming news. It is also open for partners to build new experiences which blend content from The Guardian and their own functionality and in some cases brands into the heart of The Guardian's award winning website.

Today we're launching a brand new product and framework called MicroApps which the diagram above describes. However, just as Google dogfoods its new products before launch, so do we, and we wanted to share some of the things we've been building as MicroApps using Google AppEngine for the storage and application development part.

With 36 million unique and very engaged readers, everything we make has to scale, which is why AppEngine is ideal. With it's highly scalable architecture and features such as task queues, built for creating loosely coupled apps, and memcache, AppEngine makes an excellent companion platform for MicroApps in which the apps can run anywhere in the cloud. The examples presented here range from new ways to find content which others are finding exciting or interesting, to live responses to the TV debates to ways to bring together all of the tweets of our journalists on specific subjects.


Many people are interested in what is hot in the news and what is trending. We think this is interesting, but something a bit more interesting is in the things which are unexpectedly popular. Dan Catt used AppEngine to pull together signals from sources such as OneRiot, Twitter, comments in our system and our own internal stats to create an index of Zeitgeisty-ness. For the full "science bit" please see this overview article. We're using AppEngine for the storage and processing of a lot of data, with several task queues in play to create a page which responds over time during the current day showing you what people's attention think is the most interesting content. At the end of the day these are all archived and available so you can see what the Zeitgeist was on a particular day. The MicroApp framework allows us to host all of the application on AppEngine and display it in the network pages as if it were coming out of the content management system. This allows us to build data heavy applications using the economy of scale of cloud computing platforms while not affecting the scalability of the core site. If you want to see exactly how we made Zeitgeist, Dan talks about it here.

Election Debate Live Poll

There was recently a general election in the UK and for the first time in the UK there were a series of debates about the party platforms from the leaders of the three main parties. We felt that it would be good to capture the mood of the nation by allowing people to simply click a "+" or a "-" as to whether they liked or disliked what a leader said. This was then to be displayed as a sentiment "worm" alongside the video. Michael Brunton Spall created an AppEngine app which allowed us to scale rapidly and sustainably for the duration of the debates. At one point in time in the second debate the AJAX calls from the buttons were peaking at around 750 requests per second with an average of 454 requests per second. In total over the hour and a half of the debate over 2.7 million requests were made on the AJAX voting services which made heavy use of memcache and sharded counters. This sort of temporary load would have required a vast amount of additional temporary infrastructure for us and planning. AppEngine made that simple.

Twitter Collation

Just before The Edinburgh Festival, a really rather huge arts festival in the UK, we had a hackday and Stephen Abbott made a suggestion for something that it would be nice to see was an app that would allow the tweets about the festival of a collection of journalists and performers we trusted to be pulled together in one stream. This would need a double white list to be created, one where only if they were in the collection and they mentioned the keyword would your tweet make it into the stream. This is clearly to avoid spam and unwanted messages and to filter out journalists from talking about what they'd had for breakfast (unless it was festival related). In 24 hours using AppEngine Chris Thorpe had built a machine which fanned out queries from regular cron job which hauled in the stream of each journalist and performer (each in a single task queue action) and then processed each tweet asynchronously (again each in a single task queue action). The app performed well and was then industrialized as a MicroApp by Michael Brunton Spall and Lisa van Gelder and has been used throughout the general election and to bring together tweets from journalists within sections. We're now following and processing the streams of a large number of our journalists and are creating views of those streams with multiple watched keywords. The view of the stream can then be inserted into pages just like the one below using AppEngine and our MicroApp framework with memcache used to keep the response time fast.

Random Guardian

A flippant comment, in a serious question from Chris Thorpe to Clay Shirky, when he visited us recently at The Guardian, about where the new serendipity was in news, contained the phrase "should we just build Chatroulette for news?" He said that yes, we should definitely do that and in about 2 hours and using the beta of our new APIs, Daniel Vydra had done just that in AppEngine. The application has been hugely successful at introducing people to parts of the site they've never visited before and has led to people being mildly addicted to discovering things they never knew they needed to know, just at the click of a button. We're open sourcing the code for it very soon, so you too can start experimenting.

The MicroApp platform wouldn't exist without the hard work and brilliance of a team including Matthew Wall, Matt McAlister, Stephen Dunn, Mike Bracken, Graham Tackley, Stephen Wells and Simon Willison. We're now open for business and to prove it we're holding a hackday where we're making some very rapid prototypes for media agencies. Who knows, they may like them so much as concepts they commission them and we'll have to put them into production. That'll be fine for us, with the tools we use and the platform we have we know we have an environment to scale.

Photo by Dan Catt

Posted by Chris Thorpe, Guardian

Thursday, May 20, 2010

[Gd] I/O Recap: The open web moves forward, Froyo delights developers and TV meets Web

| More

Google Code Blog: I/O Recap: The open web moves forward, Froyo delights developers and TV meets Web

With over 5,000 developers, more than 90 sessions, over 180 companies in the Sandbox and a steady stream of major announcements, it’s been a busy two days at Google I/O here in San Francisco. For us, the best part of I/O was getting to meet and talk with developers and see all the amazing things you’re building. Getting to drive the Mondo Spider at the after party was pretty awesome too!

Vic Gundotra kicked off the Day 1 keynote which featured the future of the web with HTML5, WebM, the Chrome Web Store, Google App Engine for Business and much, much more. Read the full Day 1 keynote recap here or watch the full length video below:

Day 2 kicked off early with a keynote featuring Android 2.2 (code name: Froyo), sneak peaks into the future of Android, mobile app monetization, and the official announcement of Google TV. Here is the Android part of the Day 2 keynote, and we will update this post later when the Google TV segment is ready.

Many teams prepare their products to announce at Google I/O, so there were lots of announcements beyond the keynotes as well, including
We have been blogging and tweeting non-stop, so feel free to read up on all the exciting new launches on our Code blog and @googleio Twitter feed.

To see live notes of the keynotes, see Matt Cutts’ Day 1 live wave and Day 2 live buzz. For live notes of all sessions, see the embedded waves on our session pages or go to the main Google I/O wave. Videos from all the I/O sessions will be posted soon to the on YouTube.

We’ll end with a photo slide show of some of our favorite moments from I/O:

Thanks to everyone for making the last couple of days so much fun! Hope to see you next year.

Susan Taing and Mike Marchak, Google Developer team

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

Google Chrome 5.0.375.50 has been released to the Beta channel for Linux, Mac and Windows.

This release contains some minor crash and stability fixes, in addition, we have also temporarily put our internal version of Flash Player back behind a flag.  We plan on re-enabling our internal version of Flash Player by default on the beta channel in the near future.

We have also fixed a regression so that we no longer remember incognito zoom changes (Issue: 43107)

If you spot any issues, please let us know:

Anthony Laforge
Google Chrome Team

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 6.0.408.1 for Windows, Mac, and Linux

  • [r47574] Don't remember incognito zoom changes (Issue: 43107)
  • See all
  • [r47063] Fix possible deadlock in PluginChannel. (Issue: 43617)
  • Localization UI Resizing
  • Fixed various memory related errors
More details about additional changes are available in the svn log of all revision.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Jason Kersey
Google Chrome

[Gd] The Google TV Story

| More

Android Developers Blog: The Google TV Story

Vincent Dureau, who’s in charge of Google TV, is a lean, bony-faced man with a strong French accent; not too far off my own age, I’d say. With the announcement imminent, he’s been too busy to write; I'm reporting on my talk with him to give a feel for the thinking behind the project. You’ll notice an absence of quotation marks; Vincent’s half of the conversation is reconstructed from the combination of my memory and notes. I think it’s accurate in essence, but certainly not in detail; among other things I can’t write with a French accent.

On why Google TV is needed:

Even two years ago you would have said that telephones are mostly for making calls, maybe for email and texting. Today, we know that phones can actually do a whole lot more. In the same way, people say that TV is just for watching TV. But, like the phone can be used for more than making calls, we believe that TV can be used for more than just video. Also, there’s not enough shelf space for the stuff on TV; not even with online channel guides and your PVR access and your racks full of disks. The shelf space should be as big as the web.

On why developers should care:

They’ve always had access to the desktop. With mobile devices, they managed to get into your pocket. Google TV brings them into the living room, which is where people live.

On what’s going to be in the SDK:

First, we have to make sure that most mobile apps work on your TV, too. Second, we should offer TV-specific features, like being smart about screen sizes, changing channels, embedding video streams, mashing up live TV and what’s on the PVR and what’s on the Web.

On the Google TV project:

The project started 2½ years ago, with a vision of a walled garden of TV-optimized web services. But the landscape keeps shifting, particularly in the capabilities of mobile devices. The only solution big enough for the problem is to bring the whole web to your TV.

On which apps will come with the initial release of Google TV:

First of all, we run Chrome so we can ship both Android and web apps. Some will be pre-loaded; this is a moving target but we expect that Listen, Netflix, and Amazon Video On Demand will be on board.

On what truly great Google-TV apps he imagines:

That’s irrelevant; the reason we’re building the SDK is to enable all those smart people out there that don’t work for Google to do cool stuff with TV.

On how it works if there isn’t a partnership between Google TV and your TV provider:

It should be pretty good; the device comes with an IR blaster and knows the IR interfaces for the popular satellite and cable boxes. You really should be able to get an integrated experience.

On himself:

He’s the guy who pitched the project to Google’s executive team. He has been at Google for four years, and was hired to work on TV, originally ads. Working on TV is pretty much the only thing he’s ever done. Prior to Google, he worked on compression and DIRECTV.

On which TV he watches:

He doesn’t watch TV, he tests it. His popular test materials are Battlestar Galactica, Life on Discovery,, Al-Jazeera’s newscasts (they have reporters more places than any other network); and, these days, the NBA playoffs. He does a lot more on his TV than watch TV; he uses it to run Pandora and to hear the music through the nice speakers. Whenever he hears a tune he likes, he buys it right there & then from Amazon, which can get a little expensive.

On how to get involved:

You can begin building optimized web apps today. If you’re interested in building Android apps, visit our Google TV homepage to sign up for updates on when the SDK add-on will be available. And if you’re interested in helping out in a broader scope, check out our Google jobs site and apply for an engineering position.


[Gd] Android 2.2 and developers goodies.

| More

Android Developers Blog: Android 2.2 and developers goodies.

Today at Google I/O we announced that Android 2.2 is right around the corner. This is our seventh platform release since we launched Android 1.0 in September 2008. We wanted to highlight five areas in particular:

Performance & speed: The new Dalvik JIT compiler in Android 2.2 delivers between a 2-5X performance improvement in CPU-bound code vs. Android 2.1 according to various benchmarks.

New enterprise capabilities: We’ve added Exchange capabilities such as account auto-discovery and calendar sync. Device policy management APIs allow developers to write applications that can control security features of the device such as the remote wipe, minimum password, lockscreen timeout etc.

Faster, more powerful browser: We have brought the V8 JavaScript engine to the Android browser as part of 2.2. This has resulted in a 2-3X improvement in JavaScript performance vs. 2.1.

Rich set of new APIs and services: New data backup APIs enable apps to participate in data backup and restore, allowing an application's last data to be restored when installed on a new or a reset device. Apps can utilize Android Cloud to Device Messaging to enable mobile alert, send to phone, and two-way push sync functionality. Developers can now declare whether their app should be installed on internal memory or an SD card. They can also let the system automatically determine the install location. On the native side, a new API now gives access to Skia bitmaps.

Additions to Android Market: Android Market provides Android Application Error Reports, a new bug reporting feature, giving developers access to crash and freeze reports from users. Developers will be able to access these reports via their account on the Android Market publisher website.

For a complete list of everything we’ve included in Android 2.2, please see the platform highlights.

Developers can now download the Android 2.2 SDK and Android NDK, Revision 4 from the Android developer site.

Tools update

We are releasing new version of the Android SDK Tools, Revision 6, Eclipse plug-in ADT 0.9.7 and Android NDK, Revision 4.

Android SDK Tools, Revision 6, Eclipse plug-in 0.9.7

These new versions include support for library projects that will help you share code and resources across several Android projects.

Android NDK, Revision 4

Workflow improvements
The new NDK brings a host of workflow improvement, from compilation, to debugging. Starting with 2.2, the NDK enables debugging native code on production devices.

ARMv7 instruction set support
This release enables the generation of machine code for the ARMv7-A instruction set. Benefits include higher performance, as well as full use of the hardware FPU for devices that support it.

ARM Advanced SIMD (a.k.a. NEON) instruction support
The NEON instruction set extension can be used to perform scalar computations on integers and floating points. However, it is an optional CPU feature and will not be supported by all Android ARMv7-A based devices. The NDK includes a tiny library named "cpufeatures" that can be used by native code to test at runtime the features supported by the device's target CPU.

For more information, please see the releases notes for the SDK Tools, ADT, and NDK.

As I said at the beginning, Android 2.2 will be here soon, and some devices will get the update in the coming weeks. I invite application developers to download the new SDK and tools and test your applications today.

Check out the video below to learn more about Android 2.2.


[Gd] Mail Merge in the Cloud with Google APIs

| More

Google Code Blog: Mail Merge in the Cloud with Google APIs

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Jonathan Howard, lead developer of Drawloop Technologies and one of the creators of DDPs for Google Apps, a cloud based document automation service. DDPs for Google Apps will be demoing as part of the Developer Sandbox.

One of the first comments we received upon releasing our dynamic document packages (DDPs) for Google Apps was the lack of mail merge anywhere in the cloud. A DDP combines one or more documents together while also merging data into those documents, giving you a combined file with whatever page order you'd like. What we were missing from this was a simple way of getting multiple sets of data into this DDP quickly and easily. The business need was clearly there, and wasn't being filled. Google Apps provides not only an excellent document management system, but also a set of great APIs that can be utilized by third parties to expand upon the already robust offerings within Google Docs. Never ones to back down from a challenge, we set out to determine the requirements for a cloud-based mail merge solution.

1. Nothing local. Like any cloud-based solution, the only thing that should be required from a user is a solid internet connection. Their interactions shouldn't rely on installing software or using a machine with a specific set up. Our experiences from implementing DDPs for Google Apps served us well here, as we already were interacting with Google Docs.

2. Simple to manage and run. We wanted to keep the management piece as close to what already existed as possible. This meant utilizing as much of our work on DDPs for Google Apps intact, and wrapping the mail merge piece around it. At runtime, the user shouldn't have to deal with complicated forms or having to connect files together like is the norm for desktop applications.

The first problem was easily solved by extending our existing implementation with Google Docs. Leveraging Google APIs, we are able to use Google Docs for both management of the mail merge and storage of the results. Since we wanted the management to leverage our existing technology and to be both simple and entirely based in the cloud, we decided it would be best to make it wrap around our existing DDP functionality. To manage the merge data, we create a folder inside Google Docs and place within that folder a single spreadsheet. All data for a merge can be placed in that spreadsheet, which we then tie directly to the existing DDP at runtime. Each row is now considered a single DDP run with all the results streaming back to Google Docs.

One of the biggest values of utilizing a Google spreadsheet for managing the mail merge as you have all the same functions as you normally have with spreadsheets, such as Google forms. You can easily tie a form to the mail merge spreadsheet and allow your own customers to populate your data for you.

You can install your free trial of DDPs for Google Apps by visiting the Google Apps Marketplace and clicking on the "Add it now" button.

If you have questions or ideas you'd like to share on this or any of our other offerings, please visit us this week in the Developer Sandbox at Google I/O!

Posted by Jonathan Howard, Lead Developer of Drawloop Technologies

[Gd] Google App Engine Basic Text Search

| More

Google Code Blog: Google App Engine Basic Text Search

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Brian Dorry from LTech who is demoing as part of the Developer Sandbox.

Having trouble implementing search on your App Engine Data Store? Try this technique for a basic search until official full text support is ready.

Since adding Google App Engine to our technical tool belt in 2008, we at LTech have utilized the platform for a wide range of products and customer solutions. It is cost effective, easy to use, and will automatically scale your application on Google's immense infrastructure. Knowing your applications will be running on the same technologies that Google's own systems take advantage of make it the easy choice again and again.

From our own experiences and participation in the developer community, the biggest complaint we hear is the lack of a full text search in the datastore. Google has marked this issue as "Started", but has not announced a release date yet, so alternative approaches are still going to be in play for the short term. We are big fans of Lucene (, an open source indexing and search engine, but without the ability to save the index file to disk, it becomes a non-starter.

We need a quick, non-CPU taxing solution that still takes advantage of the Google infrastructure.

Taking advantage of the App Engine Datastore, we can issue an inequalities query to perform a basic "starts with" search. This can be a good solution for searching users, tags, and domains and works well for implementing a search box auto-complete feature.

Our example solution uses JDO to generate a query that instructs the DataStore to return all records that start with the search string. This is accomplished by issuing a greater than or equal condition against the search term, and a less than condition against the search input concatenated with the unicode replacement character ('\ufffd'). The resulting query limits results to items that start with the search input, as well as any other unicode characters that follow.

This code uses JDO behind the scenes, but this trick will work with straight GQL as well. Let's take a look at the sample:

import java.util.List;
import javax.jdo.PersistenceManager;
import javax.jdo.Query;


public static List
searchGreeting(String query) {

// let's clean up the input
query = ( query != null ? query.toLowerCase() : "").trim();

PersistenceManager pm = PMF.get().getPersistenceManager();
Query q = pm.newQuery(Greeting.class);

// set the filter and params
q.setFilter("content >= :1 && content < :2"); // run query with param values and return results return (List
) q.execute(query, (query + "\ufffd"));

This code snippet is going to search the JDO defined Employee entity on the name column and return the full Employee payload for each match. Let's focus on the last two lines of code.

q.setFilter("name >= :1 && name < :2");

Here we set up the inequality. We are asking the data store to return all matches where name is between a set of two values. But how does that define a search?

return (List) q.execute(query, (query + "\ufffd"));

When we set our parameters, we pass the same query value to both with an extra character on the end of the second one. This is essentially telling the data store to return all records that start with the query term. In terms of sets, the first part of the query returns the set of all words greater than the query term, including words that don't even start with the query term. The second part of the query returns the set of all words less than the query term including any that start with the query term. The intersection of the two sets is the search result for all words starting with the search term.

This simple to implement technique will solve many basic search problems until a full text solution is available. It will work outside of JDO as well with regular GQL statements. For a python implementation, please see our friend Graeme's blog.

Posted by Brian Dorry, LTech team

Wednesday, May 19, 2010

[Gd] OrangeScape makes Google App Engine ready for business applications

| More

Google Code Blog: OrangeScape makes Google App Engine ready for business applications

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Mani Doraisamy from OrangeScape who will be demoing as part of the Developer Sandbox.

Google App Engine took two bold steps in the right direction for cloud computing in making its datastore distributed to ensure scalability and durability and in fixing its architecture to be stateless to ensure failover and availability. To quote Henry Ford: "Any customer can have any application that is scalable so long as he builds for this fixed architecture."

To date, it has worked very well with the social web app companies, but the enterprise application development community has mostly stayed away from Google App Engine for three reasons:
  • “Newness” to Google App Engine's concepts of GQL, lack of aggregate queries, denormalized schema.
  • Lack of transaction support: commit or rollback on distributed storage and read consistency within transaction scope.
  • Relying only on the cloud: not being able to run the same application on standard infrastructure inside your company.
Now you can build business applications on Google App Engine, too! OrangeScape is a Platform-as-a-Service for building business applications that run both on the cloud via Google App Engine and in your data center.

It has three main benefits:
  • It provides a modeling environment to build business processes and rules, datamodel using a familiar process design and spreadsheet like interface. The application that you build on this interface can be deployed on Google App Engine in a single click.
  • It enhances the persistence layer of Google App Engine to support transactions and read consistency on BigTable. It makes it so transparent that there is absolutely no difference for you to build applications on BigTable or on relational databases.
  • If you are a solution provider building business applications today, you may not know if all your customers will accept running applications on the cloud. Some might expect that applications run on their data center. With OrangeScape, you can build it once and run it on both - cloud and data center.
If you are excited to try it out, bookmark We will making the public beta announcement shortly after Google I/O.

Posted by Mani Doraisamy, OrangeScape team

[Gd] WaveOne Wave Server Implementation

| More

Google Code Blog: WaveOne Wave Server Implementation

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Mickaël Rémond, Founder of ProcessOne, who will be demoing as part of the Developer Sandbox.

When the Google Wave protocol and platform was announced at Google I/O in 2009, ProcessOne became an immediate fan.

What we like most is the real time nature of the protocol, which is currently critical in any new web service. We also like the fact that it integrates well in an asynchronous workflow, allowing developers to work together at the same time on the same content, even the same character. (This is, however, an extra feature and you don’t have to use it.)

In addition, we are keen on the ability to integrate gadgets, acting as mini applications, inside each conversation. This opens up a new level of opportunity to integrate various applications together in the same place. It can be seen as ‘cloud glue’, a simple way to aggregate rich data available from different applications and different application providers.

However, the most powerful enabler in the Wave protocol is federation, which allows developers to have several domains, and thus build several different content management platforms, with the ability to act as a single interoperable tool. It does not matter if you do not want to host your company data on Google Wave server; you can instead deploy your own Wave compliant tool internally and still collaborate with people outside your organisation on that content. This is cross-organization document workflow.

Since the announcement of Wave, ProcessOne has been excited by the possibilities offered by this new protocol. Federation was build on top of XMPP (eXtensible Messaging and Presence Protocol), a domain in which ProcessOne is already a leading provider. It was a natural progression for us to extend our platform to support Wave.

We decided to develop such an extension for our XMPP server, but we took the hard way. We developed our own completely new Wave server, to prove that this protocol was really interoperable with implementations from different code bases. We also wanted to prove that the new platform would meet our high expectations for integration, performance and scalability. Of course, we read the FedOne code source to understand specific aspects of the underlying Wave protocol, but we did an implementation from scratch (in Erlang).

So, how far has ProcessOne got?

We are proud to have a full Wave server implementation, both with an operational transform engine and a Wave store. We have designed a client protocol that works on XMPP, meaning that we can directly get the wave information in our OneTeam chat and VoIP client. We have even implemented this protocol in two XMPP clients (Tkabber and OneTeam) to validate the concept.

We have now reached a point where federation works, both with FedOne and Google Wave Developer Sandbox. This means that you can host waves on our server and invite people to join from any other known Wave service, or do the reverse and participate in a Wave document that is managed by another service.

What are the next steps?

From here, we need to take a few more steps to fully unleash the full potential of Wave (like OpenSocial support), but we have the foundation for an innovative collaboration platform. This Wave service will be deployed as an experimental option on our hosted messaging offering (Hosted.IM) in June. We therefore expect to become the first independent Wave Service Provider.

We also hope that our implementation will be the first seed, from which many other large Wave services will grow and spread around the world.

Let's meet in Google I/O Developer Sandbox to talk about the future of the Wave platform. We look forward to seeing you there.

Posted by Mickaël Rémond, Founder of ProcessOne

[Gd] Introducing the Google Buzz API

| More

Google Code Blog: Introducing the Google Buzz API

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

[Gd] Latitude API Launch

| More

Android Developers Blog: Latitude API Launch

Over at the Google Code Blog, there's a pretty significant announcement, about the release of APIs for Latitude. the idea, as you might expect, is that the best way to get good location-based applications is to put the tools for building them into everyone's hands.

A glance at the online documentation reveals an essentially-RESTFul API with JSON payloads, which should be easy to use from an Android app. It seems likely that a device which knows its location is a really good platform for building location-sensitive apps.


[Gd] BigQuery and Prediction API: Get more from your data with Google

| More

Google Code Blog: BigQuery and Prediction API: Get more from your data with Google

To deliver our services, Google has had to develop sophisticated internal tools to process data more efficiently. We know that some of these tools could be useful to any developer, so we’ve been working to create external versions that we can share with the world.

We’re excited to introduce two new developer tools to get more from your data: BigQuery and Prediction API. These two tools can be used with your data stored on Google Storage for Developers.

BigQuery enables fast, interactive analysis over datasets containing trillions of records. Using SQL commands via a RESTful API, you can quickly explore and understand your massive historical data. BigQuery can help you analyze your network logs, identify seasonal sales trends, or find a needle in a haystack of big data.

Prediction API exposes Google’s advanced machine learning algorithms as a RESTful web service to make your apps more intelligent. The service helps you use historical data to make real-time decisions such as recommending products, assessing user sentiment from blogs and tweets, routing messages or assessing suspicious activities.

We are introducing BigQuery and Prediction API as a preview to a limited number of developers. There is no charge for using these services during the preview. To learn more and sign up for an invitation, please visit the BigQuery and Prediction API sites.

If you are in San Francisco for Google I/O, we look forward to meeting you. Please come to our session tomorrow to learn more.

Posted by Amit Agarwal and Jordan Breckenridge, BigQuery and Prediction API Teams

[Gd] With the New Google Latitude API, Build Latitude and Location Into Your App

| More

Google Code Blog: With the New Google Latitude API, Build Latitude and Location Into Your App

Location, location, location. In case you haven’t noticed, we’re really excited about all the ways location can make mobile apps and websites more useful. With Google Latitude, we created a simple way to share your location with whomever you like, display it wherever you like, and even keep a history of it if you want. We wanted to give you even more ways to use your location, so today we’re announcing the Google Latitude API -- an easy and safe way to build Latitude and location into any apps or features that you could possibly imagine!

Since launching Latitude, our team has been talking about all the cool things you could do with your continuously updated Latitude location. While we’ve built some of our ideas, there are simply too many exciting ones for us to do alone. Instead, we wanted to let developers create apps that do even more with Latitude and location. You could, for example, build apps or features for:
  • Thermostats that turn on and off automatically when you’re driving towards or away from home.
  • Traffic that send alerts if there’s heavy traffic ahead of you or on a route you usually take based on your location history.
  • Your credit card accounts to alert you of potential fraud when a purchase is made far from where you actually are.
  • Photo albums so your vacation photos appear on a map at all the places you visited based on your location history.
We want to help developers build all these applications and more, but our first priority is privacy and making sure we give users control over their location. That way, it’s only used when, where, and how users choose. When you request access to Latitude users’ data, users will have to specifically grant access to your domain after seeing exactly what data is being requested. You may request to update and view users’ best available location, view only their city-level location, and/or update and view their location history if they’ve opted in to using Google Location History. Users will also be able to revoke access from any developer at any time from their Google Account’s personal settings. Just like with Latitude, the user always chooses who can see their location.

We’ve also learned that making a phone’s continuous location available in the background is tricky to do accurately and efficiently -- just imagine your phone’s battery life if several apps were continuously getting your location in different ways. With this in mind, we wanted to build a free and open Latitude API that lets you just start using your users’ updated locations in new ways without reinventing the wheel.

To get started, go to to read our API documentation. Then, join the Latitude API Google Group to ask questions, discuss the API with the community, and give us feedback. The Latitude API is being launched in Labs so we can listen to developer feedback before it graduates. We’re excited to see what you can do with Latitude and location so please let us know what you think!

By Ana Ulin, Software Engineer, Google Mobile Team

[Gd] Even more ways for developers to optimize with AdSense

| More

Google Code Blog: Even more ways for developers to optimize with AdSense

Last year, we announced that developers can earn revenue by showing ads in two of our products, the GoogleBar for Local Searches on a Google Map and the Custom Search element for site-restricted and other curated searches. Today, we're happy to announce two new AdSense product updates to help monetize your website.

AdSense for search ads only
AdSense for search allows publishers to add Google search functionality to their site and monetize from search ads. The Custom Search element is a prime example. However, despite the power and flexibility of the element, you may want to show ads next to your own non-Google search results. With AdSense for search ads only, developers can now include AdSense for search ads on their pages, paired with their own homegrown search results.

AdSense for Ajax
The other side of AdSense is ads targeted to content on your site. In this case, developers turn to AdSense for content. But what if your content isn't crawlable by search engines or uses Ajax to dynamically update without a page refresh? Now you can deliver AdSense for content ads via AdSense for Ajax, which allows you to give hints about your uncrawlable content. Even better, it allows you to refresh the ads dynamically when there is a context change.

If your site is a good fit for either, or both, of these offerings, sign-up for AdSense for Ajax or AdSense for search ads only today! Learn more about them from the AdSense Blog post.

By Adam Feldman and Mike Brandell, AdSense Team

[Gd] Google Storage service for Developers

| More

Google Apps Developer Blog: Google Storage service for Developers

As businesses move to the cloud, there’s a growing demand for core services such as storage that power cloud applications. Today we are introducing a preview of Google Storage for Developers, a RESTful cloud service built on Google’s storage and networking infrastructure.

Using this RESTful API, developers can easily connect their applications to fast, reliable storage replicated across several US data centers. It is highly scalable - supporting read-after-write data consistency, objects of hundreds of gigabytes in size per request, and a domain-scoped namespace. In addition, developers can manage their storage from a web-based interface and use gsutil, an open-source command-line tool and library.

Google Storage is designed for sharing and collaboration, with built-in authentication services and access controls based on Google Accounts. This makes it easy to control which users have access to what information in your internal and external applications. Right now Google Storage only supports standard Google Accounts, but we’re working hard to add support for Google Apps accounts.

We are introducing Google Storage for Developers to a limited number of developers at this time. During the preview, each developer will receive up to 100GB of data storage and 300GB monthly bandwidth at no charge. To learn more and sign up for the waiting list, please visit our website.

We’ll be demoing the service at Google I/O in our session and the Developer Sandbox. We’re looking forward to meeting those of you who are attending.

by Jessie Jiang, Google Storage for Developers Team

[Gd] Autocompletion of queries in Custom Search

| More

Google Custom Search: Autocompletion of queries in Custom Search

One of the most requested features for Custom Search is autocompletion of queries. Today, we announced at Google I/O that you can now enable query autocompletions for your search engine.

The screenshot below shows an example of query autocompletion at Travelocity.

Custom Search autocompletion is similar to what you see on—optional queries appear as you type your query in the search box. However, behind the scenes, we do a lot of things differently. We created a different algorithm that uses data from multiple sources, including queries to your search engine, as well as keywords and phrases extracted automatically from the content of websites that your search engine covers.

Because the autocompleted queries are based, in part, on the specific content of the webpages covered by your search engine, we will not generate autocompletions for custom search engines that search the entire web, i.e., autocompletions will only work if you set your preferences to Search only included sites in the control panel.

To enable autocompletions, select Enable autocompletions in the Basics tab of the control panel.

After you’ve saved your settings, replace the code for the search box in your website with the search box code from the Get code tab and you're done. Please note that it can take a few hours for us to start generating autocompletion queries for your search engine.

If you are using the Custom Search Element with a theme, the autocompletions are styled to match the look and feel of your theme. Autocompletions will also work on high-end mobile devices.

We hope that you find the feature useful. As always, give us feedback so we can improve the feature.

Posted by: Bartlomiej Niechwiej and Jeffrey Scudder, Software Engineers

[Gd] Google I/O Day 1 Key Announcements

| More

Google Code Blog: Google I/O Day 1 Key Announcements

We unveiled several exciting new products and features in our Day 1 keynote presentation, and we also have a few more surprises we announced online. Cutting edge HTML5, the Chrome Web Store, App Engine for Business, a new partnership, and more! Some of these announcements made it to the Google Code blog already, but see the Google Blog for a recap of all the highlights.

Susan Taing, Google I/O Team

[Gd] Google Storage for Developers: A Preview

| More

Google Code Blog: Google Storage for Developers: A Preview

As developers and businesses move to the cloud, there’s a growing demand for core services such as storage that power cloud applications. Today we are introducing Google Storage for Developers, a RESTful cloud service built on Google’s storage and networking infrastructure.

Using this RESTful API, developers can easily connect their applications to fast, reliable storage replicated across several US data centers. The service offers multiple authentication methods, SSL support and convenient access controls for sharing with individuals and groups. It is highly scalable - supporting read-after-write data consistency, objects of hundreds of gigabytes in size per request, and a domain-scoped namespace. In addition, developers can manage their storage from a web-based interface and use GSUtil, an open-source command-line tool and library.

We are introducing Google Storage for Developers to a limited number of developers at this time. During the preview, each developer will receive up to 100GB of data storage and 300GB monthly bandwidth at no charge. To learn more and sign up for the waiting list, please visit our website.

We’ll be demoing the service at Google I/O in our session and in the Developer Sandbox. We’re looking forward to meeting those of you who are attending.

Posted by Jessie Jiang, Google Storage for Developers Team

[Gd] App Engine goes to work with App Engine for Business

| More

Google App Engine Blog: App Engine goes to work with App Engine for Business

App Engine has a storied history at Google I/O. Two years ago, we launched Google App Engine to at the inaugural I/O. It’s been two amazing years for App Engine and we’re very excited to be back at this year’s third annual I/O with the announcement of Google App Engine for Business. Google App Engine for Business lets organizations build and maintain their applications on the same scalable architecture that powers Google applications, with added management and support features tailored specifically for the enterprise.

Google App Engine for Business introduces a number of new features that our enterprise customers have been asking for, including:

  • Centralized administration: A new, company-focused administration console lets you manage all the applications in your domain.
  • Reliability and support: 99.9% uptime service level agreement, with premium developer support available.
  • Secure by default: Only users from your Google Apps domain can access applications and your security policies are enforced on every app.
  • Pricing that makes sense: Each application costs just $8 per user, per month up to a maximum of $1000 a month. Pay only for what you use.
  • Enterprise features: Coming later this year, hosted SQL databases, SSL on your company’s domain for secure communications, and access to advanced Google services.

With these new features, we’re making it easier for businesses to take advantage of the core benefits of Google App Engine: easy development using languages you already know (Java and Python); simple administration, with no need to worry about hardware, patches or backups; and effortless scalability, automatically getting the capacity you need when you need it.

Google App Engine for Business is currently in preview, opened to a limited number of enterprises. Learn more about how you can participate, and check our roadmap to follow features as they become available.

Posted by Sean Lynch, Google App Engine team

[Gd] App Engine at Google I/O 2010

| More

Google App Engine Blog: App Engine at Google I/O 2010

It’s been a busy past few months for the App Engine team and we’re doing a ton of great stuff at I/O this year.

First up, we are happy to announce version 1.3.4 of the App Engine SDK for Python and Java developers. This release has a number of additional features including:

  • A brand new bulkloader - The new bulkloader is based on a powerful declarative syntax for importing and exporting data, and is designed for use with both Python and Java applications.
  • Experimental support for OpenID built into the Users API as well as OAuth support. These libraries provide greatly increased support for a variety of authentication types. They also make it considerably easier for developers to build applications for the Google Apps Marketplace.
  • The Blobstore API has graduated and is no longer an experimental API. It now supports files up to 2GB in size!
  • Assorted smaller bug fixes (please read the release notes for more details).

With 1.3.4, we are also announcing we will be deprecating support for Java 1.5. Developers using 1.5 will now see warnings when building their applications informing them that they should upgrade their version of Java. 1.5 will be supported for at least the next two releases of the SDK and 1.5 will continue to be supported on the App Engine service with previous versions of the SDK for three years.

We’re also demoing a few upcoming features of App Engine at I/O as part of our sessions:

  • Mapper API - A simple library for executing work in parallel over a large dataset, such as all your datastore entities or line-based data in a Blobstore blob.
  • Channel API - The Channel API lets you build applications that can push content directly to your user’s browser (aka “Comet”). No more polling for updates!

There will be opportunities for you to experiment with both APIs in the near future, so keep an eye on the Google Group and this blog for updates.

We’re also excited to announce that we will be adding App Engine to the Google Qualified Developer program in the near future. If you’re interested in becoming a qualified developer, and helping to develop the curriculum for future programs, you can visit the Developer Qualifications page and sign up to be a member of our first class!

Finally, if you are one of the developers joining us at I/O, make sure to check out the App Engine I/O sessions, visit the App Engine Developers in the Developer Sandbox, and swing by the office hours to talk with the App Engine team, or just to hang out! We look forward to seeing you there.

Posted by the App Engine Team

[Gd] Google Wave platform updates at I/O: See what you can build now!

| More

Google Wave Developer Blog: Google Wave platform updates at I/O: See what you can build now!

When we first launched Google Wave in developer preview mode at last year's I/O, thousands of developers started playing around on, experimenting with the APIs, and checking out the preliminary set of specs and whitepapers on Back then, many developers looked around and decided that they couldn't do what they wanted with the APIs yet, or the protocol wasn't fleshed out enough for their needs, so they filed their feature requests and slowly disappeared from the Wave world.

Today, we'd like to encourage all those developers to take a second look. Over the past year, and today at Google I/O, we've launched a series of improvements that make Wave a more compelling platform, product, and protocol, and enable the kind of apps and integrations developers first dreamed of when they encountered Wave.

Here's a quick recap of the last few months of API releases:

  • We introduced (and iterated on!) an extensions gallery, making it easier for users to find extensions.

  • We launched
  • Robots API v2 and the Active Robots API, making it easier to integrate with external systems. That release, along with Mashable's Google Wave API Contest, resulted in robots like Ferry for Google Docs integration, Mr. Ray for email integration, and's just-announced Toolkit for for the Google Wave APIs, which shows how developers can bring Google Wave together with the platform and Salesforce Chatter.

  • We released
  • anonymous read-only access for embedded waves, making Wave a more compelling platform for publishing content and discussions on the web, and leading to some live blogging experiments.

And here's what we've announced at I/O:

  • Run robots on any server -- not just App Engine. This means you run robots on your own web servers, and you can use your language of choice, making it significantly easier to write robots that integrate with your existing website and systems. Read more in the docs.
  • Use a robot to manipulate and retrieve attachments within a wave, so you can build something like a wave -> Flickr album converter, a CSV -> interactive map builder, or as we'll be demo'ing live at the I/O talk, a wave -> PowerPoint exporter. Read more in the docs.
  • Use the "Wave This" service to let your website's visitors easily create waves out of the content on your site. You can see an example of it in use with the Wave This Chrome Extension. Read more in the docs.
  • Fetch waves on behalf of users with Wave data APIs to build lightweight clients or apps like what we just launched, the official Google Wave Notifier Chrome Extension. Read more in the docs.

Beyond the API releases, we're also open sourcing a lot more of Google Wave's code, including the rich text editor, so you can learn how to run a wave server, like the one Novell Pulse is working on, and start prototyping with a simple frontend for editing and replying to waves. You can also extend that code to build your own alternative Wave clients. Today, SAP announced that they are working to adopt the Google Wave Federation Protocol in their product, StreamWork. Stay tuned for another blogpost with more pointers and details.

Now, all of this sounds great, but as a developer building on top of a platform, many of you will be most concerned about one thing: users. We've been in invite-only mode for the past year, and built up a loyal user base of about 1 million active users. Today, we will let anyone with a Google account use Google Wave (no more invites!), *and* even better, any company or organization using Google Apps can enable Wave for their domain. So, there should both be more users who want to use your extensions and more businesses that want developers to build extensions for them. Win-win!

We're not done yet, of course. The product and the APIs are in Labs, because we think it's important to stay flexible when creating a whole new paradigm in web based communication and collaboration. We want to be able to respond to your feedback, and we still have a lot left to do to make the vision a reality.

But we think we've made good progress with these improvements, and we invite you to check them out, give us your feedback, and hopefully join us on the rest of this journey.

Posted by Pamela Fox, Developer Relations, Google Wave Team