Friday, July 17, 2009

[Gd] Dev Channel Update:

| More

Google Chrome Releases: Dev Channel Update:

Google Chrome has been released to the Dev channel for Mac and Linux.  Windows remains on

Highlights in this release:
  • Linux: Restarting should no longer lose all session information.
  • Fix for crash when saving files. (Issue: 15555)
  • Fix a crash while dragging (and closing a tab). (Issue: 16280)
  • Linux: Fixes "fonts stop rendering after a few minutes" (Issue: 16403)
  • Linux: Fixes the "no pages load on 64-bit" issue.
More details are available in the release notes and the 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] Breaking the Persian language barrier with the AJAX APIs

| More

Google Code Blog: Breaking the Persian language barrier with the AJAX APIs

There are several barriers to the free flow of information, but the language barrier is one that we can reduce with a little help from the developer community.

To encourage the sharing of ideas and information across the web, early last year we announced the AJAX Language API. Then, a few weeks ago we announced the Virtual Key board API.

In the span of a few months, developers have already started to integrate these APIs in very innovative ways: Vast Rank,, and Jeevansathi.

Today, I'm happy to announce that we are supporting Persian in the Language API. This comes on the heels of our announcement that we support Persian on Google Translate.

With this launch, the documentation for the AJAX Language API has been translated into Persian (the first right-to-left language supported on Google Code) and both the AJAX Language API and Virtual Keyboard API now support Persian.

I encourage you to use this API and to make this world a smaller place. Thanks!

API زبان AJAX فارسی را پشتیبانی میکند.

موانع متعددی بر سر راه جریان آزاد اطلاعات وجود دارد. اما ما می توانیم موانع ترجمه را با کمی کمک از طرف برنامه نویسان کاهش دهیم.

برای تشویق به اشتراک گذاشتن ایده ها و اطلاعات در سراسر وب ، در اوایل سال گذشته ما AJAX زبان API و سپس ، چند هفته پیش صفحه کلید مجازی API را راه اندازی کردیم.

پس از تنها چند ماه برنامه نویسان به طرق بسيار خلاقانه ای شروع به استفاده از این API ها کرده اند:
Vast Rank

امروز، من با خوشحالی اعلام می کنم که ما شروع به پشتیبانی از فارسی در API زبان کرده ایم. این اقدام پس از اعلان پشتیبانی ما از ترجمه فارسی در گوگل می آید .

با این پرتاب ،اسناد AJAX زبان API به فارسی ترجمه شده است (که اولین اقدام به پشتیبانی از یک زبان سمت راست به چپ در کد گوگل می باشد) و هر دوی AJAX زبان API و API صفحه مجازی کلید در حال حاضر فارسی را پشتیبانی می کنند.

من شما را به استفاده از این API تشویق می کنم با این امید که این جهان را به یک محل در دسترس بدل کنیم. با تشکر!

By Ali Pasha and Adam Feldman, Google Developer Programs

Thursday, July 16, 2009

[Gd] Google Wave Sandbox Update

| More

Google Wave Developer Blog: Google Wave Sandbox Update

It's been quite a whirlwind since we demonstrated Google Wave at Google I/O and began giving developers access to a preview on the Google Wave Sandbox. We really appreciate the excitement and enthusiasm from the developer community for the Google Wave API.

Thus far, we've given sandbox access to about 5,800 attendees of Google I/O, the Google Developers Days in China, Japan, and Brazil, and various other events. We have also started activating the more than 20,000 requests submitted on the Google Wave Sandbox Request Form. If you haven't sent in your request, please take a moment to do so.

We are gradually ramping up capacity on the sandbox, and expect to finish activating all 20,000 requests within the next month. We'll start with those that indicated high "pain tolerance" on the form and are planning large projects, but otherwise using a first come, first served basis.

Finally, a reminder about office hours: each week the Wave engineering team provides live Q&A for all questions relating to the Wave APIs (robots, gadgets, and embed). To cater to developers around the world, we now alternate between 2 time slots every other Wednesdays:
  • July 22: 9pm - 10pm PDT
  • July 29: 11am - 12pm PDT
  • August 5: 9pm - 10pm PDT
  • August 12: 11am - 12pm PDT
  • And so on...

See the full schedule on the Google Developer Events Calendar (which you can add to your own calendar using the links at the bottom of the page). The transcripts for the office hours will be posted within 24 hours to the Google Wave API Group for everyone to read.

If you do not yet have sandbox access, you can always go to Google Wave API Group to post questions and to connect with other Wave developers. If you only want to receive our official updates and announcements, you can subscribe to the Google Wave Sandbox Announcement Group.

Posted by Austin Chau, Google Developer Programs Engineer

[Gd] Blog Editor: Moderating Comments

| More

Google Testing Blog: Blog Editor: Moderating Comments

by Patrick Copeland

You might not know this but when we started this blog back in January 2007 we were the first at Google to allow readers to comment openly on our posts. We take pride in our goal to participate in the testing community.

This openness is sometimes abused. Lately the volume of comment spam has been on the raise. We have to spend a lot of time playing "whack-a-mole" cleaning it up. It's annoying to our readers and clutters the legitimate discussion.

We've taken the step to moderate comments starting today and will delete spam before you see it. Comments that are clearly spam or are purely promotional in nature will be filtered. The only down side is that comments will have a slight latency getting posted. We will continue to encourage debate and won't censor conflicting or alternative ideas.

Thanks for understanding. And keep up the rich discussion.

[Gd] [Libraries][Update] - Dojo 1.3.2

| More

Google AJAX API Alerts: [Libraries][Update] - Dojo 1.3.2

Dojo was updated to version 1.3.2

[Gd] Stable, Beta update: Bug fixes

| More

Google Chrome Releases: Stable, Beta update: Bug fixes

Google Chrome has been released to the Beta and Stable channels. This release fixes some minor bugs:

  • Fix: Solving captcha images broken at (Issue 15569)
  • Make forward/backward navigation work even when redirection is involved. (Issue 9663, issue 10531)
  • Fix: Daylight savings time not recognized for some CET locales. (Issue 12579)
  • Fix a browser crash on closing a URL request. (Issue 8942)
  • Update the V8 Javascript engine to version to fix issues with regular expressions.
  • Update Gears to the latest release,

In addition, this release fixes the following security issues:

Heap overflow with Javascript regular expressions

Evaluating a specially-crafted regular expression in Javascript on a web page can lead to memory corruption and possibly a heap overflow. Visiting a maliciously crafted website may lead to a renderer (tab) crash or arbitrary code execution in the Google Chrome sandbox.

More info: (This issue will be made public once a majority of users are up to date with the fix.)

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

Credit: This issue was found by the Google Chrome security team.

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

Memory corruption in the browser process

A compromised renderer (tab) process could cause the browser process to allocate very large memory buffers. This error could cause the browser process (and all tabs) to crash or possibly allow arbitrary code execution with the privileges of the logged on user. To exploit this vulnerability, an attacker would need to be able to run arbitrary code inside the renderer process.  

SeverityCritical. In conjunction with a vulnerability allowing arbitrary code to run in the renderer, an attacker might be able to run code with the privileges of the logged on user.

Credit: This issue was found by the Google Chrome security team.

  • A victim would need to visit a page under an attacker's control.
  • The attacker must exploit a second vulnerability to control the renderer process.

[Gd] Better search on more websites

| More

Google Custom Search: Better search on more websites

Posted by: Radu Cornea, Software Engineer

Earlier this year, we made it easier to add high quality search to your websites by delivering search functionality right to where many of you manage your sites online: your hoster's console. The Custom Search provisioning API allows partners, such as web hosters, to configure search boxes for your site without requiring you to come to Google. This also enabled Custom Search to be added to Google Services for Websites, an offering of useful website tools and services for partners.

Many hosters have enabled Webmaster Tools and Custom Search in their control panels; is the most recent addition to our list of partners that have integrated Custom Search into their service using Google Services for Websites. provides online business services and tools, such as web hosting, domain name registration, web design, and e-commerce services as well as dedicated servers and managed hosting solutions, to small- to medium-sized businesses.

Here's a screenshot of their integration. Websites can enable search with a couple of clicks!

Working with partners such as web hosting providers has made things a great deal easier for webmasters, making useful tools more accessible. Integrating with the right tools will help you analyze your website traffic and improve user retention; Custom Search is a critical element of this, helping people find the right information, products and services quickly.

We are looking forward to enabling more partners to integrate with these important webmaster services. As always, let us know how we can improve our products and services. If you are a web site hoster interested in incorporating Google webmaster services into your platform, check out Google Services for Websites.

[Gd] The Advantages of Unit Testing Early

| More

Google Testing Blog: The Advantages of Unit Testing Early

by Shyam Seshadri

Nowadays, when I talk with (read: rant at) anyone about why they should do test driven development or write unit tests, my spiel has gotten extremely similar and redundant to the point that I don't have to think about it anymore. But even when I do pairing with skeptics, even as I cajole and coax testable code or some specific refactorings out of them, I wonder, why is it that I have to convince you of the worth of testing ? Shouldn't it be obvious ?

And sadly, it isn't. Not to many people. To many people, I come advocating the rise of the devil itself. To others, it is this redundant, totally useless thing that is covered by the manual testers anyway. The general opinion seems to be, "I'm a software engineer. It is my job to write software. Nowhere in the job description does it say that I have to write these unit tests." Well, to be fair, I haven't heard that too many times, but they might as well be thinking it, given their investment in writing unit tests. And last time I checked, an engineer's role is to deliver a working software. How do you even prove that your software works without having some unit tests to back you up ? Do you pull it up and go through it step by step, and start cursing when it breaks ? Because without unit tests, the odds are that it will.

But writing unit tests as you develop isn't just to prove that your code works (though that is a great portion of it). There are so many more benefits to writing unit tests. Lets talk in depth about a few of these below.

Instantaneous Gratification

The biggest and most obvious reason for writing unit tests (either as you go along, or before you even write code) is instantaneous gratification. When I write code (write, not spike. That is a whole different ball game that I won't get into now), I love to know that it works and does what it should do. If you are writing a smaller component of a bigger app (especially one that isn't complete yet), how are you even supposed to know if what you just painstakingly wrote even works or not ? Even the best engineers make mistakes.

Whereas with unit tests, I can write my code. Then just hit my shortcut keys to run my tests, and voila, within a second or two, I have the results, telling me that everything passed (in the ideal case) or what failed and at which line, so I know exactly what I need to work on. It just gives you a safety net to fall back on, so you don't have to remember all the ways it is supposed to work in. Something tells you if it is or not.

Also, doing Test Driven Development when developing is one of the best ways to keep track of what you are working on. I have times when I am churning out code and tests, one after the other, before I need to take a break. The concept of TDD is that I write a failing test, and then I write just enough code to pass that test. So when I take a break, I make it a point to leave at a failing test, so that when I come back, I can jump right back into writing the code to get it to pass. I don't have to spend 15 - 20 minutes reading through the code to figure out where I left off. My asserts usually tell me exactly what I need to do.

Imposing Modularity / Reusability

The very first rule of reusable code is that you have to be able to instantiate an instance of the class before you can use it. And guess what ? With unit tests, you almost always have to instantiate an instance of the class under test. Therefore, writing a unit test is always a first great step in making code reusable. And the minute you start writing unit tests, most likely, you will start running into the common pain points of not having injectable dependencies (Unless of course, you are one of the converts, in which case, good for you!).

Which brings me to the next point. Once you start having to jump through fiery hoops to set up your class just right to test it, you will start to realize when a class is getting bloated, or when a certain component belongs in its own class. For instance, why test the House when what you really want to test is the Kitchen it contains. So if the Kitchen class was initially part of the House, when you start writing unit tests, it becomes obvious enough that it belongs separately. Before long, you have modular classes which are small and self contained and can be tested independently without effort. And it definitely helps keep the code base cleaner and more comprehensible.

Refactoring Safety Net

Any project, no matter what you do, usually ends up at a juncture where the requirements change on you. And you are left with the option of refactoring your codebase to add / change it, or rewrite from scratch. One, never rewrite from scratch, always refactor. Its always faster when you refactor, no matter what you may think. Two, what do you do when you have to refactor and you don't have unit tests ? How do you know you haven't horribly broken something in that refactor ? Granted, IDE's such as Eclipse and IntelliJ have made refactoring much more convenient, but adding new functionality or editing existing features is never simple.

More often than not, we end up changing some undocumented way the existing code behaved, and blow up 10 different things (it takes skill to blow up more, believe me, I have tried). And its often something as simple as changing the way a variable is set or unset. In those cases, having unittests (remember those things you were supposed to have written?) to confirm that your refactoring broke nothing is godsend. I can't tell you the amount of times I have had to refactor a legacy code base without this safety net. The only way to ensure I did it correct was to write these large integration tests (because again, no unit tests usually tends to increase the coupling and reduce modularity, even in the most well designed code bases) which verified things at a higher level and pray fervently that I broke nothing. Then I would spend a few minutes bringing up the app everytime, and clicking on random things to make sure nothing blew up. A complete waste of my time when I could have known the same thing by just running my unit tests.


Finally, one of my favorite advantages to doing TDD or writing unit tests as I code. I have a short memory for code I have written. I could look back at the code I wrote two days ago, and have no clue what I was thinking. In those cases, all I have to do is go look at the test for a particular method, and that almost always will tell me what that method takes in as parameters, and what all it should be doing. A well constructed set of tests tell you about valid and invalid inputs, state that it should modify and output that it may return.

Now this is useful for people like me with short memory spans. But it is also useful, say, when you have a new person joining the team. We had this cushion the last time someone joined our team for a short period of time, and when we asked him to add a particular check to a method, we just pointed him to the tests for that method, which basically told him what the method does. He was able to understand the requirements, and go ahead and add the check with minimal handholding. And the tests give a safety net so he doesn't break anything else while he was at it.

Also useful is the fact that later, when someone comes marching through your door, demanding you fix this bug, you can always make sure whether it was a a bug (in which case, you are obviously missing a test case) or if it was a feature that they have now changed the requirements on (in which case you already have a test which proves it was your intent to do it, and thus not a bug).

Wednesday, July 15, 2009

[Gd] Farewell to Mashup Editor

| More

Google Mashup Editor Blog: Farewell to Mashup Editor

Posted by Eric Tholomé, Director, Developer Products

We had announced back in January that we would be shutting down the Mashup Editor in six months, and that time has come. Since a few of you still have applications running on the Mashup Editor, we decided to give you some extra time - 4 weeks. You can use this time to migrate your application to App Engine or any other infrastructure, or simply retrieve your data. We encourage you to replace your application as soon as possible with a static page giving useful information to your users about where to go. On August 12th, all traffic to the Mashup Editor will be redirected to a generic page. Note that your code is available on Project Hosting at{username}-{app name} (where non-supported characters are replaced by '-') and will remain available there for the foreseable future, but your data will not be accessible beyond August 12th. We've factored most of our learning from the Mashup Editor into App Engine, so we hope you'll give it a try if you haven't yet.

[Gd] Introducing the Debug Panel for GWT

| More

Google Web Toolkit Blog: Introducing the Debug Panel for GWT

The primary intent of the Debug Panel for the Google Web Toolkit (GWT) is to provide the developer of a GWT application performance data about the application as well as tools to debug the client side application code. Web applications built with GWT run mainly in the client's environment, over which the developer has little control or access. The Debug Panel provides tools to the developer to help lift the shroud over the client environment to help diagnose problems, help tune and improve performance as well as assist with application testing.

As with any application, testing and quality assurance is important to a GWT application. Because a GWT application is user facing, performance testing is very important. However, measuring the performance of an application running in a browser is not easy. With all the moving parts of the client code - RPCs, DOM updates, etc. - and the fact that with GWT you are no longer writing JavaScript, it can be hard to locate bottlenecks. Automating the performance tests and getting accurate numbers on RPC response time is even harder. This is where the Debug Panel for GWT comes into the picture. It is an external library that can easily be added to any GWT Web application and will provide you with that performance data, an insight into what goes on behind the scenes and help you automate the whole thing, too.

Here is a sample screenshot of the Debug Panel in action:

Here, the Debug Panel shows us the statistics of an invocation of the EchoService as well as the startup times. It is clear from the example that RPC finished quickly. It shows that the slowest component was waiting for the server to respond at 121ms. While serializing the request and deserializing the response both took 19ms, updating the UI with the data returned from the server only took 2ms. These are the kinds of numbers you would want to see!

Here is another example screenshot of the Debug Panel:

This time, the application was run in Hosted Mode and there was an exception during the RPC. Once you compile your application to JavaScript, the stack trace will be a JavaScript stack trace of course. The exception panel in the Debug Panel is also an example of the extensibility of the Debug Panel. As a GWT application developer, you can add your own panels to the Debug Panel that are customized to your application. The Debug Panel provides you with a framework to display your application's debug data as well as a lightwheight component to add to your main application, so it can communicate the relevant data to the Debug Panel, without affecting runtime performance much.

In fact, you can plug the Debug Panel into an existing application without changing the application's code. This also means that there is no change required in the compiled JavaScript. Therefore, you can serve your GWT web application both with the Debug Panel enabled, to internal IP's for example, or disabled for everybody else.

Check out an online example of the Debug Panel, check out the example's source to see how easy it is to use or check out the Google Code project for more information.

Pascal Muetschard, Software Engineering Team


[Gd] Smaller is Faster (and Safer Too)

| More

Chromium Blog: Smaller is Faster (and Safer Too)

We have just started using a new compression algorithm called Courgette to make Google Chrome updates small.

We have built Google Chrome to address multiple factors that affect browser security. One of the pillars of our approach is to keep the software up to date, so we push out updates to Google Chrome fairly regularly. On the stable channel these are mainly security bug fixes, but the updates are more adventurous and numerous on developer channel.

It is an anathema to us to push out a whole new 10MB update to give you a ten line security fix. We want smaller updates because it narrows the window of vulnerability. If the update is a tenth of the size, we can push ten times as many per unit of bandwidth. We have enough users that this means more users will be protected earlier. A secondary benefit is that a smaller update will work better for users who don't have great connectivity.

Rather then push put a whole new 10MB update, we send out a diff that takes the previous version of Google Chrome and generates the new version. We tried several binary diff algorithms and have been using up until now. We are big fans of bsdiff - it is small and worked better than anything else we tried.

But bsdiff was still producing diffs that were bigger than we felt were necessary. So we wrote a new diff algorithm that knows more about the kind of data we are pushing - large files containing compiled executables. Here are the sizes for the recent 190.1->190.4 update on the developer channel:
  • Full update: 10,385,920 bytes
  • bsdiff update: 704,512 bytes
  • Courgette update: 78,848 bytes
The small size in combination with Google Chrome's silent update means we can update as often as necessary to keep users safe.

More information on how Courgette works can be found here.

Posted by Stephen Adams, Software Engineer

Tuesday, July 14, 2009

[Gd] Google Wave API Presentations: Now Online

| More

Google Wave Developer Blog: Google Wave API Presentations: Now Online

Since the developer release a month ago, the engineering team has flown across the world talking to developers and explaining how Google Wave works - like at Google I/O in San Francisco, and most recently, at GDD Brazil in Sao Paolo. The team loves meeting developers everywhere - and of course, tasting their local delicacies (like sweet potato ice cream in Japan and pão de queijo in Brazil) - but at some point, they have to get back to actually engineering this whole Wave thing.

So, to make sure that other developers can still learn about Google Wave straight from the engineers' mouths, we've added a media gallery to the docs that links to various videos and slides. You can watch talks like "Programming with Google Wave", "Google Wave: Powered by GWT", "Google Wave: Under the Hood", among others.

If you're a developer thinking about presenting about Google Wave at your local developer events, you can use these presentations as a basis, and if you come up with your own set of slides or have a recording of your talk, let us know in the forum so that we can add them to the gallery.

Posted by Pamela Fox, Developer Relations

[Gd] Software Testing Categorization

| More

Google Testing Blog: Software Testing Categorization

by Miško Hevery

You hear people talking about small/medium/large/unit/integration/functional/scenario tests but do most of us really know what is meant by that? Here is how I think about tests.


Lets start with unit test. The best definition I can find is that it is a test which runs super-fast (under 1 ms) and when it fails you don't need debugger to figure out what is wrong. Now this has some implications. Under 1 ms means that your test cannot do any I/O. The reason this is important is that you want to run ALL (thousands) of your unit-tests every time you modify anything, preferably on each save. My patience is two seconds max. In two seconds I want to make sure that all of my unit tests ran and nothing broke. This is a great world to be in, since if tests go red you just hit Ctrl-Z few times to undo what you have done and try again. The immediate feedback is addictive. Not needing a debugger implies that the test is localized (hence the word unit, as in single class).

The purpose of the unit-test is to check the conditional logic in your code, your 'ifs' and 'loops'. This is where the majority of your bugs come from (see theory of bugs). Which is why if you do no other testing, unit tests are the best bang for your buck! Unit tests, also make sure that you have testable code. If you have unit-testable code than all other testing levels will be testable as well.

A is what I would consider great unit test example from Testability Explorer. Notice how each test tells a story. It is not testMethodA, testMethodB, etc, rather each test is a scenario. Notice how at the beginning the test are normal operations you would expect but as you get to the bottom of the file the test become little stranger. It is because those are weird corner cases which I have discovered later. Now the funny thing about is that I had to rewrite this class three times. Since I could not get it to work under all of the test cases. One of the test was always failing, until I realized that my algorithm was fundamentally flawed. By this time I had most of the project working and this is a key class for byte-code analysis process. How would you feel about ripping out something so fundamental out of your system and rewriting it from scratch? It took me two days to rewrite it until all of my test passed again. After the rewrite the overall application still worked. This is where you have an AHa! moment, when you realize just how amazing unit-tests are.

Does each class need a unit test? A qualified no. Many classes get tested indirectly when testing something else. Usually simple value objects do not have tests of their own. But don't confuse not having tests and not having test coverage. All classes/methods should have test coverage. If you TDD, than this is automatic.


So you proved that each class works individually, but how do you know that they work together? For this we need to wire related classes together just as they would be in production and exercise some basic execution paths through it. The question here we are trying to answer is not if the 'ifs' and 'loops' work, (we have already answered that,) but whether the interfaces between classes abide by their contracts. Great example of functional test is Notice how the input of each test is an inner class in the test file and the output is To get the output several classes have to collaborate together to: parse byte-codes, analyze code paths, and compute costs until the final cost numbers are asserted.

Many of the classes are tested twice. Once directly throughout unit-test as described above, and once indirectly through the functional-tests. If you would remove the unit tests I would still have high confidence that the functional tests would catch most changes which would break things, but I would have no idea where to go to look for a fix, since the mistake can be in any class involved in the execution path. The no debugger needed rule is broken here. When a functional test fails, (and there are no unit tests failing) I am forced to take out my debugger. When I find the problem, I add a unit test retroactively to my unit test to 1) prove to myself that I understand the bug and 2) prevent this bug from happening again. The retroactive unit test is the reason why the unit tests at the end of file are "strange" for a lack of a better world. They are things which I did not think of when i wrote the unit-test, but discovered when I wrote functional tests, and through lot of hours behind debugger track down to class as the culprit.

Now computing metrics is just a small part of what testability explorer does, (it also does reports, and suggestions) but those are not tested in this functional test (there are other functional tests for that). You can think of functional-tests as a set of related classes which form a cohesive functional unit for the overall application. Here are some of the functional areas in testability explorer: java byte-code parsing, java source parsing, c++ parsing, cost analysis, 3 different kinds of reports, and suggestion engine. All of these have unique set of related classes which work together and need to be tested together, but for the most part are independent.


We have proved that: 'ifs' and 'loops' work; and that the contracts are compatible, what else can we test? There is still one class of mistake we can make. You can wire the whole thing wrong. For example, passing in null instead of report, not configuring the location of the jar file for parsing, and so on. These are not logical bugs, but wiring bugs. Luckily, wiring bugs have this nice property that they fail consistently and usually spectacularly with an exception. Here is an example of end-to-end test: Notice how these tests exercises the whole application, and do not assert much. What is there to assert? We have already proven that everything works, we just want to make sure that it is wired properly.

[Gd] Sidebar Gadgets: Coming soon to a Calendar near you

| More

Google Code Blog: Sidebar Gadgets: Coming soon to a Calendar near you

We've always believed users should have open and unencumbered access to their data, and Google Calendar is no exception. Whether through iCalendar, CalDAV, or the Calendar Data API, there are a multitude of options to access Calendar from other applications. However, developers have been asking for a way to extend the Google Calendar interface itself, and we've been listening.

Today, as part of Google Calendar Labs, we're opening up Google Calendar as a gadget container.

Gadget developers will already be familiar with most of this environment, complete with features such as OpenSocial for social networking and OAuth for working with third-party services. However, for the first time we're also providing an API to control and interact with the Calendar user interface. This means that even though your gadgets are running inside a sandbox, they are first-class elements of the Calendar user experience. In fact, many of the experiments we've made available through Calendar Labs were written using the publicly available gadget API.

We hope you'll share our excitement in opening up the Google Calendar interface. To get you started, take a look at the Sidebar Gadget documentation and sample code. If you have any questions or ideas for improvement, feel free to visit the Calendar API help group and let us know!

By Trevor Johns, Google Developer Team

[Gd] Google Friend Connect - Now in 47 new languages

| More

Official Google Webmaster Central Blog: Google Friend Connect - Now in 47 new languages

Have you been holding off on using Google Friend Connect because your site isn't in English? Starting today, Friend Connect is available in 47 new languages, including French, Italian, German, Spanish, Chinese, Japanese, Hindi and Portuguese. Now you can easily add social features that match the language of other content on your site.

Most Google-created gadgets (such as the members, comments, and recommendation gadgets) are now available in these new languages. Some developers have also created gadgets that support additional languages and we hope that there will be more to come in the future. To see a list of gadgets available in your language, visit the gadget gallery.

When you add Friend Connect to a new site, it will default to your primary language. But if your site is in another language, simply select it on the site settings tab and Friend Connect will automatically render the gadgets in that language. And if have multiple sites in different languages, you can select a different language for each of your sites.

To learn more or see the full list of languages, check out the Social Web Blog.

Posted by Mendel Chuang, Product Marketing Manager, Google Friend Connect

[Gd] The Plague of Amnesia

| More

Google Testing Blog: The Plague of Amnesia

By James A. Whittaker

Memory is supposed to be the first thing to go as one ages but in the grand scheme of engineering, software development can hardly be called elderly. Indeed, we’re downright young compared to civil, mechanical, electrical and other engineering disciplines. We cannot use age as an excuse for our amnesia.

There are two types of amnesia that plague software testers. We have team amnesia that causes us to forget our prior projects, our prior bugs, tests, failures and so forth. It’s time we developed a collective memory that will help us to stop repeating our mistakes. Every project is not a fresh start, it's only a new target for what is now a more experienced team. The star ship Enterprise keeps a ship's log. A diary that documents its crews’ adventures and that can be consulted for details that might help them out of some current jam. I'm not advocating a diary for test teams, but I do want a mechanism for knowledge retention. The point is that as a team we build on our collective knowledge and success. The longer the Enterprise crews' memory, the better their execution.

Quick, tell me about the last major failure of your teams’ product? Does your team have a collective memory of common bugs? Do you share good tests? If one person writes a test that verifies some functionality does everyone else know this so they can spend their time testing elsewhere? Do problems that break automation get documented so the painstaking analysis to fix them doesn’t have to be repeated? Does the team know what each other is doing so that their testing overlaps as little as possible? Is this accomplished organically with dashboards and ongoing communication or are the only sync points work-stopping, time-wasting meetings? Answer honestly. The first step to recovery is to admit you have a problem.

The second type of memory problem is industry amnesia. When I mentioned Boris Beizer and the pesticide paradox in my last post, how many of you had to look it up? And those who did know about it, how's your AJAX skills? Be honest...there are folks with both a historical perspective and modern skills but they are far too rare. Our knowledge, it seems, isn’t collective, it’s situational. Those who remember Beizer's insights worked in a world where AJAX didn’t exist, those who webspeak without trouble missed a lot of foundational thinking and wisdom. Remembering only what is in front of us is not really memory.

Industry amnesia is a real problem. Think about it this way: That testing problem in front of you right now (insert a problem that you are working on here) has been solved before. Are you testing an operating system? Someone has, many of them. Web app? Yep, that’s been done. AJAX? Client-server? Cloud service? Yes, yes and yes. Chances are that what you are currently doing has been done before. There are some new testing problems but chances are the one in front of you now isn’t one of them. Too bad the collective memory of the industry is so bad or it would be easy to reach out for help.

Let me end this column by pointing my finger inward: How will we (Google) test the newly announced Chrome operating system? How much collective knowledge have we developed from Chrome and Android? How much of what we learned testing Android will help? How much of it will be reusable? How easily will the Chrome and Andriod test teams adapt to this new challenge? Certainly many test problems are ones we've faced before.

Will we remember?


Monday, July 13, 2009

[Gd] Webmaster Central YouTube update for July 6th - 10th

| More

Official Google Webmaster Central Blog: Webmaster Central YouTube update for July 6th - 10th

Want to see what's new on the Webmaster Central YouTube channel? Check out the answers to the latest Grab Bag questions:
Below is Matt's clarification about Google's use of the meta description tag:

Feel free to leave comments letting us know how you liked the videos, and if you have any specific questions, ask the experts in the Webmaster Help Forum.

Posted by Michael Wyszomierski, Search Quality Team

[Gd] Google App Engine for Java SDK 1.2.2 Released

| More

Google App Engine Blog: Google App Engine for Java SDK 1.2.2 Released

Greetings App Engine developers! We're pleased to announced the availability of a new Java SDK, available for download here. This is largely a bugfix release, but there are a few new features we think you'll be excited to get your hands on:

  • The appcfg upload tool includes proxy support.

  • JDO and JPA support an extension that lets you mark individual fields as "unindexed."

  • At long last, the dev appserver has a data viewer. Start your app locally and point your browser to http://localhost:8080/_ah/admin to check it out.

  • The local datastore now has the same transaction behavior as the production datastore (more info:

  • You can issue ancestor queries inside transactions.

For a full list of features, see the release notes.

[Gd] ADC 2 Updates

| More

Android Developers Blog: ADC 2 Updates

Since the announcement of Android Developer Challenge 2 in May, Android phones continue to be deployed in countries worldwide. Android phones are currently available in over 20 countries, with more on the way. As I've mentioned earlier, we'll be including real-world users of these phones to help review and score your submissions. It is important to remember that your apps will be reviewed by judges around the world on actual devices; thus, be sure to make it extremely easy for users/judges to access your apps with minimum setup.

Some of you have been asking for clarifications on what we mean by "open only to applications that have not been published". To be specific, applications that are available on Android Market before August 1, 2009 will not be eligible to participate in the contest. Users have already been providing comments for apps that are currently available on Android Market, so it wouldn't make sense for them to "judge" the same apps again in this contest. In addition, apps that include or that are based on open source projects are fully welcomed, as long as the application itself is not on Android Market until August 1, 2009.

If you want to find out more details about ADC 2, you can find everything at the ADC 2 page along with the Terms and Conditions. For the moment, the most important thing to know is that ADC 2 submissions will be due August 31. I can't wait to see what you all come up with this time.

Happy coding -- and good luck!


[Gd] Update! Google Test Automation Conference: Website available

| More

Google Testing Blog: Update! Google Test Automation Conference: Website available

by Juergen Allgayer, Conference Chair

The organization of the 4th Google Conference on Test Automation (GTAC 2009), held in Zurich October 21-22, is well underway and we are looking forward to an exiting event. We are pleased to announce the GTAC website and that presenters will be able to apply for sponsorship.

Sponsorship available
One presenter per accepted proposal will be able to apply for sponsorship from Google. For sponsored presenters Google will arrange and pay travel and lodging (within reason). Further details will be announced to speakers of accepted proposals.

Website on-line (
The conference website is now on-line with lots of information about the event, on how to submit proposals, about the venue, and much more.