Friday, February 12, 2010

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update





The dev channel has been updated to 5.0.322.2 for Windows, Mac and Linux platforms

All

  • [r38242] Don't crash when a theme specifies a nonexistent image. (Issue: 31719)

Mac
  • [r38319] Honor modifiers for clicks on home button – cmd-clicking the home button now opens your home page in a new tab. (Issue: 34900)
  • [r38204] Implemented writing direction context menu in text input fields.
  • [r38504] Add local storage nodes to the cookie manager (Issue: 33068)

Linux
  • [r38320] Use of Freetype's emboldening for fonts that don't provide bold. Fixes the sometimes blurry bold fonts. (Issue: 22360)
  • [r38372] Can now drag and drop bookmarks from Firefox. (Issue: 34141)
  • [r38246] Implement content blocking address bar icons and bubbles (Issue: 33314)

Native Client
  • Chrome for Linux and Mac OS 10.6 can now run Native Client modules directly, no plugin required. To enable this features, run Chrome with the following command line flags --internal-nacl --enable-gpu-plugin --no-sandbox.
  • Platform-independent NPAPI extensions for 2D, 3D, and mouse/keyboard events are now available.
  • We'd like to hear from you. Please send feedback to native-client-discuss@googlegroups.com,

Extensions
  • [r38239] Don't crash when extensions use cookie. (Issue: 34649)
  • [r38407] Preserve order of browser actions across extension autoupdate. (Issue: 33401)
  • Implemented overflow and reordering of browser actions (this was actually in the last update, but missed the release notes)

Known Issues
  • Linux: Crash when editing a bookmark in the bookmark manager (Issue: 35438)
  • All: Chrome doesn't show popup blocker bubble (Issue: 35594)
  • Mac/Linux: Can't save cookie settings (Issue: 35307)

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

You can find out about getting on the Dev channel here:
http://dev.chromium.org/getting-involved/dev-channel.

If you find new issues, please let us know by filing a bug at
http://code.google.com/p/chromium/issues/entry

Karen Grunberg
Google Chrome
URL: http://googlechromereleases.blogspot.com/2010/02/dev-channel-update_12.html

[Gd] GWT 2.0.2 is now available

| More

Google Web Toolkit Blog: GWT 2.0.2 is now available

GWT 2.0.2 has been released and is available for download here:


http://code.google.com/webtoolkit/download.html

This was a minor release that includes the following fixes:



  • Standard.css missing new layout styles (#4429)

  • Using a PopupPanel in Internet Explorer without a history IFrame throws a NullPointerException (#4584)

URL: http://googlewebtoolkit.blogspot.com/2010/02/gwt-202-is-now-available.html

Thursday, February 11, 2010

[Gd] Announcing Google Chart Tools

| More

Google Code Blog: Announcing Google Chart Tools

A good chart can tell a story, such as depicting when you get home on Saturday night by plotting your tweet patterns along the week.
A good chart can take an elusive concept and clarify it in a visually appealing manner. This ingenious XKCD strip uses a pie chart, a bar chart and a recursive scatter plot, to demonstrate the concept of self description.










Whether you need a simple line chart, an interactive Geo Map or a complex Motion Chart , Google can help you add live charts to your web page using our Chart and Visualization APIs. Both of these APIs are free and simple to use, however they each have distinct advantages:

1. The Chart API provides Image Charts which are rendered by a Google chart server in response to a simple URL request. Image Charts are fast to render and can be easily emailed and printed. In addition to the extensive gallery of charts, this server now also provides dynamic icons, QR codes, and math formulas.







2. The Visualization API provides Interactive charts which are rendered on the browser using a Google developed JavaScript library. Interactive charts trigger events, providing tool-tips and animations. In addition to a rich gallery of charts, this tool can also read live data from a variety of data sources such as Oracle PL/SQL or Google spreadsheets.






We have discovered that developers occasionally need some help in navigating between the many options and distinct advantages of Image Charts and Interactive Charts, and therefore decided to bring the two APIs under one new framework which we call the "Google Chart Tools". We've accordingly renamed the APIs to Image Charts API and Interactive Charts API and created a simple side-by-side comparison page which you might find useful in choosing which chart tool is better for you.

Image Chart: Oceans of the world

Interactive Chart: Oceans of the world



We hope to meet you in person at Google I/O this May. In our Google Chart Tools I/O session we plan to present many of our new features including dynamic icons, which helped us plot our version of the recursive XKCD chart below:



By Michael Fink, Google Chart Tools team
URL: http://googlecode.blogspot.com/2010/02/announcing-google-chart-tools.html

[Gd] My Extension Wish: Workflow in Wave

| More

Google Wave Developer Blog: My Extension Wish: Workflow in Wave

Greetings! I'm Amanda and I work on Developer Relations for Google Wave. Continuing on our series of dream Google Wave extensions, I want to tell you one of my own wish...a Wave-ified workflow system.

From Expense Reports to major Press Releases, there are a lot of documents a typical company produces that require a workflow to ask for reviews and collect the necessary approvals/signatures. Google Wave is already very useful as a mean for collaboration to produce such documents and can potentially be extended to process workflows as well.

To describe how this can work, let's say I need to write a press release announcing the release of a new ground-breaking product to the world. Before releasing it, I first want the product manager to sign off on it, then a lawyer, then a PR person, and finally someone from upper management. These approvals can be done using a gadget inserted at the top of the wave while the rest of the wave contains the press release itself and reviewer comments. The gadget contains a graphical representation of the workflow and shows simple colored buttons representing the state so far. This can potentially be done by parsing YAWL (Yet Another Workflow Language) into Javascript.

For example, once the press release has been approved by PM and Legal, the current gadget state is "Pending PR Approval", the PM and Legal buttons are greyed out, and the PR button is highlighted. Since Joe is the designated PR person to approve, there is an extra "Approval" button only visible to him. When an action happens, like Joe pressing that button, the state changes accordingly and proceeds to the next step in the workflow.


The extension could also let the user select different document types in the gadget and depending on the type, it can automatically check if a document already meets the basic criteria (e.g a tweet can only contains 140 characters) before it can be approved. Furthermore, once all approvals have been received, a robot can automatically delete the comment blips to prepare the document for final publication. The possibilities are endless of course, and different companies would have different workflows to match their needs. The most flexible workflow extension should allow the creation of custom workflow templates.

Google Wave may not be ready to replace heavy workflow systems such as those to process insurance claim or what not, but for many forms of official communication documents, it is the perfect tool to collaborate, (and hopefully soon) review, and approve.

Feel free to discuss ideas for workflow extensions in the API forum or in a public wave. We're looking forward to hearing your ideas!


Posted by Amanda Surya, Developer Relations
URL: http://googlewavedev.blogspot.com/2010/02/my-extension-wish-workflow-in-wave.html

[Gd] Service API changes starting with Android 2.0

| More

Android Developers Blog: Service API changes starting with Android 2.0

Service API changes starting with Android 2.0

Watching developers use the Android platform the last year has shown a number of trouble areas in the Service API as well as growing issues in the ways services operate. As a result, Android 2.0 introduced a number of changes and improvements in this area for both developers and users.

The three main changes to be aware of are:

  • Service.setForeground() is now deprecated and in 2.0 does nothing.
  • There were many edge cases in the service lifecycle that made it very easy to accidentally leave a service running; new APIs in 2.0 make this much easier to deal with.
  • Android 2.0 also introduces a new UI for end users to monitor and manage the running services on their device.

Background on services

Before going into the details of 2.0, it may be useful to go over a quick summary of services. The Service API in Android is one of the key mechanisms for applications to do work in the background. Due to the way Android is designed, once an application is no longer visible to the user it is generally considered expendable and a candidate to be killed by the system if it ever needs memory elsewhere. The main way applications get around this is by starting a Service component, which explicitly tells the system that they are doing some valuable work and would prefer that the system not kill their process if it doesn't truly need to.

This is a very powerful facility but along with that power comes some responsibility: an actively running service is taking resources away from other things that can run (including inactive processes in the background that don't need to be initialized the next time the user visits them). It is thus important that developers take care when designing their services that they only run when truly needed and avoid any bugs where they may accidentally leave the service running for long durations.

Redesigning Service.setForeground()

During the final stabilization period of Android 1.6 we started to see more issues due to an increasing number of applications using the Service.setForeground() API when they shouldn't be. This is an API that we haven't advertised much because it should not be used by most applications and can be very hard on the system: it asks that the service's process be treated as in the foreground, essentially making it unkillable and thus more difficult for the system to recover from low memory situations.

At that point in 1.6 it was too late to make any significant changes to the behavior here, but in 2.0 we have done so: Service.setForeground() now does nothing. The API was always intended to be something a service would do in conjunction with putting up an ongoing notification for the user; by saying you are in the foreground, the user should be "aware" that the service is running in some way and know how to stop it. Thus in place of the old API Andriod 2.0 introduces two new APIs that require a notification go along with being in the foreground:


public final void startForeground(int id, Notification notification);
public final void stopForeground(boolean removeNotification);

This also not coincidentally makes it much easier to manage the notification state along with the service, since the system can now guarantee that there is always a notification while the service is in the foreground, and that the notification goes away whenever the service does.

Many developers will want to write a service that works on older platforms as well as 2.0 and later; this can be accomplished by using something like the following code to selectively call the new APIs when they are available.


private static final Class[] mStartForegroundSignature = new Class[] {
int.class, Notification.class};
private static final Class[] mStopForegroundSignature = new Class[] {
boolean.class};

private NotificationManager mNM;
private Method mStartForeground;
private Method mStopForeground;
private Object[] mStartForegroundArgs = new Object[2];
private Object[] mStopForegroundArgs = new Object[1];

@Override
public void onCreate() {
mNM = (NotificationManager)getSystemService(NOTIFICATION_SERVICE);
try {
mStartForeground = getClass().getMethod("startForeground",
mStartForegroundSignature);
mStopForeground = getClass().getMethod("stopForeground",
mStopForegroundSignature);
} catch (NoSuchMethodException e) {
// Running on an older platform.
mStartForeground = mStopForeground = null;
}
}

/**
* This is a wrapper around the new startForeground method, using the older
* APIs if it is not available.
*/
void startForegroundCompat(int id, Notification notification) {
// If we have the new startForeground API, then use it.
if (mStartForeground != null) {
mStartForegroundArgs[0] = Integer.valueOf(id);
mStartForegroundArgs[1] = notification;
try {
mStartForeground.invoke(this, mStartForegroundArgs);
} catch (InvocationTargetException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke startForeground", e);
} catch (IllegalAccessException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke startForeground", e);
}
return;
}

// Fall back on the old API.
setForeground(true);
mNM.notify(id, notification);
}

/**
* This is a wrapper around the new stopForeground method, using the older
* APIs if it is not available.
*/
void stopForegroundCompat(int id) {
// If we have the new stopForeground API, then use it.
if (mStopForeground != null) {
mStopForegroundArgs[0] = Boolean.TRUE;
try {
mStopForeground.invoke(this, mStopForegroundArgs);
} catch (InvocationTargetException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke stopForeground", e);
} catch (IllegalAccessException e) {
// Should not happen.
Log.w("MyApp", "Unable to invoke stopForeground", e);
}
return;
}

// Fall back on the old API. Note to cancel BEFORE changing the
// foreground state, since we could be killed at that point.
mNM.cancel(id);
setForeground(false);
}

Service lifecycle changes

Another situation we were increasingly seeing in 1.6 was that, even ignoring the services that inappropriately make themselves foreground, we had a growing number of devices with a large number of services running in the background all fighting each other over the available memory.

Part of this problem is services that are running more than they should or there simply being too much stuff trying to be done on the device. However, we also found many issues in the interaction between services and the platform that made it easy for an application to leave a service running even when it is trying to do the right thing. Consider this typical scenario:

  1. An application calls startService().
  2. That service gets onCreate(), onStart(), and then spawns a background thread to do some work.
  3. The system is tight on memory, so has to kill the currently running service.
  4. Later when memory is free, the service is restarted, and gets onCreate() called but not onStart() because there has not been another call to startService() with a new Intent command to send it.

Now the service will sit there created, not realizing it used to be doing some work, and so not knowing it should stop itself at some point.

To address this, in Android 2.0 Service.onStart() as been deprecated (though still exists and operates as it used to in previous versions of the platform). It is replaced with a new Service.onStartCommand() callback that allows the service to better control how the system should manage it. The key part here is a new result code returned by the function, telling the system what it should do with the service if its process is killed while it is running:

  • START_STICKY is basically the same as the previous behavior, where the service is left "started" and will later be restarted by the system. The only difference from previous versions of the platform is that it if it gets restarted because its process is killed, onStartCommand() will be called on the next instance of the service with a null Intent instead of not being called at all. Services that use this mode should always check for this case and deal with it appropriately.
  • START_NOT_STICKY says that, after returning from onStartCreated(), if the process is killed with no remaining start commands to deliver, then the service will be stopped instead of restarted. This makes a lot more sense for services that are intended to only run while executing commands sent to them. For example, a service may be started every 15 minutes from an alarm to poll some network state. If it gets killed while doing that work, it would be best to just let it be stopped and get started the next time the alarm fires.
  • START_REDELIVER_INTENT is like START_NOT_STICKY, except if the service's process is killed before it calls stopSelf() for a given intent, that intent will be re-delivered to it until it completes (unless after some number of more tries it still can't complete, at which point the system gives up). This is useful for services that are receiving commands of work to do, and want to make sure they do eventually complete the work for each command sent.

For compatibility with existing applications, the default return code for applications that are targeting an earlier version of the platform is a special START_STICKY_COMPATIBILITY code that provides the old behavior of not calling onStart() with a null intent. Once you start targeting API version 5 or later, the default mode is START_STICKY and you must be prepared to deal with onStart() or onStartCommand() being called with a null Intent.

You can also easily write a Service that uses both the old and new APIs, depending on the platform. All you need to do is compile against the 2.0 SDK with this code:


// This is the old onStart method that will be called on the pre-2.0
// platform. On 2.0 or later we override onStartCommand() so this
// method will not be called.
@Override
public void onStart(Intent intent, int startId) {
handleStart(intent, startId);
}

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
handleStart(intent, startId);
return START_NOT_STICKY;
}

void handleStart(Intent intent, int startId) {
// do work
}

New "running services" user interface

Our final issue to address is the case where there are simply too many service running in the amount of memory available on a device. This may be due to bugs or design flaws in installed applications, or the user simply trying to do too much. Historically users have had no visibility into what is going on at this level in the system, but it has become important to expose this, at least for lower-end devices, as the use of services has had an increasing impact on the user experience.

To help address this, Android 2.0 introduces a new "Running Services" activity available from the Application system settings. When brought up, it looks something like this:

Running Services

The main content is a list of all running services that may be of interest to the user, organized by the processes they run in. In the example here, we see three services:

  • GTalkService is part of the standard Google application suit; it is running in Google's "gapps" process, which currently consumes 6.8MB. It has been started for 3 hours 55 minutes, which on this device is the time from when it was first booted.
  • ActivityService is part of the Phonebook app, and its process consumes 4MB. This also has been running since boot.
  • SoftKeyboard is a third party input method. It has been running since I switched to it, about 4 minutes ago.

The user can tap on any of these services to control it; for normal services that are running because they were explicitly started, this will present a dialog allowing the user to explicitly stop it:

Stop Service

Some other services, like the input method, are running for other reasons. For these, tapping on the service will go to the corresponding UI to manage it (in this case the system's input settings).

Finally, along the bottom of the screen are some obscure numbers. If you know how to interpret them, this gives you a lot of information on the memory status of your device:

  • Avail: 38MB+114MB in 25 says that the device has 38MB of completely free (or likely used for unrequired caches) memory, and has another 114MB of available memory in 25 background processes it can kill at any time.
  • Other: 32MB in 3 says that the device has 32MB of unavailable memory in 3 unkillable processes (that is, processes that are currently considered to be foreground and must be kept running)

For most users, this new user interface should be a much more effective way to manage the background applications on their device than the existing "task killer" applications. In the vast majority of cases the reason for a slow running device is too many services trying to run. This prevents the system from being able to run any background processes (which speed up app switching), and ultimately can result in thrashing through the services when not even they can all be kept running. The Running Services UI is intended to provide very specific information about the services that are running, to help make a good decision about what should be stopped. It also does not use the API to force stop an application, which can unintentionally break applications in numerous ways.

For developers, this is an important tool to ensure your services are well behaved. As you develop your app, be sure to keep an eye on Running Services to ensure that you are not accidentally leaving your services running when they shouldn't be. You should also now keep in mind that users may freely stop any of your services as they wish, without your control, and account for that.

Android's Services are a very powerful tool, but one of the main and subtle ways that application developers can harm the overall experience a user has with their phone.

URL: http://android-developers.blogspot.com/2010/02/service-api-changes-starting-with.html

[Gd] Putting test data in its place

| More

Google Web Toolkit Blog: Putting test data in its place

Inevitably, as your app grows, you will find areas that involve consuming large amounts of textual data and performing some action as a result. You may be handling a JSON response, a serialized GWT RPC payload, or HTML that has been rendered on the server. In any case, you're a test-driven developer and you know that you have a handful of automated tests just wanting to be applied. The example below is one way of constructing such tests. And while it's not rocket science per say, it's so simple and useful that we felt compelled to tell others about it.



So let's say you're doing some server-side rendering, and somewhere in your code you most likely have a permutation of the following:




DOM.createDiv().setInnerHTML(foo);


Once inserted, you might apply some style, inject some values into the resulting HTML, etc.. Basically with the DOM structure in place, the rest of your app can move and do its thing. And "its thing" is often the more complex part, which begs for a test case. You want to make sure the "thing" it's doing is the right thing.



So at this point you happily code up a few GwtTestCase(s) and suddenly realize two things. One, "foo" can be really long, is a pain to maintain in code, and is ultimately polluting your test cases. Two, "foo" is most likely to change as your app grows, whereas your test cases shouldn't. Wouldn't it be nice if you could abstract "foo" away into a file that you load into your test cases, just as you do with other non-GWT test cases? Well, the good news is that you can. Much like other resources (e.g. ImageResource, CssResource, etc...), GWT has a mechanism for embedding text files into your app by specifying an associated TextResource within a ClientBundle. For example:




public interface TestResources extends ClientBundle {

@Source("com/google/gwt/example/test/ExampleTest.dat")
TextResource foo();

}

Here Example.dat would contain the HTML that I want load into my test case, and given that it's strictly for testing purposes you'll notice that I've added it under the "example/test" folder. At this point we have a ClientBundle from which we can grab the contents of our Example.dat file. In order to do something meaningful with this, we'll use it in a newly constructed GwtTestCase:



public class ExampleTest extends GWTTestCase {

TestResources resources;

public String getModuleName() {
return "com.google.gwt.example.Example";
}

public void gwtSetUp() {
resources = GWT.create(TestResources.class);
}

public void testFoo() {
DOM.createDiv().setInnerHTML(resources.foo().getText());
/*
* insert complex code to be tested
*
*/
}
}
}

Using this technique we've managed to keep our test cases clean, and centralized any test data changes within ExampleTest.dat rather than the ExampleTest source code. So clean, so simple, and hey, it even works when you want to load up some JSON data to test with.

URL: http://googlewebtoolkit.blogspot.com/2010/02/putting-test-data-in-its-place.html

[Gd] New Google App Engine SDK 1.3.1 released

| More

Google Apps Developer Blog: New Google App Engine SDK 1.3.1 released

The Google App Engine team today announced the release of a new SDK v.1.3.1. Many Google Apps developers use the App Engine SDK, or may want to know more about it. So, here is a link to the full blog post, and an excerpt below.

Today we announce the release of version 1.3.1 of the App Engine SDK for both Python and Java. While this release contains plenty of new features and fixes, we've concentrated on using our very first SDK release of 2010 to improve the heart of many App Engine applications: the Datastore.

Here are the three major improvements that 1.3.1 has in store for datastore users:
  • Datastore Query Cursors - Cursors allow applications to save and 'bookmark' their progress through a query, so that it can be resumed later. This works great in combination with paging URLs, as well as processing in the Task Queue API, but there are many other uses. Watch for an upcoming blog post that explores Cursors in the near future. They're also really handy in the context of the next change...
  • No more 1000 result limit - That's right: with addition of Cursors and the culmination of many smaller Datastore stability and performance improvements over the last few months, we're now confident enough to remove the maximum result limit altogether. Whether you're doing a fetch, iterating, or using a Cursor, there's no limits on the number of results.
  • Reduced error rate with Automatic Datastore Retries - We've heard a lot of feedback that you don't want to deal with the Datastore's sporadic errors. In response, App Engine now automatically retries all datastore calls (with the exception of transaction commits) when your applications encounters a datastore error caused by being unable to reach Bigtable. Datastore retries automatically builds in what many of you have been doing in your code already, and our tests have shown it drastically reduces the number of errors your application experiences (by up to 3-4x error reduction for puts, 10-30x for gets).
Read the full post here.

Follow @GoogleAppsDev on Twitter.
URL: http://googleappsdeveloper.blogspot.com/2010/02/new-google-app-engine-sdk-131-released.html

[Gd] Control your Google Sites from Apps Script

| More

Google Apps Developer Blog: Control your Google Sites from Apps Script

Last August we announced Google Apps Script, which allows you to automate many of the features of Google Apps using server-side scripts. Scripts can work with contacts, calendars, spreadsheets, mail and even call SOAP and REST web services, all using standard JavaScript. We just launched additional support for creating and accessing Google Sites using the new SitesApp Service.
Henry Lau, on the Google Apps Script team, has written a great tutorial on Creating a Soccer Club Homepage. In short, his script pulls upcoming Soccer matches from Google Calendar, creates a Google Site about the team and adds the Soccer team from Contacts as collaborators. Here's some snippets of the code.

// create a site, given the domain, site URL, site title and summary
var site = SitesApp.createSite("example.com", "rover", "Team Rover", "We'll be the divisional champs this year!");

// create a page for each member of the team
var webpage = site.createWebPage("Jimmy's Page", "JimmysPage", "Welcome to Jimmy's site");

// create a page for team announcements
var annPage = site.createAnnouncementsPage("Team Announcements", "Announcements", "New announcements for the team will be posted here.");


// given one of the Google Calendar events, create an announcement
var message = "There will be a soccer match from " + event.getStartTime() + " until " + event.getEndTime() + "!";
site
.createAnnouncement("Soccer Match #1", message, annPage);

It's that easy! Check out the documentation and get started building your scripts.

Of course, if you decide that you'd rather create Google Sites via a REST interface, the recently-announced enhancements to the Sites Data API will allow you to write code in your language of choice to create and manage sites.

Ryan Boyd
Developer Relations - Google Apps
URL: http://googleappsdeveloper.blogspot.com/2010/02/control-your-google-sites-from-apps.html

[Gd] Google Apps Developer Blog - for developers, by developers

| More

Google Apps Developer Blog: Google Apps Developer Blog - for developers, by developers

Welcome to the Google Apps Developer Blog. Today we're excited to introduce the Google Apps Developer Blog, for developers interested in building applications that leverage Google Apps. In this blog we'll cover topics of interest to Google Apps developers building applications on top of Google Apps, integrating with them or utilizing the APIs. Examples of some of the topics we'll cover and resources we'll provide include:
  • code snippets and samples
  • reviews of customer integration and deployment cases
  • interviews with developers on best practices for developing in Apps
  • voting on most-requested developer extensions in Apps
  • discussion of OAuth roadmap
  • references to OpenID
  • smart ways to do logging (and analysis/reporting) in AppEngine, etc.
  • Storing JSON in AppEngine
Watch this blog and subscribe to our feed for announcements of developer events, DevFests, Google I/O updates, product announcements, links to other Google developer related content and case studies on actual integration, implementation and deployments.

Also, don't forget to register for Google I/O, which is May 19-20, 2010 in San Francisco. Google I/O will feature 80 sessions, more than 3,000 developers, and over 100 demonstrations from developers showcasing their technologies. You'll be able to talk shop with engineers building the next generation of web, mobile, and enterprise applications. Last year's I/O sold out before the start of the conference, so we encourage you to sign up soon.

We'll do our best to bring you the most relevant developer content right here on this blog, and you can also check out these excellent sources of information for Google developers:

Google Apps Discussion Forum
Google Apps Client Libraries and Sample Code
Google Apps API Overview
Google Apps API Help Forum
Google Enterprise Blog

Finally, we want your feedback! Ask questions, suggest topics, and even submit your own stories for possible inclusion in this blog. Contact me at GADBeditor at google if you have a story for submission, or story suggestion. Comments will be enabled on this blog, and we hope you'll join the discussion.

Thanks,

Don Dodge
Developer Advocate
Developer Relations Team
URL: http://googleappsdeveloper.blogspot.com/2010/02/welcome-to-google-apps-developer-blog.html

[Gd] Building Apps on Google Apps? A new blog just for you

| More

Google Code Blog: Building Apps on Google Apps? A new blog just for you

We recently launched the Google Apps Developer Blog for developers interested in building applications that leverage Google Apps. This blog will cover topics of interest to Google Apps developers building applications on top of Google Apps, integrating with them or utilizing the APIs.

Don Dodge will be the editor and a frequent contributor to this new blog. Don is a Developer Advocate at Google helping developers build new applications on Google platforms and technologies. Don has been a startup evangelist at Microsoft and is also a veteran of five start-ups including Forte Software, AltaVista, Napster, Bowstreet, and Groove Networks.

You can follow the team's updates on Twitter, too – follow @googleappsdev – and, while you're at it, stay tuned to updates from the Google enterprise team at @googleatwork.

By Mike Marchak, Google developer team
URL: http://googlecode.blogspot.com/2010/02/building-apps-on-google-apps-new-blog.html

[Gd] Beta Update: Mac and Linux

| More

Google Chrome Releases: Beta Update: Mac and Linux

The Google Chrome Beta channel for Mac and Linux has been updated to 5.0.307.7. You can read about it on the Google Chrome Blog.

We've been adding many of the features that were missing on the Mac, and working hard on making Google Chrome on both platforms more reliable. We've spent a lot of time making plug-ins (like Adobe Flash Player) more reliable.

What's new on Mac since the last Beta update?

Highlights of Linux Fixes
  • [r34915] Fix a hang on many sites using custom fonts. (Issue: 29861)
  • [r37193, r36423, others] Improvements in GTK theme mode, using system colors in more places (new tab page, highlights, scroll bars). (Issue: 25831, 29948))
  • [r37201] We now also will load plugins from ~/.config/$PRODUCT_NAME/Plugins. (Issue: 22261)
  • Improved complex text support, fixing a number of bugs in Hebrew/Arabic/Hindi/etc. display.
  • [r34222] OOM killer should now kill runaway tabs before it kills the browser. (Issue:29752)

Highlights of Mac Fixes
  • [r36016] Support pinch to zoom on the Mac. (Issue: 16305)
  • [r35440] Cmd-three finger swipe opens prev/next page in new tab. (Issue: 29804)

Users can subscribe to the Beta channel by installing from


If you find new issues, please let us know by filing a bug at http://code.google.com/p/chromium/issues/entry.

--Mark Larson, Google Chrome Team
URL: http://googlechromereleases.blogspot.com/2010/02/beta-update-mac-and-linux.html

Wednesday, February 10, 2010

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update

The stable channel has been updated to 4.0.249.89 for Windows.

Security Fixes and rewards:
Please see the Chromium security page for more detail. Note that the referenced bugs may be kept private until a majority of our users are up to date with the fix.
Congratulations to Timothy D. Morgan on receiving a Chromium Security Reward for bug 32718Note that Timothy elected to donate the reward to the Haiti relief effort, so Google raised the donation to $1337.
  • [12303] [29914Low DNS and fall-back behavior of proxies. Credit to Eric Roman of the Chromium development community and Christopher Eatinger.
  • [31009High Integer overflows in the v8 engine. Credit to Mark Dowd, under contract to Google Chrome Security Team.
  • [31692High Error processing <ruby> tag. Credit to Google Chrome Security Team (SkyLined).
  • [32309Medium Leak of redirection target via <iframe> href.
  • [$500] [32718Medium Domain confusion populating HTTP authentication dialog. Credit to Timothy D. Morgan of VSR (www.vsecurity.com).
  • [32915High Integer overflow deserializing sandbox message. Credit to Mark Dowd, under contract to Google Chrome Security Team.
Anthony Laforge
Google Chrome Program Manager
URL: http://googlechromereleases.blogspot.com/2010/02/stable-channel-update.html

[Gd] App Engine SDK 1.3.1, Including Major Improvements to Datastore!

| More

Google App Engine Blog: App Engine SDK 1.3.1, Including Major Improvements to Datastore!

We are excited to announce the release of version 1.3.1 of the App Engine SDK for both Python and Java. While this release contains plenty of new features and fixes, we've concentrated on using our very first SDK release of 2010 to improve the heart of many App Engine applications: the Datastore.



Here are the three major improvements that 1.3.1 has in store for datastore users:
  • Datastore Query Cursors - Cursors allow applications to save and 'bookmark' their progress through a query, so that it can be resumed later. This works great in combination with paging URLs, as well as processing in the Task Queue API, but there are many other uses. Watch for an upcoming blog post that explores Cursors in the near future. They're also really handy in the context of the next change...
  • No more 1000 result limit - That's right: with addition of Cursors and the culmination of many smaller Datastore stability and performance improvements over the last few months, we're now confident enough to remove the maximum result limit altogether. Whether you're doing a fetch, iterating, or using a Cursor, there's no limits on the number of results.
  • Reduced error rate with Automatic Datastore Retries - We've heard a lot of feedback that you don't want to deal with the Datastore's sporadic errors. In response, App Engine now automatically retries all datastore calls (with the exception of transaction commits) when your applications encounters a datastore error caused by being unable to reach Bigtable. Datastore retries automatically builds in what many of you have been doing in your code already, and our tests have shown it drastically reduces the number of errors your application experiences (by up to 3-4x error reduction for puts, 10-30x for gets).
But even with our focus on the Datastore, we were able to sneak in a quite a number of other new goodies into 1.3.1 as well:



For Python, we've included the AppStats RPC instrumentation library. AppStats lets users easily profile the performance of calls from their app to the App Engine backend services to identify and isolate issues such as ineffective caching, bottlenecks, and redundant RPC calls in their app. (A Java version is in beta testing now.)



And for Java, we've included a comprehensive new unit-testing framework for your App Engine apps. The unit-testing framework enables you to test your application code in a natural, fully supported manner, and also allows you to integrate your App Engine apps into other existing testing and automation frameworks.



The list of changes in 1.3.1 goes on and on (Custom Admin Console pages! Support for wildcard domain mappings! Java precompilation on by default for all applications!), so make sure to download the new version and read our release notes for the complete list (Python, Java).



Posted by the App Engine Team
URL: http://googleappengine.blogspot.com/2010/02/app-engine-sdk-131-including-major.html

[Gd] Testing in the Data Center (Manufacturing No More)

| More

Google Testing Blog: Testing in the Data Center (Manufacturing No More)

By James A. Whittaker

W. Edwards Deming helped to revolutionize the process of manufacturing automobiles in the 1970s and a decade later the software industry ran with the manufacturing analogy and the result was nearly every waterfall, spiral or agile method we have. Some like TQM, Cleanroom and Six Sigma are obvious descendants of Deming while others were just heavily influenced by his thinking. Deming was the man.

I repeat, was. My time testing in Google's data center makes it clear that this analogy just doesn't fit anymore. I want a new one. And I want one that helps me as a tester. I want one that better guides my behavior.

We just don't write or release software the way we used to. Software isn't so much built as it is grown. Software isn't shipped ... it's simply made available by, often literally, the flip of a switch. This is not your father's software. 21st century development is a seamless path from innovation to release where every phase of development, including release, is happening all the time. Users are on the inside of the firewall in that respect and feedback is constant. If a product isn't compelling we find out much earlier and it dies in the data center. I fancy these dead products serve to enrich the data center, a digital circle of life where new products are built on the bones of the ones that didn't make it.

In our father's software and Deming's model we talk about quality control and quality assurance while we play the role of inspector. In contrast, my job seems much more like that of an attending physician. In fact, a medical analogy gives us some interesting parallels to think about software testing. A physician's hospital is our data center, there is always activity and many things are happening in parallel. Physicians have patients; we have applications and features. Their medical devices are our infrastructure and tools. I can picture my application's features strewn across the data center in little virtual hospital beds. Over here is the GMail ward, over there is Maps. Search, of course, has a wing of its own and Ads, well, they all have private rooms.

In a hospital records are important. There are too many patients with specific medical conditions and treatment histories for any physician to keep straight. Imagine walking up to the operating table without examination notes and diagnoses? Imagine operating without a constant stream of real time health data?

Yet as software testers we find ourselves in this situation often. That app lying in our data center has been tested before. It has been treated before. Where are our medical notes?

So let's add little clipboards to the virtual data center beds in which our apps lay. Let's add equipment to take vitals and display them for any attending tester to see. Like human patients, apps have a pulse, data runs through code paths like blood through veins. There are important things happening, countable events that lead to statistics, indicators and create a medical history for an attending tester to use in whatever procedure they must now perform. The work of prior testers need not be ignored.

It's an unsettling aspect of the analogy that I have put developers in the role of creator, but so be it. Like other metaphorical creators before them they have spawned intrinsically flawed creatures. Security is their cancer, privacy their aging. Software is born broken and only some things can be fixed. The cancer of security can only be managed. Like actual aging, privacy is a guarantee only young software enjoys. Such is the life of a data center app.

But it is the monitors and clipboards that intrigue me. What do they say of our digital patients? As an app grows from concept into adolescence what part of their growth do we monitor? Where is the best place to place our probes? How do we document treatment and evaluations? Where do we store the notes about surgeries? What maladies have been treated? Are there problematic organs and recurrent illness? The documents and spreadsheets of the last century are inadequate. A patient's records are only useful if they are attached to the patient, up-to-date and in full living color to be read by whatever attending tester happens to be on call.

This is the challenge of the new century of software. It's not a process of get-it-as-reliable-as-possible-before-we-ship. It's health care, cradle to grave health care ... prevention, diagnosis, treatment and cure.

So slip into your scrubs, it's going to be a long night in the ER.
URL: http://googletesting.blogspot.com/2010/02/testing-in-data-center-manufacturing-no.html

Tuesday, February 9, 2010

[Gd] Google Chrome Frame Developer Updates

| More

Chromium Blog: Google Chrome Frame Developer Updates

Since Google Chrome Frame was released in September we've published regular updates to improve stability and integration with Internet Explorer. Today's update continues this work but also contains two key changes that developers should be aware of.

First, until now Google Chrome Frame has used the <meta> tag for invocation.
<meta equiv="X-UA-Compatible" content="chrome=1">
Unfortunately, doing this had a few potential problems, including some challenges for sites which couldn't place the <meta> tag early enough to trigger Google Chrome Frame reliably.

As of today, Google Chrome Frame additionally allows sites to serve an HTTP header for invocation. Use of the <meta> tag is still supported, but sites can take advantage of the new trigger by specifying an equivalent HTTP header:
X-UA-Compatible: chrome=1
This has the following benefits:
  • Sites that detect Google Chrome Frame can serve content with standard MIME types (including application/xhtml+xml), which Microsoft Internet Explorer does not natively support.
  • The HTTP header will always be detected, no matter how many other headers are served.
  • The HTTP header passes the W3C validator (which the <meta> tag syntax did not).
  • HTTP headers can be centrally configured in your web sever for blanket rollout of Google Chrome Frame support. For example, to enable GCF site-wide for browsers that support it, in Apache (with mod_headers and mod_setenvif enabled) specify a header directive like:
<IfModule mod_setenvif.c>
    <IfModule mod_headers.c>
        BrowserMatch chromeframe gcf
        Header append X-UA-Compatible "chrome=1" env=gcf
    </IfModule>
</IfModule>
Secondly, today's release also renames the "cf:" protocol to "gcf:" and disables "gcf:" by default. You can enable it on your local system for testing by adding a REG_DWORD value named EnableGCFProtocol with a value of 1 to the following registry key: HKCU\Software\Google\ChromeFrame.

This change will help avoid misuse of this development-mode feature and will reduce the number of spurious compatibility issues reported.

Your copy of Google Chrome Frame should be automatically upgraded with these changes. To learn more, ask questions, or get involved, visit our site or join the Google Chrome Frame discussion group.

Posted by Alex Russell, Software Engineer
URL: http://blog.chromium.org/2010/02/google-chrome-frame-developer-updates.html