Friday, November 18, 2011

[Gd] Fridaygram: scribbling on maps, lightweight material, canine antics

| More

The official Google Code blog: 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.


URL: http://googlecode.blogspot.com/2011/11/fridaygram-scribbling-on-maps.html

[Gd] Lossless and Transparency Encoding in WebP

| More

Chromium Blog: Lossless and Transparency Encoding in WebP

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.

Posted by Jyrki Alakuijala, Vikas Arora, and Urvang Joshi, Software Engineers
URL: http://blog.chromium.org/2011/11/lossless-and-transparency-encoding-in.html

[Gd] Dev Channel Update

| More

Chrome Releases: Dev Channel Update


The Dev channel has been updated to 17.0.942.0 for Windows, Mac, Linux, and Chrome Frame.  This build contains the following updates:

All
  • Updated V8 - 3.7.7.0.
  • Fixed New Tab page apps re-ordering issue.
  • Policy support for disabling the Cloud Print Connector has been added.
Windows
  • Fixed an issue where Chrome app windows would hang. [r110239]
Known Issues
  • Crash when notification occurs [Issue: 103427]
Full details about what changes are in this build are available in the SVN revision log.  Interested in switching release channels?  Find out how.  If you find a new issue, please let us know by filing a bug.

Dharani Govindan
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/11/dev-channel-update_17.html

[Gd] Stable Channel Update for Chromebooks

| More

Chrome Releases: Stable Channel Update for Chromebooks

The Stable channel has been updated to 15.0.874.121 (Platform version: 1011.137) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).


Highlights:
  • New flash
  • Security fixes
  • Stability fixes
If you find new issues, please let us know by visiting our help site or filing a bug. You can also submit feedback using "Report an issue" under the wrench icon. Interested in switching to the Dev channel? Find out how.

Josafat Garcia
Google Chrome

URL: http://googlechromereleases.blogspot.com/2011/11/stable-channel-update-for-chromebooks_17.html

[Gd] Lossless and transparency encoding in WebP

| More

The official Google Code blog: 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

URL: http://googlecode.blogspot.com/2011/11/lossless-and-transparency-encoding-in.html

[Gd] Introducing Closure Stylesheets

| More

The official Google Code blog: 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
URL: http://googlecode.blogspot.com/2011/11/introducing-closure-stylesheets.html

Thursday, November 17, 2011

[Gd] Introducing the next version of the Google Calendar API!

| More

Google Apps Developer Blog: Introducing the next version of the Google Calendar API!

The Google Calendar API is one of Google’s most used APIs. Today, we’re rolling out a new version of the API that will give developers even more reasons to use it. Version three of the Google Calendar API provides several improvements over previous versions of the API:

Developers familiar with the Google Tasks API will feel right at home with Calendar API v3, as it uses similar syntax and conventions, as well as the same base client libraries. These Google-supported client libraries, based on discovery, are available in many languages with:

If you’re new to the Google Calendar API, getting started is easy. Check out the Getting Started Guide, which will walk you through the basic concepts of Google Calendar, the API, and authorization. Once you’re ready to start coding, the Using the API page will explain how to download and use the client libraries in several languages.

If you’d like to try out some queries before you start coding, check out the APIs Explorer and try out some example queries with the new API.

Developers already using older versions of the API can refer to our Migration Guide. This interactive guide offers side-by-side examples of the API in v2 and v3 flavors across both the protocol and multiple languages. Simply hover over the code in v2 (or v3) and see the equivalent in the other version.

With our announcement of v3 of the API, we’re also announcing the deprecation of the previous versions (v1 and v2). The older versions enter into a three year deprecation period, beginning today, and will be turned off on November 17, 2014.

We’d love to hear your feedback on the Google Calendar API v3. Please feel free to reach out to us in the Google Calendar API forum with any questions or comments you have. We’ll also be hosting live Office Hours (via Google+ Hangout) on 11/30 from 8am-8:45am EST to discuss the new API. We hope to see you then!


Dan Holevoet   profile

Dan 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.


Alain Vongsouvanh   profile

Alain is a Developer Programs Engineer for Google Apps with a focus on Google Calendar and Google Contacts. Before Google, he graduated with his Masters in Computer Science from EPITA, France.

URL: http://googleappsdeveloper.blogspot.com/2011/11/introducing-next-version-of-google.html

[Gd] RPF: Google's Record Playback Framework

| More

Google Testing Blog: RPF: Google's Record Playback Framework

By Jason Arbon


At GTAC, folks asked how well the Record/Playback (RPF) works in the Browser Integrated Test Environment (BITE). We were originally skeptical ourselves, but figured somebody should try. Here is some anecdotal data and some background on how we started measuring the quality of RPF.
The idea is to just let users use the application in the browser, record their actions, and save them as a javascript to play back as a regression test or repro later. Like most test tools, especially code generating ones, it works most of the time but its not perfect. Po Hu had an early version working, and decided to test this out on a real world product. Po, the developer of RPF, worked with the chrome web store team to see how an early version would work for them. Why chrome web store? It is a website with lots of data-driven UX, authentication, file upload, and it was changing all the time and breaking existing Selenium scripts: a pretty hard web testing problem, only targeted the chrome browser, and most importantly they were sitting 20 feet from us.

Before sharing with the chrome web store test developer Wensi Liu, we invested a bit of time in doing something we thought was clever: fuzzy matching and inline updating of the test scripts. Selenium rocks, but after an initial regression suite is created, many teams end up spending a lot of time simply maintaining their Selenium tests as the products constantly change. Rather than simply fail like the existing Selenium automation would do when a certain element isn’t found, and require some manual DOM inspection, updating the Java code and re-deploying, re-running, re-reviewing the test code what if the test script just kept running and updates to the code could be as simple as point and click? We would keep track of all the attributes in the element recorded, and when executing we would calculate the percent match between the recorded attributes and values and those found while running. If the match isn’t exact, but within tolerances (say only its parent node or class attribute had changed), we would log a warning and keep executing the test case. If the next test steps appeared to be working as well, the tests would keep executing during test passes only log warnings, or if in debug mode, they would pause and allow for a quick update of the matching rule with point and click via the BITE UI. We figured this might reduce the number of false-positive test failures and make updating them much quicker.

We were wrong, but in a good way!

We talked to the tester after a few days of leaving him alone with RPF. He’d already re-created most of his Selenium suite of tests in RPF, and the tests were already breaking because of product changes (its a tough life for a tester at google to keep up with the developers rate of change). He seemed happy, so we asked him how this new fuzzy matching fanciness was working, or not. Wensi was like “oh yeah, that? Don’t know. Didn’t really use it...”. We started to think how our update UX could have been confusing or not discoverable, or broken. Instead, Wensi said that when a test broke, it was just far easier to re-record the script. He had to re-test the product anyway, so why not turn recording on when he manually verified things were still working, remove the old test and save this newly recorded script for replay later?

During that first week of trying out RPF, Wensi found:
  • 77% of the features in Webstore were testable by RPF
  • Generating regression test scripts via this early version of RPF was about 8X faster than building them via Selenium/WebDriver
  • The RPF scripts caught 6 functional regressions and many more intermittent server failures.
  • Common setup routines like login should be saved as modules for reuse (a crude version of this was working soon after)
  • RPF worked on Chrome OS, where Selenium by definition could never run as it required client-side binaries. RPF worked because it was a pure cloud solution, running entirely within the browser, communicating with a backend on the web.
  • Bugs filed via bite, provided a simple link, which would install BITE on the developers machine and re-execute the repros on their side. No need for manually crafted repro steps. This was cool.
  • Wensi wished RPF was cross browser. It only worked in Chrome, but people did occasionally visit the site with a non-Chrome browser.
So, we knew we were onto something interesting and continued development. In the near term though, chrome web store testing went back to using Selenium because that final 23% of features required some local Java code to handle file upload and secure checkout scenarios. In hindsight, a little testability work on the server could have solved this with some AJAX calls from the client.

We performed a check of how RPF faired on some of the top sites of the web. This is shared on the BITE project wiki. This is now a little bit out of date, with lots more fixes, but it gives you a feel for what doesn’t work. Consider it Alpha quality at this point. It works for most scenarios, but there are still some serious corner cases.

Joe Muharsky drove a lot of the UX (user experience) design for BITE to turn our original and clunky developer and functional-centric UX into something intuitive. Joe’s key focus was to keep the UX out of the way until it is needed, and make things as self-discoverable and findable as possible. We’ve haven't done formal usability studies yet, but have done several experiments with external crowd testers using these tools, with minimal instructions, as well as internal dogfooders filing bugs against Google Maps with little confusion. Some of the fancier parts of RPF have some hidden easter eggs of awkwardness, but the basic record and playback scenarios seem to be obvious to folks.

RPF has graduated from the experimental centralized test team to be a formal part of the Chrome team, and used regularly for regression test passes. The team also has an eye on enabling non-coding crowd sourced testers generate regression scripts via BITE/RPF.

Please join us in maintaining BITE/RPF, and be nice to Po Hu and Joel Hynoski who are driving this work forward within Google.
URL: http://googletesting.blogspot.com/2011/11/rpf-googles-record-playback-framework.html

[Gd] Discover v201109: Filtering on Criterion type

| More

AdWords API Blog: Discover v201109: Filtering on Criterion type

We’ve noticed a popular question in the forum: “How do I retrieve criteria of a specific type via the API?”. Previously, there was no straightforward way to filter by the criterion type on the server side and the only workaround was to retrieve all criteria and process the list on the client side.

In v201109 we introduced a new filterable field called CriteriaType to the Criterion object. For example, the following request will return criteria of types ‘KEYWORD’ and ‘PLACEMENT’ only:
<get>
<serviceSelector>
<fields>Id</fields>
<fields>CriteriaType</fields>
<predicates>
<field>CriteriaType</field>
<operator>IN</operator>
<values>KEYWORD</values>
<values>PLACEMENT</values>
</predicates>
</serviceSelector>
</get>

You can find out the list of available criteria types in the documentation.

We hope this enhancement will make it easier to work with criteria. Please visit the forum or join our Google+ Hangout today if you have any questions regarding this change.

Danial Klimkin, AdWords API Team.
URL: http://adwordsapi.blogspot.com/2011/11/discover-v201109-filtering-on-criterion.html

[Gd] OpenSocial Version 2.0.1 Final open for voting

| More

OpenSocial API Blog: OpenSocial Version 2.0.1 Final open for voting

Version 2.0.1 of the OpenSocial specification has been released for voting. One of the major updates to the specification is finalized support for the OAuth 2.0 specification.

For more information on the changes to the specification and related components, please see the voting thread and file diffs here.

Jonathan LeBlanc
Jonathan LeBlanc (@jcleblanc)
Jonathan LeBlanc is a principal developer evangelist with X.commerce. Jonathan has been a member of the OpenSocial community for over three years and is the author of O'Reilly's "Programming Social Applications".
URL: http://blog.opensocial.org/2011/11/opensocial-version-201-final-open-for.html

[Gd] Google Plugin for Eclipse (GPE) is Now Open Source

| More

Google Web Toolkit Blog: Google Plugin for Eclipse (GPE) is Now Open Source

Today is quite a milestone for the Google Plugin for Eclipse (GPE). Our team is very happy to announce that all of GPE (including GWT Designer) is open source under the Eclipse Public License (EPL) v1.0. GPE is a set of software development tools that enables Java developers to quickly design, build, optimize, and deploy cloud-based applications using the Google Web Toolkit (GWT), Speed Tracer, App Engine, and other Google Cloud services.

Because of the large ecosystem that has developed around GWT, App Engine, and Google’s Cloud services, and because our primary mission is to help users (as opposed to creating proprietary development tools), it makes a lot of sense for us to open source GPE and make it easier for the community to enhance and extend the tools.

According to Red Hat’s Max Andersen, “We have many developers using Google's Eclipse plugin to develop GWT-based applications targeting the JBoss Application Server. With the open sourcing of the plugin we are looking forward to working even more closely with the Google team and the rest of the community on making the developer experience even more productive and an integrated part of Eclipse platform. We are especially interested in seeing the Google Eclipse plugins being able to target multiple runtimes such as the JBoss Enterprise Application Platform and Google App Engine in a uniform way, working more seamlessly with standards-based tools and frameworks.”

As of today, all of the code is available directly from the new GPE project and GWT Designer project on Google Code. Note that GWT Designer itself is based upon the WindowBuilder open source project at Eclipse.org (contributed by Google last year). We will be adopting the same guidelines for contributing code used by the GWT project.

In the months to come we expect to start bringing on more committers, but don't let that stop you from contributing. The project will only grow with the community's input. Submitting bugs via the issue tracker and engaging with other users on the forums will go a long way towards ensuring the overall quality of the product.
URL: http://googlewebtoolkit.blogspot.com/2011/11/google-plugin-for-eclipse-gpe-is-now.html

Wednesday, November 16, 2011

[Gd] Stable Channel Update

| More

Chrome Releases: Stable Channel Update


The Stable channel has been updated to 15.0.874.121 for Windows, Mac, Linux and Chrome Frame platforms

All
  • Updated V8 - 3.5.10.24
  • This build contains the fix to a regression: SVG in iframe doesn't use specified dimensions (Issue: 98951)
Security fixes and rewards:
Please see the Chromium security page for more detail. Note that the referenced bugs may be kept private until a majority of our users are up to date with the fix.
  • [$1000] [103259] High CVE-2011-3900: Out-of-bounds write in v8. Credit to Christian Holler.
Full details about what changes have been made in this release are available in the SVN revisions log. Interested in switching to another channel?  Find out how.  If you find a new issue, please let us know by filing a bug.


Karen Grunberg
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/11/stable-channel-update_16.html

[Gd] Flash developers: export to HTML5 with new Swiffy extension

| More

The official Google Code blog: 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
URL: http://googlecode.blogspot.com/2011/11/flash-developers-export-to-html5-with.html

[Gd] New Datastore client library for Python ready for a test drive

| More

Google App Engine Blog: New Datastore client library for Python ready for a test drive




Last week we announced that App Engine has left preview and is now an officially supported product here at Google. And while the release (and the announcement) was chock-full of great features, one of the features that we’d like to call specific attention to is the new Datastore client library for Python (a.k.a “NDB”).

NDB has been under development for some time and this release marks its availability to a larger audience as an experimental feature. Some of the benefits of this new library include:

  • The StructuredProperty class, which allows entities to have nested structure

  • Integrated two-level caching, using both memcache and a per-request in-process cache

  • High-level asynchronous API using Python generators as coroutines (PEP 342)

  • New, cleaner implementations of Key, Model, Property and Query classes


The version of NDB contained in the 1.6.0 runtime and SDK corresponds to NDB 0.9.1, which is currently the latest NDB release.

Given that this feature is still experimental, it is subject to change, but that’s exactly why we encourage you to give it a test drive and send us any feedback that you might have. The NDB project hosted on Google Code is the best place to send this feedback. Happy coding!


Posted by Guido van Rossum, Software Engineer on the App Engine Team
URL: http://googleappengine.blogspot.com/2011/11/new-datastore-client-library-for-python.html

[Gd] Discover v201109 - AdHoc Reports

| More

AdWords API Blog: Discover v201109 - AdHoc Reports

AdHoc reports is one of the new features we introduced in v201109 of the AdWords API. AdHoc reports are free, synchronous and don’t require a stored report definition. This blog post explains this new feature and covers the best practices.

Downloading the report

AdHoc reports utilizes plain HTTP POST requests to generate reports synchronously from the AdWords API server. A raw HTTP request to download the reports is shown below:

POST /api/adwords/reportdownload/v201109 HTTP/1.1
HOST: adwords.google.com
clientCustomerId: XXX-XXX-XXXX
Content-Type: application/x-www-form-urlencoded
developerToken: XXXX
Authorization: GoogleLogin auth=XXX
returnMoneyInMicros: true
Content-Length: XXXX


__rdxml=URL_ENCODED_DEFINITION_XML

As shown, the report is downloaded by making a POST request to https://adwords.google.com/api/adwords/reportdownload/v201109. The clientCustomerId header specifies the client for which this report is being run. The Authorization header contains the authorization information for downloading the report. If you are using ClientLogin as the authorization method, this header takes the form
Authorization: GoogleLogin auth=AUTH_TOKEN_HERE
If you are using OAuth, the header takes the form
Authorization: OAuth OAUTH_SIGNATURE_HERE
The returnMoneyInMicros header tells the server whether to return money values in micros or not. This is true by default; if set to false, money values are downloaded in actual currency format. The developerToken header contains your AdWords API developer token. The Report Definition is written in XML format and is provided in the __rdxml parameter of the POST body. The request should be encoded in application/x-www-form-urlencoded or multipart/form-data format.

You may also use the GET method instead of POST to download reports by sending your request to https://adwords.google.com/api/adwords/reportdownload/v201109?__rdxml=URL_ENCODED_REPORT_DEFINITION_XML with the same headers as in the POST example. However, we recommend using POST over GET since GET requests are more likely to incur URL length limit errors.

Creating definition xml

A Report Definition corresponds to the serialized form of the ReportDefinition type. For instance, a Report Definition that downloads an AdGroup performance report for the last 7 days in CSV format would look like this:

  <reportDefinition>
<selector>
<fields>CampaignId</fields>
<fields>Id</fields>
<fields>Impressions</fields>
<fields>Clicks</fields>
<fields>Cost</fields>
<predicates>
<field>Status</field>
<operator>IN</operator>
<values>ENABLED</values>
<values>PAUSED</values>
</predicates>
</selector>
<reportName>Custom Adgroup Performance Report</reportName>
<reportType>ADGROUP_PERFORMANCE_REPORT</reportType>
<dateRangeType>LAST_7_DAYS</dateRangeType>
<downloadFormat>CSV</downloadFormat>
</reportDefinition>

Details about the supported report types and their field are available at http://code.google.com/apis/adwords/docs/appendix/reports.html.

Error codes

When downloading AdHoc reports, the AdWords API server responds with HTTP code 200 and report in the response body. In case of an error, one of the two different HTTP response code may be returned:

1. HTTP Status code is 400: This error occurs when the AdWords API server throws an API error. When this happens, the error message will be returned in the server response body. You need to examine your report definition XML and server response body and fix any errors before retrying the call. The response body would look like

!!!2|||-1|||Error message here???

An easy way to parse the error message is to match it against the regex pattern "\!\!\!([^\|]*)\|\|\|(.*)"

2. HTTP Status code is 500: This error implies that the server faced an issue while generating the report. Chances are that this is a temporary error and may go away if you retry the call after waiting for 30 seconds. However, if you get this error even after five retries, you should skip the download and report the issue on the forum.

Using the client libraries

All of the client libraries support AdHoc reports, and takes care of details like making requests with the right HTTP headers and encoding, constructing authorization headers, handling the HTTP response codes, etc. For instance, the DownloadAdHocReports.cs code example shows how to download AdHoc reports using AdWords API .NET library:

Support for cross-client reports

As mentioned in an earlier blog post, AdHoc reports do not support cross-client reports. If you wish to run reports against many clients, you can refer to this blog post for details.

We hope this blog post will help you use this new feature effectively. As usual, If you have any questions about downloading reports, you can ask us on the forum or our upcoming live Hangouts with the Developer Relations team.

  --Anash P. Oommen, AdWords API Team

URL: http://adwordsapi.blogspot.com/2011/11/discover-v201109-adhoc-reports.html

Tuesday, November 15, 2011

[Gd] Dev Channel Update for Chromebooks

| More

Chrome Releases: Dev Channel Update for Chromebooks

The Dev Channel has been updated to 16.0.912.38 (Platform version: 1193.52.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

Release highlights:

  • A number of functionality and stability fixes
  • Flash updated to 11.0.31.110


Known issues:

  • After autoupdate, the UI may freeze on first boot after logging in. This problem happens less frequently if you wait 60+ seconds to login. Workaround - If you encounter this hang, press the power button to force the Chromebook to shutdown, then restart. The machine should behave normally after that.


If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu.

Danielle Drew
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/11/dev-channel-update-for-chromebooks.html

[Gd] GTAC Videos Now Available

| More

Google Testing Blog: GTAC Videos Now Available

By James Whittaker

All the GTAC 2011 talks are now available at http://www.gtac.biz/talks and also up on You Tube. A hearty thanks to all the speakers who helped make this the best GTAC ever. 


Enjoy!
URL: http://googletesting.blogspot.com/2011/11/gtac-videos-now-available.html

[Gd] Creating More Responsive Applications with Client Handlers and Validators

| More

Google Apps Developer Blog: Creating More Responsive Applications with Client Handlers and Validators

When it comes to writing UI applications in Apps Script, we get a lot of requests to support event callbacks that are handled in the user’s browser. For example, if your application has a form, you may want to disable a button after it is clicked the first time. Until now, the only way to do that would be by using an event handler on the server to disable that button. Using Client Handlers, your application can now respond to events in the browser without the need to perform a round trip to Google Apps Script servers.

By cutting out the round trip to the server, your app can respond instantly to user input. Imagine, for example, you want to provide your users with instant feedback within your app when a user types text where a number is expected. Ideally, you would want to warn users as they type the value, instead of waiting until the form is submitted. Having a server event handler for each keystroke is definitely overkill for such a simple and common task. Luckily, these use cases are now supported with Apps Script’s new Client Handlers and validators!

Let’s take a look at some code.

Client Handlers

A Client Handler allows you to react to any event in a browser without connecting to the server. What you can do in response to an event is limited to a set of predefined common actions, but you have a lot of flexibility in making your app more responsive.

You can use Client Handlers in any UiApp regardless of whether you are embedding in a Spreadsheet or a Sites Page or publishing as a service. This simple application enables the user to click a button to display the classic “Hello world” message:

function doGet() {
var app = UiApp.createApplication();
var button = app.createButton("Say Hello");

// Create a label with the "Hello World!" text and hide it for now
var label = app.createLabel("Hello World!").setVisible(false);

// Create a new handler that does not require the server.
// We give the handler two actions to perform on different targets.
// The first action disables the widget that invokes the handler
// and the second displays the label.
var handler = app.createClientHandler()
.forEventSource().setEnabled(false)
.forTargets(label).setVisible(true);

// Add our new handler to be invoked when the button is clicked
button.addClickHandler(handler);

app.add(button);
app.add(label);
return app;
}

The Client Handlers in the above example are set up in two steps:

  1. Create a Client Handler just as we would create the server handlers you all know and love.
  2. Define the target widget for this handler. The target widget is the widget on which the handler will take action. We set the handler’s target in one of two ways: (a) By using the forTargets method to define the target widget. (b) By using the forEventSource method which lets widget wire itself to the client handler.

In the above example, we set the handler’s target to be the event source, so that it will apply to the button that is clicked. Finally, we define the action that the handler should take, in this case disabling the button using setEnabled(false). Aside from setEnabled, you can also change styles using setStyleAttribute, change text using setText, and so on. One Client Handler can perform multiple actions — just chain them together - and you can even change the target so that some actions apply to one set of widgets and some actions to another set. In our example, along with disabling the button, we set the handler to display the label when it is invoked, using setVisible.

Validators

Another new addition to Apps Script is support for validators in handlers. Validators allow handlers to check simple and complex conditions before they are invoked. For example, the following application adds two numbers given by the user, while using validators to make sure the server is only called if both of the text boxes contain numbers.

function doGet() {
var app = UiApp.createApplication();

// Create input boxes and button
var textBoxA = app.createTextBox().setId('textBoxA').setName('textBoxA');
var textBoxB = app.createTextBox().setId('textBoxB').setName('textBoxB');
var addButton = app.createButton("Add");

// Create a handler to call the adding function
// Two validations are added to this handler so that it will
// only invoke 'add' if both textBoxA and textBoxB contain
// numbers
var handler = app.createServerClickHandler('add')
.validateNumber(textBoxA)
.validateNumber(textBoxB)
.addCallbackElement(textBoxA)
.addCallbackElement(textBoxB);

addButton.addClickHandler(handler)

app.add(textBoxA);
app.add(textBoxB);
app.add(addButton);
return app;
}

function add(e) {
var app = UiApp.getActiveApplication();
var result = parseFloat(e.parameter.textBoxA) + parseFloat(e.parameter.textBoxB);
var newResultLabel = app.createLabel("Result is: " + result);
app.add(newResultLabel);
return app;
}

There’s a variety of validators to choose from that perform different tasks. You can verify the input to be a number, an integer, or an e-mail address. You can check for a specific length, or for any numerical value in a defined range. You can also use general regular expressions. Lastly, each validator has its negation.

Note that validators work with both client and server handlers.

Putting it all together

Of course, validators and Client Handlers work best together. For example, in our addition application above, the “Add” button should be disabled as long as the current input is not numeric. We would also like to let the user know why the button is disabled by displaying an error message. To do so, we combine the power of server handlers, Client Handlers, and validators in the following way:

function doGet() {
var app = UiApp.createApplication();

// Create input boxes and button.
var textBoxA = app.createTextBox().setId('textBoxA').setName('textBoxA');
var textBoxB = app.createTextBox().setId('textBoxB').setName('textBoxB');
var addButton = app.createButton("Add").setEnabled(false);
var label = app.createLabel("Please input two numbers");

// Create a handler to call the adding function.
// Two validations are added to this handler so that it will
// only invoke 'add' if both textBoxA and textBoxB contain
// numbers.
var handler = app.createServerClickHandler('add')
.validateNumber(textBoxA)
.validateNumber(textBoxB)
.addCallbackElement(textBoxA)
.addCallbackElement(textBoxB);

// Create handler to enable the button well all input is legal
var onValidInput = app.createClientHandler()
.validateNumber(textBoxA)
.validateNumber(textBoxB)
.forTargets(addButton).setEnabled(true)
.forTargets(label).setVisible(false);

// Create handler to mark invalid input in textBoxA and disable the button
var onInvalidInput1 = app.createClientHandler()
.validateNotNumber(textBoxA)
.forTargets(addButton).setEnabled(false)
.forTargets(textBoxA).setStyleAttribute("color", "red")
.forTargets(label).setVisible(true);

// Create handler to mark the input in textBoxA as valid
var onValidInput1 = app.createClientHandler()
.validateNumber(textBoxA)
.forTargets(textBoxA).setStyleAttribute("color", "black");

// Create handler to mark invalid input in textBoxB and disable the button
var onInvalidInput2 = app.createClientHandler()
.validateNotNumber(textBoxB)
.forTargets(addButton).setEnabled(false)
.forTargets(textBoxB).setStyleAttribute("color", "red")
.forTargets(label).setVisible(true);

// Create handler to mark the input in textBoxB as valid
var onValidInput2 = app.createClientHandler()
.validateNumber(textBoxB)
.forTargets(textBoxB).setStyleAttribute("color", "black");

// Add all the handlers to be called when the user types in the text boxes
textBoxA.addKeyUpHandler(onInvalidInput1);
textBoxB.addKeyUpHandler(onInvalidInput2);
textBoxA.addKeyUpHandler(onValidInput1);
textBoxB.addKeyUpHandler(onValidInput2);
textBoxA.addKeyUpHandler(onValidInput);
textBoxB.addKeyUpHandler(onValidInput);
addButton.addClickHandler(handler);

app.add(textBoxA);
app.add(textBoxB);
app.add(addButton);
app.add(label);
return app;
}

function add(e) {
var app = UiApp.getActiveApplication();
var result = parseFloat(e.parameter.textBoxA) + parseFloat(e.parameter.textBoxB);
var newResultLabel = app.createLabel("Result is: " + result);
app.add(newResultLabel);
return app;
}

All of these features can be used to create more advanced and responsive applications. Client handlers can be used to change several attributes for widgets, and validators can help you check a variety of different conditions from well formed email addresses to general regular expressions.

If you'd like to chat about these new features or have other questions about Google Apps Script, please join several members of the Apps Script team in the Google Apps Developer Office Hours on Google+ Hangouts tomorrow, Wednesday November 16th at 10am PST. You can also ask questions at any time in the Apps Script forum.


Omer Strulovich   profile

Omer was an intern on the Google Docs team for the summer of 2011. He is now back to pursuing his master’s degree in the field of cryptography.

URL: http://googleappsdeveloper.blogspot.com/2011/11/creating-more-responsive-applications.html

[Gd] Google BigQuery Service: Big data analytics at Google speed

| More

Google App Engine Blog: Google BigQuery Service: Big data analytics at Google speed

Our post today, cross-posted with the Google Enterprise Blog, comes from one of our sister projects, BigQuery. We know that many of you are interested in processing large volumes of data and we encourage you to try it out.




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.





Posted by Ju-Kay Kwek, Product Manager
URL: http://googleappengine.blogspot.com/2011/11/google-bigquery-service-big-data.html

[Gd] UPDATE2: Developer Token Required In Report Downloads

| More

AdWords API Blog: UPDATE2: Developer Token Required In Report Downloads

A little over a week ago we published a blog post informing developers that we would begin requiring a developer token with report downloads to better allow us to monitor reports, and extended the deadline in an update. We are changing the deadline to Tuesday January 17th, 2012 to give our developers more time during the busy holiday season.

As mentioned in our prior update, the sandbox will still have this change as of November 16th. We strongly encourage you to use the time between November 16th and January 17th to make the change to your applications, test against the sandbox and move the change to production. The existing production report download will ignore the header until it is required, which means you can implement the changes before the deadline without it breaking your existing applications.

We will update the client libraries to help you implement this change before the November 16th change in the sandbox environment. Please see our report download documentation for more information regarding report downloads. If you have any questions or would like to discuss this change, please post on the forum or try to attend our Google+ Hangouts with members of the AdWords API Developer Relations Team.

, AdWords API Team
URL: http://adwordsapi.blogspot.com/2011/11/update2-developer-token-required-in.html

[Gd] Dev Channel Update

| More

Chrome Releases: Dev Channel Update


The Dev channel has been updated to 17.0.938.0 for Windows, Mac, Linux, and Chrome Frame.  This build contains the following updates:
  • Updated V8 - 3.7.6.0. This release includes the new garbage collector.
  • Windows: Fixed a bug where the missing plug-in infobar would not do anything (issue 103216).
Full details about what changes are in this build are available in the SVN revision log.  Interested in switching release channels?  Find out how.  If you find a new issue, please let us know by filing a bug.

Dharani Govindan
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/11/dev-channel-update_14.html

Monday, November 14, 2011

[Gd] Google BigQuery Service: Big data analytics at Google speed

| More

The official Google Code blog: 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
URL: http://googlecode.blogspot.com/2011/11/google-bigquery-service-big-data.html