Wednesday, November 30, 2011

JavaScript Client Library for Google APIs Alpha version released

author photo
Brendan
author photo
Antonio
By Brendan O’Brien and Antonio Fuentes, Google Developer Team

Today we reached another milestone in our efforts to provide infrastructure and tools to make it easier for developers to use Google APIs: we have released the Google APIs Client Library for JavaScript in Alpha. This client library is the latest addition to our suite of client libraries, which already includes Python, PHP, and Java.

This compact and efficient client library provides access to all the Google APIs that are listed in the APIs Explorer. The client library is also flexible, supporting multiple browser environments including Chrome 8+, Firefox 3.5+, Internet Explorer 8+, Safari 4+, and Opera 11+. In addition, the JavaScript client library supports OAuth 2.0 authorization methods.

You can load the client library using the following script tag:
<script src="https://apis.google.com/js/client.js?onload=CALLBACK"></script>
Loading an API and making a request is as easy as executing:
gapi.client.load('API_NAME', 'API_VERSION', CALLBACK); // Returns a request object which can then be executed. // METHOD_NAME is only available once CALLBACK runs. var request = gapi.client.METHOD_NAME(PARAMETERS_OBJECT); request.execute(callback);
You can use the APIs Explorer to check all the methods available for an API, as well as the parameters for each method. For instance, use the above syntax with the plus.activities.search method of the Google+ API to query activities:

<!DOCTYPE html> <html>  <head>  </head>  <body>    <script type="text/javascript"> function init() {  // Load your API key from the Developer Console  gapi.client.setApiKey('YOUR_API_KEY');  // Load the API  gapi.client.load('plus', 'v1', function() {      var request = gapi.client.plus.activities.search({          'query': 'Google+',            'orderby': 'best'            });      request.execute(function(resp) {          // Output title          var heading = document.createElement('h4');          heading.appendChild(document.createTextNode( resp.title));          var content = document.getElementById('content');          content.appendChild(heading);          // Output content of the response          if (!resp.items) {            content.appendChild(document.createTextNode( 'No results found.'));          } else {            for (var i = 0; i < resp.items.length; i++) {              var entry = document.createElement('p');            entry.appendChild(document.createTextNode( resp.items[i].title));              content.appendChild(entry);            }          }        });    }); }    </script>    <script src="https://apis.google.com/js/client.js?onload=init"></script>    <div id="content"></div>  </body> </html>
To try this yourself, sign up in the Google APIs console or refer to the documentation on acquiring and using a developer key in the Google+ API.

The Google APIs Client Library for JavaScript is currently in Alpha, which means that we are actively developing it, but wanted to get the library in your hands as soon as possible, and we welcome any feedback to make the code better. While you can use the current library to start writing code, you should use caution when writing production code as library code changes may break your application. We are working hard to upgrade this release to Beta and beyond soon, and to release even more client libraries.

To get started, visit the JavaScript Client Library documentation page. We also welcome your feedback, which you can provide using the JavaScript client group.


Brendan O'Brien is a Software Engineer for the Browser Client group at Google. Prior to working on JavaScript APIs he was a frontend engineer for iGoogle. He is passionate about JavaScript and enjoys building web applications.

Antonio Fuentes is a Product Manager for the Google API Infrastructure group. He has experience launching products in the cloud computing, infrastructure, and virtualization space.

Posted by Scott Knaster, Editor

Tuesday, November 29, 2011

Introducing Au-to-do, a sample application built on Google APIs

Author Photo
By Dan Holevoet, Developer Relations Team

A platform is more than the sum of its component parts. You can read about it or hear about it, but to really learn what makes up a platform you have to try it out for yourself, play with the parts, and discover what you can build.

With that in mind, we started a project called Au-to-do: a full sample application implementing a ticket tracker, built using Google APIs, that developers can download and dissect.

Au-to-do screen shot

Au-to-do currently uses the following APIs and technologies:
Additional integrations with Google APIs are on their way. We are also planning a series of follow-up blog posts discussing each of the integrations in depth, with details on our design decisions and best practices you can use in your own projects.

By the way, if you’re wondering how to pronounce Au-to-do, you can say "auto-do" or "ought-to-do" — either is correct.

Ready to take a look at the code? Check out the getting started guide. Found a bug? Have a great idea for a feature or API integration? Let us know by filing a request.

Happy hacking!


Dan Holevoet joined the Google Developer Relations team in 2007. When not playing Starcraft, he works on Google Apps, with a focus on the Calendar and Contacts APIs. He's previously worked on iGoogle, OpenSocial, Gmail contextual gadgets, and the Google Apps Marketplace.

Posted by Scott Knaster, Editor



Monday, November 28, 2011

Simplifying Access Control in Google Cloud Storage

Author Photo
By Navneet Joneja, Product Manager

Google Cloud Storage is a robust, high-performance service that enables developers and businesses to use Google’s infrastructure to power their data. Today, we’re announcing a new feature that makes it even easier to control and share your data.

Per-Bucket Default Object ACLs

Customers building a wide variety of applications have asked us for an easier mechanism to control the permissions granted on newly created objects. Now you can define your access control policy for a bucket once by specifying a Default Object ACL for any bucket, and we’ll automatically apply that ACL to any object without an explicitly defined ACL. You can always override the default by providing a canned ACL when you upload the object or by updating the object’s ACL afterwards. This mechanism simplifies wide variety of use cases, including data sharing, controlled-access data sets and corporate drop-boxes.

New buckets without Default ACLs

After analyzing how customers use our service, we’ve also decided to make a few small changes to the behavior of buckets that have no explicit default object ACL. Effective today, new buckets are created with an implied project-private default object ACL. In other words, project editors and owners will have FULL_CONTROL access to new objects, and project viewers will have READ access to them. This change better aligns the default behavior with how our customers use storage. You can change a bucket’s default object ACL at any time after creating the bucket.

Existing buckets have an effective default object ACL of "private", and they will continue to work as they always have until and unless you specify a new default object ACL for them.


Navneet Joneja loves being at the forefront of the next generation of simple and reliable software infrastructure, the foundation on which next-generation technology is being built. When not working, he can usually be found dreaming up new ways to entertain his intensely curious one-year-old.

Posted by Scott Knaster, Editor

Google I/O 2012 extended to three days from June 27-29, 2012

Author Photo
By Monica Tran, Google I/O Team

After Google I/O 2011, you consistently told us you wanted more time to attend sessions, visit our partners in the Developer Sandbox, and meet 1:1 with the engineers behind Google’s developer platforms and APIs. We recently received an unexpected opportunity to extend Google I/O to three days, so as we announced on our +Google Developers page, we are moving the conference to June 27-29, 2012. It will still take place at Moscone Center West in San Francisco.

Google I/O 2012
June 27-29, 2012
Moscone Center West, San Francisco


In the meantime, be sure to brush up on your coding skills. They’ll come in handy when the new application process opens in February. That’s all we can tell you for now, but we’d advise against making travel arrangements until then. Continue following us at our Google Developers page on Google+ to be the first to get #io12 updates!


This post supersedes our previous Save the Date announcement. Please update your calendars: Google I/O will be coming to Moscone Center in San Francisco on June 27-29. We will be responding to FAQs via our thread on Google+.


You might remember Monica Tran from I/O Live or one of our eight Google Developer Days around the world. This year, she’s back to lead the charge on Google I/O 2012.

Posted by Scott Knaster, Editor

Friday, November 18, 2011

Fridaygram: scribbling on maps, lightweight material, canine antics

Author Photo
By Scott Knaster, Google Code Blog Editor

Earlier this week, our Google Maps API got a great new feature. When you build an application with the Maps API, you can now enable users to draw on the maps. There are tools for various shapes, so your users can draw circles or boxes to highlight locations, just like they would with physical maps. And to be even more like physical maps, users can use the tools to approximate drawing a coffee cup stain or a big crinkle.



Speaking of physical things, here’s one that exists in the real world, but barely makes a dent. Researchers in California have created what they say is the world’s lightest material. The material has a density of 0.9 mg/cc and is light enough to sit atop the fluff on a dandelion, although that usage seems impractical.

Finally, for weekend fun, take a look at this peer-reviewed paper entitled "A Vicious Cycle: A Cross-Sectional Study of Canine Tail-Chasing and Human Responses to It, Using a Free Video-Sharing Website". It will make you want to spend more time on YouTube, in the name of science.


Fridaygram is our weekly nerdy attempt at fun for developers. Fridaygrams have Google things, science stuff, and sometimes, Easter eggs.


Lossless and transparency encoding in WebP

Urvang
Vikas
Jyrki

By Jyrki Alakuijala, Vikas Arora, and Urvang Joshi, Software Engineers, WebP Team

Cross-posted with the Chromium Blog

In September 2010 we announced the WebP image format with lossy compression. WebP was proposed as an alternative to JPEG, with 25–34% better compression compared to JPEG images at equivalent SSIM index. We received lots of feedback, and have been busy improving the format. Last month we announced WebP support for animation, ICC profile, XMP metadata and tiling. Today, we introduce a new mode in WebP to compress images losslessly, and support for transparency – also known as alpha channel – in both the lossless and lossy modes.

With these new modes, you can now use WebP to better compress all types of images on the web. Photographic images typically encoded as JPEG can be encoded in WebP lossy mode to achieve smaller file size. Icons and graphics can be encoded better in WebP lossless mode than in PNG. WebP lossy with alpha can be used to create transparent images that have minimal visual degradation, yet are much smaller in file size. Animations compressed as GIFs can use animation support in WebP.

New lossless mode

Our main focus for lossless mode has been in compression density and simplicity in decoding. On average, we get a 45% reduction in size when starting with PNGs found on the web, and a 28% reduction in size compared to PNGs that are re-compressed with pngcrush and pngout. Smaller images on the page mean faster page loads.

New transparency mode

Today, webmasters who need transparency must encode images losslessly in PNG, leading to a significant size bloat. WebP alpha encodes images with low bits-per-pixel and provides an effective way to reduce the size of such images. Lossless compression of the alpha channel adds just 22% bytes over lossy (quality 90) WebP encoding. Smaller alpha overhead means richer images on webpages.

You can find a more detailed compression study for these modes here and sample images in the WebP-Gallery. The bit stream specification has not been finalized, and the encoding and decoding implementations have not yet been optimized for processing speed. We encourage you to try it out on your favorite set of images, check out the code, and provide feedback. We hope WebP will now handle all your needs for web images, and we're working to get WebP supported in more browsers.


Dr. Jyrki Alakuijala is a Software Engineer with a special interest in data compression. He is a father of five daughters, and sings in the Finnish Choir in Zürich. Before joining Google, Jyrki worked in neurosurgical and radiotherapy development.

Vikas Arora is a Software Engineer with a special interest in signal processing and data compression. Before joining Google, Vikas worked in the VLSI domain developing digital and analog signal simulators.

Urvang Joshi is a Software Engineer, especially interested in image processing, machine learning, and computer vision. He is also a table tennis and chess enthusiast.

Posted by Scott Knaster, Editor

Thursday, November 17, 2011

Introducing Closure Stylesheets


By Michael Bolin, Open Source Engineer

Cross-posted from the Open Source at Google blog

(CSS is for programming, not for pasting.)

When the Closure Tools were first released a little over two years ago, they gave web developers the ability to organize and optimize their JavaScript and HTML in a new way. But there was something missing, namely, a tool to help manage CSS.

You see, the nature of CSS runs contrary to the DRY principle that is exhibited in good software engineering. For example, if there is a color that should be used for multiple classes in a stylesheet, a developer has no choice but to copy-and-paste it everywhere because CSS has no concept of variables. Similarly, if there is a value in a stylesheet that is derived from other values, there is no way to express that because CSS also lacks functions. Common patterns of style blocks are duplicated over and over because CSS has no macros. All of these properties of CSS conspire to make stylesheets extremely difficult to maintain.

To this end, we are excited to introduce the missing piece in the Closure Tools suite: Closure Stylesheets. Closure Stylesheets is an an extension to CSS that adds variables, functions, conditionals, and mixins to standard CSS. The tool also supports minification, linting, RTL flipping, and CSS class renaming. As the existing Closure Tools have done for JavaScript and HTML, Closure Stylesheets will help you write CSS in a maintainable way, while also empowering you to deliver optimized code to your users. We hope you enjoy it! Please let us know what you think in the discussion forum.


Michael Bolin is an Open Source Engineer at Google.

Posted by Scott Knaster, Editor

Wednesday, November 16, 2011

Flash developers: export to HTML5 with new Swiffy extension

Author Photo
By Esteban de la Canal, Software Engineer

We launched Google Swiffy in July. Swiffy enables you to convert Flash SWF files to HTML5. One of our main aims for Swiffy is to let you continue to use Flash as a development environment, even when you’re developing animations for environments that don’t support Flash.

To speed up the development process, we’ve built the Swiffy Extension for Flash Professional. The extension enables you to convert your animation to HTML5 with one click (or keyboard shortcut). The extension is available for both Mac and Windows, and it uses Swiffy as a web service, so you’ll always get our latest and greatest conversion. Information about the conversion process is shown within Flash Professional.

screen shot

You can download the Swiffy Extension from the Google Swiffy site. We hope it will streamline your workflow when you use Flash and Swiffy to produce HTML5 animations. Please let us know how well it works for you via our feedback page.


Esteban de la Canal is a Software Engineer on the Swiffy team. He also enjoys game development, particularly weird-looking snake-like games in Flash.

Posted by Scott Knaster, Editor

Monday, November 14, 2011

Upcoming changes to OAuth 2.0 endpoint

Author Photo
By Justin Smith, Senior Product Manager

UPDATE 11/14: After considering the feedback and timing, we have decided to delay the launch of the changes described in this post. The new date for these changes is December 7th, 2011. Once again, we expect these changes to have minimal impact. If you have any questions or comments, please post on the OAuth 2.0 Group. We will be actively monitoring that group and will work to respond quickly.


Original post:

In the coming weeks we will be making three changes to the experimental OAuth 2.0 endpoint. We expect the impact to be minimal, and we’re emailing developers who are most likely to be affected.

We will be releasing these changes on December 7, 2011. This post describes the changes, their impact, and how they can be mitigated.

Change #1: Error responses for client-side web applications

The first change relates to the way errors are returned in OAuth 2.0 client-side web applications. It does not impact server-side, native, or device flows.

The current behavior of the OAuth 2.0 endpoint in certain error conditions is to return the error to the application as a query string parameter, for example:

https://www.example.com/back?error=access_denied.

The OAuth 2.0 specification indicates that the error should be returned in the fragment of the response. We are updating our OAuth 2.0 implementation to support the most recent draft of the specification. As a result, we will be changing the way we return errors to applications in the client-side flow.

As an example, today an error returns to your application as

https://www.example.com/back?error=access_denied. After this change, it will be returned as

https://www.example.com/back#error=access_denied.

There is no mitigation for this change, so your application will have to handle these types of errors in client-side script.

Change #2: Offline access as a separate parameter

The second change impacts the OAuth 2.0 server-side flow only. It does not impact client-side, native, or device flows. For context, this flow consists of the following steps:
  1. Redirect the browser to the Google OAuth 2.0 endpoint.
  2. The user will be shown a consent page.
  3. If the user consents, parse the authorization code from the query string of the response.
  4. Exchange the authorization code for a short-lived access token and a long-lived refresh token.
Once your application has obtained a long-lived refresh token (step 4), it may access a Google API at any time. This means server-side applications do not require the end-user to be present when obtaining new access tokens. We’re calling this type of access offline.

The client-side flow, in contrast, requires the user to be present when obtaining an access token. This type of access is called online.

With this change, we will be exposing online and offline access as a separate parameter that’s available only in the server-side flow.

When your application requests offline access, the consent page shown to a user will reflect that your application requests offline access and your application will receive an access and a refresh token. Once your application has a refresh token, it may obtain a new access token at any time.

When your application requests online access, your application will only receive an access token. No refresh token will be returned. This means that a user must be present in order for your application to obtain a new access token.

If unspecified in the request, online is the default.

A mitigation for this change is described at the end of this post.

Change #3: Server-side auto-approval

This change also impacts the OAuth 2.0 server-side flow only.

In the current implementation of OAuth2, every time your application redirects a user to Google, that user must give explicit consent before an authorization code is given to your application. As a result, sending a user through the flow another time requires them to see the consent screen again. Most applications don’t do this, but rather use the existing server-side flow as it was intended: a one-time association (import contacts, calendar operations, etc.) where the result is a refresh token which may be used to obtain new access tokens.

The behavior is changing to the following:
  • Users will only see the consent screen on their first time through the sequence.
  • If the application requests offline access, only the first authorization code exchange results in a refresh token.
To put it another way, consent will be auto-approved for returning users unless the user has revoked access. Refresh tokens are not returned for responses that were auto-approved.

The next section describes how to mitigate this change.

Mitigation of offline access (#2) and auto-approval (#3) changes

If you want to keep the existing behavior in your server-side applications, include the approval_prompt=force and access_type=offline parameters in an authorization code request.

For example, if the following is a target URL for obtaining an authorization code today:
https://accounts.google.com/o/oauth2/auth?
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code
You can maintain the current behavior by changing the target URL to:
https://accounts.google.com/o/oauth2/auth?
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code&
access_type=offline&
approval_prompt=force
You may start including these parameters in authorization code requests today.

Questions?

If you have any questions or comments, please post on the OAuth 2.0 Group (https://groups.google.com/forum/#!forum/OAuth 2.0-dev). We will be actively monitoring that group and will work to respond quickly.


Justin Smith is a Product Manager who works on authentication and authorization technologies at Google. He enjoys woodworking, cycling, country music, and the company of his wife (not necessarily in that order).

Posted by Scott Knaster, Editor

Google BigQuery Service: Big data analytics at Google speed


By Ju-kay Kwek, Product Manager

(Cross-posted on the Google App Engine Blog and the Google Enterprise Blog.)

Rapidly crunching terabytes of big data can lead to better business decisions, but this has traditionally required tremendous IT investments. Imagine a large online retailer that wants to provide better product recommendations by analyzing website usage and purchase patterns from millions of website visits. Or consider a car manufacturer that wants to maximize its advertising impact by learning how its last global campaign performed across billions of multimedia impressions. Fortune 500 companies struggle to unlock the potential of data, so it’s no surprise that it’s been even harder for smaller businesses.

We developed Google BigQuery Service for large-scale internal data analytics. At Google I/O last year, we opened a preview of the service to a limited number of enterprises and developers. Today we're releasing some big improvements, and putting one of Google's most powerful data analysis systems into the hands of more companies of all sizes.
  • We’ve added a graphical user interface for analysts and developers to rapidly explore massive data through a web application.
  • We’ve made big improvements for customers accessing the service programmatically through the API. The new REST API lets you run multiple jobs in the background and manage tables and permissions with more granularity.
  • Whether you use the BigQuery web application or API, you can now write even more powerful queries with JOIN statements. This lets you run queries across multiple data tables, linked by data that tables have in common.
  • It’s also now easy to manage, secure, and share access to your data tables in BigQuery, and export query results to the desktop or to Google Cloud Storage.

Michael J. Franklin, Professor of Computer Science at UC Berkeley, remarked that BigQuery (internally known as Dremel) leverages “thousands of machines to process data at a scale that is simply jaw-dropping given the current state of the art.” We’re looking forward to helping businesses innovate faster by harnessing their own large data sets. BigQuery is available free of charge for now, and we’ll let customers know at least 30 days before the free period ends. We’re bringing on a new batch of pilot customers, so let us know if your business wants to test drive BigQuery Service.


Ju-kay Kwek is a Product Manager for Google BigQuery Service.

Posted by Scott Knaster, Editor