Friday, October 2, 2009

[Gd] Dev Channel Updated with Fixes

| More

Google Chrome Releases: Dev Channel Updated with Fixes


This week's dev channel update includes a number of fixes.  It introduces the Native Client as a built-in feature for the first time on Windows.  Some additional Extensions APIs also make their first appearance.

All Platforms
  • [r27300] Remove "Remove Item" from download item context menu. (Issue: 23078)
  • [r26976] Omnibox now understands Zeroconf .local hosts. (Issue: 19957)
  • [r27445] Native Client is now built into the renderer but disabled by default.  For info on how to enable please see this page.
  • [r27015] cmd-f, cmd-g, cmd-e now use the system-wide find pasteboard. (Issue: 14562)
  • [r27464] cmd-up/cmd-down now work correctly. (Issue: 22585)
  • [r27378] Sheets should be positioned between the content and everything above it, no matter if they are window- or tab-modal. (Issue: 17615)
  • [r27185] Download item name no longer displayed in white in Incognito window. (Issue: 22664)
  • [r27405] about:ipc page enabled. (Issue: 22664)
  • [r27064] Omnibox now draws red bar over "https" for bad site certificates. (Issue: 22558)
  • [r27127] Typing option-return in the Omnibox now opens a new foreground tab. (Issue 22822)
  • [r27368] Extension shelf now obeys GTK theme. (Issue 23031)
  • [r27041] "Other bookmarks" link no longer chopped off non-English locales. (Issue 22788)
  • [r27194], [r27422] App shortcuts now work and use proper icon. (Issue 2258922528)
  • [r27599] Extensions menu item now in 'wrench' menu. (Issue 22883)
  • [r27319] Introduce Browser Actions. (Issue 22099 and others) (still a work in progress)
  • [r27163] Implemented extension packing on Linux.
  • [r27290] Toolstrip dragging now restricted to extension shelf.
  • [r27262] Themes and extensions now install if you have "ask for destination" option set in download options.
  • [r27376] Content scripts can now see their own functions in setTimeout.
  • [r27440] Fix crash when using non-extension iframe.
  • [r27393] Some initial i18n API (still a work in progress). (Issue: 12131)

More details about additional changes are available in the svn log of all revisions.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Jonathan Conradt
Engineering Program Manager


[Gd] Build a Voice App in the Cloud and Enter the Twilio + App Engine Developer Contest

| More

Google App Engine Blog: Build a Voice App in the Cloud and Enter the Twilio + App Engine Developer Contest

This week, Google App Engine and Twilio challenge you to build voice or voice-enhanced applications hosted on App Engine that use Twilio's voice application API to make and receive phone calls. Submit your app by October 4th to win a Dell Netbook from Twilio and $1000 of App Engine hosting credit from Google.

Twilio hosts a telephony in the cloud web service, allowing web developers to build scalable, reliable voice communications applications on web hosting platforms like Google App Engine. Put Twilio and App Engine together and you can build voice applications with features, scalability, and reliability that companies used to spend millions for.

What Are Voice Apps?

Voice apps can be as sophisticated as an airline flight status hotline or a company PBX, or as simple as getting the weather by phone. For inspiration, check out what previous contest winners have built:

Tips on Getting Started

Contest Details

Where to Submit:
Deadline: October 4th at MIDNIGHT (Pacific Time)
Prize: 1 Dell Netbook from Twilio and $1000 in Google App Engine hosting credit

Questions? Drop us a line at

Guest Post by Danielle Morrill, Director of Marketing, Twilio


[Gd] SVG at Google and in Internet Explorer

| More

Google Code Blog: SVG at Google and in Internet Explorer

At Google we're excited about new web technologies like HTML 5, CSS 3, Web Fonts, SVG, faster JavaScript, and more. It's an exciting time to be a web developer, especially with the major advancements made in modern browsers like Firefox, Safari, Opera, and Chrome the last two years. In this blog post I want to share some of the work we've been doing with SVG in particular.

Today kicks off the start of the SVG Open 2009 conference, hosted at Google this year. The SVG Open conference is an annual conference where the SVG community comes together for three-days. Other sponsors of the conference this year include Microsoft and IBM.

What is SVG?

SVG, or Scalable Vector Graphics, is an open web standard that makes it easy to add interactive vector graphics to your web pages. Vector graphics, as opposed to bitmap graphics like JPG, GIF, or PNG files, describe the shapes on your screen with mathematical equations rendered by your computer rather than pixels. This allows vector graphics to stay beautiful and crisp whether displayed on a 40" monitor or a small mobile device.

Just as HTML gives you simple tags such as <form> or <table> to add to your web pages, SVG gives you such graphical tags as <circle> or <rect> for a rectangle that you can drop into your web page. Working with SVG is very similar to working with HTML - you use JavaScript to animate and make things interactive, CSS (Cascading Style Sheets) to add style, etc.

Why Google is Excited About SVG

We're excited about SVG for a host of reasons:

First, SVG is part of the HTML 5 family of technologies. One of the major new features of HTML 5 is the fact that you can now drop SVG tags into normal HTML, directly embedded into your page. We're excited about how this will empower developers. Here, for example, is a small code sample that embeds an SVG circle and rectangle right into an HTML 5 page:
<!DOCTYPE html>
<h1>SVG/HTML 5 Example</h1>
<circle id="myCircle"
cx="100" cy="75" r="50"
stroke-width="3" />
<text x="60" y="155">Hello World</text>


Second, we like that SVG is composed of text and markup, just like HTML. Because it's markup, search engines have a much easier time working with SVG; server-side languages like PHP or Google App Engine can simply emit SVG just like they generate HTML; and users and developers can easily view the source just like a normal web page to learn and move things forward. It's also easy to import and export SVG into tools like the open source Inkscape drawing package or Adobe Illustrator.

Third, the compact size of SVG when combined with HTTP GZip compression can easily make the images on a page roughly an order of magnitude smaller, and when directly embedded into an HTML 5 page can decrease the latency of a page by reducing the number of fetches. Small and fast are definitely two things we like at Google, and we like that SVG helps enable both.

Fourth, SVG integrates with the rest of the web stack, including JavaScript, CSS, and the DOM (Document Object Model). Even better, developers can easily adapt the skills they already know when working with SVG.

Finally, SVG is an open standard that is vendor-neutral. It also has accessibility built in, so when screen readers start to work with SVG your content will be future-proofed with accessibility baked in. We also like that SVG is now natively supported on all modern browsers, including the iPhone.

What Are Some Places We Use SVG?

We use SVG ourselves in a range of products. In Google Docs, for example, you can insert drawings, illustrations, and diagrams using a built in drawing tool:

On all browsers we use SVG to build this user interface; on Internet Explorer we have to revert to an older technology named Vector Markup Language (VML) unfortunately.

Another example is the Google Visualization API, which lets you access multiple sources of structured data that you can display, choosing from a large selection of visualizations. Some of these visualizations (such as this one and this one) use SVG to do their drawing on all browsers except Internet Explorer.

Canvas Or SVG? Oh My!

A natural question is how SVG compares to the Canvas tag. In our opinion both are needed for the web and are suitable for different applications.

The Canvas tag can best be thought of as a scriptable image tag that you build up yourself using JavaScript. This means it is lower-level, requiring you to keep track of all objects you have placed on the canvas. This can be a benefit if you want to do a large degree of non-interactive animation, but can quickly become a burden if you need to build sophisticated user interfaces.

SVG, meanwhile, is higher-level, doing the bookkeeping necessary to keep track of where everything is, making things like mouse interaction much easier. If you don't need this interaction, however, the overhead imposed by SVG can get in the way of certain applications. Because SVG is markup, importing and exporting is much easier, including SEO and accessibility.

We believe that Canvas versus SVG is a false dichotomy. A great example of both technologies working together is the Firefox Download Tracker. This page shows real time updates across the world whenever a copy of Firefox is downloaded. SVG is used to draw the map of the world; this is an appropriate use, since we don't want thousands of lines of JavaScript for this but rather markup from a tool like Inkscape. Red circles are drawn on top of the SVG using the Canvas tag as copies are downloaded; this is perfect for Canvas as the circles are non-interactive and might number in the thousands if copies are being downloaded rapidly.

SVG In Internet Explorer and in Wikipedia

Now that you know a bit more about SVG, why we like it, and some of the places we use it, let me tell you a bit about some of the work we've been doing to support SVG lately.

In addition to hosting this years conference, we are also helping to address the fact that SVG can't be used on Internet Explorer. It's hard for developers to use new web technologies if they can't deploy them on IE. In response to this, we've been working with others in the open source community on a drop-in JavaScript library named SVG Web that brings SVG to Internet Explorer.

SVG Web cleverly uses existing facilities on Internet Explorer 6, 7, and 8 to instantly enable SVG support without the user having to download any new software or plugins. Using SVG Web plus native SVG support you can now target close to 100% of the existing installed web base, today. Before SVG Web you could only target about ~30% of web browsers with SVG.

Once dropped in SVG Web gives you partial support for SVG 1.1, SVG Animation (SMIL), Fonts, Video and Audio, DOM and style scripting through JavaScript, and more in about a 60K library. Your SVG content can be embedded directly into normal HTML 5 or through the OBJECT tag. If native SVG support is already present in the browser then that is used. No downloads or plugins are necessary other than Flash which is used for the actual rendering, so it's very easy to use and incorporate into an existing web site. Here's a quick one minute introduction to SVG Web:

SVG Web is currently in alpha and is a developer release. It's also important to note that it is a collaboration with many others in the open source community outside Google, including Rick Masters at F5 Networks and James Hight at Zavoo Labs. Google is just one participant in this open source project. Finally, a JavaScript library will never be as fast as native support; this doesn't take Internet Explorer off the hook for needing to implement SVG, but it does help developers in the here and now deploy their SVG today to get the wheel turning.

In addition to helping enable SVG on Internet Explorer, we've been working with Wikipedia. Wikipedia has an impressively large collection of SVG files that are under Creative Commons licenses. Every one of these files is available in the Wikimedia Commons; for example here is the Linux penguin Tux as SVG. We've been working with Wikipedia to enable interactive zooming and panning of these SVG files, similar to Google Maps; even better, this functionality works in Internet Explorer thanks to the SVG Web library on the sixth largest site on the web.

Today at the SVG Open show we are demoing a prototype of the Wikipedia SVG Zoom and Pan tool; deployment to the wider base of Wikipedia users will happen after the conference and an appropriate QA period. Here's a screencast showing the tool in action:

We hope you are as excited as we are about SVG and other new web technologies in the pipeline!

By Brad Neuberg, Google Developer Programs

[Gd] Google Friend Connect: No more FTP... just get started!

| More

Official Google Webmaster Central Blog: Google Friend Connect: No more FTP... just get started!

Until today, you had to upload a file to your website to activate Google Friend Connect features and gadgets. Today, we're dramatically simplifying the Friend Connect setup process. To get started with Friend Connect features, all you have to do is submit your website's name and URL after logging into

To learn more about the recent updates to Google Friend Connect, check out our post on the Google Social Web Blog.

Posted by Mussie Shore, Product Manager, Google Friend Connect

[Gd] Cost of Testing

| More

Google Testing Blog: Cost of Testing

By Miško Hevery

A lot of people have been asking me lately, what is the cost of testing, so I decided, that I will try to measure it, to dispel the myth that testing takes twice as long.

For the last two weeks I have been keeping track of the amount of time I spent writing tests versus the time writing production code. The number surprised even me, but after I thought about it, it makes a lot of sense. The magic number is about 10% of time spent on writing tests. Now before, you think I am nuts, let me back it up with some real numbers from a personal project I have been working on.

JavaScript LOC10,0776,8193,25832.33%
Ruby LOC4,6321,8922,74059.15%

Commits refers to the number of commits I have made to the repository. LOC is lines of code which is broken down by language. The ratio shows the typical breakdown between the production and test code when you test drive and it is about half, give or take a language. It is interesting to note that on average I commit about 11 lines out of which 6.5 are production and 4.5 are test. Now, keep in mind this is average, a lot of commits are large where you add a lot of code, but then there are a lot of commits where you are tweaking stuff, so the average is quite low.

The number of hours spent on the project is my best estimate, as I have not kept track of these numbers. Also, the 10% breakdown comes from keeping track of my coding habits for the last two weeks of coding. But, these are my best guesses.

Now when I test drive, I start with writing a test which usually takes me few minutes (about 5 minutes) to write. The test represents my scenario. I then start implementing the code to make the scenario pass, and the implementation usually takes me a lot longer (about 50 minutes). The ratio is highly asymmetrical! Why does it take me so much less time to write the scenario than it does to write the implementation given that they are about the same length? Well look at a typical test and implementation:

Here is a typical test for a feature:
ArrayTest.prototype.testFilter = function() {
var items = ["MIsKO", {name:"john"}, ["mary"], 1234];
assertEquals(4, items.filter("").length);
assertEquals(4, items.filter(undefined).length);

assertEquals(1, items.filter('iSk').length);
assertEquals("MIsKO", items.filter('isk')[0]);

assertEquals(1, items.filter('ohn').length);
assertEquals(items[1], items.filter('ohn')[0]);

assertEquals(1, items.filter('ar').length);
assertEquals(items[2], items.filter('ar')[0]);

assertEquals(1, items.filter('34').length);
assertEquals(1234, items.filter('34')[0]);

assertEquals(0, items.filter("I don't exist").length);

ArrayTest.prototype.testShouldNotFilterOnSystemData = function() {
assertEquals("", "".charAt(0)); // assumption
var items = [{$name:"misko"}];
assertEquals(0, items.filter("misko").length);

ArrayTest.prototype.testFilterOnSpecificProperty = function() {
var items = [{ignore:"a", name:"a"}, {ignore:"a", name:"abc"}];
assertEquals(2, items.filter({}).length);

assertEquals(2, items.filter({name:'a'}).length);

assertEquals(1, items.filter({name:'b'}).length);
assertEquals("abc", items.filter({name:'b'})[0].name);

ArrayTest.prototype.testFilterOnFunction = function() {
var items = [{name:"a"}, {name:"abc", done:true}];
assertEquals(1, items.filter(function(i){return i.done;}).length);

ArrayTest.prototype.testFilterIsAndFunction = function() {
var items = [{first:"misko", last:"hevery"},
{first:"mike", last:"smith"}];

assertEquals(2, items.filter({first:'', last:''}).length);
assertEquals(1, items.filter({first:'', last:'hevery'}).length);
assertEquals(0, items.filter({first:'mike', last:'hevery'}).length);
assertEquals(1, items.filter({first:'misko', last:'hevery'}).length);
assertEquals(items[0], items.filter({first:'misko', last:'hevery'})[0]);

ArrayTest.prototype.testFilterNot = function() {
var items = ["misko", "mike"];

assertEquals(1, items.filter('!isk').length);
assertEquals(items[1], items.filter('!isk')[0]);

Now here is code which implements this scenario tests above:
Array.prototype.filter = function(expression) {
var predicates = [];
predicates.check = function(value) {
for (var j = 0; j < predicates.length; j++) {
if(!predicates[j](value)) {
return false;
return true;
var getter = Scope.getter;
var search = function(obj, text){
if (text.charAt(0) === '!') {
return !search(obj, text.substr(1));
switch (typeof obj) {
case "bolean":
case "number":
case "string":
return ('' + obj).toLowerCase().indexOf(text) > -1;
case "object":
for ( var objKey in obj) {
if (objKey.charAt(0) !== '$' && search(obj[objKey], text)) {
return true;
return false;
case "array":
for ( var i = 0; i < obj.length; i++) {
if (search(obj[i], text)) {
return true;
return false;
return false;
switch (typeof expression) {
case "bolean":
case "number":
case "string":
expression = {$:expression};
case "object":
for (var key in expression) {
if (key == '$') {
var text = (''+expression[key]).toLowerCase();
if (!text) return;
predicates.push(function(value) {
return search(value, text);
} else {
var path = key;
var text = (''+expression[key]).toLowerCase();
if (!text) return;
predicates.push(function(value) {
return search(getter(value, path), text);
case "function":
return this;
var filtered = [];
for ( var j = 0; j < this.length; j++) {
var value = this[j];
if (predicates.check(value)) {
return filtered;

Now, I think that if you look at these two chunks of code, it is easy to see that even though they are about the same length, one is much harder to write. The reason, why tests take so little time to write is that they are linear in nature. No loops, ifs or interdependencies with other tests. Production code is a different story, I have to create complex ifs, loops and have to make sure that the implementation works not just for one test, but all test. This is why it takes you so much longer to write production than test code. In this particular case, I remember rewriting this function three times, before I got it to work as expected. :-)

So a naive answer is that writing test carries a 10% tax. But, we pay taxes in order to get something in return. Here is what I get for 10% which pays me back:

  • When I implement a feature I don't have to start up the whole application and click several pages until I get to page to verify that a feature works. In this case it means that I don't have to refreshing the browser, waiting for it to load a dataset and then typing some test data and manually asserting that I got what I expected. This is immediate payback in time saved!

  • Regression is almost nil. Whenever you are adding new feature you are running the risk of breaking something other then what you are working on immediately (since you are not working on it you are not actively testing it). At least once a day I have a what the @#$% moment when a change suddenly breaks a test at the opposite end of the codebase which I did not expect, and I count my lucky stars. This is worth a lot of time spent when you discover that a feature you thought was working no longer is, and by this time you have forgotten how the feature is implemented.

  • Cognitive load is greatly reduced since I don't have to keep all of the assumptions about the software in my head, this makes it really easy to switch tasks or to come back to a task after a meeting, good night sleep or a weekend.

  • I can refactor the code at will, keeping it from becoming stagnant, and hard to understand. This is a huge problem on large projects, where the code works, but it is really ugly and everyone is afraid to touch it. This is worth money tomorrow to keep you going.

These benefits translate to real value today as well as tomorrow. I write tests, because the additional benefits I get more than offset the additional cost of 10%. Even if I don't include the long term benefits, the value I get from test today are well worth it. I am faster in developing code with test. How much, well that depends on the complexity of the code. The more complex the thing you are trying to build is (more ifs/loops/dependencies) the greater the benefit of tests are.

So now you understand my puzzled look when people ask me how much slower/costlier the development with tests is.

Thursday, October 1, 2009

[Gd] Changes to website verification in Webmaster Tools

| More

Official Google Webmaster Central Blog: Changes to website verification in Webmaster Tools

If you use Webmaster Tools, you're probably familiar with verifying ownership of your sites. Simply add a specific meta tag or file to your site, click a button, and you're a verified owner. We've recently made a few small improvements to the process that we think will make it easier and more reliable for you.

The first change is an improvement to the meta tag verification method. In the past, your verification meta tag was partially based on the email address of your Google Account. That meant that if you changed the email address in your account settings, your meta tags would also change (and you'd become unverified for any sites you had used the old tag on). We've created a new version of the verification meta tag which is unrelated to your email address. Once you verify with a new meta tag, you'll never become unverified by changing your email address.

We've also revamped the way we do verification by HTML file. Previously, if your website returned an HTTP status code other than 404 for non-existent URLs, you would be unable to use the file verification method. A properly configured web server will return 404 for non-existent URLs, but it turns out that a lot of sites have problems with this requirement. We've simplified the file verification process to eliminate the checks for non-existent URLs. Now, you just download the HTML file we provide and upload it to your site without modification. We'll check the contents of the file, and if they're correct, you're done.

We hope these changes will make verification a little bit more pleasant. If you've already verified using the old methods, don't worry! Your existing verifications will continue to work. These changes only affect new verifications.

Some websites and software have features that help you verify ownership by adding the meta tag or file for you. They may need to be updated to work with the new methods. For example, Google Sites doesn't currently handle the new meta tag verification method correctly. We're aware of that problem and are working to fix it as soon as we can. If you discover other services that have similar problems, please work with their maintainer to resolve the issue. We're sorry if this causes any inconvenience.

This is just the first of several improvements we're working on for website verification. To give you a heads up, in a future update, we'll begin showing the email addresses of all verified owners of a given site to the other verified owners of that site. We think this will make it much easier to manage sites with multiple verified owners. However, if you're using an email address you wouldn't want the other owners of your site to see, now might be a good time to change it!

Posted by Sean Harding, Software Engineer

Wednesday, September 30, 2009

[Gd] Riding the Google Wave

| More

Google Web Toolkit Blog: Riding the Google Wave

Today our colleagues down under began inviting the first 100,000 users to preview Google Wave. We are very proud of the work that they have done and are quite pleased that GWT has helped make Google Wave a reality. You can read more in yesterday's Google Wave Backstage - Q&A with Dhanji Prasanna at InfoQ.

In fact the Wave team has told us that they would have not been able to build the user interface you see today without GWT. That's a great testament to our mission statement which reflects our focus on developer productivity and user performance, delivering a great AJAX experience across all major browsers. Also, with only 10-15% additional effort GWT allowed the team to build a user interface dedicated for mobile devices browsers.

Of course there's still much to do before Google Wave rolls out for everyone. If you weren't one of the developers who participated in the developer preview or helped build one of the many samples perhaps there's an extension you would like to build. Check out the Google Wave API Documentation to find out how you can get started with GWT and Google Wave.

Congratulations to the Google Wave team on achieving this milestone and we look forward to continuing  to work together.

[Gd] Translate your website with Google: Expand your audience globally

| More

Official Google Webmaster Central Blog: Translate your website with Google: Expand your audience globally

How long would it take to translate all the world's web content into 50 languages? Even if all of the translators in the world worked around the clock, with the current growth rate of content being created online and the sheer amount of data on the web, it would take hundreds of years to make even a small dent.

Today, we're happy to announce a new website translator gadget powered by Google Translate that enables you to make your site's content available in 51 languages. Now, when people visit your page, if their language (as determined by their browser settings) is different than the language of your page, they'll be prompted to automatically translate the page into their own language. If the visitor's language is the same as the language of your page, no translation banner will appear.

After clicking the Translate button, the automatic translations are shown directly on your page.

It's easy to install — all you have to do is cut and paste a short snippet into your webpage to increase the global reach of your blog or website.

Automatic translation is convenient and helps people get a quick gist of the page. However, it's not a perfect substitute for the art of professional translation. Today happens to be International Translation Day, and we'd like to take the opportunity to celebrate the contributions of translators all over the world. These translators play an essential role in enabling global communication, and with the rapid growth and ease of access to digital content, the need for them is greater than ever. We hope that professional translators, along with translation tools such as Google Translator Toolkit and this Translate gadget, will continue to help make the world's content more accessible to everyone.

Posted by Jeff Chin, Product Manager, Google Translate

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update has been promoted to the stable channel. There are no additional fixes or changes in this release.

Security Fixes:

CVE-2009-0689 dtoa() error parsing long floating point numbers

The v8 engine uses a common dtoa() implementation to parse strings into floating point numbers. We have applied a patch to fix a recent bug in this component.

Severity: High. An attacker might be able to run arbitrary code within the Google Chrome sandbox.

Credit: Original discovery by Maksymilian Arciemowicz of SecurityReason. The Google Chrome security team determined that Chrome was affected.

  • A victim would need to visit a page under an attacker's control.
  • Any code that an attacker might be able to run inside the renderer process would be inside the sandbox. Click here for more details about sandboxing.


Tuesday, September 29, 2009

[Gd] Deprecating shareable-prefs API on iGoogle

| More

iGoogle Developer Blog: Deprecating shareable-prefs API on iGoogle

If you don't know about or use the shareable-prefs API, you can safely stop reading now. If you do, we want to let you know that we'll be deprecating this API and feature.

A little over a year ago, iGoogle added shareable-prefs, enabling gadgets to share state across multiple users' pages. Since then, iGoogle has rolled out support for OpenSocial, enabling a collaboration model that is more tightly integrated into an application's design. Given this, along with the low adoption of the shareable-prefs feature in gadgets, we've decided it's time to deprecate the shareable-prefs feature.

In the next few weeks, iGoogle will remove the UI elements for shareable-prefs, preventing any new gadgets from implementing this feature. A few weeks later, iGoogle will break the links between these gadgets entirely, at which point, the gadgets will behave as if they were never shared at all. However, both users will retain the data in their preferences. The gadgets should continue to function in every other regard, but gadgets that wish to share data between users should implement OpenSocial's requestShareApp (paired with appdata, or a 3rd-party storage mechanism).

If you have any questions about these changes, please let us know in the iGoogle Developer Forum.

Posted by Dan Holevoet, Developer Programs

[Gd] Now available: Android 1.6 NDK

| More

Android Developers Blog: Now available: Android 1.6 NDK

Today Android 1.6 NDK, release 1 is available for download from the Android developer site.

To recap, the NDK is a companion to the SDK that provides tools to generate and embed native ARM machine code within your application packages. This native code has the same restrictions as the VM code, but can execute certain operations much more rapidly. This is useful if you're doing heavy computations, digital processing, or even porting existing code bases written in C or C++.

If you already use the Android 1.5 NDK, upgrading to this release is highly recommended. It provides the following improvements:

  • The ability to use OpenGL ES 1.1 headers and libraries
    If your application targets Android 1.6, your native code can now directly call OpenGL ES 1.1 functions to perform graphics rendering. This will help those programs that need to send large amounts of vertex data to the GPU. Note, however, that activity lifecycle and surface creation must still be performed from the VM. This NDK contains a new sample ("san-angeles") that shows exactly how to do that with a GLSurfaceView object.

  • The ability to target either Android 1.5 or 1.6 devices
    The NDK parses your project's properties to know which platform release it is targeting. It will then automatically use the proper headers and libraries to generate your native code. Any application that targets 1.5 will run on Android 1.5, Android 1.6 and any future official system release. Targeting 1.6 should, thus, only be done if your application requires new 1.6 features / APIs, like the ability to call OpenGL ES 1.x headers from native code.

  • The ability to put your native sources under your application's project tree
    You can now conveniently place all your sources (C, C++ and Java) under the same tree, for editing or version control purposes.

  • Many fixes to the NDK's build scripts
    The changes to the build scripts fix some annoying bugs and also increase host system compatibility.

If you have any questions, please join us in the Android NDK forum.


[Gd] TotT: Literate Testing With Matchers

| More

Google Testing Blog: TotT: Literate Testing With Matchers

By Zhanyong G. Mock Wan in Google Kirkland

Alright, it sounds like a good idea to verify that matchmakers can read and write. How does this concern us programmers, though?
Actually, we are talking about a way of writing tests here – a way that makes both the test code and its output read like English (hence “literate”). The key to this technique is matchers, which are predicates that know how to describe themselves. For example, in Google C++ Mocking Framework, ContainsRegex("Ahcho+!") is a matcher that matches any string that has the regular expression "Ahcho+!" in it. Therefore, it matches "Ahchoo!" and "Ahchoooo! Sorry.", but not "Aha!".
What's this to do with test readability, anyway? It turns out that matchers, whose names are usually verb phrases, lend themselves easily to an assertion style that resembles natural languages. Namely, the assertion

EXPECT_THAT(value, matcher);

succeeds if value matches matcher. For example,

#include <gmock/gmock.h>
using ::testing::Contains;
EXPECT_THAT(GetUserList(), Contains(admin_id));

verifies that the result of GetUserList() contains the administrator.

Now, pretend the punctuations aren't there in the last C++ statement and read it. See what I mean?

Better yet, when an EXPECT_THAT assertion fails, it will print an informative message that includes the expression being validated, its value, and the property we expect it to have – thanks to a matcher's ability to describe itself in human-friendly language. Therefore, not only is the test code readable, the test output it generates is readable too. For instance, the above example might produce:

Value of: GetUserList()
Expected: contains "yoko"
  Actual: { "john", "paul", "george", "ringo" }

This message contains relevant information for diagnosing the problem, often without having to use a debugger.
To get the same effect without using a matcher, you'd have to write something like:

std::vector<std::string> users = GetUserList();
EXPECT_TRUE(VectorContains(users, admin_id))
    << " GetUserList() returns " << users
    << " and admin_id is " << admin_id;

which is harder to write and less clear than the one-liner we saw earlier.

Google C++ Mocking Framework ( provides dozens of matchers for validating many kinds of values: numbers, strings, STL containers, structs, etc. They all produce friendly and informative messages. See to learn more. If you cannot
find one that matches (pun intended) your need, you can either combine existing matchers, or define your own from scratch. Both are quite easy to do. We'll show you how in another episode. Stay tuned!

Toilet-friendly version

[Gd] What happened in the Wave sandbox

| More

Google Wave Developer Blog: What happened in the Wave sandbox

My favorite day since we started the developer preview at Google I/O? Aug 7th. Alexander Dreiling flew down to visit the Wave team from SAP's research lab in Brisbane. He showed us a 7 min video of Gravity, a Google Wave extension that facilitates real-time, collaborative development of business processes. I never thought I'd see grown men cry over business process modelling.

Why the tears? Alex, Kathrin Fleischmann (SAP Research) and Soeren Balko (SAP NetWeaver BPM development) built a demo that highlights the power of the Google Wave platform to make complex tools live and collaborative. In the video, many team members collaborate in real time to build a model. Each piece of the model is colored based on the person that added it. The team discusses the model. Someone adds another participant midway through the development. That person uses playback to catch up on what they missed. And there is even a robot that checks and fixes semantic errors. In the end, a manager checks the work on her iPhone. Even Lars was floored and he is not easily impressed! also gave the team a virtual pat on the back when they sent over this video showing the Service Cloud's rich customer support experience in Google Wave. A mobile phone customer starts a wave with a company-supplied support robot. The robot creates a tracking record and pulls rich help content into the wave based on the customer's comments. When the problem isn't solved, the robot seamlessly brings the matter to the attention of a live agent, who can see the wave embedded in a familiar tool and interact with it there. Private replies let the agent consult colleagues before responding to the customer. All in a single wave.

Since Google I/O, more than 27,000 developers have been prototyping with the Google Wave APIs. Amazingly, these developers persevered, found work arounds, and advocated for new features when our APIs didn't do what they needed. Our APIs have made a fair bit of progress since May. Now you can build robots that control gadgets, providing a mechanism for tight integration with a rich UI. We've also made it easier to build extension installers to help people understand share extensions with their friends. The visual experience for interacting with gadgets has also been improved. We open sourced the Java Robots API. And made lots and lots of bug fixes.

While and SAP's demos are still prototypes, we are featuring a small set of amazing extensions ready to use today. LabPixes created a Sudoku gadget that lets you compete to solve a Sudoku Puzzle. A happy distraction in the hectic days leading up to September 30th! (Although I wish Lars would let me win once in awhile...) has integrated their rich video conference experience into Google Wave. It has amazing effects like making it snow or even simulating fire! AccuWeather has built a neat extension that lets you add weather forecasts to your event planning waves. Voice conversation is one of Google Wave's most commonly requested features, and we were thrilled to see Ribbit's gadget for managing telephone conferences. Lonely Planet built a very rich trip planning tool. Our own Pamela Fox updated the Google Maps gadget we have been using in our demos.

As we've talked about in the past, we're still working hard to improve the documentation and evolve the preview quality APIs to make it easy to build wave-y extensions. We're also working on larger changes like providing anonymous read-only access to embedded waves -- so anyone in the world will be able to see content of published waves. To help foster a strong developer ecosystem, we're exploring plans for a monetizable wave extension store.

To all sandbox developers, thank you for your patience, feedback, creativity and riding the sometimes bumpy waves with us. You will get accounts on tomorrow - check your sandbox account for instructions on how to login. You'll also get invitations to bring on people you want to wave with or have try your extensions. Google Wave is more fun with friends or colleagues to collaborate with so use your invitations wisely!

If you're feeling inspired to build an extension to Google Wave, sign up to give the APIs a spin, check out the developer's guide, and read the design principles. If you come up with something "wave-y" don't forget to let us know when you have extensions ready for users to try.

Stephanie Hannon, Google Wave Product Manager

Monday, September 28, 2009

[Gd] Chris Anderson: CouchDB: Relaxing Offline JavaScript

| More

Google Code Blog: Chris Anderson: CouchDB: Relaxing Offline JavaScript

Last week I hosted Chris Anderson for a Google tech talk on CouchDB as part of the Web Exponents speaker series. Chris is an Apache CouchDB committer. He is co-author of the forthcoming O'Reilly book CouchDB: The Definitive Guide and a director of

Making web applications work offline is a hot topic. Google Gears blazed the trail, and Web Storage is part of HTML5. CouchDB is a NoSQL alternative that makes it easy for web apps to run offline. This is important because even as bandwidth grows, latency is still an issue for a significant number of users, and outages or zero-bars can and do happen. CouchDB makes this a non-issue by running your application close to the user, on their device or in their browser. Chris calls this "ground computing" - a refreshing counterpoint to the oft-used "cloud computing" label. Hear more from Chris in his video and slides.

Check out other videos in the Web Exponents speaker series:

By Steve Souders, Performance Evangelist

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

The beta channel has been updated to

This update contains the following:
  • A fix to two significant history related crashing bugs 16591 and 21377.
  • A fix where PAC scripts would fail to parse if they ended with a comment and no new line 22864.
  • Corrected an issue where tabs would flash,for a split second, if multiple tabs were opened at the same time 20831.
  • Fixed an issue which prevented proper logins to CNET 22181.
Anthony Laforge
Google Chrome Program Manager

[Gd] Import Scans or Go Multilingual

| More

Official Google Data APIs Blog: Import Scans or Go Multilingual

About a month ago, we launched v3.0 of the Documents List Data API and promised more features were on the way. Well today, we're releasing two experimental features in the API: OCR and Document Translation.

The first, Optical Character Recognition (OCR), allows your application to create editable Google Documents from high-resolution images containing text (such as faxes or scanned letters). To perform OCR on a .png, .jpg, or .gif upload, add the ocr=true parameter onto your upload request:

POST /feeds/default/private/full?ocr=true HTTP/1.1

OCR will only work well on high-resolution images. The quality of the extracted text isn't perfect yet, but we're busy improving it!

Secondly, we have integrated Google Translate into the API. As a result, you can translate a document during upload. Simply add the targetLanguage and sourceLanguage parameters to your upload request:

POST /feeds/default/private/full/?targetLanguage=de&sourceLanguage=en HTTP/1.1

If sourceLanguage is omitted, we'll try to auto detect the document's language. All languages supported by Google Translate (full list here) are supported in the API.

As always, see the documentation for details. There's also a live demo (source will be available soon) up at

Posted by Jaron Schaeffer & Eric Bidelman, Google Docs Team

[Gd] [Libraries][New] - Chrome Frame 1.0.0 was added

| More

Google AJAX API Alerts: [Libraries][New] - Chrome Frame 1.0.0 was added

Chrome Frame 1.0.0 was added to the Libraries API! Hooray!

[Gd] [Libraries][Update] - YUI 2.8.0r4

| More

Google AJAX API Alerts: [Libraries][Update] - YUI 2.8.0r4

YUI was updated to version 2.8.0r4

[Gd] Google Chrome Frame Ajax Detection

| More

Google AJAX APIs Blog: Google Chrome Frame Ajax Detection

In partnership with the Google Chrome Frame team, we are making available a library to allow your web application to detect the presence of Google Chrome Frame. We on the Ajax team are excited about the possibilities of this add-on improving JavaScript performance and enabling some of the new features available in HTML5. If you have a web application which makes use of these new features, you can use this library to prompt the user to install Google Chrome Frame, or recognize when a user has just installed it. The library provides granular controls so that you can create the user experience which best suits your site.

As a short example, I've created the following simple demo which just detects whether Google Chrome Frame is installed or not with an alternate message if you are in a browser for which this plugin is not available.

Do you have Google Chrome Frame installed?
We're checking on that now.

Ben Lisbakken has also added detection for Google Chrome Frame to the Ajax Playground. If you view source on the page you can see another example of a customized CFInstall.check implementation which is designed to fit the page.

For more details on the Google Chrome Frame Ajax API, see the documentation and for questions, please visit the discussion group.


[Gd] Exploratory Testing ... in print and at STAR

| More

Google Testing Blog: Exploratory Testing ... in print and at STAR

By James A. Whittaker

Well my book survived a recession haunted publishing house and my own change of employer and is now available in print. The subtitle even changed as the techniques, which guided manual testing at Microsoft, were reapplied by Google engineers as a way to design test automation.

I'll be at STAR next week in Anaheim to talk about exploratory testing, the subject of the book. Accompanying me will be Rajat Dewan of Google who used the 'FedEx Tour' to reduce a test set from hundreds of manual test cases to exactly 9 automated ones. I hope you'll join us.


[Gd] Zipalign: an easy optimization

| More

Android Developers Blog: Zipalign: an easy optimization

The Android 1.6 SDK includes a tool called zipalign that optimizes the way an application is packaged. Doing this enables Android to interact with your application more efficiently and thus has the potential to make your application and the overall system run faster. We strongly encourage you to use zipalign on both new and already published applications and to make the optimized version available—even if your application targets a previous version of Android. We'll get into more detail on what zipalign does, how to use it, and why you'll want to do so in the rest of this post.

In Android, data files stored in each application's apk are accessed by multiple processes: the installer reads the manifest to handle the permissions associated with that application; the Home application reads resources to get the application's name and icon; the system server reads resources for a variety of reasons (e.g. to display that application's notifications); and last but not least, the resource files are obviously used by the application itself.

The resource-handling code in Android can efficiently access resources when they're aligned on 4-byte boundaries by memory-mapping them. But for resources that are not aligned (i.e. when zipalign hasn't been run on an apk), it has to fall back to explicitly reading them—which is slower and consumes additional memory.

For an application developer like you, this fallback mechanism is very convenient. It provides a lot of flexibility by allowing for several different development methods, including those that don't include aligning resources as part of their normal flow.

Unfortunately, the situation is reversed for users—reading resources from unaligned apks is slow and takes a lot of memory. In the best case, the only visible result is that both the Home application and the unaligned application launch slower than they otherwise should. In the worst case, installing several applications with unaligned resources increases memory pressure, thus causing the system to thrash around by having to constantly start and kill processes. The user ends up with a slow device with a poor battery life.

Luckily, it's very easy to align the resources:

  • Using ADT:
    • ADT (starting with 0.9.3) will automatically align release application packages if the export wizard is used to create them. To use the wizard, right click the project and choose "Android Tools" > "Export Signed Application Package..." It can also be accessed from the first page of the AndroidManifest.xml editor.
  • Using Ant:
    • The Ant build script that targets Android 1.6 (API level 4) can align application packages. Targets for older versions of the Android platform are not aligned by the Ant build script and need to be manually aligned.
    • Debug packages built with Ant for Android 1.6 applications are aligned and signed by default.
    • Release packages are aligned automatically only if Ant has enough information to sign the packages, since aligning has to happen after signing. In order to be able to sign packages, and therefore to align them, Ant needs to know the location of the keystore and the name of the key in The name of the properties are and key.alias respectively. If those properties are present, the signing tool will prompt to enter the store/key passwords during the build, and the script will sign and then align the apk file. If the properties are missing, the release package will not be signed, and therefore will not get aligned either.
  • Manually:
    • In order to manually align a package, zipalign is in the tools folder of the Android 1.6 SDK. It can be used on application packages targeting any version of Android. It should be run after signing the apk file, using the following command:
      zipalign -v 4 source.apk destination.apk
  • Verifying alignment:
    • The following command verifies that a package is aligned:
      zipalign -c -v application.apk

We encourage you manually run zipalign on your currently published applications and to make the newly aligned versions available to users. And don't forget to align any new applications going forward!