Friday, January 16, 2009

[Gd] Google Chrome Installation and Updates

| More

Chromium Blog: Google Chrome Installation and Updates

Since our public launch in September, a few Google Chrome users have had some questions about our installation and update process. We tried to answer most of them in our help center, but since many of you may not have visited the help center, this post attempts to give some background and insight into our current installation and update process.

When we started exploring various options for our installer, we came up with some explicit goals:
  • With new browser exploits showing up on regular basis, keep users free from the burden of checking for security updates.
  • Allow users who are not administrators to install Google Chrome.
  • Allow updates to happen automatically in the background even when Google Chrome is in use. The next time you open Google Chrome, it can simply start using the latest version.
  • Just like the minimal user interface (UI) of Google Chrome, limit or eliminate installer UI as much as possible.
  • Updates should be as small as possible. A security fix should be a small, fast download and should not need a full installer.
  • Uninstall should be clean and remove changes done by Google Chrome as much as possible.
After looking at existing options we found that none of them would give us all the things we wanted so we decided to write our own installer.

We believe Google Chrome installation has been made really simple. Once you run the installer, there are no screens to jump through or confusing choices to make. Installation happens and you get a first run UI window letting you import your data from your existing default browser. Some people (especially those using Windows XP as opposed to Windows Vista) were confused by our choice to install in the user profile directory instead of Program Files. There are several reasons we chose the user profile directory:
  • Anyone can install Google Chrome, not just administrators.
  • On Windows Vista there are no 'security prompts' during install. If you are running as a non-elevated Administrator, you can still install Google Chrome without having to enter an administrator's password. However we still need to ask for a password to make Google Chrome the default browser due to how Windows Vista requires browser applications to be registered with it.
  • You can choose to install or uninstall Google Chrome without affecting other people who use the same computer.
Google Chrome automatically updates itself with the help of Google Update, which is also used by other Google products including Google Talk, Gears, and the Google Earth Plugin. Using Google Update meant we could use an existing service that already takes care of lot of issues around automatic updates:
  • Maintaining different update channels, each with its own update schedules and Chrome versions.
  • Updating software in the background without any annoying dialogs.
  • Good proxy support that can handle various proxy configuration to download the installer payload.
  • Having only one instance of Google Update manage multiple Google programs installed on the machine.
Using Google Update has allowed us to push incremental changes out relatively quickly — we have released fourteen updates in three months between our release and our taking off the beta label.

During uninstall, Google Chrome deletes all the changes it made to the system, but a few people were surprised when they found all their profile data intact after reinstalling Google Chrome. This is intentional as many people try a sequence of uninstalling and then reinstalling to fix any installation issues, and we didn't want them to lose all of their profile data. If you really want to delete your Google Chrome profile we have instructions on how to do so.

Finally, if you made Google Chrome your default browser before uninstalling, we don't know how to undo that. All browsers face this problem: there's no way for one browser to know exactly how another browser registers itself as the default browser. To fix that, you should open your preferred browser, and use its option to set it as the the default browser.

Posted by Rahul Kuchhal, Software Engineer

[Gd] GWT Advocacy

| More

Google Web Toolkit Blog: GWT Advocacy

I'm a huge fan of GWT and have been since its public release in 2006. I have spent a fair amount of my spare time working with GWT by participating in the user forum and contributors forum, submitting patches to the issue tracker and maintaining open source libraries for GWT, including ones providing support for Drag and Drop (gwt-dnd), Logging (gwt-log) and sound (gwt-voices). GWT has gone through a number of exciting releases, with 1.5 easily being the most impressive release yet. You probably know that the team is fiercely working on the upcoming 1.6 release. Andrew posted a month ago about the new features slated for 1.6. As usual, I'm not sure if I'm more excited about what's in the upcoming release or all the possible things we can do next!

I'm pleased to announce that I have joined the Developer Relations team at Google as a Developer Advocate for GWT. Some of you may be wondering what a Developer Advocate does. The role has two parts. We are advocates for you, the developer, which is to make your voice heard within the product and engineering teams at Google. We also advocate broader use of Google Developer Products and APIs. Both roles work hand in hand. By listening to developer's needs I will be advocating to improve GWT as a product. A better product in turn helps increase adoption thereby growing the GWT community.

I look forward to spreading the word and to helping make GWT even better.


[Gd] Don't let history pass you by!

| More

Official Google SketchUp Blog: Don't let history pass you by!

Back in November we launched the Ancient Rome in 3D Curriculum Competition alongside a brand-new Google Earth layer highlighting the historic city in breathtaking detail.

Whether you're putting the finishing touches on your submission or have yet to explore the new layer, you still have some time! Just be sure to register and upload your files no later than Monday, February 9th.

Bona Fortuna!

Posted by Anna Bishop, Google Earth Education Team

[Gd] Don't let history pass you by!

| More

Official Google SketchUp Blog: Don't let history pass you by!

Back in November we launched the Ancient Rome in 3D Curriculum Competition alongside a brand-new Google Earth layer highlighting the historic city in breathtaking detail.

Whether you're putting the finishing touches on your submission or have yet to explore the new layer, you still have some time! Just be sure to register and upload your files no later than Monday, February 9th.

Bona Fortuna!

Posted by Anna Bishop, Google Earth Education Team

[Gd] Kolbe & Kolbe goes dynamic

| More

Official Google SketchUp Blog: Kolbe & Kolbe goes dynamic

Over the last few months, we've been thrilled to watch Kolbe & Kolbe, a window and door manufacturer from Wisconsin, build one the most impressive product catalogs on the Google 3D Warehouse. Kolbe has published over 1,800 SketchUp components, making it one of the leading manufacturers to use the 3D Warehouse for product promotion.

Today, we're even more thrilled that Kolbe has inaugurated their first Dynamic Components collection, which adds dynamic configuration options and animation to their product models. Check 'em out – we think you'll find them useful.

Posted by Peter Saal, Product Manager

Thursday, January 15, 2009

[Gd] Adding a social playlist to your site

| More

Official Google Webmaster Central Blog: Adding a social playlist to your site

As you're building your site, you may be looking for a simple way to provide fresh content that captures the attention of first time visitors and loyal users alike. They say that music brings people together, so what better way to engage your visitors than by inviting them to help build a unique, collaborative soundtrack for your website? Now, social application creator iLike has built a special version of their social playlist gadget for sites using Google Friend Connect.

Visitors can add their favorite songs
iLike's playlist gadget lets you and your visitors shape the site's "musical footprint" as a group. With this application, anyone visiting your website can listen to songs on the playlist, and if they sign in using Friend Connect, they can add their own favorites to the list. Of course, you can also add songs to the playlist, and as the site administrator, you have the ability to remove songs or change the order.

If you already have Friend Connect running on your website, you can add some musical flair in a matter of minutes with just a few clicks. Sign in at, click "Social Gadgets," and you'll find the iLike "Playlist gadget" in the gallery.

Select the "Playlist gadget," and Friend Connect will automatically generate a snippet of code for you to copy-and-paste into your website's HTML. While you're there, you may also consider adding the "Wall gadget"—music can be a great conversation starter!

This iLike gadget is fully integrated with your existing Friend Connect account, so you can edit your website's playlist, moderate wall posts, and manage membership all from a single interface.

Like all of the social applications that work with Friend Connect, iLike's application is built using OpenSocial, and it's a great example of how a social application can foster a sense of community around a website. Any site using Friend Connect can host gadgets created by the OpenSocial developer community.

If you're a site owner who wants to begin adding social features to your website, visit Google Friend Connect. No programming is required!

If you're a developer interested in building a social application to run on the tens thousands of websites that are now using Google Friend Connect, learn more at

Posted by Mussie Shore, Product Manager - Google Friend Connect

Wednesday, January 14, 2009

[Gd] From Mashup Editor to App Engine

| More

Google Mashup Editor Blog: From Mashup Editor to App Engine

Posted by Paul McDonald, Google Mashup Editor Team

As we announced today on the Google Code Blog, we will be shutting down the Mashup Editor in six months. While it is always hard to say goodbye to a product, when we launched the Mashup Editor as a private beta last year, we did so to better understand the needs of you, our developers. And you spoke, and much of what we learned together is now a big part of App Engine, the new infrastructure for hosted developer applications. We look forward to working with you in the migration to App Engine, and can't wait to see what you build.

[Gd] Changes for Jaiku and Farewell to Dodgeball and Mashup Editor

| More

Google Code Blog: Changes for Jaiku and Farewell to Dodgeball and Mashup Editor

By Vic Gundotra, Vice President, Engineering

Google has long believed that thoughtful iteration is the best way to build useful products for our users. As part of that process, we are always looking for ways to better focus our teams on the products that can have the most impact.

As we mentioned last April, we are in the process of porting Jaiku over to Google App Engine. After the migration is complete, we will release the new open source Jaiku Engine project on Google Code under the Apache License. While Google will no longer actively develop the Jaiku codebase, the service itself will live on thanks to a dedicated and passionate volunteer team of Googlers.

With the open source Jaiku Engine project, organizations, groups and individuals will be able to roll-their-own microblogging services and deploy them on Google App Engine. The new Jaiku Engine will include support for OAuth, and we're excited about developers using this proven code as a starting point in creating a freely available and federated, open source microblogging platform.

Some of you may also be familiar with, a mobile social networking service that lets you share your location with friends via text message. We have decided to discontinue in the next couple of months, after which this service will no longer be available. We will communicate the exact time-frame shortly.

Finally, in the spirit of onward and upward, we have decided to shut down the Mashup Editor, currently in limited private beta, in favor of the more powerful App Engine infrastructure. Existing Mashup Editor applications will stop receiving traffic in six months, and we hope you will join our team in making the exciting transition to App Engine.

[Gd] Seamless verification of Google Sites and Blogger with Webmaster Tools

| More

Official Google Webmaster Central Blog: Seamless verification of Google Sites and Blogger with Webmaster Tools

Verifying that you own a site is the first step towards accessing all of the great features Webmaster Tools has to offer, such as crawl errors and query statistics. The Google Sites and Blogger teams have worked hard to make site verification as simple as possible. In the following videos, I'll walk you through how to verify sites created in Google Sites and Blogger.

Google Sites:


These videos are available in our Help Center if you have additional questions about verifying a Google Site or Blogger blog with Webmaster Tools. And as always, you can find me and many other Googlers and webmasters in our Webmaster Help Forum.

Posted by Reid Yokoyama, Search Quality

[Gd] New ACLs on social features

| More

iGoogle Developer Blog: New ACLs on social features

Up until today, gadgets installed in the iGoogle developer sandbox had implicit access to social data, with no way for users to opt-out without uninstalling the gadget. We've added a feature to give more finely-grained control to users and allow users to explicitly grant or deny access to social data to their gadgets.

When users install gadgets that use social data (indicated by requiring the OpenSocial feature), they will be prompted to give permission to access social data. If a gadget is released without social features and is upgraded, users will be prompted for access within the gadget when the new version is first rendered.

When OpenSocial gadgets are available to all iGoogle users, users must grant permission before gadgets are allowed access to social data. For sandbox users, we want to ease development, so sandbox gadgets are allowed access to social data before confirmation.

Developers, this is important, so take note. If users deny access to social data, the gadget should have a good error message and graceful fallback UI.

Check for the ability to access social data with this snippet of code:


and fall back gracefully if permission is not granted.

If you have any questions, please join us in the iGoogle Developer Forum.

Posted by Dan Holevoet, Developer Programs

[Gd] Inaugural IRC Office Hours: Wed, Jan. 21st, 1-3pm PDT

| More

YouTube API Blog: Inaugural IRC Office Hours: Wed, Jan. 21st, 1-3pm PDT

Posted by Stephanie Liu, YouTube APIs and Tools Team

Starting next week, we'll be hosting live office hours on IRC ( channel #youtube-api). Come ask your questions, give feedback, gossip about the latest Atom Pub news, share best practices, or just hang out.

When: Wednesday, January 21st, 1:00 - 3:00 pm PDT
Who: Look for xirzec, stephliu, and jh_youtube, we'll be the cool kids in the back :)

If you can't make it, no worries, you can still post, as always, in the discussion forum. You can also let us know what times would work better for you in the future. See you there!

[Gd] Dev update: Weekly bug fixes

| More

Google Chrome Releases: Dev update: Weekly bug fixes

Google Chrome's Dev channel has been updated to version This release fixes a few minor bugs.

Find about the Dev channel and how to subscribe at

The list of user visible bugs is available in the release notes.

--Mark Larson, Google Chrome Program Manager

Tuesday, January 13, 2009

[Gd] Gingerbread results are in

| More

Official Google SketchUp Blog: Gingerbread results are in

Having spent some time perusing the entries for the Google SketchUp Gingerbread House Design Competition, we've reached a verdict – but it wasn't easy. Your models are (as expected) beautiful. For what it's worth, I accidentally ate part of my computer screen while we were judging. Drum roll please...

First Prize

An absolutely beautiful use of the base model, in combination with some of the supplied dynamic candy components, to create an entirely believable construction. This is a gingerbread house that aficionados – analog and digital alike – can admire. It's also a skillful use of SketchUp by someone who clearly knows what they're doing.

Second Prize

With this model, it's all about the details. The pediment (the triangular part of the roof) contains a scene of gingerbread people. The entablature (it sits between the columns and the roof) is heavily ornamented and altogether believable. When you go inside, there's an altar to a gingerbread deity. This entry is complete both in concept and execution. Gingerbread Vitruvius would be proud.

This one made us laugh. The house itself is intricate and skillfully modeled, but the best parts reveal themselves upon closer inspection. Someone's taken a giant bite out of the roof, and a giant gingerbread stormcloud (complete with gingerbread lightning bolt) threatens overhead. It's nice to see someone using a digital tool to do something that physical materials can't – ignore gravity.

Sprinkles Prize
(for the best additions to the base model)

Gingerbread Hall by Toy Maker

A classic example of a thought carried through to its logical (and very appetizing) conclusion. The house, the men, the reindeer and the sleigh are consistent in that they are made of gingerbread. This house is constructable, and a lot of work went into making it that way.

Swirl Prize
(for the best use of Dynamic Components in the model)

A close contender for best model overall, we decided to award the Swirl Prize to this entry because it's interactive. Aside from being a stunning example of SketchUp mastery, the strings of flags are Dynamic Components that lengthen and re-color as you scale them. Clicking with the Interact tool causes a rainbow to appear. You really need to download the model and open it in SketchUp to experience the full effect.

Sweet Tooth Prize
(for the most creative use of a single candy ingredient)

Candy canes for the walls. Candy canes for the roof. Candy canes for everything. Nice.

Take a look at all of the entries in this 3D Warehouse collection. Also peek at this Picasa album slideshow of some of our favorites:

Posted by Aidan Chopra, SketchUp Product Evangelist


[Gd] A new Google Sitemap Generator for your website

| More

Official Google Webmaster Central Blog: A new Google Sitemap Generator for your website

It's been well over three years since we initially announced the Python Sitemap generator in June 2005. In this time, we've seen lots of people create great third-party Sitemap generators to help webmasters create better Sitemap files. While most Sitemap generators either crawl websites or list the files on a server, we have created a different kind of Sitemap generator that uses several ways to find URLs on your website and then allows you to automatically create and maintain different kinds of Sitemap files.

Google Sitemap Generator screenshot of the admin console

About Google Sitemap Generator

Our new open-source Google Sitemap Generator finds new and modified URLs based on your webserver's traffic, its log files, or the files found on the server. By combining these methods, Google Sitemap Generator can be very fast in finding these URLs and calculating relevant metadata, thereby making your Sitemap files as effective as possible. Once Google Sitemap Generator has collected the URLs, it can create the following Sitemap files for you:

In addition, Google Sitemap Generator can send a ping to Google Blog Search for all of your new or modified URLs. You can optionally include the URLs of the Sitemap files in your robots.txt file as well as "ping" the other search engines that support the standard.

Sending the URLs to the right Sitemap files is simple thanks to the web-based administration console. This console gives you access to various features that make administration a piece of cake while maintaining a high level of security by default.

Getting started

Google Sitemap Generator is a server plug-in that can be installed on both Linux/Apache and Microsoft IIS Windows-based servers. As with other server-side plug-ins, you will need to have administrative access to the server to install it. You can find detailed information for the installation in the Google Sitemap Generator documentation.

We're excited to release Google Sitemap Generator with the source code and hope that this will encourage more web hosters to include this or similar tools in their hosting packages!

Do you have any questions? Feel free to drop by our Help Group for Google Sitemap Generator or ask general Sitemaps question in our Webmaster Help Forum.

Posted by John Mueller, Webmaster Trends Analyst, Google Zürich

[Gd] Why is my list black? An Android optimization

| More

Android Developers Blog: Why is my list black? An Android optimization

ListView is one of Android's most widely used widgets. It is rather easy to use, very flexible and incredibly powerful. ListView can also be difficult to understand at times.

One of the most common issues with ListView happens when you try to use a custom background. By default, like many Android widgets, ListView has a transparent background which means yo can see through the default window's background, a very dark gray (#FF191919 with the current dark theme.) Additionally, ListView enables the fading edges by default, as you can see at the top of the following screenshot; the first text item gradually fades to black. This technique is used throughout the system to indicate that the container can be scrolled.

Android's default ListView

The fade effect is implemented using a combination of Canvas.saveLayerAlpha() and the Porter-Duff Destination Out blending mode. This technique is similar to the one explained in Filthy Rich Clients and various presentations. Unfortunately, things start to get ugly when you try to use a custom background on the ListView or when you change the window's background. The following two screenshots show what happens in an application when you change the window's background. The left image shows what the list looks like by default and the right image shows what the list looks like during a scroll initiated with a touch gesture:

Dark fadeDark list

This rendering issue is caused by an optimization of the Android framework enabled by default on all instances of ListView (for some reason, I forgot to enable it by default on GridView.) I mentioned earlier that the fade effect is implemented using a Porter-Duff blending mode. This implementation works really well but is unfortunately very costly and can bring down drawing performance by quite a bit as it requires to capture a portion of the rendering in an offscreen bitmap and then requires extra blending (which implies readbacks from memory.)

Since ListView is most of the time displayed on a solid background, there is no reason to go down that expensive route. That's why we introduced an optimization called the "cache color hint." The cache color hint is an RGB color set by default to the window's background color, that is #191919 in Android's dark theme. When this hint is set, ListView (actually, its base class View) knows it will draw on a solid background and therefore replaces th expensive saveLayerAlpha()/Porter-Duff rendering with a simple gradient. This gradient goes from fully transparent to the cache color hint value and this is exactly what you see on the image above, with the dark gradient at the bottom of the list. However, this still does not explain why the entire list turns black during a scroll.

As I said before, ListView has a transparent/translucent background by default, and so all default Android widgets. This implies that when ListView redraws its children, it has to blend the children with the window's background. Once again, this requires costly readbacks from memory that are particularly painful during a scroll or a fling when drawing happens dozen of times per second. To improve drawing performance during scrolling operations, the Android framework reuses the cache color hint. When this hint is set, the framework copies each child of the list in a Bitmap filled with the hint value (this assumes that another optimization, called scrolling cache, is not turned off.) ListView then blits these bitmaps directly on screen and because these bitmaps are known to be opaque, no blending is required. And since the default cache color hint is #191919, you get a dark background behind each item during a scroll.

To fix this issue, all you have to do is either disable the cache color hint optimization, if you use a non-solid color background, or set the hint to the appropriate solid color value. This can be dome from code or preferably from XML, by using the android:cacheColorHint attribute. To disable the optimization, simply use the transparent color #00000000. The following screenshot shows a list with android:cacheColorHint="#00000000" set in the XML layout file:

Fade on a custom background

As you can see, the fade works perfectly against the custom wooden background. I find the cache color hint feature interesting because it shows how optimizations can make developers' life more difficult in some situations. In this particular case, however, the benefit of the default behavior outweighs the added complexity for the developer.

Note: this article was originally posted on my personal blog.


Monday, January 12, 2009

[Gd] Preventing Virtual Blight: my presentation from Web 2.0 Summit

| More

Official Google Webmaster Central Blog: Preventing Virtual Blight: my presentation from Web 2.0 Summit

One of the things I'm thinking about in 2009 is how Google can be even more transparent and communicate more. That led me to a personal goal for 2009: if I give a substantial conference presentation (not just a question and answer session), I'd like to digitize the talk so that people who couldn't attend the conference can still watch the presentation.

In that spirit, here's a belated holiday present. In November 2008 I spoke on a panel about "Preventing Virtual Blight" at the Web 2.0 Summit in San Francisco. A few weeks later I ended up recreating the talk at the Googleplex and we recorded the video. In fact, this is a "director's cut" because I could take a little more time for the presentation. Here's the video of the presentation:

And if you'd like to follow along at home, I'll include the actual presentation as well:

You can also access the presentation directly. By the way thanks to Wysz for recording this not just on a shoestring budget but for free. I think we've got another video ready to go pretty soon, too.

Written by Matt Cutts, Search Quality Team

[Gd] Preventing Virtual Blight: my presentation from Web 2.0 Summit

| More

Official Google Webmaster Central Blog: Preventing Virtual Blight: my presentation from Web 2.0 Summit

One of the things I'm thinking about in 2009 is how Google can be even more transparent and communicate more. That led me to a personal goal for 2009: if I give a substantial conference presentation (not just a question and answer session), I'd like to digitize the talk so that people who couldn't attend the conference can still watch the presentation.

In that spirit, here's a belated holiday present. In November 2008 I spoke on a panel about "Preventing Virtual Blight" at the Web 2.0 Summit in San Francisco. A few weeks later I ended up recreating the talk at the Googleplex and we recorded the video. In fact, this is a "director's cut" because I could take a little more time for the presentation. Here's the video of the presentation:

And if you'd like to follow along at home, I'll include the actual presentation as well:

You can also access the presentation directly. By the way thanks to Wysz for recording this not just on a shoestring budget but for free. I think we've got another video ready to go pretty soon, too.

Written by Matt Cutts, Search Quality Team

Sunday, January 11, 2009

SketchUp visits the AIAS Forum

| More

Official Google SketchUp Blog: SketchUp visits the AIAS Forum

The American Institute of Architecture Students welcomed the new year in Denver, Colorado for its annual AIAS FORUM. The event brought together over 600 students from various Architecture and Design programs in the US as well as representatives from chapters in Australia, Mexico and Puerto Rico. The AIAS FORUM offered students an opportunity to learn about both the experiences of professional architects and issues surrounding architecture education, while interacting with today's best architects and designers and meeting other students to exchange ideas.

Having attended the AIAS Forum in Boston a few years back, this year's event brought back lots of good memories. I remember the Expo from that Forum, and there was a certain excitement about finding the opportunities and tools needed to get us a real bona-fide spot in the architecture world. Lunch was pretty good, too.

Like in Boston, the Architecture College and Career Expo this year gave students and teachers an opportunity to grab some lunch and wander through an exhibition of colleges, architectural firms, building materials suppliers, and computer software tools. At our demo table, we answered lots of great questions, talked about the new features in SketchUp 7, and handed out some much appreciated souvenir Chapstick to the students who skied the day before.

It was great to meet the many students who had previous experience with SketchUp! Lots of them use SketchUp in their studio classes and arrived with specific how-to questions about tools, techniques, and plugins. Other students preparing to start SketchUp classes watched live demos of SketchUp and Google Earth. SketchUp has become a staple for architecture students, whether they are making massing models, detailed designs, analyzing energy performance, or designing t-shirts.

We also hosted a workshop called Mastering 3D Using SketchUp: Geomodeling Training. Attendees were taught the fundamentals of SketchUp and learned how to optimize models and geo-reference them in Google Earth. The room was filled to capacity, so there was certainly no shortage of interested and enthusiastic students. We had fun finding solutions to their personal SketchUp questions and sent them on their way with as many SketchUp tips as possible!

Posted by Catherine Moats, 3D Data Specialist, and Josh Reilly, SketchUp Trainer

Stable, Beta update: New Gears

| More

Google Chrome Releases: Stable, Beta update: New Gears

Google Chrome's Stable and Beta channels have been updated to version

This is a minor update to add the following fixes:
  • Update Gears to version to fix a crash with some offline applications
  • Enable spell-checking for Hebrew
--Mark Larson, Google Chrome Program Manager

Dev update: New WebKit version, new features, and a new Dev channel

| More

Google Chrome Releases: Dev update: New WebKit version, new features, and a new Dev channel

Google Chrome's Dev channel has been updated to version

Previous Dev Channel Users Moved to Beta Channel
This release is far less polished than what Dev channel users have been getting during Google Chrome's Beta, so we've moved existing Dev channel users to the Beta channel. You can decide whether to switch to the new Dev channel or stay on the Beta channel.

Use the new channel changer to re-subscribe to the Dev channel.

Highlights of This Release
There's a long list of new features in the release notes, but here are some of the highlights:

  • New version of WebKit, with lots of fixes and new features like CSS gradients and reflections.
  • New network code. Google Chrome now has its own implementation of the HTTP network protocol (we were using the WinHTTP library on Windows, but need common code for Mac and Linux).
  • Form Autocomplete.
  • Full-page zoom.
  • Autoscroll (rough implementation). Middle-click on a page to scroll the page in any direction.

--Mark Larson, Google Chrome Program Manager

Google Chrome Release Channels

| More

Chromium Blog: Google Chrome Release Channels

Release early, release often. We think that's the best way to develop software that delights people. With Google Chrome, we want to release fewer features more often instead of making you wait 12 months for the next Major Dot-Oh Release Jam-Packed With Features. We can get your feedback faster, fix things faster, and release new improvements as soon as they're ready. We want Google Chrome to stay nimble so it can keep pace with changes in the sites and web apps you use. 

Because we don't have those big Dot-Oh release milestones on the calendar, we don't have long periods of Beta testing new features. Instead we use automatic update channels to release Google Chrome to a community of early adopters. The channels are essentially a never-ending Beta test and a continuous feedback loop that lets us rapidly develop new ideas into solid product features. 

You can subscribe to one of our update channels:
  • Stable channel. Everyone is on the Stable channel when they first install Google Chrome. The Stable channel is updated with features and fixes once they have been throughly tested in the Beta channel. If you want a rock solid browser but don't need the latest features, the Stable channel is for you.
  • Beta channel. People who like to use and help refine the latest features subscribe to the Beta channel. Every month or so, we promote stable and complete features from the Dev channel to the Beta channel. The Beta channel is more stable than Dev, but may lack the polish one expects from a finished product.
  • Developer preview channel. The Dev channel is where ideas get tested (and sometimes fail). The Dev channel can be very unstable at times, and new features usually require some manual configuration to be enabled. Still, simply using Dev channel releases is an easy (practically zero-effort) way for anyone to help improve Google Chrome.
To get more actively involved with Google Chrome, subscribe to the Dev or Beta channel. Just run a little program (found here) and that's it. After that, you'll automatically get early access updates.

If you're ready to try some new stuff, we've just released a Dev channel update that has a new version of WebKit, a new network stack, and some features like form autocomplete (read about it here). It's less polished than what Dev channel users have been getting during Google Chrome's Beta, so we've moved all of our existing Dev channel users to the Beta channel. If you were on the Dev channel, you can decide whether to switch to the new Dev channel or stay on the new Beta channel.

Posted by Mark Larson, Technical Program Manager

TotT: Use EasyMock

| More

Google Testing Blog: TotT: Use EasyMock

Welcome back! We trust you all had a good holiday season and are ready for more TotTs -- Dave

Most of us are aware that mock and stub objects can make testing easier by isolating the class under test from external dependencies. This goes hand-in-hand with dependency injection. Writing all these classes can be a pain though.

EasyMock provides an alternative. It dynamically implements an interface which records and replays your desired behavior. Let's say you want to model an ATM interface:

public interface Atm {
  boolean enterAccount(String accountNumber);
  boolean enterPin(String pin);
  boolean enterWithdrawalAmount(int dollars);

It is pretty easy to mock this interface. Still, every mock has to implement all three methods, even if you only need one. You also need a separate mock for each set of inputs. With EasyMock, you can create mocks as you need them, recording and replaying your expectations:

public void testAtmLogin() {
  Atm mockAtm = createMock(Atm.class); // 1
  EasyMock.expect(mockAtm.enterAccount("MyAccount")).andReturn(true); // 2
  EasyMock.expect(mockAtm.enterPin("1234")).andReturn(true); // 3
  EasyMock.replay(mockAtm); // 4
  Account account = new Account();
  account.login(mockAtm); // 5
  EasyMock.verify(mockAtm); // 6

We tell EasyMock to create a dynamic proxy implementing Atm (1), which starts in record mode. Then we record two method calls along with the expected results (2 and 3). The replay() call tells EasyMock to stop recording (4). After that, calls on the object return the set values. If it gets a call it does not expect, it throws an Exception to fail fast. Account now uses the mock as if it were the real thing (5). The verify() method checks to see if the mock actually received all the calls you expect (6). It really is that simple. If we want to simulate failure, we can set up another test to return false from one of the method calls.

EasyMock has lots more capabilities as well. It can throw exceptions. It also can record multiple calls to the same method returning the same or different results. You also can create stub expectations and nice mocks so you don't have to record every expected call. You also can create several mocks, and even nest them to test classes with complex dependencies. Beware, though, this often creates brittle tests, and is a sign the class under test needs refactoring.

Basic EasyMock only mocks interfaces, but there is an EasyMockClassExtension that mocks non-final classes when you really must. See the EasyMock documentation at the link below for details.

Remember to download this episode of Testing on the Toilet and post it in your office.

Flex + the Embedded Player: A Christmas Story

| More

YouTube API Blog: Flex + the Embedded Player: A Christmas Story

Posted by Pamela Fox, Maps API Team

Hey YouTube folks! My name is Pamela Fox, and I hail from the Maps API world. I was charged with the task this year of creating the map for the NORAD Santa Tracker (yes, Google even indexes Santa), and I decided to convert last year's JavaScript map into a Flex map. This meant converting every feature into Flex, including arguably the most important feature: displaying YouTube-hosted Santa Cam videos in the infowindows. The kiddies get a kick out of seeing Santa soaring, tumbling, and freewheeling through the endless diamond sky.

I wanted what I thought was a basic feature: using the embedded player to play 23 different YouTube videos in the same Flex app. I started with a straightforward implementation - using the SWFLoader Flex component with the source set to the URL of the YouTube video. But I noticed some funny behavior - the first video would load, but none after that. After some searching around, I discovered the reason for this: if the first loaded YouTube SWF isn't properly removed by calling its destroy method(), any subsequently loaded YouTube SWF won't play correctly. The solution is to call destroy() on the YouTube SWF - but wait a second, it's not that easy. Flex/AS3 SWFs cannot call methods on AS2 SWFs, and YouTube SWFs are indeed written in AS2.

After harassing various YouTube engineers and reading through the AS3 Chromeless Player wrapper code, I came up with the solution shown in the diagram below.

The Flex app uses SWFLoader to load in an AS2 SWF, which I call the "YouTube bridge". The YouTube bridge creates a LocalConnection, which is a way for any SWF to invoke methods on any other SWF that's open simultaneously on a computer. The bridge specifies what connection it can receive commands from, and then defines two functions that other SWFs can call - loadMovie() and dispose(). The loadMovie() function takes in a YouTube ID, creates a MovieClip and loads the YouTube movie into it. The dispose() function calls destroy() on that MovieClip, and then does various other cleanup operations. The Flex app then tells that same connection what method names it wants to invoke, either "loadMovie" or "dispose". Some snippets of the LocalConnection code are shown below:

// Flex
outBox = new LocalConnection();
outBox.send(outBoxName, "dispose");
outBox.send(outBoxName, "loadMovie", ids[counter]);

// AS2
var inbox = new LocalConnection();
inbox.dispose = function () {

When I first coded this, I hard-coded a name for the connection name in the Flex + AS2. This meant that my app couldn't be used in multiple browsers at the same time, since all instances of the app would be sending and receiving messages from the same inbox, and they'd get awfully confused. To remedy that, I generate a random ID in the Flex app, pass that into the query string when loading the YouTube bridge, and then have the bridge use the value of the query parameter as the inbox name. A snippet of that code is shown below:

// Flex
outBoxName = String(new Date().getUTCMilliseconds());
swfLoader.load("youtubebridge.swf?boxName=" + outBoxName);

// AS2

The full code (MXML + FLA) is available, and you can test out the demo app. Now that I've made it easy for you all, I hope to see some nifty YouTube/Flex mashups.. and maybe even some Youtube/Flex/Maps mashups!

Interfacing with hard-to-test third-party code

| More

Google Testing Blog: Interfacing with hard-to-test third-party code

by Miško Hevery

Shahar asks an excellent question about how to deal with frameworks which we use in our projects, but which were not written with testability in mind.
Hi Misko, First I would like to thank you for the “Guide to Writing Testable Code”, which really helped me to think about better ways to organize my code and architecture. Trying to apply the guide to the code I’m working on, I came up with some difficulties. Our code is based on external frameworks and libraries. Being dependent on external frameworks makes it harder to write tests, since test setup is much more complex. It’s not just a single class we’re using, but rather a whole bunch of classes, base classes, definitions and configuration files. Can you provide some tips about using external libraries or frameworks, in a manner that will allow easy testing of the code?

-- Thanks, Shahar

There are two different kind of situations you can get yourself into:

  1. Either your code calls a third-party library (such as you calling into LDAP authentication, or JDBC driver)

  2. Or a third party library calls you and forces you to implement an interface or extend a base class (such as when using servlets).

Unless these APIs are written with testability in mind, they will hamper your ability to write tests.

Calling Third-Party Libraries

I always try to separate myself from third party library with a Facade and an Adapter. Facade is an interface which has a simplified view of the third-party API. Let me give you an example. Have a look at javax.naming.ldap. It is a collection of several interfaces and classes, with a complex way in which you have to call them. If your code depends on this interface you will drown in mocking hell. Now I don't know why the API is so complex, but I do know that my application only needs a fraction of these calls. I also know that many of these calls are configuration specific and outside of bootstrapping code these APIs are cluttering what I have to mock out.

I start from the other end. I ask myself this question. 'What would an ideal API look like for my application?' The key here is 'my application' An application which only needs to authenticate will have a very different 'ideal API' than an application which needs to manage the LDAP. Because we are focusing on our application the resulting API is significantly simplified. It is very possible that for most applications the ideal interface may be something along these lines.
interface Authenticator {
boolean authenticate(String username,
String password);

As you can see this interface is a lot simpler to mock and work with than the original one as a result it is a lot more testable. In essence the ideal interfaces are what separates the testable world from the legacy world.

Once we have an ideal interface all we have to do is implement the adapter which bridges our ideal interface with the actual one. This adapter may be a pain to test, but at least the pain is in a single location.

The benefit of this is that:

  • We can easily implement an InMemoryAuthenticator for running our application in the QA environment.

  • If the third-party APIs change than those changes only affect our adapter code.

  • If we now have to authenticate against a Kerberos or Windows registry the implementation is straight forward.

  • We are less likely to introduce a usage bug since calling the ideal API is simpler than calling the original API.

Plugging into an Existing Framework

Let's take servlets as an example of hard to test framework. Why are servlets hard to test?

  • Servlets require a no argument constructor which prevents us from using dependency injection. See how to think about the new operator.

  • Servlets pass around HttpServletRequest and HttpServletResponse which are very hard to instantiate or mock.

At a high level I use the same strategy of separating myself from the servlet APIs. I implement my actions in a separate class
class LoginPage {
Authenticator authenticator;
boolean success;
String errorMessage;
LoginPage(Authenticator authenticator) {
this.authenticator = authenticator;

String execute(Map<String, String> parameters,
String cookie) {
// do some work
success = ...;
errorMessage = ...;

String render(Writer writer) {
if (success)
return "redirect URL";

The code above is easy to test because:

  • It does not inherit from any base class.

  • Dependency injection allows us to inject mock authenticator (Unlike the no argument constructor in servlets).

  • The work phase is separated from the rendering phase. It is really hard to assert anything useful on the Writer but we can assert on the state of the LoginPage, such as success and errorMessage.

  • The input parameters to the LoginPage are very easy to instantiate. (Map<String, String>, String for cookie, or a StringWriter for the writer).

What we have achieved is that all of our application logic is in the LoginPage and all of the untestable mess is in the LoginServlet which acts like an adapter. We can than test the LoginPage in depth. The LoginSevlet is not so simple, and in most cases I just don't bother testing it since there can only be wiring bug in that code. There should be no application logic in the LoginServlet since we have moved all of the application logic to LoginPage.

Let's look at the adapter class:
class LoginServlet extends HttpServlet {
Provider<LoginPage> loginPageProvider;

// no arg constructor required by
// Servlet Framework
LoginServlet() {

// Dependency injected constructor used for testing
LoginServlet(Provider<LoginPage> loginPageProvider) {
this.loginPageProvider = loginPageProvider;

service(HttpServletRequest req,
HttpServletResponse resp) {
LoginPage page = loginPageProvider.get();
String redirect = page.render(resp.getWriter())
if (redirect != null)

Notice the use of two constructors. One fully dependency injected and the other no argument. If I write a test I will use the dependency injected constructor which will than allow me to mock out all of my dependencies.

Also notice that the no argument constructor is forcing me to use global state, which is very bad, but in the case of servlets I have no choice. However, I make sure that only servlets access the global state and the rest of my application is unaware of this global variable and uses proper dependency injection techniques.

BTW there are many frameworks out there which sit on top of servlets and which provide you a very testable APIs. They all achieve this by separating you from the servlet implementation and from HttpServletRequest and HttpServletResponse. For example Waffle and WebWork

Tabbed Browsing in Google Chrome

| More

Chromium Blog: Tabbed Browsing in Google Chrome

Tabbed Browsing is a prominent feature of modern browsers. We think it's one of the key elements that makes the browser a window manager for the web. Since we thought of the tab as the "container" element within which all other aspects of the browser lived, we designed the Chrome UI with the tab strip at the very top. But we didn't stop at aesthetic upheaval. As we were designing Google Chrome, we designed our tab strip behavior with an eye to making heavy use efficient. Observing how we were using our existing browsers, we were able to identify some pain points and come up with solutions targeted at fixing them. In this post I'll talk a bit about some of the things we've done.


One of the most persistently annoying issues with tabbed browsing was the following situation:

You have a full tab strip and a "hub" page open towards the left of the strip. Perhaps its your RSS reader, or a news site like Google News. You open interesting links in new tabs so you can keep reading through the headlines. The problem is, the new tabs open at the end of the tab strip, beyond many other unrelated tabs that also happen to be open. Sometimes, because of the "many-tab overflow" UIs in existing browsers, the tabs that you are queuing up to read in just a moment may disappear off the end of the strip. In short: finding tabs can sometimes be a challenge.

In addition, when you're done reading one of the articles you opened and close its tab, selection jumps back to the opener. This was one of the improvements I made to the tab strip in Firefox a couple of years ago, but with some extended use it turns out to not be the best action when there are multiple tabs opened from the same opener. Worse still, when combined with the "overflow" UI I mentioned above, the result was disorienting "bouncing" between the left and right ends of the tabstrip.

What did we do? In Google Chrome, we open tabs opened from links in the background adjacent to their opener tab. This keeps the spatial proximity of related tasks close. So you don't end up with the "bouncing" scenario I just described. We also maintain loose grouping relationships between such related tabs, so that when you are done reading one of several articles opened from a hub page, we shift selection to the next in the group, rather than going back to the hub. We think this makes the news reading use case a lot simpler. We don't persist this group relationship when you switch to an unrelated tab, though, to avoid situations that might lead to unpredictable switching behavior if you move on to a different task.

Cleaning Up

Another common annoyance was related to closing several tabs quickly. In most tab strips, when you close a tab the other tabs expand to fit the space that has just been made available. The upshot of this is that the close boxes of the remaining tabs all move around slightly, which makes it harder to quickly close tabs by clicking in the same spot. Older versions of Firefox solved this by putting the close box in a static position at the end of the tab strip, but lab research showed this approach had usability and discoverability problems for novices not used to tabbed browsing, so the close box was moved into the tab (which now seems to be the standard location for tabbed browsers).

For Chrome, we came up with something a little different. Realizing that maintaining a fixed width for tabs when closing them would keep close buttons aligned under the mouse pointer, we designed a system whereby the tab strip will re-layout when you close a tab to fill the gap left, but not resize the remaining tabs, until you move your mouse away from the tab strip (thus signaling you're done closing tabs).

Open Issues

Based on feedback we've received so far, here are a few areas where our tab strip design needs further improvement:
Many Tab Overflow

We don't have a complete system for handling many open tabs right now. We let tabs grow infinitely smaller. This ends up looking bad when there are a very large number of tabs open. We chose not to go with an overflow menu or scrolling tab strip like in some other browsers because we think there are other usability problems with those approaches. Specifically, when you implement an overflow solution you generally pick a minimum "readable" width for the tab and overflow tabs when there are too many at that width to fit. The problem is usually that that width seems to be too wide, so there can be unnecessary overflow in conditions where a smaller tab width would have meant all of the tabs would have fit. We also don't really like the drop-down menu approach as it has a spatial disconnect (vertical scanning vs. horizontal tabs) that makes it clumsy to use quickly. In the end, we would like a system that doesn't over-zealously clip tabs out of the tab strip so that people with many tabs can still access their tabs with one click.

Disoriented Anchor Tabs

Opening tabs next to the tab that opened them can mean for some use cases that the behavior of having a few "anchor" tabs positioned at the left edge of the strip is more difficult since tabs opened from them are opened in between. We like the idea of "tab pinning" or "locking" as a solution for this, but haven't invested a lot of time in designing how this might work just yet. There may be some overlap with "startup tabs" in Options.

Restoring Mistakenly Closed Windows

We also don't prompt when you close a window with several tabs. The reason we don't do this is that one of our core design philosophies has been to avoid modal question prompts that interrupt the user when they're trying to get things done (in this case, use a standard window control to close the window). We're aware that the prompt has saved people (including ourselves!) using other browsers from losing tabs, but we have been trying to come up with a more creative system for helping this scenario that doesn't interfere with the window's close button. In recent trunk builds, you'll find that you can re-open a recently closed window from the New Tab Page, and that the "Recently Closed" section of the New Tab Page now spans multiple sessions. This is a good way to "undo" an accidentally closed window, in the same way you can "undo" an accidentally closed tab. To try this out you can get on the Google Chrome Dev Channel.

In all of these areas we've resisted adding options to control behavior. Keeping our set of options minimal is a good forcing function for us as user interface designers to come up with the right approach, since we never rely on the crutch of making the user decide what we were unable to. Instead, our approach has been to experiment with different behaviors and end up taking the approach that works the best. We are heavy users, and we've designed this user interface for heavy web users, so we hope it scales as well for you as it does for us!

Posted by Ben Goodger, Software Engineer

AdWords Downtime: January 10, 10am-2pm PST

| More

AdWords API Blog: AdWords Downtime: January 10, 10am-2pm PST

We'll be performing routine system maintenance on Saturday, January 10 from approximately 10:00am to 2:00pm PST. You won't be able to access AdWords or the API during this time frame, but your ads will continue to run as normal.

-Jeffrey Posnick, AdWords API Team

Can I use this Intent?

| More

Android Developers Blog: Can I use this Intent?

Android offers a very powerful and yet easy to use tool called intents. An intent can be use to turn applications into high-level libraries and make code re-use something even better than before. The Android Home screen and AnyCut use intents extensively to create shortcuts for instance. While it is nice to be able to make use of a loosely coupled API, there is no guarantee that the intent you send will be received by another application. This happens in particular with 3rd party apps, like Panoramio and its RADAR intent.

While working on a new application, I came up with a very simple way to find out whether the system contains any application capable of responding to the intent you want to use. I implemented this technique in my application to gray out the menu item that the user would normally click to trigger the intent. The code is pretty simple and easy to follow:

* Indicates whether the specified action can be used as an intent. This
* method queries the package manager for installed packages that can
* respond to an intent with the specified action. If no suitable package is
* found, this method returns false.
* @param context The application's environment.
* @param action The Intent action to check for availability.
* @return True if an Intent with the specified action can be sent and
* responded to, false otherwise.
public static boolean isIntentAvailable(Context context, String action) {
final PackageManager packageManager = context.getPackageManager();
final Intent intent = new Intent(action);
List<ResolveInfo> list =
return list.size() > 0;

Here is how I use it:

public boolean onPrepareOptionsMenu(Menu menu) {
final boolean scanAvailable = isIntentAvailable(this,

MenuItem item;
item = menu.findItem(;

return super.onPrepareOptionsMenu(menu);

In this example, the menu is grayed out if the Barcode Scanner application is not installed. Another, simpler, way to do this is to catch the ActivityNotFoundException when calling startActivity() but it only lets you react to the problem, you cannot predict it and update the UI accordingly to prevent the user from doing something that won't work. The technique described here can also be used at startup time to ask the user whether he'd like to install the missing package, you can then simply redirect him to the Android Market by using the appropriate URI.

Note: this article was originally posted on my personal blog.



| More

Featured Projects on Google Code: HowSFVotes


Author: Jesse Costello-Good

Google APIs used:

Google Maps API for Flash, Google App Engine

This mashup gives you various ways to visualize the per-region votes in various elections in the San Francisco bay area.



| More

Featured Projects on Google Code: HowSFVotes


Author: Jesse Costello-Good

Google APIs used:

Google Maps API for Flash, Google App Engine

This mashup gives you various ways to visualize the per-region votes in various elections in the San Francisco bay area.


Japanese WMC Blog launched

| More

Official Google Webmaster Central Blog: Japanese WMC Blog launched

Konnichiwa! Hajimemashite! *Hello, Nice to meet you!

We just launched a new Webmaster Central Blog in Japanese. For those of you who feel more comfortable reading Japanese, and are interested in webmaster-related information from Google, and even learning about issues specific to our region and language, we hope you enjoy on our Japanese version of the Webmaster Central Blog :D

Written by Naoko Imai, Search Quality Team

Feliz Navidad from the Spanish Webmaster Central team!

| More

Official Google Webmaster Central Blog: Feliz Navidad from the Spanish Webmaster Central team!

About three and a half months ago we kicked off the Spanish Webmaster Central blog hoping to reach many webmasters. Given the time of the year, we would like to say a big ¡Muchas Gracias! to all our readers.

It's been both a pleasure and a great opportunity for us to share our knowledge and hear your feedback. A few of this year's highlights:

For the blog, we had:As for conferences, we had the chance to talk to some of you in:And last, but not least, the Spanish Help Group, with lots of interesting stories.

This is us, several members of the Spanish Webmaster Central team:

From left to right: Cristina, Alvar, Rebecca, and Esperanza in Google's Dublin office, with a holiday touch :)

Written by Alvar López, Search Quality Team