Google Code Blog
0
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!
A Toast to Code Jam 2008
4 days ago
0
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!
0
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.
Get Out and Vote! (on Google Code)
14 days ago
0
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!
0
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:
- Index up to 50,000 documents
- Use the Connector Framework to index proprietary document repositories
- Use the Feed API and metadata search to index information with unique formats
- Use Onebox to retrieve information from real-time services
- Take the authentication and secure search capabilities for a test drive
- Customize the search results page, or extract it in XML format for use on another web site
0
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.
Moving another step closer to single-sign on
20 days ago
0
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.
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.
Google moves towards single sign-on with OpenID
21 days ago
0
By Erich Sachs, Google Security Team
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.
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.
0
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!
0
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.
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.