If you missed any sessions at Google I/O, we’re happy to let you know that beginning tomorrow (Tuesday June 1), videos and slides from all I/O sessions will start going live on code.google.com/io and the GoogleDevelopers YouTube channel.

We’ll be releasing videos by session track per the schedule below. We don’t have specific times to announce, but note that they’ll go live during PDT business hours:

Tues June 1: App Engine, GWT

Wed June 2: Enterprise, Android

Thurs June 3: Google Chrome, Social Web

Fri June 4: Tech Talks, Fireside Chats

Mon June 7: Geo, Google APIs, Google Wave

As each set of videos goes live, we’ll post updates on @googleio and Buzz. Thanks for your patience thus far. Stay tuned!

The Chrome Developer Tools are great for debugging HTML, JavaScript and CSS in Chrome. If you're writing a webpage or even a web app for the Chrome Web Store, you can inspect elements in the DOM, debug live JavaScript, and edit CSS styles directly in the current page. Extensions can make Google Chrome an even better web development environment by providing additional features that you can easily access in your browser. To help developers like you, we created a page that features extensions for web development. We hope you’ll find them useful in creating applications and sites for the web.

For example, Speed Tracer is an extension to help you identify and fix performance issues in your web applications. With Speed Tracer, you can get a better idea of where time is being spent in your application and troubleshoot problems in JavaScript parsing and execution, CSS style, and more.

Another useful extension is the Resolution Test that changes the size of the browser window, so web developers can preview websites in different screen resolutions. It also includes a list of commonly used resolutions, as well as a custom option to input your own resolution.

With the Web Developer extension, you can access additional developer tools such as validation options, page resizing and a CSS elements viewer; all from an additional button in the toolbar.

Another extension you should check out is the Chrome Editor that allows you to easily code within your browser, so you don’t have to flip between your browser and code editor. You can also save a code reference locally to your computer for later use.

If you’ve ever wanted to write desktop or mobile apps for orkut, this open source Java library provides you with that opportunity. Using three-legged OAuth, you can get friends’ profile data, post and retrieve status and activity updates, read and write scraps, create and retrieve photo albums, and upload pictures. To get started, simply download the library, check out the included samples, and start coding.

With this library, it’s easy to have an application up and running with just a few lines of code. The snippet below shows how to create a photo album, share it with your friends, and upload photos:

CreateAlbumTx createAlbum = albumsFactory.createAlbum( "College Days", "The best days of my life!");Album album = createAlbum.getAlbum();albumsFactory.shareAlbumWithFriends(album);

As you develop your application, we’d love if you’d let us know what you create. We’re excited to see how you use this library to integrate orkut with other exciting products and technologies... and in fact, we already started! Take a look at our orkut FotoScrapr app, which we built on Google App Engine using a slick Google Web Toolkit interface. If you like what you see, feel free to browse through the FotoScrapr source code.

And finally, if you’re not a Java developer, don’t worry. We’d be thrilled to work with you to port this library to other languages. Just reach out to us on the orkut developer forum.

So dive in and start coding – we can’t wait to see what you’re going to come up with!

Sound interesting? Here's how you can become a part of it: Attend the Random Hacks of Kindness Hackathon and develop software that saves lives, alleviates suffering and helps communities to recover after natural disasters strike.

Random Hacks of Kindness is a joint effort founded by Google, Yahoo!, Microsoft, NASA and The World Bank, dedicated to bringing software developers together to respond to challenges facing humanity in the area of natural disaster risk. We start with problem definitions created through consultations with NGOs, governments and experts in the field from around the world, then we invite hackers to a come together to organize and go to work putting their skills to use to solve those problems with software solutions that make a difference on the ground. At a RHoK hackathon, new technologies are born, existing platforms are built upon, and innovative new ideas attract attention and support. At the close of the hackathon, teams present the technologies they have developed and prizes are awarded.

The next Random Hacks of Kindness Hackathon is happening in Washington, D.C. from June 4th through 6th, with global satellite events going on around the world in Jakarta, Sydney, Nairobi and Sao Paolo. The evening of June 4th, The State Department is hosting a reception for RHoK to kick off two days of intensive hacking on June 5th and 6th at the Microsoft Offices in Chevy Chase, MD. Check out the full agenda or learn more about the global satellites right here.

Why Do This?

Save the world: You have the skills to make a difference. Hacks developed at the last RHoK hackathon were used on the ground in Haiti and Chile following the devastating earthquakes there in early 2010. The world needs these solutions.

Exposure: Got a new product, idea or technology to share with the hacker community? Put it to work at the hackathon.

Assistance: Extend the function and applicability of your existing products or software through global crowdsourced development.

Input: Get real-time feedback from Subject Matter Experts in software and disaster risk.

Insight: Learn about what other companies and developers are doing in the same space.

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!

Day 2 kicked off early with a keynote featuring Android 2.2 (code name: Froyo), sneak peeks 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. (UPDATE: You can find the Google TV segment here.)

Many teams prepare their products to announce at Google I/O, so there were lots of announcements beyond the keynotes as well, including

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.

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 (http://lucene.apache.org/), 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.

ProblemTaking 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.

SolutionOur 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:

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.

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:

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.

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.

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 is the Google Wave Federation Protocol, 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 gotten?

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.

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.

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.

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.

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 http://code.google.com/apis/latitude 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!

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 onlyAdSense 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 AjaxThe 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.

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.

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.

Google and Typekit believe that web fonts, in conjunction with the richer text styling offered by CSS3 and HTML5, provide the visual richness and high fidelity control of print typography while remaining accessible to machines and devices.

There are still some challenges when using web fonts, and the launch of an open source WebFont Loader addresses one of these difficulties: different browsers treat the download of web fonts differently. For example, Firefox will initially render a website’s text in the site’s fallback font until the web font is downloaded, and then the text will be re-rendered and re-flowed using the downloaded web font. Chrome and Safari won’t display the text until the web font is fully downloaded, and Internet Explorer sometimes won’t render any content at all until the web font is available.

The WebFont Loader puts the developer in control of how web fonts are handled by various browsers. The API fires JavaScript events at certain points, for example when the web font completes downloading. With these events, developers can control how web fonts behave on a site so that they download consistently across all browsers. In addition, developers can set the fallback font's size to more closely match the web font, so content doesn't reflow after loading.

Furthermore, the WebFont Loader is designed to make it easy to switch between different providers of web fonts, including Google, Typekit, and others. The code is modular, and we expect to add modules for other major web font providers in coming weeks.

Google is excited to work with Typekit to further web font technology. We look forward to working with others as well to continue to advance typography on the web.

Today we announced Google App Engine for Business, with a host of new features to help enterprises run their business applications on Google’s infrastructure (read our blog post to learn more). We’re also excited to announce our work with VMware to connect our developer tools, making it possible to create rich, multi-device web applications that can be hosted in a variety of Java-compatible hosting environments. Call it cloud portability for the enterprise -- productively build apps that you can deploy onto Google App Engine for Business, a VMware environment (your vSphere infrastructure, your choice of vCloud partners, or VMforce), or other infrastructure such as Amazon EC2.

As part of this announcement, we’re providing early access to these tools -- you can start using them right now by downloading the latest milestone version of VMware’s SpringSource Tool Suite (STS). If you prefer to wait for the general release, you can sign up to be notified.

Spring RooWith Spring Roo, a next-generation rapid application development tool, Java developers can easily build full applications in minutes, using the Java Persistence API (JPA) to connect to new or existing databases. Roo outputs standard Java code, so it’s easy to refine the back end with the SpringSource Tool Suite and the front end with the Google Web Toolkit SDK, using Roo as much or as little as desired.

Google Web Toolkit SDKNew data presentation widgets in Google Web Toolkit speed development of traditional enterprise applications, increase performance and interactivity for enterprise users, and make it much easier to create engaging mobile apps with a fraction of the investment previously required.

SpringSource Tool SuiteUsing the Eclipse-based SpringSource Tool Suite, developers can now choose to deploy their application in their current VMware vSphere environment, in VMware vCloud, directly to Google App Engine for Business, or elsewhere. We call this cloud portability.

Google Web Toolkit Speed TracerSpeed Tracer now helps developers identify and fix performance problems not only in the client and network portions of their apps, but also on the server. By incorporating server-side time traces from both Spring Insight and Google App Engine AppStats, Speed Tracer provides a consolidated view of where sluggishness actually comes from -- be it client, network, or server -- so it’s much easier to see what to fix.

If you’re building business apps, we hope you’ll find these tools make it easier and more fun to get your job done. Maybe you’ll save time and money by developing and testing apps on App Engine, and then deploying to your VMware environment. Maybe you’ll run a second instance of your apps on App Engine for disaster recovery. Or, maybe you’ll take your existing on-premise apps and extend them to the web and to mobile devices in a fraction of the time it might have otherwise taken. The point is, whatever you decide, you can be confident that it’s possible, and that you’re not locked in.

We’re happy to be working with VMware to bring increased interoperability, portability and choice to enterprise developers. We invite you to download the latest milestone version of STS and try these tools for yourself.

Today we are excited to announce a collection of high quality open source web fonts in the Google Font Directory, and the Google Font API to make them available to everybody on the web. For a long time, the web has lagged print and even other electronic media in typographic sophistication. To enjoy the visual richness of diverse fonts, webmasters have resorted to workarounds such as baking text into images. Thanks to browser support for web fonts, this is rapidly changing. Web fonts, enabled by the CSS3 @font-face standard, are hosted in the cloud and sent to browsers as needed.

Google has been working with a number of talented font designers to produce a varied collection of high quality open source fonts for the Google Font Directory. With the Google Font API, using these fonts on your web page is almost as easy as using the standard set of so-called “web-safe” fonts that come installed on most computers.

The Google Font API provides a simple, cross-browser method for using any font in the Google Font Directory on your web page. The fonts have all the advantages of normal text: in addition to being richer visually, text styled in web fonts is still searchable, scales crisply when zoomed, and is accessible to users using screen readers.

Getting started using the Google Font API is easy. Just add a couple lines of HTML:

The Google Font API hides a lot of complexity behind the scenes. Google’s serving infrastructure takes care of converting the font into a format compatible with any modern browser (including Internet Explorer 6 and up), sends just the styles and weights you select, and the font files and CSS are tuned and optimized for web serving. For example, cache headers are set to maximize the likelihood that the fonts will be served from the browser’s cache with no need for a network roundtrip, even when the same font is linked from different websites.

These fonts also work well with CSS3 and HTML5 styling, including drop shadows, rotation, etc. In addition, selecting these fonts in your CSS works just the same as for locally installed fonts, facilitating clean separation of content and presentation.

The fonts in the Google Font Directory come from a diverse array of designers, including open source developers and highly regarded type designers, and also include the highly acclaimed Droid Sans and Droid Serif fonts, designed by Ascender Corporation as a custom font for Android. We invite you to browse through the directory and get to know the fonts and designers better. Since all the fonts are open source, you can use them any way you like. We also have a separate project hosted on Google Code for downloading the original font files. Since they’re open source, they can be used for just about any purpose, including for print.

We’re hoping designers will contribute many more fonts in coming months to the Google Font Directory. If you’re a designer and are interested in contributing your font, get in touch with us by completing this form.

To showcase the Google Font API, Smashing Magazine has relaunched their site using the open source Droid font hosted by Google. We’re excited about the potential for integrating the Google Font API into many types of publications and web applications. For example, the new themes for Google Spreadsheet forms are a great example of a rich visual experience using web fonts.

This is just the beginning for web fonts. Today, we’re only supporting Western European languages (Latin-1), and we expect to support a number of diverse languages shortly.

We launched Google App Engine two years ago to enable application developers to rapidly build and scale their apps on Google’s infrastructure, without having to worry about maintaining their own servers. Today, we’re excited to bring this platform to IT departments, 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.

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.

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 Roundarch's Technical Architect Greg Knapowski and Sr. Front End Developer Lawrence O’Sullivan who will be demoing as part of the Developer Sandbox.

Our client, NYSTROM Herff Jones Education Division, the leading producer of maps and globes for schools, sees many classrooms replacing chalk boards and wall maps with interactive white boards and laptop computers. Our Roundarch team worked to develop StrataLogica™, a web-based learning application that delivers map and atlas content in an engaging 3D, interactive environment utilizing the Google Earth API.

The Google Earth API was used as a foundation for StrataLogica™ to make use of its sophisticated image rendering logic, satellite imagery and access to built-in tools and navigation controls. As an enterprise scale application, we faced some interesting challenges and gained many insights along the way that we’d like to share.

Our first task was to prove we could wrap Nystrom’s existing educationally-focused maps and globes onto Google Earth while retaining the same high quality resolution delivered in their print products.

Achieving acceptable image resolution resulted in file sizes which were much too large. In addition, we needed to deliver an increased level of map content and granularity of images as the user zoomed into the earth. To address these two issues, we created a custom process that takes an Adobe Illustrator file and outputs Superoverlays in accordance with KML 2.1 standards. Using open source Python frameworks, we created a customized solution that outputs Superoverlays with various levels of content.

Our next challenge was to provide support for authoring and maintaining content, in the browser, using the Google Earth plugin. All content is authored and maintained in a content management system (CMS) in much the same way as any dynamic website. One unique difference is that some of the content elements are geo-referenced coordinates that specify the location of content on earth. In the case of placemark balloons, the geo-referenced coordinates identify “hotspots” on the Nystrom maps which become clickable when the user turns on a setting. The placemark balloons provide supplementary audio, image, video and descriptive content such as the example shown above for the Appalachian Mountains.

An ETL (extract, transform, load) process is used to transfer published content into the StrataLogica™ application database. We then use Java Server Pages (JSPs) to generate the KML which renders the placemark balloons. The KML contains both the “hotspot” coordinates and embedded HTML to display the audio, video, images and text. This example illustrates that standard web technologies can be used to deliver content through the Google Earth API with the exception that KML is generated in addition to HTML.

Once Nystrom was able to see their maps and content rendered on Google Earth through the plug-in, we needed to create a compelling and immersive educational experience to allow teachers and students to interact with maps, not just view them. Our team added features such as marking tools, custom content authoring tools and the ability for users to share and collaborate. For those of you attending Google I/O, stop by our booth in the Sandbox space to experience StrataLogica™ firsthand and chat with our team about the front-end development challenges we faced and how we overcame them. If you aren’t attending we encourage you to check out our blog post at http://blog.roundarch.com where we share more about how we developed StrataLogica™.

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 Adam Kalsey, Developer Evangelist at Voxeo Developer Network, who will be demoing as part of the Developer Sandbox.

Connecting to your customers via voice, SMS, or even IM allows you to reach them when they aren't at their desks. These real-time communications mediums are skyrocketing in usage and ubiquity, as what is more ubiquitous than the phone? Building an application that works over the phone or instant messaging is easier than you think.

Telephony has traditionally required complicated hardware and software or specialized programming languages. In recent years, however, web programming tools and models ranging from VoiceXML to web services APIs have made it easy for any developer to create communications services.

Companies for years have been providing customer self-service applications as Interactive Voice Response (IVR) systems as a way of boosting customer satisfaction while cutting service costs. These techniques and tools are starting to make their way into other mediums and at the same time are coming down in price, making them accessible to a whole new class of developers. This is leading to some great innovation as developers find creative ways to weave phones and text into their applications.

It's not just voice. A rising percentage of the population is just as likely to communicate over text messaging, IM, and social networks as they are to pick up the phone. APIs and customer-self service systems must adapt to the preferences of the customers they want to help. Over the next decade, 50% of the automated communications that today happens over the telephone will shift to other mediums. It's important for the applications you develop to serve your customers tobe available on the networks they choose to use.

Here's how an IVR application might work over instant messaging. Your company provides a Jabber IM address for people to contact you. Any of your customers using Google Talk can strike up a conversation. Your code intercepts their message and routes it to the right department based on the keywords used in the chat. Perhaps you even respond off hours letting people know when your agents are available or answer common questions automatically from a knowledge base.

Have you ever wanted your Google Talk number to be answered by your code? When your friends call, you'd like to pick it up, and when telemarketers call, you’d like it to go straight to voicemail. In addition to accepting calls, your application can make calls, sending appointment reminders or triggering alerts using only a few lines of code. You can even set the caller ID of the outbound call to your Google Voice number so that return calls come to you.

To demonstrate how easy it is for a developer to weave voice and text into their application, lets look at a sample application running on our Tropo cloud communications platform.

We've created a mashup for the San Francisco Bay Area Rapid Transit (BART) schedules so you can see when the next train is due to arrive at the station of your choice. Call or SMS (407) 374-9954 or send an IM to bartdemo@tropo.im with Google Talk to try it. You can even talk to @tropobart on Twitter. Tropo treats Twitter as an IM network, sending all @mentions to your application just like an instant message would be.

Tropo works by converting phone calls, IMs, and text messages to API calls that your code works with. An incoming call or message is delivered to your code and your code tells Tropo what to say back.

Real-time communications APIs for voice allow you to give instructions to the phone system and IM networks to answer or make calls, accept text messages, interact with your users using speech synthesis and speech recognition, set up conferences, or just about anything else you can think of and mash it up with Google technologies, like this Wave robot that adds conference calls to any Wave.

To learn more about building voice and text applications and the real-time communications APIs that are available to you, visit Voxeo in the Google I/O Developer Sandbox or visit the Voxeo blog and Tropo blog.

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 Jeremy Glassenberg from Box.net, who will be demoing as part of the Developer Sandbox.

Google's rich platform for developers is matched only by its variety of innovative web services. So when working with Google APIs, why use only one or two Google services?

When launching with the Google Apps Marketplace in March, Box.net could see opportunities in connecting with Google services across the board, from sharing files in Gmail to enhancing collaboration in Google Sites. But how could we connect to half a dozen different services, while making the interaction with a partner completely seamless and easy to use?

Luckily, for those who want to go all-out on the Google platform, Google's diverse APIs provide what you need to code efficiently, and organized to connect everything in a way that makes sense. Here is what we’ve found helpful to help you optimize your development experience:

1. Standards across APIs

By leveraging Google's support for the OpenID and Oauth protocols, we can not only connect Google users to access Box.net easily, but also to make all features of Google accessible from Box. This way, when Google Apps accounts connect to Box, we can automatically connect users to Google Docs, Google Sites, Google Calendar and Gmail through the magic of a secure, centralized single sign-on process.

2. APIs and Gadgets make for a seamless integration

We wanted to make it easy for users to access services like Gmail and Google Docs from within Box. With our OpenBox Developer Platform, we could make those Google services accessible through our simple file menu. Users could right-click on a file, and choose to "Share in Gmail", "Edit with Google Docs", etc. But we wanted to go even further, and integrate "inside and out" - making Google accessible in Box, and Box accessible in Google's services. This was made possible with Google Gadgets.

By adjusting gadgets we made for OpenSocial partners such as LinkedIn, we could easily create Box.net gadgets that also work with iGoogle, Google Sites, and even Gmail Labs and Google Calendar Labs. These "Box.net inside Google" gadgets became surprisingly popular among new users.

We even found it possible to connect Google services together more deeply through these two-way integrations. By making our OpenBox features available in our Google Gadgets, our users could edit a document from Box in Google Docs, or share a file into Google Sites, from within the Gmail sidebar.

3. Focus on user experience

With multiple connections to Google services in Box, and the placement of Box.net inside four Google services via Google Gadgets, this became an exciting engineering project. But we couldn't forget that everything needed to work in a straightforward, easy-to-use manner for businesses in Google Apps. Luckily, Google Apps' design and installation process for the Marketplace helps to bring just about everything together for the user.

The installation process enables you to obtain the OpenID information for a Google Apps administrator, access rights to various Google APIs, and connect users in the same Google Apps domains automatically. This sounds great for your code, but pay attention to the user experience. Google Apps administrators need to understand what they're about to make accessible to their users. Sub-users of the Apps account need to be able to sign up easily as well.

Users and administrators will also want to choose which services to use. In our case, some users wanted to edit Google Docs in Box.net, while others just want to access Box.net from within Gmail or Google Sites. Thus, just like within Google Apps' administrative console, Box.net made individual components easy to enable and disable. We also provided detailed instructions for adding and using each piece of the integration.

---

At Box, we look forward to continuing work with Google, integrating even more deeply as Box.net and Google both expand our platforms.

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 Jim McNelis, co-founder and principal of Dito, who will be demoing as part of the Developer Sandbox.

As an early Google Apps Authorized Resellers, Dito, an IT services company I co-founded in 2007, has become a trusted advisor to a diverse group of organizations using Google Apps. We’ve established strong relationships with each of our customers and are a go-to source for information on specific features and functionality, best practices, and work flow processes. This gives us a unique insight into end-users’ needs as they ramp up on Google Apps, and we continually work to improve our service offerings and our customers’ experiences.

Over time, we compiled feedback from our clients and noticed an interesting trend - customers wanted a better way to manage their shared contacts within Google Apps. Out of the box, Google Apps handles shared contact management via API’s, as opposed to a Graphical User Interface (GUI) which is most common. Many small organizations don’t have the resources to develop a solution to interface with API’s. So, we decided to develop one for them that could easily integrate with Google Apps to allow administrators to manage, and end-users to browse and search, shared contacts within their domain.

We appreciate the reliability and scalability of cloud-based solutions and wanted our application to live “in the cloud” as well. After extensive research, we determined that Google App Engine was the right platform for our application since it works seamlessly with other products and tools within the Google ecosystem like Google Web Toolkit and the Google Apps APIs. From there, we set out to develop our app: Dito Directory for Google Apps.

Dito Directory represented Dito’s first foray into the development business. Sure, our developers had years of experience, but our team was new and we were preparing to develop apps on the bleeding edge of technology. In years prior, developing an application with this functionality and accessibility would have been an expensive and exhaustive process which would have required client-side application development and everything that goes with it.

Google App Engine and the Google Apps Marketplace erased these challenges and provide us with a simple yet elegant platform and distribution channel to deliver our application to the masses. From concept to delivery, the application took two developers less than four months to complete - just in time for the launch of the Google Apps Marketplace.

Since then, almost 1000 Google Apps admins have installed Dito Directory on their domain resulting in numerous happy admins and end-users. I hate to say it, but it wasn’t hard to get 1000 people to install our app either. We basically relied on our existing customer base and the popularity of the Google Apps Marketplace to advertise our apps. There has been not been a significant marketing push or advertising dollar spent...we simply developed the application, launched it on the marketplace, and now watch about 15 domains install Dito Directory every day.

With all of the installs, we received great feedback from our customers, and our team continues to improve the functionality and performance of the app. As a result, Directory continues to evolve to meet customers needs. We don’t have to guess what users want, we simply listen to what they have to say and iterate accordingly. And since our app is cloud-based, upgrades are easy. There is no additional software to install. After we release new features, simply refresh your browser and the app is updated.

During Google I/O this week, our team will showcase Dito Directory in the Enterprise pod at the Developer Sandbox. If you’re attending the conference, please stop by to chat about our app, give us feedback, or just say hello. We’ll also be giving away the paid version of our app to 10 lucky winners at the conference, and other exciting prizes. I hope to see you there.

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 Ryan Massie, Product Manager at Clicker.com who will be demoing as part of the Developer Sandbox.

Over the years, the technical gap between engineering for the Web and engineering for an operating system has continued to narrow. Third party plug-ins led the way in this progression, until their services eventually became standardized and built into the browser itself. Now, using HTML5, we're outgrowing many of the limitations that came with developing for a specific OS or device, enabling us to create next generation user-experiences that bring more utility to more platforms than ever before.

In general, building for the Web enables us to be more agile. By establishing implementation guidelines for video, animation, audio and storage, HTML5 further reduces the level of fragmentation across the Web, empowering developers to efficiently build rich, browser-based experiences of superior quality.

For us here at Clicker, that means opportunities to create more unique and immersive experiences that guide users to the premium-quality TV shows, movies, music videos and Web originals available to watch online. Using HTML5, we’re able to offer more innovative in-browser experiences with movement and reflections while providing a faster performance.

One reason the Web is an amazing platform is because changes made to a given website are instantaneous and can be viewed by anyone in the world with an Internet connection. By creating browser-based utilities, optimized for various screens and devices, we can continue to create consistent, reliable and scalable experiences that push the boundaries of what people can do online, making the Web an increasingly more interesting place. And as developers, it's important to make the Open Web a success. HTML5 and other advancements give us more opportunities to stretch the boundaries of what we can enable people to do. And, without the hindrance of downloads and the added benefit of increased browser speed, consumers will increasingly expect rich, browser-based experiences. This end-user demand will continue to spur the overall pace of innovation and development on the Open Web.

We look forward to meeting fellow developers and continuing the conversation in person at I/O this week!

Following the sneak preview of Gmail contextual gadgets during the launch of the Google Apps Marketplace, we announced a limited trusted tester period for those who couldn’t wait to get started. We were pleased with the overwhelming interest in the API, and were able to invite a select group of developers to participate.

We are happy to announce that the Gmail contextual gadgets API is available to all Google Apps Marketplace developers today. For more on how to get started, check out the documentation and read the full announcement on the Google Enterprise Blog.

For anyone interested in a deep-dive on Gmail contextual gadgets, make sure to check out my session at Google I/O!

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 myERP.com’s Francois Nadal (CEO) and Thomas Ricard (CTO) who will be demoing as part of the Developer Sandbox.

Our all-in-one business suite includes all the functions a company needs to run their business from CRM to accounting to supply chain management. We've gotten a tremendous response from customers: in less than 3 weeks, we signed up more than 3,000 new small and medium customers.

Getting started was not easy. First, we had to convert our Java application to the cloud, using Google Web Toolkit (GWT). It was a task that took us nearly 2 years to complete — we launched the first released of our ERP in the cloud in late 2008. It attracted the interest of Google engineers who subsequently invited us to present at the Google I/O 2009 developer conference in San Francisco.

To prepare for the Google Apps Marketplace launch, we started modifying our codebase. There were two very separate tasks to achieve. The first one was to OpenID-enable myERP.com, and more specifically SSO-enable it. A Google Apps user should never be asked to enter his or her credentials to login to myERP.com. When you work with Google, you have to focus even more than you are used to on the user experience. The user should never see the underlying technology and just navigate from his Gmail inbox or his Google Calendar to myERP.com as if everything was a single application. That was the toughest part to do, since our application was not ready for it. So, we did a lot of refactoring. We're proud today to use our myERP.com software through our own Google Apps account.

The second part was easier since we were already integrated with Google Contacts and Calendar long before the Google Apps Marketplace. The main change was that we used to ask individual users for their credentials, which was a security risk. Now, we use OAuth. This development took us 2 weeks. We currently use the Google Contacts API to retrieve (import), create, update and delete customers created in myERP.com. We also use the Provisioning API to synchronize accounts in myERP.com with accounts in Google Apps. MyERP.com now lets customers use Gmail and Calendar to manage their Business Actions. Our next Google Apps development will focus on Google Docs: frequently requested features include exporting data to a Google Spreadsheet and putting an invoice in a Google Document.

We will be demoing in the Developer Sandbox at Google I/O, and we look forward to seeing you there!

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 Amit Kulkarni, Co-Founder and CEO of Manymoon, who will be demoing as part of the Developer Sandbox.

Manymoon is a free social productivity tool that helps teams manage and share projects, tasks and conversations. We became part of the Google Apps Marketplace at launch and have seen tremendous early success. Over 1,000 new businesses sign up each week, making us one of the top apps in the Marketplace. Below are some of our tips for building a successful app:

1. Define the problem - and make sure it's a big one!For us, that was all the communication that gets lost in email. We thought email is great for notifications and is great ... as of 10 years ago.But the internet is now social and about communicating for fun and work and both! And Google Apps has 25 million users and is signing up over 3000 new businesses a day.We realized there was a significant opportunity.

2. Simplicity SticksBuilding a web app is different than building an enterprise app. The premium is on intuitiveness and ease of use. You've lost if the user has to read a manual, FAQ or go through a tutorial. User attention spans are short and it's critical for them to get up to speed in minutes. And that meant starting with something very simple: sharing tasks and projects.

3. Focus on What You're Great AtWhile in private beta, we had numerous customers asking for the ability to add documents to tasks and projects. The more we discussed with customers the more we realized that they were asking for features outside of our core vision. For example, they were asking for things like version control and co-browsing. This would have taken us months to build and is a whole different startup in fact! Instead, we decided to integrate with the Google Docs APIs. From a technical perspective, it provided us with the features our private beta users needed and it only took us a few weeks to complete! We immediately saw significant traction with users since our daily visits increased by 300%.

As we receive feature requests from users, we always look to see how we can integrate existing Google Apps to provide a better user experience. Another great example is our calendar feature. Customers were asking for a graphical calendar feature that included all necessary project information: open tasks, events and milestones. We were able to use the Google Calendar API and in just a few days provide this feature to users. We did this by using the API to automate multiple steps: create a calendar, share it with people and seamlessly update it with the latest project information.

4. Re-Use and Drive EngagementOne major benefit of using Google APIs was the way it reduced the friction to get users engaged. We did this by re-using each user's existing data in Manymoon! Specifically, a user can use Manymoon for tasks and projects that immediately work with their existing Google Docs, Google Calendars, Google Sites and Google Accounts (including OpenID). This dramatically reduces the barrier to the user trying a new app and increases relevance (since their existing data is available within the app).

I'm returning to host Ignite at Moscone West for the third Google I/O on Wednesday at 4pm PST (here's the wave). The short talks will be a mixture of tech culture, tech achievements and tech challenges. Our nine speakers will be the perfect cap to the Day 1 of the conference. Each speaker will have just 5 minutes to tell their tale via 20 slides that auto-advance every 15 seconds.

In case you want to brush up on Ignite before Google I/O, you can peruse the Ignite Show video site. Ignite is in over a hundred cities world-wide, and we collect as many of the talks as we can at www.igniteshow.com.