Friday, July 24, 2009

[Gd] Google Wave Federation Protocol and Open Source Updates

| More

Google Wave Developer Blog: Google Wave Federation Protocol and Open Source Updates

Following Monday’s API Hackathon, we hosted Federation Day, which included 150 developers interested in learning more about Google Wave, contributing to the Google Wave Federation Protocol, and providing their own wave services. While these are still early days for the federation protocol and open source project, our vision for Wave recognizes the importance of encouraging and promoting third-party implementations, so users and businesses are able to customize and manage everything from the ground up (features, data, etc).

To kickoff Federation Day, we open sourced two components: 1) the Operational Transform (OT) code and the underlying wave model, and 2) a basic client/server prototype that uses the wave protocol. The OT code is the heart and soul of the collaborative experience in Google Wave and we plan that code will evolve into the production-quality reference implementation. The prototype is intended primarily as a simple "hello, world" implementation, to encourage experimentation using the Google Wave Federation Protocol. All of this code -- nearly 40,000 lines of Java code -- is available under the Apache 2.0 license, and we'll be open sourcing more code as wave evolves. Check out the source code and get started with the introductory documentation.

Since Google I/O, we've been iterating on the draft protocol specification, and have made substantial enhancements to the Operational Transformation algorithm -- to the point where the open source code is actually ahead of the algorithm implemented in our servers in production. We've also Creative Commons licensed the protocol specification, the whitepapers and the Google Wave APIs documentation.

Next up, we are working towards using the new Operational Transform code in our own production systems, and opening up the federation port on (and later the instance).

To get more details about these updates, please check out this status note. Looking forward to seeing you on the forum!

Posted by Jochen Bekmann and Sam Thorogood, Software Engineers, Google Wave

[Gd] Update! GTAC Keynote Speakers: Niklaus Wirth and Alberto di Meglio

| More

Google Testing Blog: Update! GTAC Keynote Speakers: Niklaus Wirth and Alberto di Meglio

by Juergen Allgayer, Conference Chair

We are thrilled to announce that Niklaus Wirth and Alberto di Meglio are this years keynote speakers at the 4th Google Test Automation Conference (GTAC).

Niklaus Wirth
Prof. Niklaus Wirth, is the designer of several programing languages and operating systems, including Pascal and Oberon. He received many awards including the Turing award, is author of many books and articles such as "Program Development by Stepwise Refinement" and "Algorithms + Data Structures = Programs". Prof. Niklaus Wirth served as professor at Stanford, University of Zurich, and ETH Zurich.

Alberto di Meglio
In 2003, Dr. Alberto di Meglio was appointed by CERN as Software Integration Manager in the Middleware Reengineering Activity of the first Enabling Grids for E-science (EGEE) project. At the end of the EGEE project, thanks to the very successful results obtained with the integration and testing tools and procedures developed for the grid middleware developed by EGEE, Alberto set up Infrastructure for Testing, Integration and Configuration of Software, an international infrastructure co-funded by EC FP7 (European Commission: CORDIS - Seventh Framework Programme) for building and testing software on the grid, of which he is currently Project Director.

Reminder: Call for proposals
If you would like to give a talk at GTAC please remember to submit your proposal until August 1 at the latest. Please visit for details.

Thursday, July 23, 2009

[Gd] New Video Portal For Film Buffs, Powered by YouTube

| More

YouTube API Blog: New Video Portal For Film Buffs, Powered by YouTube

Attention film buffs!

The American Film Institute (AFI) just launched a new video portal on featuring hundreds of videos from its vast archives. AFI is utilizing YouTube's APIs in order to stream videos directly from AFI's YouTube channel, as well as other great clips curated from YouTube. In addition to accessing the video content, users can post comments on the video site as well as embed the videos on other sites, blogs and social networking pages.

The collection will be regularly augmented with videos selected from the AFI Archive, which contains 10,000 hours of material produced during AFI's 42-year history, much of which has never been seen by the general public. Be sure not to miss great clips such as "Alfred Hitchcock On Mastering Cinematic Tension" or "Steven Spielberg: The Toughest Thing For A Director".

We're thrilled that the YouTube APIs can help unlock such amazing material. Nice work, AFI!

Posted by George Strompolos, YouTube Partner Team

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

Google Chrome has been released to the Beta channel. Some principal changes release since

  • Updated V8 to to improve stability and performance.
  • Printing fixes and print selection for Windows.
  • Initial support for the video tag.
  • Updated look and feel of the url bar (aka the Omnibox).
  • Improved our Developer Tools by adding the scripts and profiles tabs, plus support for docking the inspector into the main window.
In addition to some minor UI changes:
  • Minor Tweaks renamed as "Personal Stuff" in the Options menu
  • Browsing data options added to the Options menu, under Personal Stuff.
  • Default download location and font/language settings moved from Minor Tweaks to the Under the hood tab
  • Exceptions is a tab in the "Passwords and Exceptions" dialog, rather than a separate button in the Passwords section of the Options menu.
You can install the current Beta channel release from

Anthony Laforge
Google Chrome Program Manager

[Gd] Presentations from Google Developer Days in Asia are now live

| More

Google Code Blog: Presentations from Google Developer Days in Asia are now live

Videos, presentations, and photos from our Google Developer Days in China and Japan are now live. China's event kicked off our 2009 GDDs in Beijing on June 5 and Japan's GDD was a few days later on June 9.
At each event, attendees had the opportunity to learn about products such as Android, Chrome, OpenSocial, and App Engine and interacted with Google developers during office hours. Developers even got a sneak peak of Google Wave!

By Alyssa Sachs, Google Developer Programs

[Gd] The Plague of Homelessness

| More

Google Testing Blog: The Plague of Homelessness

By James A. Whittaker

There are two communities who regularly find bugs, the testers who are paid to find them and the users who stumble upon them quite by accident. Clearly the users aren’t doing so on purpose, but through the normal course of using the software to get work (or entertainment, socializing and so forth) done failures do occur. Often it is the magic combination of an application interacting with real user data on a real user’s computing environment that causes software to fail. Isn’t it obvious then that testers should endeavor to create such data and environmental conditions in the test lab in order to find these bugs before the software ships?

Actually, the test community has been diligently making an attempt to do just that for decades. I call this bringing the user into the test lab, either in body or in spirit. My own PhD dissertation was on the topic of statistical usage testing and I was nowhere near the first person to think of the idea as my multi-page bibliography will attest. But there is a natural limit to the success of such efforts. Testers simply cannot be users or simulate their actions in a realistic enough way to find all the important bugs. Unless you actually live in the software you will miss important issues.

It’s like homeownership. It doesn’t matter how well the house is built. It doesn’t matter how diligent the builder and the subcontractors are during the construction process. The house can be thoroughly inspected during every phase of construction by the contractor, the homeowner and the state building inspector. There are just some problems that will only be found once the house is occupied for some period of time. It needs to be used, dined in, slept in, showered in, cooked in, partied in, relaxed in and all the other things homeowners do in their houses. It’s not until the teenager takes an hour long shower while the sprinklers are running that the septic system is found deficient. It’s not until a car is parked in the garage overnight that we find out the rebar was left out of the concrete slab. The builder won't and often can't do these things.

And time matters as well. It takes a few months of blowing light bulbs at the rate of one every other week to discover the glitch in the wiring and a year has to pass before the nail heads begin protruding from the drywall. These are issues for the homeowner, not the builder. These are the software equivalents of memory leaks and data corruption, time is a necessary element in finding such problems.

These are some number of bugs that simply cannot be found until the house is lived in and software is no different. It needs to be in the hands of real users doing real work with real data in real environments. Those bugs are as inaccessible to testers as nail pops and missing rebar are to home builders.

Testers are homeless. We can do what we can do and nothing more. It’s good to understand our limitations and plan for the inevitable “punch lists” from our users. Pretending that once an application is released the project is over is simply wrong headed. There is a warranty period that we are overlooking and that period is still part of the testing phase.


[Gd] Japan's mixi adds mobile support with its OpenSocial RESTful API

| More

OpenSocial API Blog: Japan's mixi adds mobile support with its OpenSocial RESTful API

Hello, my name is Hidetaka Yamashita, and I am in charge of mixi's OpenSocial Mobile project. I am very happy to announce that mixi has recently added support for mobile phones to our OpenSocial platform. is currently the most popular Japanese social networking service (SNS) and has more than 17 million registered users. You may have heard about our recently launched OpenSocial developer sandbox in April. With this announcement, we are introducing our "mixi apps for mobile" platform which is based on OpenSocial's RESTful API using 2-legged OAuth.


In Japan most people use 3G mobile phones that connect to the Internet at max 7.2Mbps. Currently, more people access the web through mobile phones than through PCs. In mixi's case, access from PCs is approximately 30% compared to mobile phone access, which is 70%. Therefore, it is crucial for mixi to offer mobile phone support for OpenSocial applications.

How mixi's mobile platform works

mixi's mobile development platform is targeted for non-native mobile development, where third party developers build mobile social apps on their own application servers. However, when accessing the application from a mobile phone, users still point their phones to the main mixi site as it serves mainly as a proxy to the third party site. As the response returns from the third party site, the mixi Application Proxy processes the response (which is purely content) and merges it into a complete XHTML response (by adding a header and footer). It is then passed back to the requesting mobile phone. Since the core application itself resides on a third party site, developers build their apps using the RESTful API with 2-legged OAuth to securely access social data from mixi.

With mixi's RESTful API with 2-legged OAuth, OpenSocial applications can run anytime, anywhere!

Supported Features

API (requires authentication using 2-legged OAuth). You can access all the core OpenSocial APIs, as well as photos and communities on mixi.

Timeline (for mobile)
  • Closed beta version - Ongoing now
  • Consumer launch - September 2009
  • Official ads program - September 2009
  • Virtual currency and Payment API - October 2009
To learn more about mixi's new OpenSocial mobile platform please visit: (Note: this site is in Japanese.)

Posted by Hidetaka Yamashita, mixi, Inc.

[Gd] Google Web Toolkit 1.7 Now Available

| More

Google Web Toolkit Blog: Google Web Toolkit 1.7 Now Available

GWT 1.7 is a minor update that adds better support for Internet Explorer 8, Firefox 3.5, and Safari 4. Each of these new browser versions introduced at least one change that negatively impacted compiled GWT modules, so we recommend that you do update to GWT 1.7 and recompile your existing applications to ensure that they work well with the latest versions of browsers. No source code changes on your part should be required.

Normally, a minor update such as this would have been named 1.6.5 (the previous latest version of GWT was 1.6.4), but we did add the value "ie8" to the "user.agent" deferred binding property, which could impact projects using custom deferred binding rules that are sensitive to that property. Thus, we went with GWT 1.7 rather than GWT 1.6.5, to indicate that you may
need to pay attention to that change. Details are in the release notes.

In every other respect, this is just a bugfix release, so in the vast
majority of cases, the update-recompile process should be nearly effortless.

Download Google Web Toolkit 1.7


Wednesday, July 22, 2009

[Gd] Careful! Extensions Can Bite!

| More

Chromium Blog: Careful! Extensions Can Bite!

Since we began work on an extensions system for Chromium, we've received a lot of positive feedback. While the system is not yet complete, we've noticed that a lot of you have started creating and installing extensions for daily use. This is really encouraging, and it motivates us to quickly finish things up, to enable extensions by default on all Google Chrome releases.

If you're using extensions now, you should keep in mind that they are powerful software. Extensions integrate with your browser, so they can access and change everything that happens in it. For example, the same technology that enables an extension to periodically check the number of messages in your Gmail inbox could also be used to read all your personal mail and tweet it to your mom! This can happen because of malicious intent or simply because of a bug.

To help protect your experience when using extensions, we recently enabled auto-update for extensions on the dev channel release. Like Chrome's auto-update mechanism, extensions will be updated using the Omaha protocol, giving developers the ability to push out bug fixes and new features rapidly to users of their extensions. This is an important step towards a v1 release of extensions for all users, so we're pretty excited.

In addition, when we turn the extension system on, we plan to offer a gallery with ratings and comments that you can use to judge whether you want to install a particular extension. We will also have processes in place that, combined with reports from users, should help limit the number of malicious extensions that get uploaded and distributed to users. These processes will include removal of extensions that we have reason to believe are malicious. Until these things are in place and the extension system is officially launched, we recommend that you only install extensions that you built yourself.

Posted by Aaron Boodman, Software Engineer

[Gd] Dev Channel Update:

| More

Google Chrome Releases: Dev Channel Update:

This week's update includes changes for Windows, Mac and Linux. Significant changes include:
  • Form suggestions now shrink properly as the list of suggestions gets shorter. (Issue: 15334)
  • Extensions can now auto-update. (Issue: 12117)
  • Set the default minimum font size to 12 for Chinese and 10 for Japanese, Korean, Arabic and Thai. (Issues: 16868, 16875)
  • Mac now supports drag and drop of URLs, plain text, and HTML into
  • and out of the content area, as well as within text fields and the
    thumbnails on the new tab page. URLs can be dragged to and from other
    apps, the Finder/Desktop, and the Dock.
  • (Mac) Fix for download shelf crash when clearing all downloads. (Issues: 15855, 15893)
  • (Mac) First cut at infobars. Not pretty, just functional. (Issues: 15839, 14937, 14462, 16487)
  • (Mac) Add JavaScript Console menu item to View > Developer submenu. (Issue: 16135)
  • (Linux) Allow dragging a link from the web contents to the bookmark bar to get a named bookmark. (Issue: 16791)
  • (Linux) Add additional hotkeys (Ctrl-Enter, Shift-F5, Shift+Scroll Wheel). (Issue: 16792)
  • (Linux) Dockable developer tools.
More details about additional changes 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

Tuesday, July 21, 2009

[Gd] Above and Beyond the Call of Duty, with Permission

| More

Google Code Blog: Above and Beyond the Call of Duty, with Permission

Project Hosting on Google Code is a beehive of activity, with many large and active projects and even more that aspire to that level. Now it will be a little easier for project members to sort out who should be doing what by documenting each member's duties in plain language on the new People sub-tab. Here's an example from the zscreen project:

Duties describe what each member is expected to be doing. Project owners can grant permissions that control what each member is allowed to do. While permissions can be fairly fine-grained, it's usually best to grant broad permissions, and then trust your project members to do their duties or go above and beyond them when the situation calls for it.

In open source software development, anyone can access the source code of the project, and it's important to allow anyone to access issues and project documentation. But in some projects, there is a need to restrict some information to a subset of project members for a limited time. For example, you might want to quickly patch a security hole before publicizing the details of how to exploit it. Project members can now place restrictions on individual issues to control who can view, update, or comment on them.
Here's some of what our new permission system allows project owners to do when they need to:
  • Acknowledge the role of a contributing user without giving them any additional permissions
  • Trust a contributor to update issues or wiki pages without letting them modify source code
  • Restrict access to specific issues to just committers, or to a specific subset of members
  • Restrict comments on specific issues or wiki pages when another feedback channel should be used instead
  • Automatically set access restrictions based on issue labels
Getting started is easy, just click the People sub-tab and start to document what you and your project team are supposed to be doing. If you need to mess with permissions, see our permission system documentation for all the details.

If you'd like to meet some of the people behind Google Code, please drop by the Google booth at OSCON 2009 this week.

By Jason Robins, Project Hosting on Google Code Team

[Gd] Blog Stats

| More

Google Testing Blog: Blog Stats

by Patrick Copeland

We get questions once in a while about our readership. Here's a brief summary of the last 30 days...

Page view count: 34,140
Time on each page: 2:52
Most popular day to read: Tuesday's.
Most traffic (top 5 in order): US, India, UK, Germany, Canada

Most popular posts...

  1. /2009/07/why-are-we-embarrassed-to-admit-that-we (2,227)
  2. /2009/06/7-plagues-of-software-testing (2,151)
  3. /2009/07/software-testing-categorization
  4. /2009/07/advantages-of-unit-testing
  5. /2009/06/plague-of-repetitiveness
  6. /2009/07/old-habits-die-hard
  7. /2009/07/separation-anxiety
  8. /2009/06/gtac-call-for-proposals
  9. /2009/07/plague-of-amnesia

[Gd] The Plague of Boredom

| More

Google Testing Blog: The Plague of Boredom

By James A. Whittaker

"Testing is boring." Don’t pretend for a moment that you’ve never heard a developer, designer or other non tester express that sentiment and take a moment to search your own soul for the truth. Even the most bigoted tester would have to admit to contracting the boredom plague at some point. The day-in, day-out execution of tests and the filing of bug reports simply doesn't hold the interest of most technical people who are drawn to computing for its creative and challenging reputation. Even if you find yourself immune to the boredom, you have to admit there are many monotonous and uncreative aspects of testing.

It doesn’t begin that way though. Early in a tester’s career, the thrill of the bug hunt can keep a tester going for many months. It can be as intoxicating as playing a video game and trying to find some elusive prize. And lots of progress in terms of skill is made in those early years with testers going from novice to pretty good in no time flat. Who can argue with a career that offers such learning, advancement and intellectually interesting problems?

But as the achievement curve levels out, the task of testing can get very repetitive and that quickly turns to monotony. I think, promotion concerns aside, this is why many testers switch to development after a few years. The challenge and creativity gets eclipsed by the monotony.

I think bored testers are missing something. I submit that it is only the tactical aspects of software testing that become boring over time and many turn to automation to cure this. Automation as a potion against the tedium of executing test cases and filing bugs reports is one thing, but automation is no replacement for the strategic aspects of the testing process and it is in this strategy that we find salvation from this plague. The act of test case design, deciding what should and shouldn’t be tested and in what proportion, is not something automation is good at and yet it is an interesting and intellectually challenging task. Neither is the strategic problem of monitoring tests and determining when to stop. These are hard and interesting strategic problems that will banish the plague of boredom. Testers can succumb to the plague of boredom or they can shift their focus from mostly tactical to a nice mix of tactical work and strategic thinking.

Make sure that in your rush to perform the small tactical testing tasks you aren't dropping the strategic aspects of your work because therein are the interesting technical challenges and high level thinking that will hold your interest and keep this plague at bay.


[Gd] Gmail for Mobile HTML5 Series: Autogrowing Textareas

| More

Google Code Blog: Gmail for Mobile HTML5 Series: Autogrowing Textareas

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of what we've learned in a brief series of follow-up blog posts. This week I'll talk about autogrowing textareas for entering large amounts of text.

When composing a long message in a web app, regardless of whether it's on a desktop or a mobile device, you really want to see as much of your draft as possible and make use of all the available screen space.
One of my biggest gripes are fixed-size textareas that restrict me to only a couple lines of visible text when my screen is actually many times larger than the size of the textarea.

In today's blog post, I'll share a JavaScript solution for textareas that automatically grow (vertically) to the size of the content. They make composing long messages much easier and, for all those iPhone users out there, takes away the need to scroll with the dreaded magnifying glass! We're working on getting this into Gmail for mobile but here it is now as a teaser of things to come.

Measuring the height of the content

The first step is to detect when the content has changed. Some solutions on the net recommend using a timer (see our previous post to find out more about timers) to check if content has changed. However, that approach is not ideal on a mobile device, where both battery life and processor power are limited.

Instead, we will listen for key-up events from the browser. This guarantees that we only measure the textarea when the content has actually changed.

<textarea id="growingTextarea" onkeyup="grow();"></textarea>

The second step is to actually measure the height of the content. There are solutions on the net that recommend keeping a copy of the content in a div and measuring the div to get the height; however, due to memory and processor limitations on a mobile device, those solutions don't scale well when the content gets large (and it's also hard to replicate textarea line wrapping behavior exactly in a div).

Therefore we will make use of the scrollHeight and clientHeight properties. For our purposes, scrollHeight is the height of all the content while clientHeight is the height of the content that's visible in the textarea (for more precise definitions, see scrollHeight and clientHeight)
function grow() {
var textarea = document.getElementById('growingTextarea');
var newHeight = textarea.scrollHeight;
var currentHeight = textarea.clientHeight;

One limitation of using scrollHeight and clientHeight is that we aren't able to shrink the textarea when content is deleted. When all the content of a textarea is visible, the scrollHeight is equal to the clientHeight. Therefore we aren't able to detect that our textarea is actually larger than the minimum size required to fit all the content (please do leave a comment if you think of a solution that doesn't require re-rendering the page).

Growing the textarea

To grow the text area, we modify the height CSS property:
if (newHeight > currentHeight) { = newHeight + 5 * TEXTAREA_LINE_HEIGHT + 'px';
Notice how we only change the height if newHeight > currentHeight. Depending on the browser, changing the height (even if it's to the same value) will cause the page to re-render. On a mobile device, we want to try our best to minimize the number of operations.

Also, we grow the textarea by five lines every time we grow. From a UI perspective, this reduces the amount of jitter when composing a message but, from a performance perspective, this reduces the number of times we need to re-render the page.

(Quick note for developers implementing this for a browser with scrollbars: you might want to modify the CSS overflow property to preventing the scrollbar from appearing and disappearing as you grow your textarea)

The complete solution

Growing textareas are easy to implement and they make composing long messages infinitely more usable. So go out there add it to all your web apps!
// Value of the line-height CSS property for the textarea.

function grow() {
var textarea = document.getElementById('growingTextarea');
var newHeight = textarea.scrollHeight;
var currentHeight = textarea.clientHeight;

if (newHeight > currentHeight) { = newHeight + 5 * TEXTAREA_LINE_HEIGHT + 'px';
<textarea id="growingTextarea" onkeyup="grow();"><br />

Previous posts from Gmail for Mobile HTML5 Series
Using timers effectively

By Casey Ho, Software Engineer, Google Mobile

Monday, July 20, 2009

[Gd] Behind the scenes with two AJAX API Developers

| More

Google AJAX APIs Blog: Behind the scenes with two AJAX API Developers

We enjoy featuring real-world applications that show how versatile the AJAX APIs can be. Below we're highlighting two very different apps and the developers who built them:

AroundMe is an iPhone application where the AJAX APIs are central to the user experience. Specifically, the app utilizes the Local Search API to enable users to find information about their surroundings. In the videos below, Marco Pifferi (the developer behind AroundMe) gives a demo of his app, his thoughts on using the AJAX APIs, and tips for integrating them in mobile apps.

Mibbit is a web-based chat application that uses the AJAX APIs to enhance the chat experience. The language APIs help users to translate their messages into a number of different languages. Mibbit also uses the Maps API and YouTube API to display embedded maps or YouTube videos if a user includes a Maps or YouTube URL in their chat. Jimmy Moore, creator of Mibbit, walks through Mibbit in his video below.

Do you have a great app that uses the AJAX APIs? Submit a video about it and we may feature it on this blog. Questions? Stop by our support forum or IRC channel.

[Gd] Webmaster Tools gets a "Summer Shine"

| More

Official Google Webmaster Central Blog: Webmaster Tools gets a "Summer Shine"

The Google Webmaster Tools team has code names for each update we release. Today's update is aptly named "Summer Shine".

Here are a few highlights:
  • Our site selector now lists all verified sites that you own, and allows you to search as you type.
  • You can now block non-homepage sitelinks. Before today if you owned, you couldn't block sitelinks for
  • You can now see URL removal requests submitted by other users for any sites you own, and revoke them if necessary. In the past, if another webmaster for your site mistakenly removed a URL on your site and left for vacation it was a difficult process to undo the request.
  • Our "Home" page is much easier to navigate. We now make a clear distinction between verified and unverified sites.
We hope you like the improvements; tell us what you think.

Posted by Sagar Kamdar, Product Manager, Webmaster Tools

[Gd] Google Wave: Updates from today's hackathon

| More

Google Wave Developer Blog: Google Wave: Updates from today's hackathon

The Google Wave API Hackathon in Mountain View is off to a good start with over 150 people from places as faraway as New Zealand and the Netherlands coding at the Googleplex.

(Photo credit: James D. Peterson)

Over the last seven weeks we've seen some early examples of how developers have used the Google Wave APIs, some of which are posted on the Google Wave Samples Gallery. The projects listed in the samples gallery also include source code, so they can serve as a good reference for you. To highlight a few, there's:
  • Groupy-the-bot: A robot, written in Python, that enables users to create groups and manage their own subscriptions.

  • Floodit Game: A competitive gadget game where users take turns capturing as many squares as possible.

  • Waves in WordPress: A neat use of the embed API that makes it easy to put waves in a post or page on WordPress.

On the Google Wave team, we've also been hard at work improving the sandbox's stability and performance, as well as enhancing the APIs available: the UI and speed of gadget rendering, enabling cleaner gadget --> robot communication, and we've open sourced the Robots Java API.

For those developers out there looking to get started, as we blogged last week, we’ve already rolled out roughly 6,000 developer accounts and we’re working through an additional 20,000 requests over the course of the next month. If you haven't done so already, you’re welcome to request a sandbox account.

In other news: this morning we announced that we plan to start extending the Google Wave preview beyond developers on September 30th. This will take place on rather than the separate "sandbox" instance we are currently using, and we plan to involve about 100,000 users. In addition to the developers already using Wave, we will invite groups of users from the hundreds of thousands who offered to help report bugs when they signed up on

Leading up to that rollout, we’re focusing on improving the speed, stability and usability of Google Wave. This includes of course addressing many of the issues highlighted by the developers in the sandbox thus far (thanks for your feedback!). We're also continuing to expand the Google Wave APIs, and we'd love your feedback on the forum. As we have mentioned in the past, our goal is that extensions built by third parties feel fully on-par with Google Wave's native features to users. We know we have some way to go and really appreciate your help in getting there.

Stay tuned for more updates from tomorrow's Google Wave Federation Day.

Posted by Dan Peterson, Product Manager, Google Wave

[Gd] Apollo 11 mission's 40th Anniversary: One large step for open source code...

| More

Google Code Blog: Apollo 11 mission's 40th Anniversary: One large step for open source code...

On this day 40 years ago, Neil Armstrong and Buzz Aldrin became the first humans to walk on the Moon. This was quite an achievement for mankind and a key milestone in world history.

To commemorate this event the Command Module code (Comanche054) and Lunar Module code (Luminary099) have been transcribed from scanned images to run on yaAGC (an open source AGC emulator) by the Virtual AGC and AGS project.

For more information on this project, I recommend looking at the website and the open source project.

Here are a few links to the source code:
As the project evolves, look for syntax highlighting done with a special extension for google-code-prettify.

Image - NASA/courtesy of

By Nathaniel Manista, Project Hosting on Google Code