Tuesday, 23 December 2008
Facebook StumbleUpon Twitter Google+ Pin It

2008 Year in Review

Before looking back on this past year, we'd like to thank the developer community for your involvement and enthusiasm in 2008. Without you none of our accomplishments would've been possible and coming to work would not have been nearly as rewarding or exciting.

In 2008 the developer team at Google made it significantly easier for developers to build increasingly sophisticated web apps. Looking back, some of the most notable events from the last year include the App Engine launch, GWT 1.5 launch, Chrome launch, AJAX Language API launch, AJAX Libraries API launch and the broad adoption of OpenSocial.

We also worked hard to make it simple to integrate and extend Google applications through the launch of the You Tube API, Visualization API, Maps for Flash API, Finance API and Custom Search API.

We were also really happy to participate in the Open Handset Alliance where we saw the announcement of the Android Developer Challenge winners, the Android 1.0 SDK launch, and the first app downloads in the Android Market.

Our favorite part of 2008, however, was interacting with you at Google I/O and at Developer Days. These events allowed us to meet inspirational developers in 15 countries around the world who are building fantastic applications.

In 2009, we look forward to building products to make the web better and that let you, the developer community, build better apps on the web. We are already excited about seeing you at events next year.

Happy Holidays from the Google Developer Team.

Tuesday, 16 December 2008
Facebook StumbleUpon Twitter Google+ Pin It

App Engine's System Status Dashboard

We recently announced a System Status Dashboard for Google App Engine. As developers depend on App Engine for important applications, we wanted to provide more visibility into App Engine's availability and performance.

Application development today is pretty different than it was just a few years ago. Most web apps now make use of hosted third-party services for features like search, maps, video, or translation (e.g., our AJAX APIs). These services mean developers don't have to invest in massive computing resources to build these features themselves, and can instead focus on what is exciting and new about their apps.

Building in dependencies to third-party services or moving to a new hosting infrastructure is not something developers take lightly. This new App Engine dashboard provides some of the same monitoring data that we use internally, so you can make informed decisions about your hosting infrastructure.

Learn more (about this and other recent announcements) in the App Engine blog and please let us know what you think.

Friday, 12 December 2008
Facebook StumbleUpon Twitter Google+ Pin It

Happy holidays from Google Code!

Matt Hansen

At Google Code, we are getting into the holiday spirit early. To thank open source developers for their support, I'm happy to announce that we are giving every project on Google Code a whole lot more quota!

We're increasing the maximum file sizes from 20MB to 40MB, Subversion quotas from 100MB to 1GB, and download quotas from 100MB to 2GB.
Happy holidays!

P.S. If you need more space, let us know!

Thursday, 11 December 2008
Facebook StumbleUpon Twitter Google+ Pin It

Google Web Toolkit out in the wild

Since Google Web Toolkit (GWT) launched, there have been many rich, robust Ajax applications which developers have told us they wouldn't have been able to build without GWT. We're thrilled to hear that GWT has increased productivity for developers and helped them to improve performance of their AJAX apps. On that note, we'd like to introduce you to 4 developers across a diverse range of web apps -- all of which were built with GWT. Whether you're new to GWT or not, these developers share some great insight into how they used GWT, what they like and would like to see from GWT, and finally their own learnings from building with GWT.

These developer videos, as well as descriptions of other GWT-built apps, are available here: Who's Using GWT. And if you're interested in the latest on GWT, check out the Official Google Web Toolkit Blog.

*Viewing tip: While we've embedded the videos here, we highly recommend watching them directly on YouTube and choosing the "watch in HD" option.

GoGrid is a cloud computing infrastructure service provider which enables you to deploy and scale load-balanced cloud server networks via a multi-server control panel. GoGrid was recently named Best In Show at LinuxWorld 2008. "We wanted to build a thick client inside the browser... GWT is very powerful and has increased our productivity greatly... We're able to build a very complex, rich, UI application quickly and easily." - Justin Kitagawa, GoGrid

Lombardi Blueprint is a business process mapping and diagramming tool. "We don't have to worry about all the browser quirks that you fight with when you're writing in pure javascript. We just write in the language that we like to use and they take care of all the difficult bits for us." - Alex Moffat, Lombardi Blueprint

scenechronize is a production management web application for film, television and commercials. "We chose to use GWT because it allowed us to write in Java which opened up a wide range of tools available for Java-based apps.... Because GWT supports multiple browsers, we're able to write our app so it looks and works the same across 4 major browser types." - Rob Powers, Scenechronize

Whirled is a social virtual world website which includes multi-player games. "We used GWT to build the social networking website part of Whirled, and it's done a lot of the heavy lifting for us... Whirled is now about 60K lines of code just for the client. Being able to enforce the same kind of engineering discipline that we do everywhere else has been a huge help." - Michael Bayne, Whirled

YouTube <3's Developers

There's been a small flurry of announcements lately about things the YouTube APIs team has done to make life easier for our developers, and we wanted to make sure you heard about them!

Backwards compatibility guidelines
Since we just launched V2 of the API, we also published some guidelines and best practices to help ensure that breaking changes aren't introduced into your app with new versions. Read more in our "Mandate For Change" post.

Test your apps against new builds
A week before new builds are pushed to production, they'll go up on stage.gdata.youtube.com. Subscribe to our announcement forum to get notified about new builds, and do regression testing by pointing your app at stage.gdata.youtube.com. Read more in our "All the World's a Stage" post.

Interactive query generator
We released a helpful tool to play with API requests in the browser so you can get a feel for the mechanics. Because we show you the raw request and responses, it's also an easy way to do some quick testing and debugging. Read the full announcement in our "Try Before You Buy" post.

YouTube App Gallery
To help get you get some exposure and to help new developers get some inspiration, we launched the gallery. Browse, comment, and rate projects as well as submit your own. Read the full announcement here.

We hope this helps both new and old YouTube developers alike. Let us know how it's going in the discussion forum.

Tuesday, 9 December 2008
Facebook StumbleUpon Twitter Google+ Pin It

Increased code search coverage, now with Git and Mercurial support

Ali Pasha

At Google Code search, we've seen distributed version control systems get more popular. Linux has been using one for several years and several large open source projects have migrated to using one in the last few years. In recognition of that, we are now announcing that we crawl Git and Mercurial repositories.

For Git, we now crawl repositories hosted by several public git hosting sites including GitHub and repo.or.cz. In addition to that, we also crawl Android, Chromium and Linux code.
For Mercurial repositories, we now crawl most popular open source repositories including Mozilla, JDK, and NetBeans.
Finally, we have also extended coverage to support Codeplex: System.ServiceModel package:codeplex.com

Feel free to provide feedback to let us know how we're doing.

Google Visualization API Library now available for Google Web Toolkit

We're happy to announce the Google Visualization API Library for Google Web Toolkit (GWT). This has been a requested addition to GWT for some time now on the developer forum and we are excited to make it available.

You can now utilize the visualization and reporting capabilities of the Google Visualization API while writing native Java code for your GWT applications and enjoy the best of both worlds. The library includes wrappers for many of Google's visualizations, such as Bar Chart, Annotated Time Line, Map, Motion Chart, Organizational Chart and many others. We have marked all the visualizations that are currently supported by this library in the Visualization Gallery.

The library also includes classes that enable you to easily wrap any existing Visualization API-compliant visualization in GWT so that you can access it from Java complied by the GWT compiler. So if you want to wrap your own visualization or the nifty Piles of Money visualization, you can easily do so.

Lastly, the library includes a class that makes it easy to write new visualizations in GWT-compiled Java and make it available as JS for general use in the Visualization API. This is cool if you've been itching to contribute new visualizations but prefer coding in Java.

Here is example code that draws the well known Annotated Time Line chart in Java using the new Visualization API Library:

UPDATE: Changed the code font size to fit on one line so you can copy & paste

package com.blogpost.client;

import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.Window;
import com.google.gwt.user.client.ui.RootPanel;
import com.google.gwt.visualization.client.AjaxLoader;
import com.google.gwt.visualization.client.DataTable;
import com.google.gwt.visualization.client.Query;
import com.google.gwt.visualization.client.QueryResponse;
import com.google.gwt.visualization.client.Query.Callback;
import com.google.gwt.visualization.client.visualizations.AnnotatedTimeLine;

public class BlogPost implements EntryPoint {
public void onModuleLoad() {
AjaxLoader.loadVisualizationApi(new Runnable(){
public void run() {
Query query =
query.send(new Callback(){

public void onResponse(QueryResponse response) {
if (response.isError()) {
Window.alert("An error occured: " + response.getDetailedMessage());

DataTable data = response.getDataTable();
AnnotatedTimeLine.Options options = AnnotatedTimeLine.Options.create();
RootPanel.get().add(new AnnotatedTimeLine(data, options, "800px", "400px"));
}}, AnnotatedTimeLine.PACKAGE);

This code draws the same visualization that can be seen in the example for Annotated Time Line in the Visualization Gadget Gallery. Both get their data from Google Spreadsheets, only this code does so in Java instead of Javascript or as a Gadget.


Monday, 8 December 2008
Facebook StumbleUpon Twitter Google+ Pin It

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

By Brad Chen, Native Client Team

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

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

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

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

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

Google Chart API all spruced up

It's nearly a year now since the Google Chart API was launched, and we've got some treats for you to celebrate!

We've added several new options for adding markers to your chart, including financial markers, which lots of you have been asking for!

And you can now use invisible guide data sets to position markers accurately on your chart. Anyone who's got independent data lines on their wishlist - this one is for you!

If you were looking for concentric pie charts, or the ability to control the orientation of your pie chart, you're in luck!

Other new features include
  • Control for axis lines and tick marks
  • Data labels
  • Margin control
  • Automatic spacing for bar charts

You can read more about all of these features, and the updates we've made to the existing features, on the Chart API site.

Salesforce.com announces Force.com for App Engine

This morning Salesforce.com announced Force.com for Google App Engine, a Python library for apps running on App Engine that enables simple and robust access to the Force.com Web services API. Using this library, App Engine developers can now build and deploy scalable web apps that manipulate and display data stored on Force.com. App Engine developers interested in building enterprise-class applications can now build anything from browser-based tools for members of your organization to personalized, customer-focused apps that scale to meet demand.

To learn more about Force.com, you can visit the Force.com documentation. To learn more about App Engine, check out our docs or visit the App Engine Google Group!

Tuesday, 2 December 2008
Facebook StumbleUpon Twitter Google+ Pin It

User Experience in the Identity Community

By Eric Sachs and Ben Laurie, Google Security Team

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

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

[Also posted on the Google Online Security Blog.]