Tuesday, December 23, 2008

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, December 16, 2008

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, December 12, 2008

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, December 11, 2008

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, December 09, 2008

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.create("http://spreadsheets.google.com/pub?key=pCQbetd-CptH5QNY89vLtAg");
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();
options.setDisplayAnnotations(true);
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.

Enjoy!

Monday, December 08, 2008

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, December 02, 2008

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

Tuesday, November 25, 2008

Adding some style to the wiki on Google Code



Based on user feedback, we added a few highly requested features to the project hosting wiki on Google Code.

To improve navigation from one wiki page to another, we added side navigation across wiki pages (e.g doctype docs). You can add a 'Wiki sidebar' by specifying the wiki file that describes your side navigation in the Administration tab under Wiki settings.
To help navigate a wiki page, we added the ability to add a generated table of contents. To add a table of contents, just copy the following syntax to your wiki page.
<wiki:toc max_depth="1" />
Finally, to improve the style of your wiki pages we have added some html support. For more information on what html is supported, take a look at the documentation.

As always, we look forward to your feedback.

Monday, November 17, 2008

Google Developer Days 2008 have come to an end





We've concluded Google Developer Days 2008, a set of one-day developer events. They started in Yokohama, Japan on June 10 and ended in Tel Aviv, Israel on November 2. Attendees had the opportunity to learn about products such as Android, Chrome, OpenSocial, and App Engine and interacted with Google developers in hands-on code labs.

We posted the presentations and photos; hopefully they'll continue to be a useful resource for you. Thanks for making these such great events!

Friday, November 14, 2008

A Toast to Code Jam 2008



Cheers to the 100 Code Jammers who made it to the Code Jam finals in Mountain View today! We hope you enjoyed the competition as much as we enjoyed seeing you type furiously, solve ridiculously challenging puzzles, and meet other programming pros. Speaking of pros, a team that included past Code Jam winners used their 20% time to create a new platform that allowed everyone to program in the language of their choice. It was, as you know, a long road to the last round of Code Jam. More than 11,000 of you participated in online rounds, 500 semi-finalists reached the regional stage and 100 finalists from 23 different countries competed this morning. We're pleased to finally announce the day's results: Tiancheng Lou of China took home the $10,000 Grand Prize. Zeyuan Zhu from China won second place, Bruce Merry from United Kingdom came in third and cash prizes went to the other finalists.

Congrats to all and see you at the next Jam!

Improving the issue tracker for larger projects



When we created the issue tracker for Project hosting on Google Code our goal was to keep things simple. We had found that most issue trackers include too many fields and options that aren't applicable to a given issue. As a result, we intentionally did not implement issue relationships like is-blocked-on and is-duplicate-of. For most of the projects that we host, simply adding a comment that mentions the other issue is enough information to get the job done.

Now we host more large projects, and some projects that started small with us have grown large. So, starting today, we are offering a formal 'Blocked on' field. And, when you close an issue as 'Duplicate', you can merge it into the original issue. For more information, take a look at our issue tracker documentation.

For projects that regularly triage issues, you can now pick where to go after you have finished updating an issue.

We hope that these changes help make the issue tracker as easy to use on larger projects as it is for smaller ones.

As always, we look forward to your feedback.

Tuesday, November 04, 2008

Get Out and Vote! (on Google Code)



This election season, the Google Code Team has been inspired by democracy. We have been looking at code.google.com and thinking about ways to make the site better for our users. For example, we updated the homepage a few weeks ago to make it easier to find some of our most popular products. However, we wanted to give our users the right to vote. So, when Google Moderator was released to the public, we thought it would be the perfect tool to get your feedback and ideas. The best part is that you can vote on good ideas so they move to the top of the list and vote against bad ideas so they don't. We added a feedback link in the footer on Google Code, but you can get started using the link below.

Vote on Google Code!

We plan to review your feedback to help us prioritize improvements to Google Code. We'll also respond periodically to the highest rated comments in the Google Code Blog.

So get out and vote on Google Code!

Announcing the Google Search Appliance virtual edition for developers



Ever wanted to write code against Google search technology, test your apps, and see how it all integrates into your development environment without having to pay a thing? If you're an IT administrator, you'll have that chance with the new virtual edition of the Google Search Appliance. The Google Search Appliance virtual edition is for non-commercial, development purposes only, and gives developers the opportunity to test against the features of the physical Google Search Appliance.

The Google Search Appliance virtual edition provides a free test bed for the Google Search Appliance - our solution for securely searching enterprise content behind the corporate firewall - helping ensure a smooth transition to the production-ready hardware. If your organization is considering adopting an enterprise search solution, the virtual edition platform gives your team the flexibility to build applications against the Google Search Appliance, try different configuration scenarios, explore proofs-of-concept and test the APIs supported by Google enterprise search technology. As part of testing with the virtual edition, you can:
These features might come in handy, particularly if your existing environment contains the array of legacy systems, databases, servers and integration architecture typical of most large organizations. And because it's free, your boss might give you an extra week's vacation just for trying it out (don't quote us on that). You can download Google Search Appliance virtual edition software onto any server that is supported by VMWare virtualization. To learn more and get started, click here. And since we always love feedback, feel free to drop by our developer community or send your thoughts to enterprise-gsa-virtual@google.com.

Monday, November 03, 2008

Introducing Powerful Visualizations for your server-side data



Today, we're publicly documenting the Google Visualization API's open-wire protocol, thus dramatically expanding the capabilities of this API beyond what had been available since we first launched in March of this year. Organizations can now expose their server-side data, such as in SQL databases and even in Excel spreadsheets, and display this data through visualizations from our growing directory. This flexibility makes it possible to connect easily almost any data source to a wealth of 40+ visualizations, including standard pie and line charts and complex heat maps and motion charts.

To make it even easier for developers to get started, we have documented an open-source Python library that enables any Python developer to quickly start using the API. What we find particularly cool about this library is that it also runs on Google's AppEngine. You don't even need to be an owner of your own servers to expose your data: You can place it on AppEngine and use the Visualization API to expose your data in meaningful, insightful ways in dashboards and reports. Expect to see additional server-side tools for the Visualization API in the near future.

Moreover, this week at the Dreamforce conference, Salesforce announced they've created tools, including code snippets and API harnesses, to make the Google Visualization API even easier to use. Salesforce customers can now quickly and easily add dashboards and custom reporting applications over their Salesforce data and publish these on any webpage. ISVs and BI firms such as Panorama and Conceptual Clarity, who are already marketing their powerful reporting tools over Google Spreadsheets using the Visualization API, now have access to Salesforce customers. The icing on the cake: since they use the Visualization API, they can address this new market without adding new code to their existing applications.

To learn more about how to implement your data store as a Visualization API data source, by checking out our documentation.

Thursday, October 30, 2008

Moving another step closer to single-sign on

By Eric Sachs, Google Security Team

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

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

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

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

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

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

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

Wednesday, October 29, 2008

Google moves towards single sign-on with OpenID



Currently users are required to create individual passwords for many websites they visit, but users would prefer to avoid this step so they could visits websites more easily. Similarly, many websites on the Internet have asked for a way to enable users to log into their sites without forcing them to create another password. If users could log into sites without needing another password, it would allow websites to provide a more personalized experience to their users.

In September we announced some research that we shared as part of an effort by the OpenID community to evaluate the user experience of federated login. Other companies like Yahoo have also published their user research. Starting today, we are providing limited access to an API for an OpenID identity provider that is based on the user experience research of the OpenID community. Websites can now allow Google Account users to login to their website by using the OpenID protocol. We hope the continued evolution of both the technical features of OpenID, as well as the improvements in user experience. will lead to a solution that can be widely deployed for federated login. One of the companies using this new service is www.zoho.com. Raju Vegesna at ZoHo says that "We now offer all our users the ability to login to ZoHo using their Google Account to avoid the need to create yet another login and password."

The initial version of the API will use the OpenID 2.0 protocol to enable websites to validate the identity of a Google Account user, including the optional ability to request the user's e-mail address. Below is an example of the flow that a user might see if he or she starts at a website that uses this new feature:

The website could use a modified login box that looks like the one below. If the user enters a Gmail address and indicates that he or she does not have a password for this site, then the site can redirect him or her to Google.



The user would then be taken to the Google website and asked to confirm whether he or she wants to sign in to KidMallPics.



Finally, the user would be redirected back to KidMallPics, where he or she would be immediately signed in.



More information about this new API can be found on the Open ID page in Google Code. To request access to the limited trial, please visit our Google Federated Login discussion group and register using the online registration form.

Google is also working with the open source community on ways to combine the OAuth and OpenID protocol in the future. That way a website can not only request the user's identity and e-mail address, but can also request access to information available via OAuth-enabled APIs such as Google Data APIs as well as standard data formats such as Portable Contacts and OpenSocial REST APIs. In the future, this should allow a website to immediately provide a much more streamlined, personalized and socially relevant experience for users when they log in to trusted websites.

Friday, October 24, 2008

Looks Good To Me, Part Deux -- Assigned Code Reviewers



In our continuing effort to improve project hosting, we have just launched a new code review feature called "assigned reviews". Assigned reviews builds on the post-commit source code review tool we announced back in July, providing your team a more structured approach to soliciting feedback and improving the quality of your code base.

Now projects that use code reviews have two choices: post-commit reviews for code reviews after submission, and assigned code reviews for all code heading into trunk. Of course, you can also not use any reviews at all. Use whatever style or styles that work best for your team.

How does it work? Simple. Commit your code to a branch of your choosing, then create a new "Type-Review" Issue requesting that another team member do a code review for your branch. Review requests can be labeled, commented on, and assigned (or reassigned) like any other issue. Once created, review requests show up both in your project's issue tracker, and in a new table at the top of your project's recent source code changes list. Check it out:



For detailed instructions, see the code review tool documentation.

Be on the lookout for more improvements to the review process in the future. Happy reviewing!

Tuesday, October 21, 2008

Introducing the Gears Geolocation API for all laptop WiFi users

By Charles Wiles, Product Manager, Google Mobile Team

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



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

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

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

Thursday, October 16, 2008

iGoogle launches canvas view

By Dan Holevoet, Developer Programs

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



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

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

Thursday, October 09, 2008

Gadgets and Google Code



Gadgets and Google Code have always had a special relationship, as many developers use Google Code to host their gadgets. We are, therefore, happy to announce that you can now add gadgets to any wiki page (including the project homepage) on Google Code using the <wiki:gadget> syntax shown below.

<wiki:gadget url="http://www.ohloh.net/projects/gwt/widgets/project_cocomo.xml" border="0">

To show you how powerful this is, we created a page of gadgets we found useful. See MarkMail's announcement and Ohloh's announcement for more details about their gadgets.

While gadgets are a great way to bring content to Google Code, they are also a great way to take a little piece of Google Code with you. Take the google-web-toolkit issue tracker as an example:



They enable you to create your own personal dashboard. In fact, this is how I track my various projects. To enable this, new Google Code project hosting gadgets are now available for each project on Google Code. They can be discovered under the feeds link in the project homepage.

http://code.google.com/p/google-web-toolkit/feeds
http://code.google.com/p/wikia/feeds

Let us know what you think! We'd love to hear your ideas on how to make the Gadgets integration on Google Code even better!

As always, we look forward to your feedback.

Zoho Mail goes offline with Gears





We have so much respect for the Zoho team here at Google. They produce great software, and they do it regularly! Their latest accomplishment has been getting their email product, Zoho Mail, working offline.

Brad Neuberg sat down with the guys to chat about this new release. He delves into the offline flow of the product, and then into the architecture behind it. How do they handle syncing? What features do they turn off when you are offline? How explicit to you have to be? Listen in to hear their thoughts!

Thursday, October 02, 2008

Project Updates on Google Code



We are happy to announce that we just launched project update streams (and feeds) for each open source project on Google Code. The new project updates page, which is linked to from each project homepage, shows the updates that are occurring in the project.

One of the benefits of open source software development is that you can watch how the software is built. Take a look at the updates of some popular open source projects:


These updates are also available as feeds. Here are the feeds for the urls above:

Wednesday, October 01, 2008

Measuring Speed The Slow Way



Let's say you figured out a wicked-cool way to speed up how quickly your website loads. You know with great certainty that the most popular web page will load much, much faster. Then, you remember that the page always loads much, much faster in your browser with the web server running on your development box. You need numbers that represent what your users will actually experience.

Depending on your development process, you may have several measuring opportunities such as after a live release, on a staging server, on a continuous build, or on your own development box.

Only a live release gives numbers that users experience--through different types of connections, different computers, different browsers. But, it comes with some challenges:
  • You must instrument your site (one example tool is jiffy-web).
  • You must isolate changes.
    • The most straight-forward way to do that is to release only one change at a time. That avoids having multiple changes altering performance numbers--for better or for worse--at the same time.
  • Consider releasing changes to a subset of users.
    • That helps safe-guard against real-world events like holidays, big news days, exploding hard drives, and, perhaps the worst possible fate of all: a slashdotting.
Measuring real traffic is important, but performance should also be measured earlier in the development process. Millions of users will not hit your development web server--they won't, right?! You need a way to measure your pages without that.

Today, Steve Souders has released Hammerhead, a Firefox plug-in that is just the ticket for measuring web page load times. It has a sweet feature that repeatedly loads pages both with and without the browser cache so you can understand different use cases. One thing Hammerhead will not do for you is slow down your web connection. The page load times that you measure on your development machine will likely be faster than your users' wildest dreams.

Measuring page load times with a real DSL or dial up connection would be ideal, but if you cannot do that, all hope is not lost. You can try the following tools that simulate slower connection speeds on a single box:Please share your own favorite tools in the comments. Each of these tools is super easy to install and setup options to simulate slower connections. However, they each have some caveats that you need to keep in mind.

Firefox Throttle hooks into the WinSock API to limit bandwidth and avoids using proxy settings. (If you use it, be sure to disable "burst-mode".) Right now, Firefox Throttle only limits bandwidth. That means it controls how much data arrives in a given time period after the first bits arrive. It does not limit latency. Latency controls how long it takes packets to travel to and from the server. See Wikipedia's Relationship between latency and throughput for more details. For certain webpages, latency can make up a large part of the overall load time. The next Firefox Throttle release is expected to include latency delays and other webmaster friendly features to simulate slower, less-reliable connections. With these enhancements, Firefox Throttle will be an easy recommendation.

Fiddler and Charles act as proxies, and, as a result they make browsers act rather differently. For instance, IE and Firefox drastically limit the maximum number of connections (IE8 from 60+ to 6 and FF3 from 30 to 8). If you happen to know that all your users go though a proxy anyway, then this will not matter to you. Otherwise, it can mean that web pages load substantially differently.

If you have more time and hardware with which to tinker, you may want to check out tools like dummynet (FreeBSD or Mac OS X), or netem (Linux). They have even more knobs and controls and can be put between the web browser hardware and the serving hardware.

Measurements at each stage of web development can guide performance improvements. Hammerhead combined with a connection simulator like Firefox Throttle can be a great addition to your web development tool chest.

Thursday, September 25, 2008

Simple Graphics Calculator Using the Visualization API and the Scatterchart



We recently came across a great use of the Visualization Platform. In fact, this is something that we never thought the platform would be used for.

Steve Aitken, a developer contributing to the Visualization Developer Group, created a simple graphics calculator for Javascript-supported math functions that plots functions using the Google Visualization Scatter Chart. Here is a screenshot of a simple calculation of -sin(2x):



Steve has been kind enough to share the code with us (even though it was originally written for his girlfriend). A slightly modified version is pasted below:
<html>
<head>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load("visualization", "1", {packages:["scatterchart"]});
function drawChart(equation,xmin,xmax, numPoints, pointSize) {
var data = new google.visualization.DataTable();
data.addColumn('number', 'x');
data.addColumn('number', 'y');
data.addRows(numPoints);
var step = (xmax-xmin) / (numPoints-1);
for(var i = 0; i < numPoints; i++)
{
var x = xmin + step * i;
data.setValue(i,0,x);
with(Math) {
var y = eval(equation);
}
data.setValue(i,1,y);
}
document.getElementById("chart_div").innerHTML = "";
var chart = new google.visualization.ScatterChart(
document.getElementById('chart_div'));
chart.draw(data, {width: 600, height: 400, titleX: 'X',
titleY: 'Y', legend: 'none', pointSize: pointSize});
}
</script>
</head>

<body>
equation: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
<input id="txteq" type="text" value="-sin(2*x)" />
<br />
minimum value(x): &nbsp;<input id="txtmin" type="text" value="-3.14" />
<br />
maximum value(x): &nbsp;<input id="txtmax" type="text" value="3.14"/>
<br />
Precision (number of points): &nbsp;<input id="precision" type="text" value="1000"/>
<br />
Point size: &nbsp; <input id="pointSize" type="text" value="2"/>
<br />
<input id="Button1" type="button" value="Draw Graph"
onclick="javascript:drawChart(
document.getElementById('txteq').value,
parseFloat(document.getElementById('txtmin').value, 10),
parseFloat(document.getElementById('txtmax').value, 10),
parseInt(document.getElementById('precision').value, 10),
parseInt(document.getElementById('pointSize').value, 10))" />

<div id="chart_div"></div>
</body>
</html>

We thank Steve for the inspiration and would love to see more creative uses of the platform from you.

The Visualization Team


Monday, September 22, 2008

A new era for Book Search begins with new APIs

By Venu Vemula, Google Book Search Team

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

Today we are happy to include the developer community in this historic effort with the announcement of two new APIs:
  • An Embedded Viewer API, which allows you to embed book previews on your site and control them programmatically using JavaScript.
  • A robust Data API, which allows you to access full-text search results and access with users' book reviews, ratings, and individual My Library collections.
By allowing anyone to integrate with the complete Google Book Search index, we hope this broader community will find new ways to connect users with books that are interesting and relevant to them.

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

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

Google Developer Day Israel: Registration now open

By Alyssa England, Google Developer Programs

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

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

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

Friday, September 19, 2008

Usability Research on Federated Login

By Eric Sachs, Product Manager, Google Security

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

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



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

Wednesday, September 17, 2008

DataView Makes Working with Visualizations Even Easier



Visualizations are usually nifty, small pieces of code that make our data come alive. In order to live in peace on the web, they need to be streamlined and compact.

At times, these visualization applications are a product of a creative designer who publishes their work for free for all of us to use. Often these designers do not have the time and resources to deal with data input structures.

Therefore, when integrating with a specific visualization, we often need to format the DataTable just right, so it fits the way the visualization expects to get the data. Say as an example, a first column needs to be of type date, the second a number and the third a text comment. What if our DataTable is not in that exact format? What if we want to create several visualizations over the same data source? To date this required manipulating the DataTable to fit the particular visualization and made the API a bit less flexible.

To make fitting data to the visualization even easier and simpler, and the Visualization API even more flexible, we've borrowed from the well-known SQL concept of Views and created our own DataView. Today, with Google Visualization's DataView you can reorder columns and "hide" a column such that the view includes only the columns you need to visualize. And, the DataView stays fully synchronized with the DataTable at all times, so any change to the underlying DataTable is reflected in the DataView.

Let's see a simple example that demonstrates this.

The following code creates three charts from a DataTable. The data displayed is yearly results for the imaginary Acme Rail company. We display a table, a bar chart and a BarsOfStuff chart. The BarsOfStuff chart is used because we are showing data for Acme Rail, and we thought it'd be cool to use the little trains in the chart:
<html>
<head>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<link rel="stylesheet" type="text/css" href="http://visapi- gadgets.googlecode.com/svn/trunk/barsofstuff/bos.css"/>
<script type="text/javascript" src="http://visapi- gadgets.googlecode.com/svn/trunk/barsofstuff/bos.js"></script>
<script type="text/javascript">

google.load("visualization", "1", {packages:["barchart","table"]});

google.setOnLoadCallback(drawData);

// Initialize the DataTable
function drawData() {
var data = new google.visualization.DataTable();
data.addColumn('string', 'Line');
data.addColumn('number', 'Revenue');
data.addColumn('number', 'Expenses');
data.addColumn('number', 'Commuters');
data.addRows(4);
data.setValue(0, 0, 'NorthEast');
data.setValue(0, 1, 38350);
data.setValue(0, 2, 15724);
data.setValue(0, 3, 1534);
data.setValue(1, 0, 'Cross-Pacific');
data.setValue(1, 1, 25740);
data.setValue(1, 2, 12613);
data.setValue(1, 3, 1170);
data.setValue(2, 0, 'Midwest');
data.setValue(2, 1, 11550);
data.setValue(2, 2, 4389);
data.setValue(2, 3, 660);
data.setValue(3, 0, 'Pan-America');
data.setValue(3, 1, 21720);
data.setValue(3, 2, 9774);
data.setValue(3, 3, 362);

//Draw the charts
var table = new google.visualization.Table(document.getElementById('table_div'));
table.draw(data, {showRowNumber: true});

var chart = new google.visualization.BarChart(document.getElementById('chart_div'));
chart.draw(data, {width: 400, height: 240, is3D: false, title: 'Acme Rail Yearly Performance'});

var stuffoptions = {title: 'Acme Rail Commuters by Line'};
var stuffchart = new BarsOfStuff(document.getElementById('stuff_div'))
stuffchart.draw(data, stuffoptions);

}
</script>
</head>

<body>
<div id="table_div"></div>
<div id="chart_div"></div>
<div id="stuff_div" style="width: 400px"></div>
</body>
</html>
The result looks like this:



The problem is that BarsOfStuff is a cool chart, but it is very simple. It can only accept a single data series in the format: [Series Title; Series Value].

Notice that right now the chart compares revenue per rail line, but we wanted it to display the number of commuters per line (as the title suggests).

How can we fix this? With DataView it is a simple matter of adding two lines of code and pointing the BarsOfStuff chart to the DataView instead of the DataTable. We add:
        var view = new google.visualization.DataView(data);
view.setColumns([0,3]);
And initialize the BarsOfStuff chart with the DataView:
        stuffchart.draw(view, stuffoptions);
And we get:



Voila! The BarsOfStuff chart now shows the data we wanted it to visualize - commuters per rail line.

Yet another new feature to make developing complex dashboards with Google Visualization even easier is the clone() method, used to clone a DataTable instead of constructing a new copy from scratch.

We're working on making the DataView even more powerful, and of-course, working on other features and additions to the Visualization platform.

For more information on Google Visualization, check out our developer documentation pages.

Happy visualizing!

Tuesday, September 16, 2008

Creating special results in your custom search engine



If you have a custom search engine, you can jazz up the customization gig by integrating Subscribed Links into your search engine. The Subscribed Links API enables you to create custom result snippets, as well as define the keywords or queries that would trigger them.

For instance, users who want to search for information about the comic book character Asterix might do the following: Type the search query in the search box, scan the search results for the most promising website, click the link to that website, wait for the website to load, and—finally—skim the page for pieces of pertinent information. However, if your custom search engine has a subscribed link for comic book characters, users can just type "asterix" in the search box and immediately get your custom result at the top of the results page. They don't have to scroll, scan, or click anything else to get the answer to their query.

Subscribed Links can directly answer questions, display links to services, provide news and status information, and calculate quantities, among other things. To get an idea of what you can do with Subscribed Links, read the developer guide and check out some live examples in the Google Subscribed Links Directory.

As if that's not cool enough, you can also integrate subscribed links created by other developers with your search engine. To learn more, read the Custom Search Developer's Guide.

Tuesday, September 09, 2008

Picasa Web Albums Enables Video Uploads Via API

By Detlev Schwabe, Software Engineer

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

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

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

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

Tuesday, September 02, 2008

Google Chrome, Chromium, and V8 launch today



It has been an exciting couple of days. Google Chrome launched along with a new blog for Chromium the underlying open source project. Whenever you see an internal project go live to the world, and see the source become open it feels great. We've reposted the blog's first post below, by Ben Goodger:

Today, Google launched a new web browser called Google Chrome. At the same time, we are releasing all of the code as open source under a permissive BSD license. The open source project is called Chromium - after the metal used to make chrome.

Why did Google release the source code?

Primarily it's because one of the fundamental goals of the Chromium project is to help drive the web forward. Open source projects like Firefox and WebKit have led the way in defining the next generation of web technologies and standards, and we felt the best way we could help was to follow suit, and be as open as we could. To be clear, improving the web in this way also has some clear benefits for us as a company. With a richer set of APIs we can build more interesting apps allowing people to do more online. The more people do online, the more they can use our services. At any rate, we have worked on this project by ourselves for long enough - it's time for us to engage with the wider web community so that we can move on to the next set of challenges.

We believe that open source works not only because it allows people to join us and improve our products, but also (and more importantly) because it means other projects are able to use the code we've developed. Where we've developed innovative new technology, we hope that other projects can use it to make their products better, just as we've been able to adopt code from other open source projects to make our product better.

How will we be working with the open source community?

To begin with, we are engaging with the WebKit community to integrate our patches back into the main line of WebKit development. Because of Chromium's unique multi-process architecture, the integration of the V8 JavaScript engine, and other factors, we've built a fairly significant port of WebKit on Windows, and are developing the same for Mac OS X and Linux. We want to make sure that we can find a productive way to integrate and sync up with the WebKit community in this effort as we move forward.

Today, you can visit our project website at www.chromium.org, where you can get the latest source code or the freshest development build. If you're interested in keeping track of what's going on, you can join one of our discussion groups, where you can participate in development discussions and keep track of bugs as they're filed and fixed. Maybe you'll want to fix a few, too! You'll also find information on reporting bugs and all the various other aspects of the project. We hope you'll check it out!

This is the Chromium blog. The posts here will be of a mostly technical nature, discussing the design theory and implementation details of work we've done or are doing. Over the next few weeks there'll be a number of posts that give a high level tour of the most important aspects of the browser.

Finally, if you've not yet done so, take Google Chrome for a spin. You can download it from http://www.google.com/chrome/.