We are pleased to announce our newest addition to the shopping family -- a simple yet powerful programmatic interface that enables retailers to upload their content to Google and query data from Google. The new Shopping APIs have two components: Content and Search. As part of this launch, we’re are also deprecating the Base API and replacing it with today’s new Shopping APIs.
The Content API for Shopping allows retailers to upload product data to Google for use in multiple places online like Google Product Search, Product Ads, Google Affiliate Network, Google Commerce Search, and Shopping Rich Snippets.
The Search API for Shopping makes it easy for our Google Commerce Search customers, Google Affiliate Network publishers, and developers to build innovative applications using product data.
The Shopping APIs replace the Base APIThese new Shopping APIs replace the existing Google Base Data API for our content providers and search applications. We are deprecating the Base API and will fully retire it on June 1, 2011. For existing developers making the switch, we’ve provided a Migration Guide to help.
You can read more details about these announcements on the Google Merchant Center blog and our FAQ on Google Base Data API Deprecation.
Today we announced a fun 20% robotics project that resulted in three ways you can play with your iRobot Create®, LEGO® MINDSTORMS®, or VEX Pro® through the cloud. We did this by enhancing App Inventor for Android, contributing to the open source Cellbots Java app, and beefing up the Cellbots Python libraries. Together these apps provide new connectivity between robots, Android, the cloud, and your browser.
You can start empowering your Android phone with robot mobility by picking the solution below that matches your skill level and programming style:
We hope this gives developers, hobbyists, and students a head start in connecting the next generation of cloud apps to the world of robotics. Be sure to push your mobile phone’s processor to its limits and share the results with the Cellbots Google Group. Try using Willow Garage’s OpenCV for Android or the new Gingerbread APIs for gyroscopes, enhanced OpenGL graphics, and multiple cameras!
(Cross-posted from the Chromium Blog)
We’re happy to announce that WebGL is now on by default in Google Chrome’s beta channel, with some shiny new demos to show off what the technology can do.
WebGL is a 3D graphics API for JavaScript that developers can use to create fully 3D web apps. It is based on the OpenGL ES 2.0 API, which should be familiar to many 3D graphics developers. Google, Mozilla, Apple, Opera and graphics hardware vendors have been working together to standardize WebGL for over a year now, and since the spec is just about final at this point, we wanted to get our implementation out there for feedback.
While you may not find much WebGL content on the web, we expect developers to quickly create a lot of content given the power and familiarity of the API. To inspire developers and give users a taste of the kind of apps they can expect in the near future, we’ve worked with a few talented teams to build a few more 3D web apps:
Body Browser, a human anatomy explorer built by a team at Google as a 20% project
Nine Point Five, a 3D earthquake map by Dean McNamee
Music Visualizer, a jukebox that synchronizes 3D graphics to the beat of the music by Jacob Seidelin
You can find these and other demos in the new Chrome Experiments Gallery for WebGL demos. Now that WebGL is enabled in the beta channel, the Chrome Experiments team is looking for your cool WebGL app submissions to show off this slick technology, so don’t forget to submit your cool 3D apps!
When Google acquired Instantiations in August 2010, everyone knew about our Java Eclipse products. Shortly after we joined, we talked about how best to help developers now that we are part of Google. We have always wanted to get these tools in more developers’ hands. So, back in September we decided to give them away for free! The community response has been fantastic. With that done, we asked ourselves, how could we make a good thing even better? How about by open sourcing the code and creating two new Eclipse projects!
Today we are announcing Google’s donation of the source code and IP for two of these products to the open source community through the Eclipse Foundation. This donation includes WindowBuilder, the leading Eclipse Java GUI Designer, and CodePro Profiler, which identifies Java code performance issues. Specifically, the WindowBuilder Engine and designers for SWT and Swing. All in all, this is a value of more than $5 million dollars worth of code and IP.
The Eclipse Foundation’s Executive Director, Mike Milinkovich, states that, “this is clearly a significant new project announcement, and very good news for Java developers using Eclipse. It has been impressive to see the continued growth and popularity of WindowBuilder, as this product has always filled a much needed gap in the Eclipse offerings. We look forward to it appearing in an Eclipse release soon. We’re very pleased with Google’s generous support of Eclipse, and the Java developer community around the world.”
One of the exciting aspects of innovating in the open source arena is that customers benefit from a full community. We are very excited to see the diverse collection of companies and individuals that have already expressed an interest in contributing to these projects. Commercial level support is important to many customers. Genuitec, makers of MyEclipse, intends to offer commercial support for the various WindowBuilder based products including the SWT, Swing Designer and even the GWT Designer from Google. Please sign up on the Genuitec site for more information. Similarly, OnPositive intends to offer commercial support for CodePro Profiler, as well as lead as the committers on the Eclipse Community Project. Sign up on the OnPositive site for more information.
"Genuitec is pleased to offer commercial support for WindowBuilder-based products - Swing, SWT and GWT - in early 2011 for companies who wish to continue a paid support contract once their Google support expires. We've been involved with the Eclipse Foundation since the beginning, so we are very familiar with these products. Thus, providing commercial support for this product line is a natural fit for us," said Maher Masri, President of Genuitec.
“Over the years OnPositive has built up unique experience with the CodePro Profiler and we are excited to offer commercial support for it. Google’s donation ensures that Java developers can build faster applications,” said Pavel Petrochenko, President of OnPositive.
WindowBuilderWindowBuilder is regarded as the leading GUI builder in the Java community (winning the award for Best Commercial Eclipse Tool in 2009). It includes powerful functionality for creating user interfaces based on the popular Swing, SWT (Standard Widget Toolkit), GWT (Google Web Toolkit), RCP and XWT UI frameworks.
CodePro ProfilerCodePro Profiler is an Eclipse-based Java application profiling tool that helps developers identify performance issues early in the development cycle and find CPU and algorithmic bottlenecks, memory leaks, threading issues, and other concurrency-related problems that can slow down an application or cause it to hang.
Both WindowBuilder and CodePro Profiler will become Eclipse projects in the first half of 2011. Once each one is set up as a project and available for download from the Eclipse site, the products will be accessible to use as open source code under the the standard Eclipse license. I am looking forward to leading the WindowBuilder project.
If you have any questions, you can learn more at this FAQ or we look forward to hearing from you on the forums.
You’ve already been able to simply include a photo in a Google Buzz post using the Buzz API. Today we’re making it much easier to add photos to Buzz posts. Additionally, using Picasa as the photo repository, you’ll now be able to wield the Buzz API to take all sorts of other actions on behalf of the user:
Accessing a photo entry through the Buzz API is just as easy as getting an activity. The form for retrieving an activity is:
https://www.googleapis.com/buzz/v1/activities/{userId}/@self/{activityId}
With just a few alterations, we get the form for retrieving a photo:
https://www.googleapis.com/buzz/v1/photos/{userId}/@self/{albumId}/@photos/{photoId}
With live data, it would look like the following URL:
https://www.googleapis.com/buzz/v1/photos/farago/@self/5251364904403459921/@photos/5251366163678993586?alt=json&prettyprint;=true
Browse to that address and you’ll get data that will point to this Picasa photo:
The read-only endpoints will return public data without authentication. For authenticated access to the photos endpoints, you must be granted an OAuth token for the user with both the Buzz and Photos API scopes. For existing users, you will need to discard the OAuth tokens scoped to the Buzz API and request authorization to both scopes. More details can be found on the Google Buzz API documentation site.
Photos are an essential part of social applications. We expect these new capabilities will allow you to enrich your user’s experience with a minimum of fuss. As always, please swing by the Developer Forum to let us know what you think. And if you haven’t already, start using the APIs console to track your API usage and other coolness.
(Updated 10 Dec 2010 -- corrected link to 3rd Place Hilversum developer Kornel Lesinski's Twitter page.)
Last month, more than 50 developers assembled in Hilversum, Netherlands, and San Francisco, California for an HTML5 game jam.
The idea of HTML5 gaming may seem unusual, but if the results from this event are anything to go by, there will be plenty more HTML5 games in the future. In just over 24 hours of coding, attendees were able to produce the seeds of great games, powered by standard web technologies. The games we saw were novel, visually appealing, and in many cases, already very playable.
HTML5 is making it easy to develop games for standard web browsers, and it also provides a way for developers to reach mobiles and tablets with a single code base. Watch for other initiatives, like Mozilla's current HTML5 gaming competition, to take HTML5 gaming to the next level.
Here’s a look at the winners from both venues. You can see a detailed list of all the entries here.
A novel 8-bit style game where you “leap” over the bad guys. A good demo of the Canvas element and a complete game with levels and scoring. Congratulations David Ganzhorn and Mike Rotondo on winning the HTML5 Game Jam in the USA.
A puzzle game where you build a fortress to protect the monkey, demonstrating a physics engine in Canvas. Congratulations Tom Hastjarjanto on winning the HTML5 Game Jam in Europe.
A platform shooter involving turtle-like creatures on wheels, using Canvas. By Wolff Dobson, Charles Lee, Nicolas Coderre, Dan Fessler, Sara Asher. (No online demo at present.)
A refresh on the classic “Snake” game, demonstrating multiplayer powered by NodeJS and WebSocket, and 3D transforms of the canvas element. By David Durman & Ales Sturala. (No online demo at present, but code repository available.)
A casual puzzle game by Bruno Garcia, where you link up adjacent matching fruit.
A stunning 3D game inspired by the classic Syndicate series showcasing just how far we’ve come with Canvas-based graphics. Observe the collision detection and be sure to hit the “Flying Carpet” button as well as the space bar to fire! This game was also shown in the “Web or Native for Mobile Development?” session at the recent Google Developer Days conferences in Europe. Created by Kornel Lesinski, Peter van der Zee, and Edwin Martin.
A few other readily playable games you might enjoy are:
We were also honoured to have keynotes by two pioneers of web-based gaming. In Hilversum, the speaker was Tino Zijdel, creator of DHTML Lemmings back in 2004. Tino, coincidentally a Hilversum local, explained the tricks he used to make the game playable on the browsers of the day. He has subsequently written his account of the Game Jam. It’s in Dutch, so here’s an English translation. There were additional presentations from from Yu Jianrong, who covered ten tips for HTML5 Game Development and Paul Irish on HTML5.
The San Francisco keynote was given by Marcin Wichary, who gave a keynote on games and HTML5. Marcin is the creator of the Pac-Man doodle and also the first version of the popular HTML5Rocks slides. Marcin talked about his experiences in recreating Pac-Man and the timeless aspects of videogaming in modern age, shared some behind-the-scenes trivia, and shared the technology used to write the doodle and debug it.
We thank SPIL Games for hosting and co-organising the Netherlands event, and we also thank Samsung for contributing a Galaxy Tab for the Game Jam at that venue. Developers working on touch apps were able to use the Tab for testing, and we later gave the device away as a prize. Congratulations all who took part!
You can find more details about the event, including links to code repositories and further demos, at HTML5GameJam.com.
More and more websites are enhancing their login systems to include buttons for identity providers such as Google, Yahoo, Facebook, Twitter, Microsoft, etc. Users generally prefer this approach because it makes it easier for them to sign up for a new site that they visit. However if a user already has an account at a website, and they are used to logging in with their email and password, then it is hard to get them to switch to using an identity provider.
Google has recently released a sample site that shows how a website can migrate users away from password based logins, and instead have them leverage an identity provider. This sample site incorporates many of the ideas of the Internet Identity community, as well as feedback from numerous websites who have been on the cutting edge of applying these techniques. The following video provides highlights of some elements of the user experience.
The sample site is at openidsamplestore.com, but we suggest first reading this FAQ which describes the site and has links to additional videos of some of the features. We hope website developers will use these techniques to reduce the need for passwords on their site.
Twenty years ago this month, Tim Berners-Lee published his proposal for the World Wide Web. Since then, web browsers and web programming languages have come a long way. A few of us on the Chrome team decided to write an online guide for everyday users who are curious about the basics of how browsers and the web work, and how their evolution has changed the way we work and play online. Called "20 Things I Learned about Browsers and the Web," this online guidebook is illustrated by Christoph Niemann, and built in HTML5, JavaScript and CSS3, with our friends at Fi.
In building an online book app, HTML5, JavaScript and CSS3 gave us the ability to bring to life features that hearken back to what we love about books with the best aspects of the open web: the app works everywhere, and on any device with a modern browser. Here are a few features of the book experience that we’re particularly excited about:
This illustrated guidebook is best experienced in Chrome or any up-to-date, HTML5-compliant modern browser. We hope you enjoy the read as much as we did creating it, at www.20thingsilearned.com or goo.gl/20things.
Google Person Finder has become a useful tool in responding to natural disasters by reconnecting people with their family and friends. We’ve been looking at the next phase of Google Person Finder and decided to begin hosting the open source project at Google Code. We’re inviting the developer community to help improve Google Person Finder and the PFIF data format.
Google Person Finder provides a common place to search for, comment on, and connect records from many missing person registries. After the January 12th earthquake in Haiti, a team of Googlers worked with the U.S. Department of State to quickly create a site that helped people who were affected by the disaster. The site was used heavily after the Chile earthquake in February and put in action again in April after the Qinghai earthquake in China and in August for the Pakistan floods.
The software powering Google Person Finder is open source so we’re listing the open issues and feature requests we’ve received over the past few months in hopes the community can help us improve the code. We’ve created a Developer Guide to help developers get started. As always, we invite those interested to post questions on our public Person Finder discussion group. Those who are interested in improving the PFIF data format can also join the PFIF discussion group.
In addition to opening our product for developers, we’ve decided it’s now time to turn off our Google Person Finder instances for Haiti, Chile, China, and Pakistan. It doesn’t seem useful to be serving these missing person records on the Internet indefinitely, so we intend for each instance of Google Person Finder to be running for a limited time. Once an instance has served its purpose, we will archive the PFIF records in a secure location for historical preservation for one year while we work to identify a permanent owner for these records. Assuming a long-term owner cannot be found, we will delete the records after one calendar year. For more information, please feel free to review the Google Person Finder FAQ.
If you’ve used Google Search recently, you may have noticed a new feature that we’re calling Instant Previews. By clicking on the (sprited) magnifying glass icon next to a search result you see a preview of that page, often with the relevant content highlighted. Once activated, you can mouse over the rest of the results and quickly (instantly!) see previews of those search results, too.
Adding this feature to Google Search involved a lot of client-side Javascript. Being Google, we had to make sure we could deliver this feature without slowing down the page. We know our users want their results fast. So we thought we’d share some techniques involved in making this new feature fast.
This is nothing new for Google Search: all our Javascript is compiled to make it as small as possible. We use the open-sourced Closure Compiler. In addition to minimizing the Javascript code, it also re-writes expressions, reuses variables, and prunes out code that is not being used. The Javascript on the search results page is deferred, and also cached very aggressively on the client side so that it’s not downloaded more than once per version.
When you activate Instant Previews, the result previews are requested by your web browser.There are several ways to fetch the data we need using Javascript. The most popular techniques are XmlHttpRequest (XHR) and JSONP. XHR generally gives you better control and error-handling, but it has two drawbacks: browsers caching tends to be less reliable, and only same-origin requests are permitted (this is starting to change with modern browsers and cross-origin resource sharing, though). With JSONP, on the other hand, the requested script returns the desired data as a JSON object wrapped in a Javascript callback function, which in our case looks something like
google.vs.r({"dim":[302,585],"url":"http://example.com",ssegs:[...]}).
Although error handling with JSONP is a bit harder to do compared to XHR (not all browsers support onerror events), JSONP can be cached aggressively by the browser, and is not subject to same-origin restrictions. This last point is important for Instant Previews because web browsers restrict the number of concurrent requests that they send to any one host. Using a different host for the preview requests means that we don’t block other requests in the page.
onerror
There are a couple of tricks when using JSONP that are worth noting:
At this point you are probably curious as to what we’re returning in our JSONP calls, and in particular, why we are using JSON and not just plain images. Perhaps you even used Firebug or your browser’s Developer Tools to examine the Instant Previews requests. If so, you will have noticed that we send back the image data as sets of data URIs. Data URIs are base64 encodings of image data, that modern browsers (IE8+, Chrome, Safari, Firefox, Opera, etc) can use to display images, instead of loading them from a server as usual.
To show previews, we need the image, and the relevant content of the page for the particular query, with bounding boxes that we draw on top of the image to show where that content appears on the page. If we used static images, we’d need to make one request for the content and one request for the image; using JSONP with data URIs, we make just one request. Data URIs are limited to 32K on IE8, so we send “slices” that are all under that limit, and then use Javascript to generate the necessary image tags to display them. And even though base64 encoding adds about 33% to the size of the image, our tests showed that gzip-compressed data URIs are comparable in size to the original JPEGs.
We use caching throughout our implementation, but it’s important to not forget about client-side caching as well. By using JSONP and data URIs, we limit the number of requests made, and also make sure that the browser will cache the data, so that if you refresh a page or redo a query, you should get the previews, well... instantly!
There’s an exciting new event happening December 6th dubbed the “Woodstock for Cloud Developers.” We’ll be participating at Cloudstock, an industry event taking place in San Francisco’s Moscone West, that brings together a growing developer community and some of the leading cloud technology companies (such as Google, vmware, Salesforce.com and Amazon) to learn, hack and network.
Google is a strong believer in the open technologies powering the web, such as HTML5. Cloud computing is about powering innovations on the web with platforms and services that make developers like you more efficient and allow you to concentrate on solving business problems. No longer do you have to worry about the hassle of acquiring and managing servers, disks, RAM and CPU-- it’s all accessible in the cloud.
Google will be presenting the following sessions at Cloudstock:
We have another session which will be announced shortly-- stay tuned to this blog and the GoogleCode twitter account!
Register for the free Cloudstock event at:http://www.cloudstockevent.com/Moscone WestSan Francisco, CAMonday, December 6th, 2010
Looking forward to meeting you there!
Google Project Hosting is all about helping software developers work together on source code, code reviews, issues, and wiki pages for technical documentation. In fact, the projects we host have collectively accumulated several million issue comments. Working together means that, from time to time, the ball is in your court and you need to respond to other users.
We send out notification emails to let the appropriate users know when an issue has been entered or a comment has been added to an issue, wiki page, or code review. These emails contain a link that allows you to enter your response in your project on code.google.com/p. But starting now, we are making it much easier and faster to respond to these comments by processing email replies that you send us.
So, check your inbox for new notification emails sent directly to you. When you see an email footer line that says that you can reply, just press the reply button in your email client, bang out a thoughtful response, and hit “Send”. Project committers and owners can even update an issue’s status and other values via email. For example, to let your teammates know that you are working on an urgent defect report that just came in, reply with:
Please try it out the next time you receive a notification email. If you have questions, see our documentation on inbound email and user groups.
We know that developers are always interested in learning about new APIs and best practices for existing ones. And, one of the best ways to learn is face to face interaction with an expert in the subject.
Your friendly neighborhood Google Developer Relations team members work everyday with the APIs you care about. We host, as well as attend, a number of events around the world to help as many developers as possible throughout the year. However, it hasn’t been easy for interested developers to find relevant events close to them.
We also realized that while many developers have met at least a couple of our Developer Advocates, it’s hard to tie an Advocate to their API expertise.
Enter the Advocate Bios and Developer Events pages.
The Advocates Bios page provides names, pictures and short descriptions of Developer Relations team members. You can filter them by what they work on and/or where they’re based out of.
The Developer Events page is a mashup of the Calendar and Maps APIs, running on an App Engine backend. Want to know about upcoming Android events in Prague? Or whether Patrick Chanezon is speaking at the GDD in Munich on Nov 9th? (He is!) You can do all of that and more with the Developer Events page.
Both the bios and the events pages are conveniently linked under the Developer Resources section on the Google Code home page.
We hope to see you at the events!
Last year, as part of Google’s initiative to make the web faster, we introduced Page Speed, a tool that gives developers suggestions to speed up web pages. It’s usually pretty straightforward for developers and webmasters to implement these suggestions by updating their web server configuration, HTML, JavaScript, CSS and images. But we thought we could make it even easier -- ideally these optimizations should happen with minimal developer and webmaster effort.
So today, we’re introducing a module for the Apache HTTP Server called mod_pagespeed to perform many speed optimizations automatically. We’re starting with more than 15 on-the-fly optimizations that address various aspects of web performance, including optimizing caching, minimizing client-server round trips and minimizing payload size. We’ve seen mod_pagespeed reduce page load times by up to 50% (an average across a rough sample of sites we tried) -- in other words, essentially speeding up websites by about 2x, and sometimes even faster.
(Video comparison of the AdSense blog site with and without mod_pagespeed)
Here are a few simple optimizations that are a pain to do manually, but that mod_pagespeed excels at:
We’re working with Go Daddy to get mod_pagespeed running for many of its 8.5 million customers. Warren Adelman, President and COO of Go Daddy, says:
"Go Daddy is continually looking for ways to provide our customers the best user experience possible. That's the reason we partnered with Google on the 'Make the Web Faster' initiative. Go Daddy engineers are seeing a dramatic decrease in load times of customers' websites using mod_pagespeed and other technologies provided. We hope to provide the technology to our customers soon - not only for their benefit, but for their website visitors as well.”
We’re also working with Cotendo to integrate the core engine of mod_pagespeed as part of their Content Delivery Network (CDN) service.
mod_pagespeed integrates as a module for the Apache HTTP Server, and we’ve released it as open-source for Apache for many Linux distributions. Download mod_pagespeed for your platform and let us know what you think on the project’s mailing list. We hope to work with the hosting, developer and webmaster community to improve mod_pagespeed and make the web faster.
Cross-posted from the Google Web Toolkit Blog
Earlier this year at Google I/O, we announced a collaboration between Google and VMware focused on making it easy to build business-oriented, cloud portable web apps. We showed how businesses could use our integrated developer tools to build modern web apps that are “cloud ready” from the start, and can be deployed to any standard environment, including Google App Engine and on VMware vFabric on-premise solutions. Today we are happy to announce that these tools will be generally available within the next few weeks.
Of course, if you’re itching to get a head start, you can jump right in by downloading the release candidate version of SpringSource Tool Suite.
If you’d prefer to wait for the general release, you can sign up to be notified as soon as they are available.
The list of developer tools includes that are available as part of this collaboration include:
Spring Roo and Google Web Toolkit - Spring Roo, a next generation rapid application development tool, combined with the power of Google Web Toolkit (GWT) enables developers to build rich browser apps in enterprise production environments. These GWT-powered applications leverage modern browser technologies such as AJAX and HTML5 to create the most compelling end-user experience on both desktops and mobile browsers.
Spring Insight and Google Speed Tracer - Google’s Speed Tracer with VMware’s Spring Insight performance tracing technology enable end-to-end performance visibility into cloud applications. This integration provides a holistic view into the web application performance, improving the end-user experience by optimizing the client side as well as the server side.
SpringSource Tool Suite and Google Plugin for Eclipse - The integration of SpringSource Tool Suite and the Google Plugin for Eclipse makes it easy for developers to build and maintain large scale, web-based, enterprise applications, putting tools that were previously only available when building desktop and server solutions in the hands of those building cutting edge web apps.
For a complete “Getting Started” guide, be sure to checkout Getting Started with GWT, Spring Roo, and SpringSource Tool Suite.
Both teams are excited about the strides we can make in the mobile web app space. As it stands today, the current technology stack makes it possible to create optimized web apps targeted for the mobile browser. Longer term, we will be looking at incorporating mobile best practices, styled UIs, and HTML5 features such as app cache, local database storage, and geolocation to make the developer and end-user experience first class.
As always, we’d love to hear your feedback and thoughts on this release. Our GWT developer forum is the best place to post this information. Happy coding!
Last week Jason Grigsby visited Google as part of our Web Exponents speaker series which highlights innovations in web technology. Jason is a tech leader in mobile web development. In addition to spotting trends in the mobile space, Jason is at the front lines building mobile apps at Cloud Four. His humorous and informative talk includes technology recommendations and insightful examples from the world of mobile. Check out the video of the talk below. You can also download the slides.
Jason’s mobile strategy counterexamples include Chanel (they have an iPhone app but their website is unusable on the iPhone) and the difficulties of finding an Apple Store on the iPhone. His DOs and DON’Ts are:
DOs:
DON’Ts:
These all ring true for anyone with experience building for mobile. The hard part is figuring out the right solution for providing the right experience for desktop as well as diverse mobile devices. Jason gives a glimpse into the key features of a solution:
The challenge in my opinion is in the steps of breaking out content from markup and determining which content is appropriate for a given device. We need frameworks that better support these ideas, but there’s still a lot of heavy design work on the developer’s shoulders. Jason points to NPR as an example of a large site that has successfully implemented this architecture. Check out Jason’s talk to find out more, and also check out some of the other videos in the Web Exponents playlist.
import gdata.analytics.clientAPP_NAME = 'goal_names_demo'my_client = gdata.analytics.client.AnalyticsClient(source=APP_NAME)# Authorizemy_client.client_login( INSERT_USER_NAME, INSERT_PASSWORD, APP_NAME, service='analytics')# Make a query.query = gdata.analytics.client.GoalQuery( acct_id='INSERT_ACCOUNT_ID', web_prop_id='INSERT_WEB_PROP_ID', profile_id='INSERT_PROFILE_ID')# Get and print results.results = my_client.GetManagementFeed(query)for entry in results.entry: print 'Goal number = %s' % entry.goal.number print 'Goal name = %s' % entry.goal.name print 'Goal value = %s' % entry.goal.value
Cross-posted from the Chromium Blog
As part of Google’s initiative to make the web faster, over the past few months we have released a number of tools to help site owners speed up their websites. We launched the Page Speed Firefox extension to evaluate the performance of web pages and to get suggestions on how to improve them, we introduced the Speed Tracer Chrome extension to help identify and fix performance problems in web applications, and we released a set of closure tools to help build rich web applications with fully optimized JavaScript code. While these tools have been incredibly successful in helping developers optimize their sites, as we’ve evaluated our progress, we continue to notice a single component of web pages is consistently responsible for the majority of the latency on pages across the web: images.
Most of the common image formats on the web today were established over a decade ago and are based on technology from around that time. Some engineers at Google decided to figure out if there was a way to further compress lossy images like JPEG to make them load faster, while still preserving quality and resolution. As part of this effort, we are releasing a developer preview of a new image format, WebP, that promises to significantly reduce the byte size of photos on the web, allowing web sites to load faster than before.
Images and photos make up about 65% of the bytes transmitted per web page today. They can significantly slow down a user’s web experience, especially on bandwidth-constrained networks such as a mobile network. Images on the web consist primarily of lossy formats such as JPEG, and to a lesser extent lossless formats such as PNG and GIF. Our team focused on improving compression of the lossy images, which constitute the larger percentage of images on the web today.
To improve on the compression that JPEG provides, we used an image compressor based on the VP8 codec that Google open-sourced in May 2010. We applied the techniques from VP8 video intra frame coding to push the envelope in still image coding. We also adapted a very lightweight container based on RIFF. While this container format contributes a minimal overhead of only 20 bytes per image, it is extensible to allow authors to save meta-data they would like to store.
While the benefits of a VP8 based image format were clear in theory, we needed to test them in the real world. In order to gauge the effectiveness of our efforts, we randomly picked about 1,000,000 images from the web (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without perceptibly compromising visual quality. This resulted in an average 39% reduction in file size. We expect that developers will achieve in practice even better file size reduction with WebP when starting from an uncompressed image.
To help you assess WebP’s performance with other formats, we have shared a selection of open-source and classic images along with file sizes so you can visually compare them on this site. We are also releasing a conversion tool that you can use to convert images to the WebP format. We’re looking forward to working with the browser and web developer community on the WebP spec and on adding native support for WebP. While WebP images can’t be viewed until browsers support the format, we are developing a patch for WebKit to provide native support for WebP in an upcoming release of Google Chrome. We plan to add support for a transparency layer, also known as alpha channel in a future update.
We’re excited to hear feedback from the developer community on our discussion group, so download the conversion tool, try it out on your favorite set of images, and let us know what you think.
