Saturday, March 12, 2011

[Gd] Update on Marketplace Billing API

| More

Google Apps Developer Blog: Update on Marketplace Billing API

Nearly 3 months ago we announced a preview of the Google Apps Marketplace billing feature. Based on feedback we’ve received over this time from trusted testers and other early adopters, we are closing the preview for new developers and will launch a significant update later this year.

For the next version, we’re working on making the billing features both easier to integrate with and easier for customers to use. Additional changes will enable us to innovate faster with expanded country support, payment options, and other exciting features due later on. Version 2 of the licensing API will continue to be supported throughout these changes.

Developers using the preview implementation can continue to do so until the new version is available and customers are transitioned. Those just getting started with the Marketplace are encouraged to use their own payment solution until the new version is available.

Please let us know if you have any questions by posting in the Google Apps Marketplace API forum.

Posted by Steven Bazyl, Google Apps Marketplace Team


Friday, March 11, 2011

[Gd] A Mini-Newsletter From Your Google Chrome Security Team

| More

Chromium Blog: A Mini-Newsletter From Your Google Chrome Security Team

We’re always working hard to enhance the Chrome browser with bug fixes, new defenses and new features. The release of Chrome 10 is no different, and there are some items worth highlighting:

Chrome 10: Flash sandboxing
With Chrome 10, our first cut of the previously announced Flash sandboxing initiative is now enabled by default for the Windows platform on Vista and newer. Additionally, because we automatically update Flash to the latest and most secure version, this should provide useful defense in depth.

Chrome 10: Out-of-date plug-in warnings
As we previously mentioned, we believe that some of the most significant opportunities to increase user security revolve around plugins. We’ve made a number of improvements in this area, including actively encouraging users to update their plug-ins to the most secure version. Chrome now detects when a plug-in is out of date and blocks it with a simple infobar. This infobar helps guide the user towards updating their plug-in with the latest security fixes.

Chrome 10: Plug-in blocking enhancements
Some of our more advanced users prefer fine-grained control over which plug-ins they wish to run -- which can have security and privacy benefits. Chrome has long had a feature which blocks plug-ins by default (Wrench menu -> Preferences -> Under the hood -> Content Settings -> Plug-ins). We’ve improved this feature by adding a context menu to the blocked plug-in placeholder. This menu lets users control which plug-ins do and do not run. Using a context menu helps prevent clickjacking attacks that try to bypass the block. Plug-in placeholders can also be hidden (for example, if they are floating over and obscuring real content), and the actual plug-in that wishes to run is made apparent.

Chromium Security Rewards program still going strong
We mentioned in passing in the 9.0.597.107 release notes that our rewards program has passed $100,000 of rewards. We’d like to re-iterate our thanks to all the named researchers in our Hall of Fame. We’re continually delighted with the stream of interesting and clever bugs that we receive, so it will be exciting to see what the rest of 2011 brings. Remember, we love giving out money!

Still hiring!
We are always looking to expand the Google Chrome Security Team, and we’re looking for a wide range of talents. We can promise exciting and varied work, working to protect hundreds of millions of users and working alongside the best in the industry. Why not have a look at our job posting?

Posted by Chris Evans, Google Chrome Security Team, Bernhard Bauer, Software Engineer, and Carlos Pizano, Software Engineer

[Gd] Stable and Beta Channel Updates

| More

Google Chrome Releases: Stable and Beta Channel Updates

The Chrome Stable and Beta channels have been updated to 10.0.648.133 for Windows, Mac, Linux and Chrome Frame. This release fixes the following security issue:

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.
  • [$1337] CVE-2011-1290 [75712] High Memory corruption in style handling. Credit to Vincenzo Iozzo, Ralf Philipp Weinmann and Willem Pinckaers reported through ZDI.
If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Jason Kersey
Google Chrome

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 11.0.696.3 for All platforms

The following bugs were fixed
  • Can not select omnibox auto suggested entries by clicking at it (Issue 75366).
  • Linux: "Behavior " string is not externalized on the Exceptions page(Issue 74080).
  • Chromium not loading some plugins (Issue 75351).
  • POST omits body after NTLM authentication (Issue 62687).

Known Issues
  • Crash when opening tab/startup @ SkBitmap::lockPixels (Issue 75531).

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Karen Grunberg
Google Chrome

[Gd] Chrome OS Beta Channel Update

| More

Google Chrome Releases: Chrome OS Beta Channel Update

The Chrome OS Beta channel has been updated to the latest R10 release including the new Chrome 10 (10.0.648.127). Full details of the Chrome 10 release is available in the blogpost
If you find new issues, please let us know by visiting our help site or filing a bug.

Josafat Garcia
Google Chrome 

[Gd] How Google Tests Software - Part Four

| More

Google Testing Blog: How Google Tests Software - Part Four

By James Whittaker

Crawl, walk, run.

One of the key ways Google achieves good results with fewer testers than many companies is that we rarely attempt to ship a large set of features at once. In fact, the exact opposite is often the goal: build the core of a product and release it the moment it is useful to as large a crowd as feasible, then get their feedback and iterate. This is what we did with Gmail, a product that kept its beta tag for four years. That tag was our warning to users that it was still being perfected. We removed the beta tag only when we reached our goal of 99.99% uptime for a real user’s email data. Obviously, quality is a work in progress!

It’s not as cowboy a process as I make it out to be. In fact, in order to make it to what we call the beta channel release, a product must go through a number of other channels and prove its worth. For Chrome, a product I spent my first two years at Google working on, multiple channels were used depending on our confidence in the product’s quality and the extent of feedback we were looking for. The sequence looked something like this:

Canary Channel is used for code we suspect isn’t fit for release. Like a canary in a coalmine, if it failed to survive then we had work to do. Canary channel builds are only for the ultra tolerant user running experiments and not depending on the application to get real work done.

Dev Channel is what developers use on their day-to-day work. All engineers on a product are expected to pick this build and use it for real work.

Test Channel is the build used for internal dog food and represents a candidate beta channel build given good sustained performance.

The Beta Channel or Release Channel builds are the first ones that get external exposure. A build only gets to the release channel after spending enough time in the prior channels that is gets a chance to prove itself against a barrage of both tests and real usage.

This crawl, walk, run approach gives us the chance to run tests and experiment on our applications early and obtain feedback from real human beings in addition to all the automation we run in each of these channels every day.

There are analytical benefits to this process as well. If a bug is found in the field a tester can create a test that reproduces it and run it against builds in each channel to determine if a fix has already been implemented.

[Gd] Finding success in the Chrome Web Store

| More

The official Google Code blog: Finding success in the Chrome Web Store

Chrome Web Store logoEven though the Chrome Web Store launched in the US just a few months ago, some developers are already seeing great results. From games to productivity apps, the store has helped all kinds of web applications grow.

Our friends from World Golf Tour, Sliderocket, Wikinvest, and Springpad share their experiences with the Chrome Web Store through five brand new case studies. While each of these developers has a unique view point, some common themes have surfaced:
  1. The Chrome Web Store can help you acquire more users really fast: For example for, users of the Chrome Web Store app account for more than 50% of the web site’s traffic.
  2. Chrome Web Store users are very engaged with apps: Springpad and Wikinvest report that Chrome app users spend up to 100% more time interacting with the app, than a typical visitor spends on their regular website.
  3. You can improve the monetization of your app through the Chrome Web Store: Premium apps like the World Golf Tour and Sliderocket report significantly higher conversion rates for Chrome app users than the rest of the user base and a growing percentage of business leads originating from the store respectively.
  4. Posting your app in the store requires relatively little effort: The app publishing process in the store is smooth and required little to no custom work for all the developers, profiled in the case studies.
If you are interested in publishing your app in the Chrome Web Store or learning more about how the Chrome Web Store can help your business, explore our developer documentation and join us in our developer forum.

By Christos Apartoglou, Product Marketing

Thursday, March 10, 2011

[Gd] Renderscript Part 2

| More

Android Developers Blog: Renderscript Part 2

[This post is by R. Jason Sams, an Android engineer who specializes in graphics, performance tuning, and software architecture. —Tim Bray]

In Introducing Renderscript I gave a brief overview of this technology. In this post I’ll look at “compute” in more detail. In Renderscript we use “compute” to mean offloading of data processing from Dalvik code to Renderscript code which may run on the same or different processor(s).

Renderscript’s Design Goals

Renderscript has three primary goals, given here from most to least important.

Portability: Application code needs to be able to run across all devices, even those with radically different hardware. ARM currently comes in several variants — with and without VFP, with and without NEON, and with various register counts. Beyond ARM, there are other CPU architectures like x86, several GPU architectures, and even more DSP architectures.

Performance: The second objective is to get as much performance as possible within the constraints of Portability. For Renderscript to make sense we need to achieve much greater performance than established solutions.

Usability: The third goal is to simplify development as much as possible. Where possible we automate steps to avoid glue code and other developer busy work.

Those three goals lead to several design trade-offs. It’s these trade-offs that separate Renderscript from the existing approaches on the device, such as Dalvik or the NDK. They should be thought of as different tools intended to solve different problems.

Core Design Choices

The first choice that needed to be made is what language should be used. When it comes to languages there are almost unlimited options. Shading style languages, C, and C++ were considered. In the end the shading style languages were ruled out due to the need to be able to manipulate data structures for graphical applications such as scene graphs. The lack of pointers and recursion were considered crippling limitations for usability. C++ on the other hand was very desirable but ran into issues with portability. The advanced C++ features are very difficult to run on non-cpu hardware. In the end we chose to base Renderscript on C99 because it offers equal performance to the other choices, is very well understood by developers, and poses no issues running on a wide range of hardware.

The next design trade-off was work flow. Specifically we focused on how to convert source code to machine code. We explored several options and actually implemented two different solutions during the development of Renderscript. The older versions (Eclair through Gingerbread) compiled the C source code all the way to machine code on the device. While this had some nice properties such as the ability for applications to generate source on the fly it turned out to be a usability problem. Having to compile your app, install it, run it, then find your syntax error was painful. Also the weaker CPU in devices limited the static analysis and scope of optimizations that could be done.

Then we switched to LLVM, moving to a model where scripts are compiled and analyzed on the host using a modified version of clang. We perform high level optimizations at this stage, then emit LLVM bitcode. The translation of the intermediate bitcode to machine code still happens on the device (along with additional device-specific optimizations).

Our last big trade-off for compute was thread launching. The trade-off here is between performance and portability. Given sufficient knowledge, existing compute solutions allow a developer to tune an application for a specific hardware platform to the detriment of others. Given unlimited time and resources developers could tune for every hardware combination. While testing and tuning a variety of devices is never bad, no amount of work allows them to tune for unreleased hardware they don’t yet have. A more portable solution places the tuning burden on the runtime, providing greater average performance at the cost of peak performance. Given that the number one goal was portability we chose to place this burden on the runtime.

A secondary effect of choosing runtime thread-launch management is that dynamic decisions can be made about where to run a script. For example, some compute hardware can support pointers and recursion while others cannot. We could have chosen to disallow these things and give developers a lowest common denominator API, but we chose to instead let the runtime analyze the scripts. This allows developers to get full use of hardware that supports these features, since there is always a fully featured CPU to fall back upon. In the end, developers can focus on writing good apps and the hardware manufacturers can compete on making the most fully featured and efficient hardware. As new features appear, applications will benefit without application code changes.

Usability was a major driver in Renderscript’s design. Most existing compute and graphics platforms require elaborate glue logic to tie the high performance code back to the core application code. This code is very bug prone and usually painful to write. The static analysis we do in the host Renderscript compiler is helpful in solving this issue. Each user script generates a Dalvik “glue” class. Names for the glue class and its accessors are derived from the contents of the script. This greatly simplifies the use of the scripts from Dalvik.

Example: The Application Level

Given these trade-offs, what does a simple compute application look like? In this very basic example we will take a normal object and run a script that copies it to a second bitmap, converting it to monochrome along the way. Let’s look at the application code which invokes the script before we look at the script itself; this comes from the HelloCompute SDK sample:

    private Bitmap mBitmapIn;
private Bitmap mBitmapOut;
private RenderScript mRS;
private Allocation mInAllocation;
private Allocation mOutAllocation;
private ScriptC_mono mScript;

private void createScript() {
mRS = RenderScript.create(this);

mInAllocation = Allocation.createFromBitmap(mRS, mBitmapIn,
mOutAllocation = Allocation.createTyped(mRS, mInAllocation.getType());

mScript = new ScriptC_mono(mRS, getResources(), R.raw.mono);


This function assumes that the two bitmaps have already been created and are of the same size and format.

The first thing all Renderscript applications need is a context object. This is the core object used to create and manage all other Renderscript objects. This first line of the function creates the object, mRS. This object must be kept alive for the duration the application intends to use it or any objects created with it.

The next two function calls create compute allocations from the Bitmaps. Renderscript has its own memory allocator, because the memory may potentially be shared by multiple processors and possibly exist in more than one memory space. When an allocation is created its potential uses need to be enumerated so the system may choose the correct type of memory for its intended uses.

The first function createFromBitmap() creates a matching Renderscript allocation object and copies the contents of the bitmap into the allocation. Allocations are the basic units of memory used in renderscript. The second Allocation created with createTyped() generates an Allocation identical in structure to the first. The definition of that structure is retrieved from the first with the getType() query. Renderscript types define the structure of an Allocation. In this case the type was generated from the height, width, and format of the incoming bitmap.

The next line loads the script, which is named “”. R.raw.mono identifies it; scripts are stored as raw resources in an application’s APK. Note the name of the auto-generated “glue” class, ScriptC_mono.

The next three lines set properties of the script, using generated methods in the “glue” class.

Now we have everything set up. The function invoke_filter() actually does some work for us. This causes the function filter() in the script to be called. If the function had parameters they could be passed here. Return values are not allowed as invocations are asynchronous.

The last line of the function copies the result of our compute script back to the managed bitmap; it has the necessary synchronization code built-in to ensure the script has completed running.

Example: The Script

Here’s the Renderscript stored in which the application code above invokes:

#pragma version(1)
#pragma rs java_package_name(

rs_allocation gIn;
rs_allocation gOut;
rs_script gScript;

const static float3 gMonoMult = {0.299f, 0.587f, 0.114f};

void root(const uchar4 *v_in, uchar4 *v_out, const void *usrData, uint32_t x, uint32_t y) {
float4 f4 = rsUnpackColor8888(*v_in);

float3 mono = dot(f4.rgb, gMonoMult);
*v_out = rsPackColorTo8888(mono);

void filter() {
rsForEach(gScript, gIn, gOut, 0);

The first line is simply an indication to the compiler which revision of the native Renderscript API the script is written against. The second line controls the package association of the generated reflected code.

The three globals listed correspond to the globals which were set up in our managed code. The fourth global is not reflected because it is marked as static. Non-static, const, globals are also allowed but only generate a get reflected method. This can be useful for keeping constants in sync between scripts and managed code.

The function root() is special to renderscript. Conceptually it’s similar to main() in C. When a script is invoked by the runtime, this is the function that will be called. In this case the parameters are the incoming and outgoing pixels from our allocation. A generic user pointer is also provided along with the address within the allocation that this invocation is processing. This example ignores these parameters.

The three lines of the root function unpack the pixel from RGBA_8888 to a vector of four floats. The second line uses a built-in math function to compute the dot product of the monochrome constants with the incoming pixel data to get our grey level. Note that while dot returns a single float it can be assigned to a float3 which simply copies the value to each of the x, y, and z components of the float3. In the end we use another builtin to repack the floats back to a 32 bit pixel. This is also an example of an overloaded function as there are separate versions of rsPackColorTo8888 which take RGB (float3) or RGBA (float4) data. If A is not provided the overloaded functions assume a value of 1.0f.

The filter() function is called from managed code to do the conversion. It simply does a compute launch on each element of the allocation. The first parameter is the script to be launched - the root function of this script will be invoked for each element in the allocation. The second and third parameters are the input and output data allocations. The last parameter is the pointer for the user data if we desired to pass additional information to the root function.

The forEach will launch across multiple threads if the device has multiple processors. In the future forEach can provide a transition point where control may pass from one processor to another. In this example it is reasonable to expect that in the future filter() would get executed on the CPU and root() would occur on a GPU or DSP.

I hope this gives glimpse into the design behind Renderscript and a simple example of how it can be used.


Wednesday, March 9, 2011

[Gd] Celebrating 1 year of Integrated Goodness

| More

Google Apps Developer Blog: Celebrating 1 year of Integrated Goodness

The Google Apps Marketplace turns one year old today. Over the last year, we’ve seen over 300 business applications join the Apps Marketplace. As a Developer Advocate on the Apps Marketplace, I’ve worked with the developers and product managers of many of these applications to help them understand our APIs and how integrations will help their users.

On our first birthday, I want to share some of my thoughts based on what I’ve seen as an advocate for developers and our mutual customers.

My definition of deeply integrated

A deeply integrated app is one that values my time -- the developers have done everything possible to build an amazing user experience throughout the process of configuring and deploying the application as well as day-to-day use.

When integrations truly impress me, I call them star integrations.

Stop making me create accounts and passwords

This is a core tenant of the Apps Marketplace, and one that I strongly believe in. We knew we wanted to eliminate the proliferation of passwords and create a smooth Single Sign-On (SSO) experience when we were building the Marketplace.

While not many business applications had adopted OpenID for authentication, we rallied behind this open standard (with some additional discovery extensions) to enable SSO. I’m happy and proud to say there are now hundreds of business web applications which are OpenID relying parties. While some only support Google Apps, or Google Apps and Gmail accounts currently, it’s a step in the right direction for our users.

How does Single Sign-On work with the Apps Marketplace? It’s super simple for a user to access all of their apps from the navigation at the top of Gmail, Calendar, Docs and more.

Beyond access from Google’s applications, some apps also allow their users to login via their Google Apps accounts directly from their homepages. This saves time for users and gets these integrations a shiny Star in my book.

Cohuman: Allows me to sign in with my Google Apps account directly from their site, in addition to providing Single Sign-On access from the universal navigation bar

Eliminate my data silos

I want one calendar, one set of contacts, one e-mail inbox, and one repository for my documents. I don’t want to re-enter this information in yet another application-- I already have it in Google Apps.

I often hear developers say ‘2-way synchronization is a hard problem.’ I agree, but sometimes the hard work is worth it to build a great user experience.

Auto-complete my Contacts

I don’t always remember the e-mail addresses of my friends, colleagues and clients, but that info is in my Google Contacts. The good news is, building auto-complete using the Google Contacts API can mostly be done in the front-end, without full synchronization. When you prompt me with a ‘To’ field to invite someone to collaborate on a project with, you should make it super easy for me to fill out.

Mavenlink:Allows me to send invitations to contacts or colleagues to collaborate on a project. They make it very easy by auto-completing addresses using my Google Contacts.

Connect with my Google Docs

I store everything in my Google Docs -- my presentations, my financials and even some of my favorite screenshots. Please, please, please don’t make me export and import docs, but rather enable me to easily use those docs from within my favorite applications.

Manymoon: Automatically manages the ACLs of docs I attach to a task or project, so new project members automatically get access to the project docs

Your integration with Google Docs doesn’t need to be only in your interface. I love it when developers take new features in the Google Apps UI and extend them to be features of their applications. For example, collections (folders) in Google Docs enable you to organize and share your content, but they’re typically just a loose collection of documents. Your application can make them more useful by creating folders and managing their content. Creates a Google Docs folder and Google Calendar automatically when a teacher creates a new course. This allows students to access all the information about their class from within the tools they already use.

Manage my central calendar

If I have an upcoming project due, a phone call with an important customer, or a homework assignment to turn in, I want to be able to go to my Google Calendar and see all the events. I don’t want to bounce between a dozen apps (even with the wonders of SSO, that’s painful!). If your application has any date-based data, give me the option of using Google Calendar to store it.

To do this, there are two basic ways to store data from a third-party app in Google Calendar -- in the user’s personal calendar, or by creating a separate (“secondary”) calendar for a project or other entity. I’m often asked which is the best strategy, and this is one of the few things I don’t have an opinion on. Do what your users want, or offer both options.

TripIt: Has a Calendar Sidebar Gadget to give me a quick glance view of my upcoming trips

When an app puts events into my Google Calendar, I’m also able to take advantage of built-in support for things like alerts, which gives me configurable popup, email and SMS notifications of my upcoming events.

Make my data available on the go

I’m not always sitting at my desk waiting for the next phone call or e-mail to flow in -- I’m on US-101 for a few hours every day. I’m fortunate to be on a Google shuttle where my laptop is easily accessible, but not all of your users are that lucky.

Google has made all of my favorite apps, like Google Calendars, Contacts, Mail and Chat all work really well on my Android phone. We’ve also invested in sync for other devices such as the Blackberry and the iPhone.

When you eliminate data silos and allow me to store all my info in Google Apps, you also empower me to use my data everywhere I go, making me a more productive and happier user.

AffinityLive: Creates appointments in Google Calendar, making them available on the web and on your mobile device

Some apps on the Marketplace also provide mobile-optimized web sites or native mobile apps to help you access your app-specific data on the go. But how do you do SSO on a mobile device? This is the biggest challenge Apps Marketplace developers mention when building mobile versions of their apps. There are several different strategies which work well for Marketplace apps. The best solution I’ve seen is using OpenID to open a browser and login to TripIt, with a custom URL scheme registered as the Intent Filter in Android. Sure, opening a browser is a little ugly, but since I’m often already logged into my account, it’s a smoother experience than typing a username+password. Alternatively, the mobile apps for Concur Breeze use a one-time mobile PIN which you must enter when you first setup the app.

Enable me to take action in context

How often do you copy and paste an e-mail address from Gmail into your CRM to lookup a customer? Or look at a Calendar appointment and want more information about the people you’re meeting with? Or receive an e-mail asking you to approve an expense report, requiring you to popup a new window and login to your expenses app?

You shouldn’t have to, and a deeply integrated app won’t make you.

Show me relevant information next to my e-mails

Gmail Contextual Gadgets ranks as my favorite API we’ve released for Google Apps. It allows you to register a regular expression which attempts to match against each Gmail message -- using the e-mail addresses, subject or body of the message. If a match succeeds, your application is triggered as a gadget which appears below each matching e-mail message.

That’s the geeky definition, but what do Gmail Contextual Gadgets do in practice? They save me, and all your other users plenty of precious time, by allowing us to see information take action to e-mails right within the context of those messages.

Harvest: If I forgot to submit my timesheets for the week, it sends me a reminder and I can file the timesheets right from within the email

Solve360: When I receive an e-mail from a potential customer, I can immediately capture the opportunity in my CRM

Become my friend in Google Talk

Gmail gadgets aren’t the only way that apps can make me more efficient in the context of my other tasks. Apps can also take advantage of Google Talk, which is available for Google Apps users in Gmail, in iGoogle and on their mobile devices.

GQueues: Uses the XMPP functionality built into App Engine to allow me to IM the application to add a new task. So, if I have an e-mail open or am running around with my Android, I can pop open a Google Task and quickly add a task.

Make my dates more Interesting

Calendar Sidebar Gadgets are also contextual, allowing you to display relevant information about the event. Imagine if the created event was about a project-- a sidebar gadget could display other upcoming events related to the project, information about the members in the project and give quick access to relevant documents.

Let me pack my bags if we must part ways

Google has an initiative and team called the Data Liberation Front. Their goal is to make sure it’s really easy to move data in and out of Google products, like Calendar, Contacts, Docs and more. They enable data portability through a combination of user-facing UI and developer-facing APIs.

Some of the applications on the Apps Marketplace also make it easy to move data in and out.

Viewpath: If I want to get my data out of Viewpath, I can easily export it as a Microsoft Project file.

Earn your stars!

Get started on your integrations now and earn stars from your customers . Then work with those customers to share the story of how your deep integrations with Google Apps made them happier and more efficient.

If you’re feeling your creativity is limited by the available integration points offered by our APIs, let us know how we can help by chiming into the Buzz stream below. Also chime in if you want to share an awesome integration you’ve built, even if you’re not quite ready to share a customer story.

Want to weigh in on this topic? Discuss on Buzz

Ryan Boyd profile | twitter | events

Ryan is a Developer Advocate on the Google Apps Marketplace team, helping businesses build applications integrated into Google Apps. Wearing both engineering and business development hats, you'll find Ryan writing code and helping businesses get to market with integrated features.


[Gd] Implementing Workflows on App Engine with Fantasm

| More

Google App Engine Blog: Implementing Workflows on App Engine with Fantasm

This post is another entry in our ongoing series of guest posts contributed by App Engine developers. Today we partner with Jason Collins and Shawn Rusaw of VendAsta Technologies who discuss their simplistic workflow management system for Python App Engine called Fantasm. Fantasm is very simple to start using but incredibly powerful. So powerful in fact, that they couldn't fit it into one blog post. So for more detail, see the Implementing Workflows on App Engine with Fantasm article in our documentation.

Most software systems of reasonable size need to implement workflows: a series of processing steps and decision points over an artifact, typically a document. You are likely using workflows even if you don't realize it; often processing is built up iteratively over time until you're left with a complex system with lots of subtleties. These systems can mysterious and difficult to manage or extend.

A formal workflow engine can offer help in these instances. It allows developers to break the steps and decision points into manageable and testable chunks, so that processing is predictable and measurable. Workflow engines can offer visibility into system operations and metrics around execution times and failure points. They provide retry mechanisms and allow tasks to be distributed among multiple computers.

We have developed Fantasm to be just such a workflow engine. Fantasm is a Python library that allows you to specify your tasks and steps between those tasks in a YAML configuration file. It uses a finite state machine model where the tasks are states and the steps are transitions. As a developer, you implement the code that executes inside of a state and are only responsible to return an event that is used to identify the appropriate transition to the next state. It is similar to the App Engine Pipeline API but is more simplistic and serves as a user-friendly introduction to the concept of workflows in App Engine apps.

Fantasm has become the central processing tool within our organization and we hope it can be of help to yours. For a more in-depth look at Fantasm (including examples!), please see the full Implementing Workflows on App Engine with Fantasm article in the App Engine documentation.

Posted by Wesley Chun, App Engine team

[Gd] Update to reporting service in AdWords API v201101

| More

AdWords API Blog: Update to reporting service in AdWords API v201101

Last week we announced AdWords API v201101, which included support for My Client Center (MCC) cross-client reports.

This feature did not go live as expected, so is currently only available to a limited set of developers. We hope to make it generally available in the coming weeks.

Please note that ReportDefinitionService will continue to work for non-cross-client reports as it did before.

If you have any questions please post them on the AdWords API forum.

Posted by Katie Wasilenko, AdWords API Team


[Gd] New demo launch: AdWords Command Line Interface (AWCLI)

| More

AdWords API Blog: New demo launch: AdWords Command Line Interface (AWCLI)

Today we’re releasing a new AdWords API sample application: AWCLI (AdWords Command Line Interface) intended to demonstrate a way for using the API. It’s a tool for AdWords interaction which was designed for power users and administrators to be able to inspect AdWords objects from a command line. It could also be used in various scripts and cron jobs.

The current code is work in progress. We’re sharing this code as open source to provide a starting point for new developers and to demonstrate some of the core functionality in the API.

AWCLI features
  • Shell-like command line interface with tab-completion.
  • Ability to list (ls), navigate (cd), retrieve (cat), edit (edit) and delete (rm) AdWords objects (campaigns, ad groups etc).
  • Search (find) function.
  • Local objects cache for easy referencing.
  • Environment (env), history (history) and other utility functions.

Getting AWCLI

AWCLI is available from the Google Code page and is part of AdWords Java API project. It can be obtained from the downloads page: You can find installation and running instructions as well as usage examples on the project wiki page.

Please join us to discuss the tool and report any bugs on the project page or forum.

- Danial Klimkin, AdWords API Team.

[Gd] Styling and skinning your apps with TravelTripper

| More

Google Web Toolkit Blog: Styling and skinning your apps with TravelTripper

There's more than one way to skin a GWT app. In this guest blog post, Erik Uzureau, User Experience Engineer at TravelTripper, shares their approach.


Styling/Skinning RezTrip

At TravelTripper, we make hotel reservation software. Our main product is a "booking engine" called RezTrip, a web based application that allows visitors of a hotel’s website to directly book a stay with that hotel.

As GWT applications go, we think RezTrip, when it comes to the question of styling, presents an interesting departure from traditional development. As a "white label" application, we needed to create our app in such a way that allows our hotel clients the ability to customize not only the "frame" around the application, but also the internal style of the application itself, such as fonts, colors, etc.

In other words, each hotel needs the ability to create their own custom header, footer, or sidebar and have it wrap the booking "application" portion of the page. Furthermore, each hotel needs to be able to change all the colors, fonts, and even some icons within the application.

The desired end result is a single booking engine application, running on multiple web sites, but always mimicking the look and feel of each individual hotel site.

We have two additional constraints:

  1. Cost - While our first priority is building a system with ultimate flexibility, the time spent to create each customization represents a direct bite into our profit margins. The business guys were explicit about keeping these costs to a minimum.

  2. Dynamic Changes - Clients are naturally picky about the appearance of their website, and their tailored booking engine is no exception. Experience told us that we would be fielding constant requests to tweak different aspects of the customized properties. This has to be easy to do and have minimal impact on the overall site performance.

Satisfying our Constraints

Keeping Costs Low

Our in-house GWT team is top-notch, but expensive. The previous version of our application was built on basic JSP/HTML/CSS technology, and the customization work had been done by a more affordable entry-level web designer. Similarly, for this version of the application, we wanted to limit the involvement of our GWT developers as much as possible, where possibly leaving stylistic tweaks to our web designer.

We want the customizer to be able to do *all* the work, without requiring any Java or GWT knowledge.

Making Changes Easy and Harmless

We realized that GWT's application compilation philosophy changed a lot of our longstanding web development assumptions. We didn't want to create custom UiBinder files for each hotel's frame, or have to make spot changes to CSS that would require a full recompile and redeployment of the application.

We want to be able to make CSS changes without recompiling or redeploying the app.

Our Solution

The only way to satisfy the above two constraints is to have all the customization work happen in simple HTML/CSS files that live outside the GWT project and WAR directory. This allows the customizer to work in pure HTML/CSS, directly with the files on the server, without ever having to modify the internals of the GWT application. Changes can take effect immediately, without a need to redeploy the app.

The Application Frame

We decided to have a separate index.html file for each property's customization. This allows custom header/footer/sidebar HTML, CSS and JavaScript to be included in the hotel's main page.

Another challenge for us was the need for the application portion of the booking engine to be able to be dynamically resized relative to the user's browser. To accomplish this, we decided to use a DockLayoutPanel, which handles the separation between the main application and the custom frame. We load an empty SimplePanel into each of the North, South, West, East sections of the DockLayoutPanel, and our application in the Center.

Next, we add special code that runs directly from onModuleLoad() that scours the host HTML document for four DIVs with 4 unique ids: tt-Header, tt-Footer, tt-EastSidebar, and tt-WestSidebar. If the app finds a DIV with those ids, it loads it into the corresponding SimplePanel and auto-sizes to the contents. If no corresponding DIV is found, the app hides the SimplePanel entirely and sets the width or height to 0.

What this means is, that the customizer doesn't get to lay out the HTML page exactly like it will be displayed when live. Instead s/he must smash the relevant content into the four qualified DIVs. This is a minor annoyance, but at the end of the day, the code itself is still the same basic HTML/CSS/JavaScript, and so it is perfectly manageable by the web designer. The GWT application is already compiled to super-fast JavaScript, so there's no need for the customizer to know any GWT. Instead, the customizer can just edit the contents in the HTML file and hit refresh to see the changes.


Here again, we had to come up with a custom solution. To avoid the recompile/redeploy issue and also to keep it simple for the customizer, we had to handle the CSS for customizing the application without having to modify any code inside the GWT project.

What we ended up doing was creating three levels of CSS:

  1. UiBinder - Any time we needed to use a CSS style to adjust the size or layout of a widget or panel, we kept that CSS code in UiBinder XML. We only want the actual GWT developers to change the layout/size of the UI elements, so they needed to be in a sense “hidden” from the customizer. We loved how the default UiBinder behaviour is to generate md5 class names, allowing us to create lots of custom CSS rules, without worrying about namespace overlap and also ensure that the customizer would know not to override them.

  2. master.css - Next, we created a "master" CSS file where we put all the other CSS styles, which we thought were fair game, to be overridden by the customizer. This is a huge CSS file, but when minimized (yuicompressor) and gzipped, the end result was still better than the latency hit we had when originally we tried to spread these across multiple files (for organizational purposes). Note that the master.css file is loaded directly from the main HTML file.

  3. designer.css - The final layer is the "designer" CSS, which is where we have the customizer put all the CSS rules which override the defaults. The class names in this file all match the class names in the master CSS, but since we load the designer CSS in the page *after* we load the master CSS, the former will always override the latter.


Despite our constraints, we were able to configure our GWT application to perform exactly as we desired. Our application is fully customizable, both in terms of the surrounding frame layout and also the internal application's colors and fonts, all without the customizer having to know any Java or GWT. By carefully separating the different layers of the app, we were able to make it easily and efficiently customizable on the fly, without ever having to redeploy the application.

Sample index.html File

<!DOCTYPE html>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">

<title>Paradise Hotel Reservation System</title>

<!-- Master CSS File -->
<!-- All styles in here can be overridden in designer.CSS (below) -->
<link rel="stylesheet" href="../reztrip/CSS/master.CSS" type="text/CSS"/>

<!-- Designer CSS File -->
<!-- Single css file to be created and modified by the customizer. -->
<!-- New styles for the frame and overridden style from master.CSS go here -->
<link rel="stylesheet" href="style/designer.CSS" type="text/CSS"/>

<script type="text/javascript" language="javascript"


<div id="tt-Header" class="tt-Frame-Header">
<!-- because tt-Header has content, we will load it and auto-size -->
<!-- it in the header area of the application frame -->

<table class="tt-Frame-HeaderTable">
      <img src="img/paradise_logo.png"></img>
      <img src="img/paradise_menu.png"></img>


<div id="tt-Footer" class="tt-Frame-Footer">
<!-- empty, so no footer will load -->

<div id="tt-EastSidebar" class="tt-Frame-EastSidebar">
<!-- empty, so no east sidebar will load -->

<div id="tt-WestSidebar" class="tt-Frame-WestSidebar">
<!-- empty, so no west sidebar will load -->

<!-- OPTIONAL: include this if you want history support -->
<iframe src="javascript:''" id="__gwt_historyFrame" tabIndex="-1"


Tuesday, March 8, 2011

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 11.0.696.0 for Windows, Macintosh, and Chrome Frame platforms

  • Updated V8 -
  • New “cookies and other data” page in tabbed settings (Issue 64154).
  • Turned confirm to quit on by default (Issue 60591)
  • Tweak the Tab Overview UI (Issue 50307)
  • Cloud Print connector UI enabled.
Known Issues
  • Regression: Can not select omnibox auto suggested entries by clicking at it (Issue 75366)
  • REGRESSION: Bookmark focus is not lost when moved away from the bookmark bar (Issue 75367)
More details about additional changes are available in the log of all revisions. You can find out about getting on the Dev channel here:

 If you find new issues, please let us know by filing a bug at
Karen Grunberg
Google Chrome

[Gd] Chrome Stable Release

| More

Google Chrome Releases: Chrome Stable Release

The Google Chrome team is excited to announce the arrival of Chrome 10.0.648.127 to the Stable Channel for Windows, Mac, Linux, and Chrome Frame.  Chrome 10 contains some really great improvements including:
  • New version of V8 - Crankshaft - which greatly improves javascript performance
  • New settings pages that open in a tab, rather than a dialog box
  • Improved security with malware reporting and disabling outdated plugins by default
  • Sandboxed Adobe Flash on Windows
  • Password sync as part of Chrome Sync now enabled by default
  • GPU Accelerated Video
  • Background WebApps
  • webNavigation extension API

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.

As can be seen, a few lower-severity issues were rewarded on account of being particularly interesting or clever. And some rewards were issued at the $1500 and $2000 level, reflecting bug reports where the reporter also worked with Chromium developers to provide an accepted patch.
  • [42574] [42765] Low Possible to navigate or close the top location in a sandboxed frame. Credit to sirdarckcat of the Google Security Team.
  • [Linux only] [49747] Low Work around an X server bug and crash with long messages. Credit to Louis Lang.
  • [Linux only] [66962] Low Possible browser crash with parallel print()s. Credit to Aki Helin of OUSPG.
  • [$1337] [69187] Medium Cross-origin error message leak. Credit to Daniel Divricean.
  • [$500] [69628] High Memory corruption with counter nodes. Credit to Martin Barbella.
  • [$1000] [70027] High Stale node in box layout. Credit to Martin Barbella.
  • [$500] [70336] Medium Cross-origin error message leak with workers. Credit to Daniel Divricean.
  • [$1000] [70442] High Use after free with DOM URL handling. Credit to Sergey Glazunov.
  • [Linux only] [70779] Medium Out of bounds read handling unicode ranges. Credit to miaubiz.
  • [$1337] [70877] High Same origin policy bypass in v8. Credit to Daniel Divricean.
  • [70885] [71167] Low Pop-up blocker bypasses. Credit to Chamal de Silva.
  • [$1000] [71763] High Use-after-free in document script lifetime handling. Credit to miaubiz.
  • [71788] High Out-of-bounds write in the OGG container. Credit to Google Chrome Security Team (SkyLined); plus subsequent independent discovery by David Weston of Microsoft and MSVR.
  • [$1000] [72028] High Stale pointer in table painting. Credit to Martin Barbella.
  • [73026] High Use of corrupt out-of-bounds structure in video code. Credit to Tavis Ormandy of the Google Security Team.
  • [$1000] [73066] High Crash with the DataView object. Credit to Sergey Glazunov.
  • [$1000] [73134] High Bad cast in text rendering. Credit to miaubiz.
  • [$2000] [73196] High Stale pointer in WebKit context code. Credit to Sergey Glazunov.
  • [73716] Low Leak of heap address in XSLT. Credit to Google Chrome Security Team (Chris Evans).
  • [$1500] [73746] High Stale pointer with SVG cursors. Credit to Sergey Glazunov.
  • [$1000] [74030] High DOM tree corruption with attribute handling. Credit to Sergey Glazunov.
  • [$1000] [74662] High Corruption via re-entrancy of RegExp code. Credit to Christian Holler.
  • [$1000] [74675] High Invalid memory access in v8. Credit to Christian Holler.
We would also like to thank Ben Hawkes of the Google Security Team, Sergey Glazunov, Martin Barbella and “temp01irc” for working with us during the development cycle and helping prevent bugs from ever reaching the stable channel.

Last, but not least, we’d like to offer special thanks (plus additional rewards to those listed above) to Christian Holler. This is for working with us on his grammar-based fuzzing project, resulting in a more stable and secure “Crankshaft” engine for v8.

More on what's new at the Official Chrome Blog.  You can find full details about the changes that are in Chrome 10 in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Jason Kersey
Google Chrome