Thursday, 31 March 2011
At Google, we’re striving to make the whole web fast. As part of that effort, we’re launching a new web-based tool in Google Labs, Page Speed Online, which analyzes the performance of web pages and gives specific suggestions for making them faster. Page Speed Online is available from any browser, at any time. This allows website owners to get immediate access to Page Speed performance suggestions so they can make their pages faster.
Page Speed Online is powered by the same Page Speed SDK that powers the Chrome and Firefox extensions and webpagetest.org.
Please give Page Speed Online a try. We’re eager to hear your feedback on our mailing list and find out how you’re using it to optimize your site.
Hello, esteemed Google Code Blog readers! My name is Scott Knaster, and I’m the new editor of this blog. I’m interrupting the usual flow of posts to let you know about some new things happening around here. This blog has the company’s name on it, but of course, like all blogs, it’s written by individual people, to be read by other individual people, like you. We want to do a little more to celebrate that, starting with these small steps:
- We’re adding a photo and some info about each post’s author. Googlers get around, to hackathons, conferences, and GTUGs, and now you’ll have faces to match up with names when we meet in real life.
- We’ll spend more time responding to comments. As always, we encourage and appreciate your thoughtful, on-topic comments.
- We’ll be tweeting more at @googlecode over on Twitter, too. And you can find a list of Google developer-related Twitter accounts here (choose Developers from the Category drop-down).
- I’ll be hanging around here a lot. Think of me as the host of a big, geeky dinner party. Mostly I’ll be helping edit posts written by others—experts who work on the products they post about—but I’ll also write a few posts myself.
Please email me at email@example.com if you have any thoughts or feedback for improving this blog. Or, just leave a comment on this post.
Thanks for being here!
Monday, 28 March 2011
(Cross-posted with the Google Open Source Blog.)
Google Summer of Code is a highly competitive program with a limited number of students being accepted. We are pleased to announce that this year we have enlarged the program so that we can accept as many as 150 additional students. We hope all interested students will apply!
Now it is time for the students to submit their proposals to the accepted mentoring organizations via the Google Summer of Code program website from today through Friday, April 8th 19:00 UTC. For the past 10 days students have had the opportunity to review the Ideas pages for this year’s 175 accepted projects and to research which projects they would like to contribute to for this year’s Google Summer of Code.
Every year we have thousands of students who apply for the Google Summer of Code program but due to the limited number of slots many students are not able to be a part of the program. The quality of your proposal is what will make you stand out from your peers. Students should consult the Google Summer of Code student manual for suggestions on how to write a proposal that will grab the attention of the mentoring organizations. Multiple proposals are allowed but we highly recommend focusing on quality over quantity. The mentoring organizations have many proposals to review, so it is important to follow each organization’s specific guidelines or templates and we advise you to submit your proposal early so you can receive timely feedback.
By Stephanie Taylor, Open Source Programs Office
Tuesday, 22 March 2011
(Cross-posted from the Google Webmaster Central Blog.)
Today we’re launching the most requested feature for Page Speed, Page Speed for Chrome. Now Google Chrome users can get Page Speed performance suggestions to make their sites faster, right inside the Chrome browser. We would like to thank all our users for your great feedback and support since we launched. We’re humbled that 1.4 M unique users are using the Page Speed extension and finding it useful to help with their web performance diagnosis.
Google Chrome support has always been high on our priority list but we wanted to get it right. It was critical that the same engine that powers the Page Speed Add-On for Firefox be used here as well. So we first built the Page Speed SDK, which we then integrated into the Chrome extension.
Page Speed for Chrome retains the same core features as the Firefox add-on. In addition, there are two major improvements appearing in this version first. We’ve improved scoring and suggestion ordering to help web developers focus on higher-potential optimizations first. Plus, because making the web faster is a global initiative, Page Speed now supports displaying localized rule results in 40 languages! These improvements are part of the Page Speed SDK, so they will also appear in the next release of our Firefox add-on as well.
If your site serves different content based on the browser’s user agent, you now have a good method for page performance analysis as seen by different browsers, with Page Speed coverage for Firefox and Chrome through the extensions, and Internet Explorer via webpagetest.org, which integrates the Page Speed SDK.
We’d love to hear from you, as always. Please try Page Speed for Chrome, and give us feedback on our mailing list about additional functionality you’d like to see. Stay tuned for updates to Page Speed for Chrome that take advantage of exciting new technologies such as Native Client.
By Matthew Steele and Richard Rabbat, Page Speed Team
Monday, 21 March 2011
Part viewing party and part community building, Google I/O Extended events are free and worldwide, focused on bringing the developer community together to live-stream the keynote and other major sessions of Google I/O. Each location’s event will be a little different, so check the registration page of the closest location to see what they have planned. With limited space, registration is required. Learn more and find an I/O Extended event near you on the I/O Extended site. These events are being organized by local developer community leaders and university ambassadors, so please reach out to them specifically if you have any questions about the details.
Here are just a few of the locations hosting an I/O Extended event:
- Aachen, Germany
- Barcelona, Spain
- Berlin, Germany
- Brussels, Belgium
- Bucharest, Romania
- Dublin, Ireland
- London, England
- Madrid, Spain
- Malaga, Spain
- Istanbul, Turkey
- Kyiv, Ukraine
- Munich, Germany
- Murcia, Spain
- Vienna, Austria
- Warsaw, Poland
- Boise, ID, USA
- Charlotte, NC, USA
- Maui, HI, USA
- San Jose, CA, USA
- Twin Cities, MN, USA
- Washington, DC, USA
- Waterloo, Ontario, Canada (link updated)
See more locations on the map and register for a Google I/O Extended event in your area.
We look forward to having you join us for Google I/O Extended!
By Amy Walgenbach, Google I/O Team
Thursday, 17 March 2011
The old show_ads did lots of work: loading additional scripts, gathering information about the web page it was running on, and building the ad request to send back to Google. The new show_ads has a different job. It creates a friendly (same-origin) iframe on the web page, and starts the old script with a new name, show_ads_impl, running inside that iframe. The _impl does all the heavy lifting, and in the end the ads look exactly the same. But there’s a substantial speed advantage: many things happening inside an iframe don’t block the web browser’s other work.
How much of an effect this has depends on context: a page with nothing but ads on it isn’t going to get any faster. But on the real-world sites we tested, the latency overhead from our ads is basically gone. Page load times with the new asynchronous AdSense implementation are statistically indistinguishable from load times for the same pages with no ads at all.
The new show_ads is a drop-in replacement for the old one: web site owners don’t need to do anything to get this speed-up. But these dynamically-populated friendly iframes are finicky beasts. For now, we’re only using this technique on Chrome, Firefox, and Internet Explorer 8, with more to come once we’re sure that it plays well with other browsers.
And what if you’ve built a page that loads AdSense ads and then manipulates them in exotic ways not compatible with friendly iframes? (This is the web, after all, land of “What do you mean that’s ‘not supported’? I tried it, and it worked!”) You can set “google_enable_async = false” for any individual ad slot to revert to the old blocking behavior. But if your site loads ads in some tortuous way because you were looking for latency benefits, consider giving the straightforward invocation of show_ads.js a whirl. Because now, we’re fast.
By Michael Kleber, Ads Latency Team
Wednesday, 16 March 2011
There are three forms of authentication supported by almost all of Google’s APIs. AuthSub and OAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.
If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.
ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an
HTTP 403error response from our servers with the following in error included in the response body:
There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.
The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.
While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.
By Jeffrey Posnick, Google Developer Relations
Tuesday, 15 March 2011
Some of these changes have already occurred. Many user-facing Google products now allow or require SSL, including encrypting Google web search, defaulting to SSL in Gmail, and requiring SSL in Google Docs. Next on our list is to improve SSL support for our developer facing APIs. For most APIs, our technical documentation, client libraries and code samples already use SSL. Many new APIs and versions will be SSL only. Further, the Google Maps API, which previously offered SSL only to Premier customers, is offering SSL to all developers starting today.
Additionally, beginning September 15, 2011, Google will require that all users of Google Documents List API, Google Spreadsheets API, and Google Sites API use SSL connections for all API requests. Specifically, this change will disallow all HTTP requests, responding with an HTTP 400 Bad Request response. API requests will only be accepted via HTTPS. For example, a request to http://docs.google.com/feeds/default/private/full will no longer pull a list of a user's documents. Instead, a request must be made to https://docs.google.com/feeds/default/private/full.
This change should be transparent if you're using the most recent version of the Google Data client libraries, since they already use SSL for all requests. If you're not using the latest version, then please upgrade as soon as possible. If you're not using our client libraries, then simply change any use of an HTTP URL to its corresponding HTTPS version in your code. Your existing OAuth and AuthSub tokens will continue to work using the HTTPS URLs, even if they were requested with a scope that uses an ‘http://’ scheme.
Although we’re initially requiring SSL for only a few APIs (those whose traffic was already mostly over SSL), we strongly recommend that you convert all your API clients as soon as possible to help protect your users’ data. Check the documentation for each API for more information about that API's SSL support, including the updated Google Documents List API documentation, Google Spreadsheets API documentation, and Google Sites API documentation.
If you have any questions or concerns about this change, please follow up in the forums of the API you are using.
By Adam Feldman, Google Developer Team
March 16 - Android, 9:00 am
March 17 - Chrome, 9:00 am
March 18 - App Engine, 9:00 am
March 21 - YouTube APIs, 9:00 am
March 22 - Game Developers, 9:00 am
March 23 - Google Maps / Geo, 4:00 pm
March 24 - Commerce, 9:00 am
March 25 - Developer Tools / GWT, 9:00 am
March 28 - Accessibility, 4:00 pm
March 29 - Google Apps / Enterprise, 4:00 pm
All times are listed in PDT
When you visit the site tomorrow morning, you will see a tab in the navigation that reads “Android”--that’s where you will find all of the questions and submission forms for Round I. We’re excited to see what everyone comes up with!
By Monica Tran, Google I/O Team
Monday, 14 March 2011
Since we announced support for OAuth in 2008, we've seen tremendous usage growth in our APIs that require user authorization, like Calendar and Docs. While the spec isn't completely finalized, Google is pleased to announce our experimental support of an easier way for developers to obtain user authorization for our APIs: OAuth 2.0 with bearer tokens. Whether you use our updated client libraries or just write to the protocol, you should be able to do more with less code.
In addition to supporting a simplified protocol, we're also introducing a simpler, cleaner consent page for OAuth 2.0:
Google believes in open systems that give users value, transparency and control. We hope the OAuth 2.0 protocol helps developers deliver just that: powerful applications that make use of user data without compromising on safety or security. Check out our documentation to get started with OAuth 2.0.
By Andrew Wansley, Google Developer Team
Thursday, 10 March 2011
Our friends from World Golf Tour, Sliderocket, Wikinvest, Todo.ly and Springpad share their experiences with the Chrome Web Store through five brand new case studies. While each of these developers has a unique view point, some common themes have surfaced:
- The Chrome Web Store can help you acquire more users really fast: For example for Todo.ly, users of the Chrome Web Store app account for more than 50% of the web site’s traffic.
- Chrome Web Store users are very engaged with apps: Springpad and Wikinvest report that Chrome app users spend up to 100% more time interacting with the app, than a typical visitor spends on their regular website.
- You can improve the monetization of your app through the Chrome Web Store: Premium apps like the World Golf Tour and Sliderocket report significantly higher conversion rates for Chrome app users than the rest of the user base and a growing percentage of business leads originating from the store respectively.
- Posting your app in the store requires relatively little effort: The app publishing process in the store is smooth and required little to no custom work for all the developers, profiled in the case studies.
By Christos Apartoglou, Product Marketing
Tuesday, 8 March 2011
For those of you who were quick to register, we thank you for continuing to support our developer initiatives -- this year's I/O is slated to be one of our best yet. For the rest of our developers, we weren’t kidding when we told you we <3 our developers.
Starting Wednesday, March 16, we will be launching Last Call for Google I/O: A contest that spans 10 days, 10 developer challenges and 100 chances to win tickets to attend the now-sold-out Google I/O 2011.
Here’s how it works. We will announce a new challenge on the contest site on select dates at either 9am or 4pm PDT, that will last for 24 hours each. There will be 10 days of challenges with 10 winners on each day, spanning the following developer products:
- March 16 - Android, 9:00 am
- March 17 - Chrome, 9:00 am
- March 18 - App Engine, 9:00 am
- March 21 - YouTube APIs, 9:00 am
- March 22 - Game Developers, 9:00 am
- March 23 - Google Maps / Geo, 4:00 pm
- March 24 - Commerce, 9:00 am
- March 25 - Developer Tools / GWT, 9:00 am
- March 28 - Accessibility, 4:00 pm
- March 29 - Google Apps / Enterprise, 4:00 pm
Each of the challenges will focus on one of our developer products and has two rounds. Plan to be in front of your computers for the first half-hour that the challenge starts to complete a series of questions for Round I, which will qualify you for the main coding challenge in Round II. You will have a little over 20hrs to complete Round II.
We want to make sure that we provide the opportunity to attend Google I/O to as many developers as possible and hope you’re feeling up to the task. The contest is valid in the 50 United States and the District of Columbia with winners being announced on April 4. And don’t forget that we will be livestreaming the keynotes and taping sessions during Google I/O. Stay tuned!
For more information and contest rules, visit the contest site.
By Vic Gundotra, VP Engineering
The festivities start at 1pm on March 13 with the opening of The League of Extraordinary Hackers followed by a very special SuperHappyDevHouse at 7pm at the Speakeasy on 412 Congress Ave in Austin.
Business by day, hacking by nightFrom 1pm to 6pm, we’ll be hosting a series of 15-minute rapid-fire API briefings focused on Google’s latest developer offerings including: Android, Chrome, HTML5, Blogger, Google TV, Google Maps, App Engine, YouTube, Web Fonts, Cellbots, and Fusion Tables. Immediately following each talk, the speakers will be holding court during office hours in Speakeasy’s open air rooftop lounge.
At the same time, we’ll be demoing Google TV and the YouTube Leanback experience in the Leanback Lounge on the second floor. And if you’re just looking for a place to chill, meet other Google developers, or grab free WiFi and juice for your devices, we’ve got you covered in that department as well.
|Yes, this is one of our drink cards.|
This event promises to be one-of-a-kind and a rare respite from the pure partying events at SXSW. Of course it wouldn’t be possible with a great cast of sponsors including Google, Windows Live, The LEGO Group, NPR, Sencha, Red Bull Creation, Twilio, and Rdio.
- The League of Extraordinary Hackers is on Facebook, Plancast, and Lanyrd
- SHDH@SXSW is on Facebook, Plancast, and Lanyrd
Hope to see you there!
P.S. Make sure to follow @googlesxsw for updates during the show!
— Chris Messina, Developer Relations
Monday, 7 March 2011
Google is always looking for new ways to make it easier for developers to get started with our APIs. When you come across a new Google API, you often want to try it out without investing too much time. With that in mind, we are happy to announce the Google APIs Explorer, an interactive tool that lets you easily try out Google APIs right from your browser. Today, the Explorer supports over a half dozen APIs – and we expect that number to grow rapidly over the coming weeks and months.
By selecting an API you want to explore, you can see all the available methods and parameters along with inline documentation. Just fill out the parameters for the method you want to try and click “Execute”. The Explorer composes the request, executes it, and displays the response in real time. For some APIs that access private data you will need to “Switch to Private Access” and authorize the Explorer to do so.
To get you started, here are some sample requests; follow the links and press “Execute”:
- Expand a goo.gl URL using the URL Shortener API
- Translate a phrase to French using the Translate API
- List your personal Buzz posts using the Buzz API (requires private access)
The Explorer makes it easier for developers to discover what APIs we offer and get started using them within minutes. If you have any questions or comments, visit the help page or the support forum. We’d love to hear your feedback.
By Anton Lopyrev and Jason Hall, Google Developer Team
Wednesday, 2 March 2011
Today, the annual Game Developers Conference (GDC) officially kicks off in San Francisco. From browser technologies to cloud storage solutions, Google has many products and services that can be useful to game developers. Until now, it was hard for developers to track down information on how Google can help them build, distribute and monetize their games. This is why we are excited to release Google Game Developer Central.
Google Game Developer Central provides an overview of Google products and services that are particularly relevant to game developers. You’ll be able to explore different platforms like Chrome, learn about technologies such as GWT, WebGL and HTML5, and check out monetization options like AdMob.
This is just the first iteration of Google Game Developer Central. In the next few months, we plan to add additional content to make this an even better resource for all game developers. If you’d like to give us feedback on how to improve the site, please join our developer forum or for those of you at GDC, stop by our booth on the expo floor. We look forward to meeting you in person!
By Ian Ni-Lewis, Game Developer Relations Team