Saturday, May 9, 2009

[Gd] Google Trends for your website

| More

Official Google Webmaster Central Blog: Google Trends for your website

Webmaster Level: All

In a recent post on the Official Google Blog, we mentioned our Google Trends gadget, and we thought it made sense to also post something here for all the webmasters that might be interested in having Trends on their website. Google Trends is a great way to see what's popular on the web -- people tend to search for what they care about -- and the Trends gadget makes it easy for you to put Trends on your website. Just cut and paste a small snippet of code, input your search terms, and you can show your readers how searches for Obama have changed during the last 30 days or who's the most popular American Idol contestant. So take a little piece of Google with you, and show your readers what's hot on the web.

Posted by Matt Ghering, Product Marketing Manager

Friday, May 8, 2009

[Gd] No Dev update this week

| More

Google Chrome Releases: No Dev update this week

We were not able to issue a Dev channel release this week. Our test team did a great job in qualifying two Stable udpates and a Beta update this week, and we just didn't have the bandwidth to push a Dev channel release.

We'll get an update out early next week. Stay tuned for some exciting new features we hope to land in the Dev channel.

Mark Larson
Google Chrome Program Manager

[Gd] Beta Update

| More

Google Chrome Releases: Beta Update

Google Chrome's Beta channel has been updated to This release includes about 200 changes pulled in from the releases subsequent to

Some highlights for this release:
  • Lots of UI tweaks, bug, and stability fixes!
  • Added the ability to remove most visited thumbnails from the New Tab page. (Issue: 685)
  • Autocomplete now pulls suggestions from search engines, that support the functionality, and retains a history of those searches. For example, if you have searched from in the past, start typing in the omnibox, press the Tab key then a search term and suggestions and past searches will appear for Wikipedia. (Issue: 3636)
  • Added a confirmation box when closing the browser with in progress downloads. (Issue: 1028)
  • Added "Reopen closed tab" and create "New Tab" to the context menu on the tab bar. (Issue: 2144)

A detailed list of changes in this release is in the release notes.

Anthony Laforge, PMP
Google Chrome


[Gd] Previews of I/O Sessions: Brad Chen, Sven Mawson and Ben Lisbakken

| More

Google Code Blog: Previews of I/O Sessions: Brad Chen, Sven Mawson and Ben Lisbakken

We hope you enjoyed watching the previous set of previews for Google I/O sessions. These previews are a way for the speakers to present their topics in their own voice and for you to be able to pick and choose which sessions you would like to attend ahead of the conference. Keep an eye out for more previews on the other sessions at I/O in the coming weeks; we look forward to seeing you at Google I/O, on May 27-28.

Brad Chen - Native Client: Using Native Code to Build Compute Intensive Web Applications

Sven Mawson - Evolution of the Google Data Protocol: New Features for Building more Efficient Applications

Ben Lisbakken - Fun Hacks and Cool JavaScript: The Advanced Techniques Behind the Google AJAX API Playground

By Neel Kshetramade, Google Developer Programs

[Gd] Python SDK version 1.2.2 released

| More

Google App Engine Blog: Python SDK version 1.2.2 released

We've released version 1.2.2 of the App Engine SDK for Python. Some highlights from the release notes:

  • Urlfetch fetch now has support for user configurable deadlines.

  • Datastore indexes on single properties can now be disabled by setting indexed=False on the property constructor.

  • Datastore now supports Key-only queries, using either SELECT __key__ or db.Query(Model, keys_only=True)

  • Bulk Loader improvements: New appcfg download_data command. Better backoff support and debugging output for long requests.

For a full list see the SdkReleaseNotes wiki page.

Downloads for Windows, Mac, and Linux are available on the Downloads page. This SDK update was for the Python runtime, so please post your feedback in the Python runtime discussion group.


[Gd] More ways to engage your community

| More

Official Google Webmaster Central Blog: More ways to engage your community

Webmaster Level: All

Over the last few weeks, Google Friend Connect has added several new ways for you to strengthen the community that visits your site. These gadgets help to make your site more engaging and gives your visitors a new way to interact with your content and other visitors.

Here is a quick overview of these new gadgets:

Event gadget - Have an upcoming event you want to promote to your community? Embed this gadget on your site to let members get details about the event, see a map, indicate if they're coming, and see who else is attending. They can even add the event to their personal Google Calendars with just a click.

Polls gadget - Polls are a fun and easy way for your visitors to express themselves and a great tool for you to see what your users like. This gadget makes it easy to publish opinion polls and adds a social element by displaying the faces of the community members and friends who voted on each answer.

Get Answers gadget - Add the Get Answers gadget to your site to encourage visitors to ask questions of the community and answer questions posed by other community members. This gadget lets visitors browse questions, submit answers, and vote on answers they think are the best.

Comments gadget - Bring your site to life by adding the comments gadget to your pages. This gadget enables visitors to post comments and links to videos on your site. Visitors can even use the new translation feature to read comments in their preferred language.

Check out the Friend Connect gallery to see these gadgets along with all the other features Friend Connect has to offer. And keep an eye on the Social Web Blog for additional gadgets we'll soon be launching.

Posted by Mendel Chuang, Product Marketing Manager

[Gd] Rob Campbell: Debugging and Testing the Web with Firebug

| More

Google Code Blog: Rob Campbell: Debugging and Testing the Web with Firebug

The sixth Web Exponents tech talk features Rob Campbell's presentation on Firebug. Rob works at Mozilla. He's one of the developers that Mozilla dedicated to the Firebug effort last July. Rob is one of the main drivers of the Firebug project, starting and heading up the weekly concalls, and closely tracking bugs and releases. As one of the founders of the Firebug Working Group, I'm excited to see Mozilla taking a more active role in Firebug. The benefits are clear as we see more features and greater stability with each Firebug release. Here's the video of Rob's presentation as well as a link to his slides.

Rob starts by highlighting what's new in Firebug 1.4 alpha. It's a joy for me to see that activation (enabling and disabling) has been simplified. Rob points out that the firebug icon serves also as a menu. One of the menu items is "Open With Editor", which developers will find useful for saving changes to their pages. A much needed UI change is flipping the tabs and buttons. The tabs used to be below the buttons. Putting them at the top is closer to what users expect from working with other tabbed UIs.

The new "pause" button will be useful for anyone debugging JavaScript. This implements "break on next" functionality, making it easier to stop when event handlers are called. Firebug's Net Panel has had significant improvements. The UI is better (colors!), but there's even more. The underlying timing information has been improved to give more accurate results. There are also markers for DOMContentLoaded and OnLoad, to show where those fire in relation to network requests.

Firebug Extensions provide a way for developers to add functionality that can be shared with others. Rob mentions several extensions including:Writing an extension is a great way to explore future directions for Firebug.

Rob talks about future roadmap. Firebug 1.5 will focus on extensions - making them easier to build and use. Firebug 1.6 will change the underlying JavaScript debugging mechanism in Firefox to support new features. Add Rob's blog to your RSS reader to find out about these future releases and other improvements to Firebug.

By Steve Souders, Performance Evangelist

Thursday, May 7, 2009

[Gd] Who's @ Google I/O - spotlight on the Open Web

| More

Google Code Blog: Who's @ Google I/O - spotlight on the Open Web

Web developers face many limitations when trying to develop web applications that match the functionality of desktop applications. Many people are working on removing these limitations and helping make the open web an even more powerful platform. Browsers have recently focused on and significantly improved JavaScript performance, and new HTML5 and related APIs are currently being formulated and implemented, giving developers even more capabilities. Through efforts like O3D, Chromium, and Native Client, we want to contribute our technology and web development expertise to developing and promoting open web standards that will ultimately help developers build better apps and make their users happy.

Here are some of the developers who'll be at Google I/O (only 19 days away) and speaking or demoing their products built on open web technologies:
  • Browser Perspectives: An Open Discussion
    Web developers are asking more from today's browsers — more speed, more functionality, and a greater ability to build web applications that make users happy. To talk about how browser development happens with respect to new standards, such as what influences decisions around which new APIs to implement first and how to implement new features in the face of still-changing standards proposals, we have a panel with representatives from Google, Microsoft, Mozilla, and Opera. The discussion will be moderated by Mike Schroepfer, VP of Engineering at Facebook.

  • Bespin Project (Mozilla Labs)
    Bespin is a Mozilla Labs experiment that proposes an open, extensible web-based framework for code editing that also promotes the use of open standards. The Bespin web code editor is built on HTML5 technology. Dion Almaer and Ben Galbraith will be leading a session, Bespin and the Open Web, where they talk about their experiences.

  • Opera Software
    Opera is actively involved in contributing and deploying open web technologies. Specifically, they are currently helping specify GeoLocation, HTML 5, CSS 3, cross-device widgets and SVG, amongst others, and dev.opera.comshowcases techniques and technologies to developers. The Opera Dragonfly developer tools are built using the latest Web technologies. Charles McCathieNevile will be one of the speakers on the Browser Perspectives talk.

  • Yahoo! Pipes
    Pipes lets users remix popular feed types and create data mashups using a visual editor. This visual editor allows you to drag pre-configured modules onto its canvas and wire them together. Pipes use the HTML5 <canvas> tag extensively in the Pipes Editor and Pipe thumbnails.

  • Large Animal Games
    Large Animal Games has developed over 75 games for a variety of platforms, many of which are fully integrated with OpenSocial. They've developed a cross-network game platform called Toga which enables the simultaneous deployment of games across multiple social networks, including those that support OpenSocial. They're also in the process of developing a game using O3D that will ultimately be integrated with social networks via Toga.

  • Crazy Pixel Productions
    Crazy Pixel Productions is a full service 3D animation and game development studio that specializes in top notch art and incredibly immersive worlds. Crazy Pixel has worked on producing art for the O3D Beach demo and is now developing a new game based on O3D.
You can also take a look at our sessions page for a full list of sessions. In particular, sessions under the "Client" track focus on making changes in client products such as browsers to empower the open web platform, implementing HTML5 and related APIs, discussions around 3D and native code, and more. The Sandbox will include engineers of Google product teams that are deploying open web technologies, like the Gmail for mobile HTML5 app, Native Client, Chrome extensions, and O3D.

Google I/O is only 19 days from now - to sign up, go to!

*Keep up with the latest I/O updates: @googleio.

By Christine Tsai, Google Developer Team

[Gd] Tip: Build a quality gadget

| More

Google Desktop APIs: Tip: Build a quality gadget

What makes a quality gadget?
  • Platform specification: If you create a gadget only for Windows, make sure that the gadget is not installable on Mac or Linux:
    <windows minimumGadgetHostVersion=""/>  <!-- Windows is supported -->
    <mac supported="no"/> <!-- No support for Mac -->
    For more information, check the gadget.gmanifest documentation.

  • Good performance: The gadget should make optimum use of the hardware and operating system services. The efficiency of software can usually be greatly improved by an intelligent choice of high-level algorithms, rather than using local "tricks" or optimizations that can lead to maintenance problems. Factors that may be of interest are response time and memory requirements.

  • Robustness: The gadget should continue to function in non-standard conditions such as incorrect user input. For example, when the user types something wrong, you can warn the user with a basic message box.

  • Appropriate interface: The gadget should be friendly and inviting to users. The design and choice of the interface should take into account the needs and capabilities of the users. Many times, gadget features are not utilized because the interface is difficult.

  • Documentation: The gadget must link to a website that provides support and information about the gadget. On the website, you can write detailed descriptions about what the gadget can do. And don’t forget to display your email address so the users can easily provide feedback about your gadget, offer to translate it, or report a bug. Try to always include a page with frequently asked questions. One good idea is to add a YouTube video about your gadget on the website to show what it can do.
Posted by Stefan Van Damme, Gadget Developer

[Gd] Stable Update: Bug fix

| More

Google Chrome Releases: Stable Update: Bug fix

Google Chrome's Stable channel has been updated to version to fix a crash during startup for a small percentage of users. 

Mark Larson
Google Chrome Program Manager

[Gd] Google API Libraries for GWT - May 2009 Release

| More

Google Web Toolkit Blog: Google API Libraries for GWT - May 2009 Release

By Eric Ayers, Google Web Toolkit Team

We are pleased to announce updates to the Google API Libraries for the Google Web Toolkit  project.  The Google API Libraries for GWT project allows GWT developers to access some of Google's popular JavaScript APIs.  This release contains new bindings for two libraries:

These libraries each come with sample code and Javadoc documentation.

In addition, other libraries have been updated.  Highlights include:

  • UI Styling and full GoogleBar support for the Google Maps API.
  • Ajax Loader support integrated with Search, Maps, Language, and Visualization.
  • Formatters support, new event types, and new OrgChart features added to bindings for Google Visualization API.
  • Bugfixes for the Gears API wrappers, for a full release of support for Gears 0.4 features.
  • Locked Domain feature added and improved performance for the Gadgets API.
These updates are now available for download at the Google API Libraries for GWT  project hosted on Google Code.

[Gd] Upcoming Budget Optimizer Changes

| More

AdWords API Blog: Upcoming Budget Optimizer Changes

We want to take a minute to notify all AdWords API developers about an upcoming change in the way bids are handled in campaigns that make use of the Budget Optimizer. If none of your campaigns use the Budget Optimizer, or if you never plan on turning the Budget Optimizer off, then feel free to stop reading (and get back to trying out the new v2009 Sandbox!).

Each Campaign object has a budgetOptimizerSettings property, which in turn has a takeOnOptimizedBids setting. Currently, if takeOnOptimizedBids is set to false and you turn off the Budget Optimizer in a campaign, the original bids that were manually set for the ad groups and criteria contained in the campaign will be restored. In other words, the AdWords API will save your old bids from before the Budget Optimizer was turned on, and restore them when it is turned off. If takeOnOptimizedBids is set to true, however, the old bids will not be restored when the Budget Optimizer is turned off. Instead, the last bids that were automatically set by the Budget Optimizer will persist for the ad groups and criteria in your campaign.

You can, if you wish, use the AdWords API to manually update the bids for ad groups and criteria once the Budget Optimizer is turned off in either scenario.

The upcoming change will effectively treat takeOnOptimizedBids as if it were set to true (regardless of what it is actually set to) for all campaigns using the Budget Optimizer. Once the Budget Optimizer is turned off, all bids will be set to the last bid used by the Budget Optimizer. This change will match the behavior currently in place when the Budget Optimizer is turned off via the AdWords web interface.

We're planning on making this change to AdWords API behavior on May 19. It is not likely that you will have to make any substantial changes to your code in advance of this change, but please take the new behavior into account when you write code that turns the Budget Optimizer off.

-Jeffrey Posnick, AdWords API Team

[Gd] Gmail for mobile HTML5 Series - Part 2: Using AppCache to Launch Offline

| More

Google Code Blog: Gmail for mobile HTML5 Series - Part 2: Using AppCache to Launch Offline

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices built on HTML5. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow up blog posts. Last week we explained how to go about creating a simple manifest file, and how the browser uses it to load a page. This week we will go a bit more in-depth about the subject.

One of the problems we faced in creating our manifest file, was how to update it when our javascript changes. At first we thought that we might have to change one of the URLs each time we wanted to push an update. As it turns out, the URLs listed in the manifest do not have to change at all in order cause an update, changing the whitespace or a comment will also do the trick. For Gmail, we a comment in the manifest that contains a hash of all of the resources listed in the manifest. That way, if any of the resources change, the manifest will also change and cause a background update to occur for all of our clients. An example of what this looks like is shown below.

# version: 3f1b9s84
... other URLs ...

There are other types of entries that are possible in a manifest, but that the iPhone does not currently support. According to the spec, there are 3 categories of URLs that can be listed in a manifest:
  • Cache (what we have dealt with so far),
  • Fallback,
  • Network
Although fallback and network URLs are not yet supported on the iPhone, they are mostly supported in the Webkit Nightly builds. Network URLs are those that are never cached by AppCache, and that are allowed to be satisfied by the network. Fallback URLs are those that are attempted, and then satisfied by by AppCache only if the network attempt fails. Both Network and Fallback URLs are prefix matches. An example of what this looks like is shown below.



/thumbnails/ images/missing_thumb.jpg

This manifest tells the browser that GET requests to any URL under /images/ are allowed to hit the server. Without this being listed, GET requests for it would fail immediately. This manifest also tells the browser that URLs under /thumbnails/ are allowed to hit the server, but if they fail, satisfy the request by server missing_thumb.jpg, which will be stored in AppCache.

So far all of the features we've covered about AppCache have not needed any Javascript to use them. This is undoubtedly by design, as it makes it extremely easy to use. However, it is always useful to know what advanced functionality can be unlocked using Javascript. The Application Cache is exposed as a singleton through window.applicationCache. It provides events that can be used to indicate when updates are happening and a status property that can be one of:
  • 0 - UNCACHED
  • 1 - IDLE
  • 2 - CHECKING
In Gmail, we use the status property to determine if the page was loaded out of AppCache, or if it was loaded from the network. In order to do this, we have the following code run at the very start of page load:

if (window.applicationCache.status == 0) {
// Page was loaded from the Network.
} else {
// Page was loaded from AppCache

There are also a couple of functions available, swapCache and updateCache, which we'll not go into detail on since we have not found any use for them yet.

Stay tuned for the next post where we will explore how to use the sqlite3 command-line tool to inspect the iPhone Simulator's AppCache database. And just another reminder that we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, looking forward to meeting you in person.


The HTML5 working draft:

WHATWG working draft:

Apple's MobileSafari documentation:

Webkit Source Code:

By Andrew Grieve, Software Engineer, Google Mobile

Wednesday, May 6, 2009

[Gd] Survival techniques for web app acceptance tests, Part 2: increasing effectiveness and utility

| More

Google Testing Blog: Survival techniques for web app acceptance tests, Part 2: increasing effectiveness and utility

By Julian Harty

Part 1 of this series provided practical how-tos to create acceptance tests. Read on to learn how to make your tests more useful.

Increasing the velocity

Once we have some automated acceptance tests, they must be run, without delay, as often as appropriate to answer the concerns of the team. We may want to run a subset of the tests after each change of the code. The process of running tests can be automated and integrated with a source control system that continuously builds the code and runs various automated tests. If the acceptance tests are sufficiently fast and can run unattended, they should be included in the tests run by the continuous build system. One challenge for our acceptance tests at Google is to enable the web browser to run without appearing on screen; our machines don’t typically have a physical or logical GUI. Utilities such as vnc and xvfb can host the web browser and enable us to run our acceptance tests. A useful guide on test automation is the book Pragmatic Project Automation by Mike Clark.

Fluid writing of test automation code smooths over obstacles, coping with the interface twixt web application and your code. When the application has been designed with testing in mind, hooks exist; keyboard shortcuts are proffered; and debug data is available for the asking. Hooks include IDs on key elements such as the search field, enabling tests to identify the correct element quickly, unambiguously, and correctly even as the layout of the UI changes.

Increasing variety and fidelity

Varying the tests

Tests that repeat exactly the same steps using the same parameters tread a well-worn path through the application and may side-step some nearby bugs which we could find by changing a couple of parameters in the tests. Ways to change the tests include using external data sources and using random values for number of repetitions, sleeps, number of items to order, etc. You need to be able to distinguish between tests that fail because they are flaky and those that report valid failures in the software being tested, so make sure the tests record the parameters they used in sufficient detail to enable the test to be re-run consistently and predictably.

Using a variety of web browsers

Browsers differ between one provider and another and between versions. Your application may be trouble-free in one browser, yet entirely unusable in another. Make sure your automated tests execute in each of the major browsers used by your users; our list typically includes Internet Explorer, Firefox, Safari, Opera, and Chrome. Tools such as Selenium RC ( and WebDriver ( support most of the browsers, and if your tests are designed to run in parallel, you may be able to take advantage of parallel test execution frameworks such as Selenium Grid.

Emulating mobile devices

Many web applications are now used on mobile phones such as the iPhone or G1. While there are some early versions of WebDriver for these devices, you may find emulating these devices in a desktop browser is sufficient to give you the confidence you need. Firefox’s excellent extensions and profiles make such testing easy to implement. Safari’s development tools can be used to specify the parameters you need, such as which device to emulate. Here’s an example of how to configure Firefox in WebDriver to emulate a version 1.1 iPhone.

private static final String IPHONE_USER_AGENT_V1_1 =

"Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420.1 "

+ "(KHTML; like Gecko) Version/3.0 Mobile/3B48b Safari/419.3";


* Returns the WebDriver instance with settings to emulate

* an iPhone V1.1


public static WebDriver createWebDriverForIPhoneV1_1() {

final String emptyString = "";

FirefoxProfile profile = new FirefoxProfile();

// Blank out headers that would otherwise confuse the web server.

profile.setPreference("general.appversion.override", "");

profile.setPreference("general.description.override", "");

profile.setPreference("general.platform.override", "");



profile.setPreference("general.appname.override", "iPhone");


"general.useragent.override", IPHONE_USER_AGENT_V1_1);

WebDriver webDriver = new FirefoxDriver(profile);

return webDriver;


The user-agent string can be found online in many cases or captured from a tame web server that records the HTTP headers. I use, which even emails the values to me in a format I can easily adapt to use in my test code.

Robust tests

Robust tests can continue to operate correctly even when things change in the application being tested or in the environment. Web applications use HTML, so try to add IDs and CSS classes to relevant elements of the application. Although these additions potentially increase the size of the page, they enable easier and more consistent identification, navigation, and selection of the user interface.

Try to avoid brittle identifiers, such as xpath expressions that rely on positional data. For example, /div[3]/div[1] becomes unreliable as soon as any of the positions change – and problems may be hard to identify unless the change is easy to identify.

Add guard conditions that assert your assumptions are still accurate. Design the tests to fail if any of the assumptions prove false. If possible, make the tests fail at compile time to provide the earliest possible feedback.

Try to only make positive assertions. For example, if you expect an action to cause an item to be added to a list, assert that after the action the list contains the expected value, not that the list has changed size (because other functionality may affect the size). Also, if it's not something your test is concerned about, don't make assertions about it.

Informative tests

Help your tests to help others by being informative. Use a combination of meaningful error messages and more detailed logs to help people to tell whether the tests are working as intended and, if problems occur, to figure out what’s going wrong.

Recording evidence

Taking screenshots of the UI when a problem occurs can help to debug the issue and disambiguate between mismatches in our assumptions vs. problems in the application. It’s not an exact science: screenshots are seldom recorded at exactly the same time as the interaction with the application; typically they’re recorded afterwards, and the application may have changed in the interim period, no matter how short that period is.

Debug traces are useful for diagnosing acute problems, and range from simple debug statements like ‘I made it to this point’ to dumps of the entire state of values returned from the application by our automation tool. In comparison, logging is intended for longer-term tracking of behaviour which enables larger-scale thinking, such as enabling a test to be reproduced reliably over time.

Good error messages should say what’s expected and include the actual values being compared. Here are two examples of combinations of tests and assert messages, the second more helpful than the first:

1. Int actualResult = addTwoRandomOddNumbers();

assertTrue("Something wrong with calculation", actualResult % 2 == 0);

2. Int actualResult = addTwoRandomOddNumbers(number1, number2);

assertEquals(String.format("Adding two odd numbers [%d] and [%d] should return an even result. Calculated result = %d", number1, number2, actualResult) actualResult % 2 == 0);

Bit-rot, the half-life of tests

Vint Cerf coined the phrase bit-rot to reflect the decay of usefulness or availability of software and data stored on computers. In science, half-life is a measurement of the decay of radioactivity over time, and is the period taken for the radioactivity to reduce by 50%. Similarly, our tests are likely to suffer from bit-rot and will become less useful over time as the system and its use change.

The only cure for bit-rot is prevention. Encourage the developers to adopt and own the tests.

Tests for our tests?

As our tests get bigger and more complex, let’s add unit tests to help ensure our acceptance tests behave as expected. Mock objects are one practical way to reliably automate the tests, with several good and free frameworks available for common programming languages. I suggest you create unit tests for more involved support functions and for ‘driver’ code, rather than for the tests themselves.

Peripheral topics

If you think creating automated tests for a web application is hard, try using the web site with accessibility software such as a screen reader to learn just how inaccessible some of our web applications are! Screen readers, like automated tests, need ways to interrogate, interact with, and interpret the contents of web applications. In general, increasing the accessibility of a site can improve testability and vice-versa. So while you’re working hard with the team to improve the testability, try to use the site with a screen reader. Here's one example: Fire Vox, a screen reader for Firefox.

The third and final post of this series will reflect on the aims and challenges of acceptance tests.


[Gd] [Libraries][Update] - Dojo 1.3.1

| More

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

Dojo was updated to version 1.3.1

[Gd] Building a Google Earth app for Foundation grantees

| More

Google Code Blog: Building a Google Earth app for Foundation grantees

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Ron Hess from

Recently I had the great pleasure of working with a team of folks from the Foundation, Google Earth Outreach, Foundation clients and internal R&D folks. We were all working together to build something that we think is very meaningful and exciting for non-profits. I'd like to thank Lauren Ingram and John Kucera from R&D, Steve Wright from Foundation and Tanya Keen from Google Earth Outreach for their work on this over the past few months.

Tanya describes the idea behind the program: Since the early days of Google Earth Outreach, non-profits have been asking us if there was an easy way to put all of their partners, volunteers, donors, etc. onto a map. We found out that nonprofits had been asking the same of the folks at the Foundation, so we got together to make it happen.

Anyway, on to the app. It's basically a clever mash-up of the new Google Earth browser plug-in and Geocoding APIs that maps and displays the location of objects in your org in Earth. Here is a video that gives you a preview of how the app works:

When designing the app, we wanted to allow mapping to happen for accounts and non account objects like the opportunities or custom objects found in the Salesforce CRM application. This requirement led us to a design custom object to hold location information. This object can then be linked to any object in the system, such as an opportunity to assist a village in Africa, or the location of a well in Spain. We called this a Geo Location object. Within the app you can manually specify the location information or the app can lookup and store that for you.

The Application
The application has the standard Account and Opportunity objects found in the Platform, and we created a custom object in to hold the location information that we will need to display the map markers on the Google Earth Browser plugin. This location object also holds the information that we would like to display in the popup balloon. The balloon is end user configurable using a pick list, which is actually another custom field. On the platform two objects can be linked or related using a lookup field. In the simplest case the custom object has lookup field that relates to the original account that holds the address.

The application also has a geocoding feature that will perform a pass across all the account addresses in your system and create the location objects. This uses the AJAX libraries provided by Google to generate the geocode locations and then uses the Visualforce AJAX features to store them into the Location objects. After this process is complete you are ready to customize your balloon templates. I included the 5 basic templates from the Google Earth Outreach "Building Better Balloons" tutorial, since these were well thought out and covered the most common configurations.

The design goal behind building a configuration object is so that the non-profit organizations that install and use this application will have a tremendous customization ability, yet not have to do any programing to achieve it. Here is a snap of the Location object detail page where users can customize the balloon that will appear when a location is clicked. As you can see it's quite easy for a non programer to set the template, photo, caption and description information. These fields make up the custom object Geo_Location.

The Code
The code that generates the map is the most interesting part for me, what we have done is to build a KML string from all the information in the system (that the user would like to map) and then pass this KML string into the Google Earth Map API. Here is a look at the Javascript that we use to map the objects, quite easy actually.

You will notice that I am using a tag in the middle of a javascript block, this tag <apex:outputText is actually a Visualforce markup tag, and is replaced on the server by the KML that my Apex Code generates. Apex is our server side coding language, more info about Apex Code can be found on the found on the Salesforce developer website.

The KML is generated on the server and placed in the page so that parseKml() has all the information it needs, including the balloons, when the page is generated and sent to the browser. This avoids any round trips between the browser and's service.

This is a relatively simple app to build, so we added another feature to make it a bit more useful. We offer a button to export the KML for use with Google Earth client app. This uses the same code that generates the KML for the in browser page, so adding this feature was as easy as building a new button in Salesforce CRM. If you've never customized Salesforce CRM, I often describe this process as "clicks, not code". In the setup area you step into a short wizard to specify the label for the button, the location on the page and the action that it will perform. The Action can be a URL, Javascript or Visualforce as needed.

We are releasing this app to pilot customers the week of April 27, so if you are a non-profit or you know of a non-profit organization that could use an application like this, please visit our contact page and sign up for the pilot.

Come by and see us at Google I/O May 27-28 where will be speaking on several topics including Open Social, Google Visualization and Google App Engine.

By Ron Hess, Developer Evangelist -

[Gd] Painless threading

| More

Android Developers Blog: Painless threading

Whenever you first start an Android application, a thread called "main" is automatically created. The main thread, also called the UI thread, is very important because it is in charge of dispatching the events to the appropriate widgets and this includes the drawing events. It is also the thread you interact with Android widgets on. For instance, if you touch the a button on screen, the UI thread dispatches the touch event to the widget which in turn sets its pressed state and posts an invalidate request to the event queue. The UI thread dequeues the request and notifies the widget to redraw itself.

This single thread model can yield poor performance in Android applications that do not consider the implications. Since everything happens on a single thread performing long operations, like network access or database queries, on this thread will block the whole user interface. No event can be dispatched, including drawing events, while the long operation is underway. From the user's perspective, the application appears hung. Even worse, if the UI thread is blocked for more than a few seconds (about 5 seconds currently) the user is presented with the infamous "application not responding" (ANR) dialog.

If you want to see how bad this can look, write a simple application with a button that invokes Thread.sleep(2000) in its OnClickListener. The button will remain in its pressed state for about 2 seconds before going back to its normal state. When this happens, it is very easy for the user to perceive the application as slow.

Now that you know you must avoid lengthy operations on the UI thread, you will probably use extra threads (background or worker threads) to perform these operations, and rightly so. Let's take the example of a click listener downloading an image over the network and displaying it in an ImageView:

public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
Bitmap b = loadImageFromNetwork();

At first, this code seems to be a good solution to your problem, as it does not block the UI thread. Unfortunately, it violates the single thread model: the Android UI toolkit is not thread-safe and must always be manipulated on the UI thread. In this piece of code, the ImageView is manipulated on a worker thread, which can cause really weird problems. Tracking down and fixing such bugs can be difficult and time-consuming.

Android offers several ways to access the UI thread from other threads. You may already be familiar with some of them but here is a comprehensive list:

Any of these classes and methods could be used to correct our previous code example:

public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
final Bitmap b = loadImageFromNetwork(); Runnable() {
public void run() {

Unfortunately, these classes and methods also tend to make your code more complicated and more difficult to read. It becomes even worse when your implement complex operations that require frequent UI updates. To remedy this problem, Android 1.5 offers a new utility class, called AsyncTask, that simplifies the creation of long-running tasks that need to communicate with the user interface.

AsyncTask is also available for Android 1.0 and 1.1 under the name UserTask. It offers the exact same API and all you have to do is copy its source code in your application.

The goal of AsyncTask is to take care of thread management for you. Our previous example can easily be rewritten with AsyncTask:

public void onClick(View v) {
new DownloadImageTask().execute("");

private class DownloadImageTask extends AsyncTask {
protected Bitmap doInBackground(String... urls) {
return loadImageFromNetwork(urls[0]);

protected void onPostExecute(Bitmap result) {

As you can see, AsyncTask must be used by subclassing it. It is also very important to remember that an AsyncTask instance has to be created on the UI thread and can be executed only once. You can read the AsyncTask documentation for a full understanding on how to use this class, but here is a quick overview of how it works:

In addition to the official documentation, you can read several complex examples in the source code of Shelves ( and and Photostream (, and I highly recommend reading the source code of Shelves to see how to persist tasks across configuration changes and how to cancel them properly when the activity is destroyed.

Regardless of whether or not you use AsyncTask, always remember these two rules about the single thread model: do not block the UI thread and make sure the Android UI toolkit is only accessed on the UI thread. AsyncTask just makes it easier to do both of these things.

If you want to learn more cool techniques, come join us at Google I/O. Members of the Android team will be there to give a series of in-depth technical sessions and answer all your questions.


Tuesday, May 5, 2009

[Gd] Stable Update: Security Fix

| More

Google Chrome Releases: Stable Update: Security Fix

Google Chrome's Stable channel has been updated to version to fix two security issues discovered by internal Google testing.

This release also contains
  • A new notification at startup that makes it easier to set Google Chrome as the default browser. If you don't want Google Chrome to be the default browser, you can click 'Don't ask again'.
  • A new version of Gears (
Security Fixes

CVE-2009-1441: Input validation error in the browser process.
A failure to properly validate input from a renderer (tab) process could allow an attacker to crash the browser and possibly run arbitrary code with the privileges of the logged on user. To exploit this vulnerability, an attacker would need to be able to run arbitrary code inside the renderer process.

Severity: Critical. An attacker might be able to run code with the privileges of the logged on user.

Mitigation: An attacker would need to be able to run arbitrary code in the renderer process.

CVE-2009-1442: Integer overflow in Skia 2D graphics.
A failure to check the result of integer multiplication when computing image sizes could allow a specially-crafted image or canvas to cause a tab to crash and it might be possible for an attacker to execute arbitrary code inside the (sandboxed) renderer process.

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

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


[Gd] YouTube APIs: Search Explained

| More

YouTube API Blog: YouTube APIs: Search Explained

In an alternate universe (where I have a goatee) I may be a voice actor instead of a Googler. However, since we live in this universe, the best I can do is make you a screencast about the YouTube API. Specifically, this video discusses the various search options we have in our Data API and the various limitations and caveats to keep in mind while integrating it into your program or website.

If our API documentation is like the printed manual in the box of a new purchase that you never read, think of this video as the one-page laminated card with pretty pictures on it telling you not to get crushed by a bookshelf or hurt your back. Enjoy!


[Gd] Gadget Checker: A simple way to make good gadgets great

| More

iGoogle Developer Blog: Gadget Checker: A simple way to make good gadgets great

Writing software is hard, and it's easy for bugs to creep in. Gadgets are no different. And while developing gadgets here at Google, we discovered that many gadget bugs only show up when you've finished developing -- like when Japanese users can't see that translation you worked on for ages, or when your gadget turns out to be frustratingly slow.

It's important to have great gadgets in iGoogle. To help you, we'd like to share a tool that we wrote to catch many common gadget errors: Gadget Checker. We like to think of it as a small tool with a big impact. Use it before you submit your gadget to the Directory to pick up errors such as missing ModulePrefs attributes and missing images, scripts or stylesheets. It also makes suggestions for avoiding common latency traps, like unused API libraries, and for internationalizing your gadget. Simply load a gadget and run the tests, and you may find that you've fallen into one of the common problems. If so, there's advice in the gadget on how to address the issue.

To allow developers to use the tool while developing their gadget, Gadget Checker can open a gadget saved as a local file or in the Google Gadget Editor. (Tip: Consider using a special iGoogle tab containing Gadget Checker and the GGE next to each other, just for developing gadgets.) Once you've opened a local file in Gadget Code Checker, you can save it directly to GGE to fix all the bugs you found. Gadget Checker can even check any existing gadget simply by entering its URL.

Of course, the list of checks is nowhere near complete. If there's some pet peeve that you wish Gadget Code Checker looked for, feel free to let us know. We hope Gadget Code Checker makes it easier for you to develop great gadgets, and are looking forward to developing additional tools to help too.

One more thing. We hope you'll join us at Google I/O in late May. It's a useful way to interact with Google engineers and other developers. And two days in San Francisco isn't too shabby, either! Register today.

Posted by Egmont Koblinger and Martin Strauss, iGoogle Software Engineers

[Gd] @javax.inject.Inject

| More

Google Code Blog: @javax.inject.Inject

Five years ago, Spring 1.0 brought Java dependency injection into the mainstream. Three years later, Google Guice 1.0 introduced annotation-based dependency injection and made Java programming a little easier. Since then, developers have had to choose between a) writing external configuration or b) importing vendor-specific annotations.

Today, we hope to give developers the best of both worlds. Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks. At the moment, the set of specified annotations consists of:
  • @Inject - Identifies injectable constructors, methods, and fields
  • @Qualifier - Identifies qualifier annotations
  • @Scope - Identifies scope annotations
  • @Named - String-based qualifier
  • @Singleton - Identifies a type that the injector only instantiates once
One additional interface is specified for use in conjunction with these annotations:
  • Provider<T> - Provides instances of a type T. For any type T that can be injected, you can also inject Provider<T>.
You can check out an early draft of the specification. We deliberately left external dependency configuration out, so as not to quash ongoing innovation. We haven't formally submitted this standard to the JCP yet, but we plan to do so shortly. Standards wonks can read a draft of our JSR proposal.

The expert group will be inclusive and will work in the open. For example, our mailing list is publicly readable, and we host the specification at Google Code. Several industry players have already expressed interest in supporting this effort. Contact us if you'd like to help out.

Interested in learning more about dependency injection? Don't miss Jesse and Dhanji's Big Modular Java with Guice session at Google I/O!

By Bob Lee, Google Guice founder

[Gd] Previews of I/O Sessions: Eric Bidelman, Chris Nesladek and Eric Sachs

| More

Google Code Blog: Previews of I/O Sessions: Eric Bidelman, Chris Nesladek and Eric Sachs

For those who are attending I/O, we thought it might be useful to hear from some of the speakers in advance. These videos provide a preview of one or more topics that will be covered in their talks. If you're torn between two sessions at the same time slot, they may help you choose which one to attend. We'll release a few more of these over the coming weeks and we look forward to seeing you at Google I/O, on May 27-28.

Eric Bidelman - Using Google Data APIs and OAuth to Create an OpenSocial Gadget (with Monsur Hossain)

Chris Nesladek - Pixel Perfect Code: How to Marry Interaction and Visual Design the Android Way

Eric Sachs - Practical Standards-based Security and Identity in the Enterprise

Here's a complete list of sessions at I/O.

By Neel Kshetramade, Google Developer Programs

Monday, May 4, 2009

[Gd] GWT and Maven - Playing Nicely Together Since 2008

| More

Google Web Toolkit Blog: GWT and Maven - Playing Nicely Together Since 2008

StudyBlue is an academic social networking application, built with GWT, that helps students study smarter, faster. To manage the build process during the development of their application, the StudyBlue team uses the Maven build system. Chris Klundt and Hicham Bouabdallah from StudyBlue have kindly dropped by to share their tips on getting GWT and Maven to play nicely together.

Maven is a great resource that allows developers to enable dependency management within their GWT web applications. While a complete description of Maven's dependency management is beyond the scope of this article, we encourage you to read more here . Essentially, Maven allows you to modularize your GWT project, separating the reusable pieces of code (i.e. Custom Widgets or Data Transfer Objects) into their own projects while maintaining versioning. In addition, Maven allows you to incorporate several different modules without having to write/maintain a complex Ant build file.


When developing your application you may quickly realize that it would be beneficial to separate large pieces into separate modules for easier management and reusability. We have multiple internal applications that use the same Data Transfer Objects and Custom Widgets. In our case, we found that separating these two pieces into separate modules made everyone's life easier. In order to accomplish this, we created two separate Maven modules, studyblue-data and studyblue-widgets.

Your resulting project hierarchy will look like this once its all hooked up:

Diagram illustrating a StudyBlue sample project hierarchy

Each of the new modules (data and widgets) look similar to the main project because they contain a gwt.xml file, however their project structure looks like this:

  + studyblue-data/
     + src/
         + main/
             + java/
             + resources/
         + test
             + java/
             + resources/

Your Data.gwt.xml file would look like this:

       <!-- Inherit the core Web Toolkit stuff. -->
       <inherits name="''/">
       <source path="client">

Your file would be empty in most cases:



public class Data implements EntryPoint {

public void onModuleLoad() {


As per usual, your source code goes under the package. We created an additional project for studyblue-widgets similar to the one above. At this point, you should have three projects open in your Workspace (your main web app, your newly created data module, and your newly created widget module). Once you've organized your code, it's time to hook it up with your core web application via a few hooks with Maven and the gwt.xml files.

Connecting to Maven

So what is that pom.xml file all about? The first step is downloading the GWT-Maven plugin for Eclipse (which takes care of most of the heavy lifting) . Once you've installed the plugin, you're ready to organize your pom.xml files (one each for: data, widgets, web app).

Our studyblue-data pom.xml file looks like the combination of the following:

 <?xml version="1.0" encoding="UTF-8"?>
 <project xmlns="" xsi="" schemalocation="">

   <name>studyblue gwt data</name>

This is the portion that indicates how the jar should be created. The jar's title is "[artifactId]-[version].[packaging]". The parts in red, you would subsitute with your own information. *Note: We use -SNAPSHOT to notify Maven that the jar should be updated on every build (see below).

  &nbsp      <url></url>

   <!-- include pluginRepository and repository for GWT-Maven -->

The repositories tag tells your project where to download the gwt jars (servlet, user, etc). The pluginRepositories tag tells your project where to download the Maven-GWT plugin.


The build tag tells Maven what Java version you want your jar to be compiled into (1.6 in this case). The resources tag lets your project compiler know which java files should be included in the jar (i.e. ALL YOUR CODE).


The properties tag allows us to set a variable (gwtVersion) so Maven knows which version of GWT it needs to download when compiling. When it's time to upgrade, just change the version and the rest takes care of itself.


The dependencies tag tells your project which jars you need to compile. In the case of the studyblue-data and studyblue-widgets modules, we reference the GWT user jar, so we need to include it. Notice it takes use of the gwtVersion variable. There are six different types of scope. The three most important are "runtime", "provided" and "compile". Runtime means "I don't need it during compilation of the jar, but I do need it when the jar is executed." Provided means "The project that depends on this module will provide the jar". Compile means "This module needs the jar immediately for compilation".

In this case, we plan on connecting the studyblue-data and studyblue-widget modules to our main web app, which will "provide" the necessary GWT jars for these modules.


If one module needs to reference an additional module (i.e. studyblue-widgets depends on studyblue-data), you could insert the above code into studyblue-widget dependencies.


Don't forget to close your project tag :) Make sure you generate the appropriate pom.xml for your widgets module as well.


Alright, so you've separated your data and widgets from your main app. You built two projects and included a pom.xml file in each. Now it's time to build studyblue-data and studyblue-widgets into jars so you (and your teammates) can use them as necessary.

This part is super easy, just open command prompt or terminal and navigate to the project's root folder. Type the following:

  mvn clean deploy

That's it. Your project will be compiled with all the necessary libraries and is available for consumption by you and your teammates under the title entered above (studyblue-data-1.1.0-SNAPSHOT.jar and studyblue-widget-1.1.0-SNAPSHOT.jar).

Putting It All Together

So, you now have the two jars available, and you could just simply add them to your main web app's classpath. However, if you enable Maven on your main web app, you'll be able to take advantage of Maven's dependency management. This way you'll be able to download updated jars instantly and automatically. Additionally, assuming your main web app project is Mavenized you can include the GWT jar dependencies (servlet, user, etc) in the web app automatically.

To do this, you need to insert the following into your main web apps pom.xml below the properties tag:


The profiles tag allows our developers to use whichever GWT jars are necessary for their operating system (takes care of Windows vs. Mac vs. Linux automatically :) ). No more keeping copies of all GWT jars and native libraries in your project folder.

Finally, modify the dependencies section to look like this:


Notice here that the <scope> for the GWT jars is "compile", which ensures they are downloaded during compilation of the web app and "provided" to the dependent modules studyblue-data and studyblue-widgets. The GWT servlet jar is only needed when the web app is executed, so we choose "runtime" here.

Don't forget your gwt.xml

In order to make sure that our main web app knows about studyblue-data and studyblue-widgets we have to include the following lines in our main app's gwt.xml file:

<inherits name=&apos;; />
<inherits name=&apos;com.studyblue.widgets.Widgets&apos; />

Reflecting Updates In Your Modules

During development, we want our main web app to reflect changes that we make in the modules (studyblue-data and studyblue-widgets), everytime we build the project. This way every developer who is working on a project that references the modules (including our main web app), can get the latest build of the jars. We use the Maven keyword "-SNAPSHOT" when versioning our modules during development (i.e. studyblue-data-1.1.0-SNAPSHOT). Snapshot is a special version that indicates a current development copy. With a SNAPSHOT version, Maven will automatically fetch the latest SNAPSHOT every time you build your project. For rapidly moving code, this can be a necessity, particularly in a team environment. When you are ready to release the code, you finalize the version by removing "-SNAPSHOT".

To update your SNAPSHOTS before executing hosted mode or compilation, run this command in your project's root directory:

mvn clean --update-snapshots

Running Hosted Mode and Compiling

As long as your Maven dependencies are added to your project's classpath, you can execute hosted mode and GWT-Compile without worry. At StudyBlue, we use the Maven plugin for Eclipse ( ) to add all our Maven dependencies to our classpath, update snapshots and for editing the pom.xml files.


Maven can be tricky to setup, but once you've got it connected to your GWT project, you'll be amazed at how efficient and modular your application can become.