Fridaygram: goodbye to 2011

By Scott Knaster, Google Code Blog Editor

This is the last Fridaygram of 2011, and like most everybody else, we’re in a reflective mood. It’s also the 208th post on Google Code Blog this year, which means we’ve averaged more than one post every two days, so that’s plenty of stuff for you to read. What did we write about?

At Google, we love to launch. Many of our posts were about new APIs and client libraries. We also posted a bunch of times about HTML5 and Chrome and about making the web faster. And we posted about Android, Google+, and Google Apps developer news.

Many of our 2011 posts were about the steady progress of App Engine, Cloud Storage, and other cloud topics for developers. We also published several times about commerce and in-app payments.

2011 was a stellar year for Google I/O and other developer events around the world. Some of our most popular posts provided announcements, details, and recaps of these events. And we welcomed a couple dozen guest posts during Google I/O from developers with cool stories to tell.

The two most popular Code Blog posts of the year were both launches: the Dart preview in October, and the Swiffy launch in June.

Last, and surely least, I posted 26 Fridaygrams in an attempt to amuse and enlighten you. Thank you for reading those, and thanks for dropping by and reading all the posts we’ve thrown your way this year. See you in 2012!

And finally, please enjoy one more Easter egg.

Getting to know the Android Developer Challenge finalists

By Chukwuemeka Afigbo, Program Manager, Sub-Saharan Africa

Cross-posted from the Google Africa Blog

Last month, the five finalists of the Android Developer Challenge came together to share their experiences with the world via Google+ Hangouts. 

Selected from a group of more than 200 submissions and 30 semi-finalists, the five finalists were Chike Maduegbuna, Bobola Oniwura and Tope Omotunde of AfriNolly (Nigeria); David Lemayian of Olalashe (Kenya); Gerald Kibugi of Shopper’s Delight (Kenya); Herko Lategan of Rainbow Racer (South Africa); and Richard Marsh of Wedding Plandroid (South Africa). 

The interview was hosted by CP Africa, a popular African blog and Gbenga Sesan, Nigerian tech evangelist, who conducted the interview while sitting in the departure lounge of the Murtala Mohammed International Airport in Lagos as he waited to board his flight to Addis Ababa.



Thanks to the power of the internet and Google+, the interview was held simultaneously in Nigeria, Kenya and South Africa, in collaboration with three developer hubs: Umbono (Cape Town, South Africa), Co Creation Hub (Lagos, Nigeria) and iHub (Nairobi, Kenya). The finalists answered live questions and questions from people around the world including Ghana, Italy, Malaysia, Mali, Nigeria and Uganda using Google Moderator. 

The top-voted question was on how to prioritize features when building an application, while another participant wanted to know what kind of changes the finalists hoped to create in Africa with their applications. 

To learn more about the finalists for the Android Developer Challenge and their applications, please visit the new case studies section of the Google Africa Developers website. If you create solutions using Google services for developers (Google Apps, Chrome extensions, Android, App Engine, etc.) and want to share your story with the world, let us know!


Chukwuemeka Afigbo is a Program Manager in the Sub-Saharan Africa Outreach Team. He is an avid football (soccer) fan.

Posted by Scott Knaster, Editor

Google Prediction API: faster, easier to use, and more accurate

By Marc Cohen, Developer Relations

This holiday season, the Google Prediction API Team is bringing you four presents and, thanks to the joys of cloud computing, no reindeer are required for delivery. Here’s what you’ve already received:

• Faster on-ramp: We’ve made it easier to get started by enabling you to create an empty model (by sending a trainedmodels.insert request with no storageDataLocation specified) and add training data using the trainedmodels.update method. This change allows you to submit your model contents without needing to stage the data in Google Cloud Storage.
• Improved updates: The algorithms used to implement model updates (adding additional data to existing models) have been modified to work faster than ever.
• More classification algorithms: We’ve increased the number of classification algorithms used to build predictive models, resulting in across-the-board improvements in accuracy.
• Integration with Google Apps Script: Prediction services are now available as part of Google Apps Script, which means you can integrate prediction services with Google Docs, Google Maps, Gmail, and other great Google products.

All of the above enhancements are supported by the current Prediction API version 1.4 so you can enjoy these features using the existing client libraries.

Happy Holidays from the Google Prediction API Team. We’re looking forward to bringing you more exciting features in 2012!


Marc Cohen is a member of Google’s Developer Relations Team in Seattle. When not teaching Python programming and listening to indie rock music, he enjoys using the Google Prediction API to peer into the future.

Posted by Scott Knaster, Editor

Speed metrics in Google Analytics

By Satish Kambala, Staff Software Engineer

At Google we believe that speed matters and a faster web is better for everyone. That’s why we started the Make The Web Faster initiative. To improve the speed of a website, we need to measure how fast web pages load. The Site Speed report, which is now available by default to all users of Google Analytics, provides just that: it enables website owners to measure page load time for their web pages.

You can use the Site Speed report to correlate speed with other metrics in Google Analytics, such as page views and conversions. This enables website owners to identify and optimize those pages that drive these metrics. Page load times can be analyzed by browser type or user location to understand if specific optimizations are required. Recently, we enhanced the Site Speed report by adding a new section called Technical (see screenshot below) which displays network and server time components of page load time.

You can learn more about the Site Speed report here. This report, along with powerful page speed analysis tools such as Page Speed Online, will help website owners delight their users by building fast and responsive websites.

Have ideas on how to make your website faster or ways to speed up the entire Web? Send us your thoughts.


Satish Kambala works at Google on stuff that helps in making the web faster. In his free time, apart from watching cricket and movies, Satish likes exploring places with his wife.

Posted by Scott Knaster, Editor

Fridaygram: universal terms, distant space, watch where you walk

By Scott Knaster, Google Code Blog Editor

Earlier this week, we launched a single Terms of Service for most of our APIs. You might know the Terms of Service (ToS) as those legal documents you click through quickly when you start using a new product, but they’re vitally important, as they specify exactly what you and we can expect from each other when you use our APIs. (Internally, we refer to the new terms as uToS [universal terms of service], pronounced "you toss".)

The project began some time ago as a general developer ToS cleanup. At the time, we looked at the Google Terms of Service shared across many consumer products, and figured developers deserved equal consideration. In reviewing the developer ToS documents, it became clear that there was plenty of language in common among various products. And this week, the new Terms launched, covering most APIs, with more to come in time. Of the APIs that are included, a few have additional terms, but these tend to be brief. And things overall are much simpler and cleaner than before.

This project is an example of something that affects every Google developer and Google too, and yet it’s not really a technical topic. This ToS simplification was no minor project: it was over two years in the making. Getting to simplify an important set of documents by removing over 125,000 words of text is a wonderful thing.

Speaking of universal things, the incredible Voyager 1 spacecraft is now about 18 billion kilometers from the sun and is nearing the end of our solar system. Voyager now inhabits a part of space between planets and other stars that has an intense magnetic field, among other unusual properties, and we’ll learn more about the place from Voyager itself. One scientist says that Voyager is now in a "stagnation region", and I think we all know what that feels like.

And finally, if you’re planning your holiday vacation over the weekend, you might want to see what happens if you ask Google Maps for walking directions from Rivendell to Mordor.


Fridaygram posts are just for fun, and sometimes even legal stuff can be fun. Fridaygrams are designed for your Friday afternoon and weekend enjoyment. Each Fridaygram item must pass only one test: it has to be interesting to us nerds.

Introducing AdSense Management Services in Google Apps Script

By Silvano Luciani, Developer Programs Engineer, AdSense API Team

Starting today, the AdSense Management API is available as part of AdSense Services in Google Apps Script. This means that you’ll be able to automate your AdSense reporting across Google products using a JavaScript cloud scripting language to do things like:

• Create AdSense performance reports for your AdSense accounts in a Google spreadsheet.
• Create a chart based on your AdSense reporting data and display it in a Google spreadsheet.
• Embed your scripts in a Google Sites page, for instance to import a chart.
• Use triggers to schedule the execution of your scripts, for instance to periodically update the chart imported in the Google Sites page.

You can start using the service by checking out the reference documentation, which also contains some sample scripts, and by reading this tutorial, which implements the use cases mentioned above.


Based in London, Silvano Luciani joined Google in 2011 to make the AdSense API developers happier people. Before that, he has worked in Finland, Italy, Spain and the UK, writing web based configuration management tools for ISPs, social networks, web based training materials, e-commerce apps and more. He has recently discovered that he loves charts, and has finally started to play the drums in the London’s office music room. If you can call what he does "playing the drums".

Posted by Scott Knaster, Editor

Mobile Web performance challenges and strategies

By Ramki Krishnan, Technical Program Manager

Consumers are increasingly relying on their mobile devices to access the Web, thrusting mobile web performance into the limelight. Mobile users expect web pages to display on their mobile devices as fast as or faster than on their desktops.

As part of Google’s effort to Make The Web Faster, we invited Guy Podjarny, CTO of Blaze.io, to talk about some of the major performance concerns in the mobile web and ways to alleviate these issues. Guy’s talk focused on Front-End Optimization and highlighted 3 areas: mobile network, software, and hardware. Each of these impacts performance in myriad ways. The full video is available here, and runs just under an hour. If you don’t have time to watch this enlightening talk, this post discusses some key takeaways.

Mobile networks have high latency, and reducing the number of requests and the size of downloads are well-known optimization strategies. Guy also mentions using on-demand image displays such as loading above-the-fold images by default and other images only as they scroll into view. To handle network reliability, he recommends non-blocking requests eliminating single points of failure, with a selective aggregation of files needed for content display. Periodic pinging of the cell tower by the client can also reduce latency associated with dropped connections, but judicious timeouts and battery drain on the mobile device need to be factored in.

Modern mobile browsers are built mobile-friendly, and they can be helped further by exploiting localStorage to store CSS and JavaScript files. Pipelining multiple requests on a connection is an option, but developers need to work around head-of-line blocking by using techniques such as splitting dynamic and static resource requests on different domains.

Mobile hardware CPUs are weaker than their desktop counterparts. Guy points out the need to minimize JavaScript when designing mobile-friendly web pages and avoid reflows or defer JavaScript until after page loads. Clever image rendering techniques such as automatically resizing images to devices and loading full resolution only on zoom can also help.

Guy’s presentation makes clear that mobile web optimizations need to mitigate latencies introduced by mobile networks, software, and hardware. Rapidly changing OSes and browsers add to the challenges facing publishers. New and evolved tools and technologies will help ensure an optimal web browsing experience for mobile users.


Ramki Krishnan works at Google on the "Make The Web Faster" team. When not at work, he dreams of being a tennis pro, a humorist, and a rock drummer all rolled into one.

Posted by Scott Knaster, Editor

In-App Payments expands its borders

By Pali Bhat, Group Product Manager

Cross-posted on the Google Commerce Blog and Chromium Blog

Since Google In-App Payments launched in July for developers in the United States, we’ve received great feedback on how easy it is to integrate as well as how simple it is for consumers to use. While the API has been off to a strong start, there’s been a growing demand for availability outside of the United States.

So starting today, we are opening developer enrollment for Google In-App Payments to 17 additional countries. In addition to the United States, developers from Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Ireland, Italy, Japan, the Netherlands, Norway, Portugal, Spain, Sweden, and the United Kingdom can now use the Google In-App Payments API to incorporate an in-context payment experience into applications on the Chrome Web Store and their own sites.

Developers using In-App Payments are seeing strong conversions and revenue streams thanks to these key features:

• Ease of use: the short payment process for consumers takes place right in the developer’s app or site.
• Large existing user base: there are millions of Google Wallet online users in over 140 countries.
• Low fees: developers pay just 5% on all transactions.

You can get started accepting payments in your web apps by following the tutorial and get answers to any questions in the forum. We look forward to expanding to even more countries in the future, as well as continuously working to improve the Google In-App Payments experience.


Posted by Scott Knaster, Editor

Automate with the Google Affiliate Network API

By Ali Pasha, Google Affiliate Network Product Manager

Google Affiliate Network is a free program that makes it easy for website publishers to connect with quality advertisers and get rewarded for driving conversions.

Today we’re making it even easier for affiliates and advertisers to work with Google Affiliate Network by launching the Google Affiliate Network API, which enables publishers and advertisers to automate various tasks related to Google Affiliate Network.

For more information, please see the Google Affiliate Network blog.


Ali Pasha has been a Google Product Manager for several years and now works on Google Affiliate Network. Ali has also made key contributions to Android App Inventor, Google Code, Google Code Search, and Google AJAX APIs.

Posted by Scott Knaster, Editor

Introducing the Google APIs Terms of Service and an update to Code Labs

By Adam Feldman, APIs Product Manager

The Google APIs Terms of Service

Beginning today, most of our APIs use a single Terms of Service. We have rewritten these terms from the ground up with the goals of making them concise and easier to understand. Our intent is to simplify, not to make dramatic functional changes.

For all the APIs that share this single Terms of Service, you won’t need to study a whole new document, although some have brief specific Additional Terms.  In this rewrite, we have removed over 125,000 words from the combined previous terms, resulting in less to read and faster access to your favorite APIs.  Over time, other APIs will be migrated to the new terms.  Please review each API’s documentation to see its terms.

The new Terms of Service is another step in making Google APIs more technically consistent by sharing common infrastructure such as the Discovery service, the APIs Explorer, and the APIs Console.

Removing the Code Labs Label

In order to reduce confusion we're removing the Code Labs label from APIs on code.google.com. The Google Labs program has wound down. APIs formerly in Code Labs will now use the standard header in their documentation. The APIs themselves are unchanged.

Adam Feldman is a Product Manager, focusing on all of Google's APIs and making sure Google provides the best possible platform to developers.

Posted by Ashleigh Rentz, Editor Emerita