Saturday, August 28, 2010

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

The beta channel for Chrome has been updated to 6.0.472.51 for all platforms. It contains many stability fixes, UI updates, and some additional translation work.

Interested in seeing all the changes? Check out the full svn revision log.

Change the release channel you are currently on.

Found a bug? Please let us know!

Jason Kersey
Google Chrome

Friday, August 27, 2010

[Gd] An update on JavaOne

| More

Google Code Blog: An update on JavaOne

Like many of you, every year we look forward to the workshops, conferences and events related to open source software. In our view, these are among the best ways we can engage the community, by sharing our experiences and learning from yours. So we’re sad to announce that we won't be able to present at JavaOne this year. We wish that we could, but Oracle’s recent lawsuit against Google and open source has made it impossible for us to freely share our thoughts about the future of Java and open source generally. This is a painful realization for us, as we've participated in every JavaOne since 2004, and I personally have spoken at all but the first in 1996.

We understand that this may disappoint and inconvenience many of you, but we look forward to presenting at other venues soon. We’re proud to participate in the open source Java community, and look forward to finding additional ways to engage and contribute.

By Joshua Bloch, Google Open Source Programs Office

[Gd] Expensify Accelerates Sign ups with the Provisioning API

| More

Google Apps Developer Blog: Expensify Accelerates Sign ups with the Provisioning API

Editor's Note: This post was written by Zhenya Grinshteyn and Tom Jacobs of Expensify. We invited Expensify to share their experience with the Google Apps Marketplace.

Expensify does expense reports that don't suck by importing expenses and receipts from your credit cards and mobile phones, submitting expense reports through email, and reimbursing online with QuickBooks and direct deposit.

The Foundation: Single Sign-On

We were really excited when Google approached us to be a launch partner for their new Google Apps Marketplace because tons of our customers use Google Apps -- including us! We have long wanted to put an 'Expenses' link up there next to Mail and Documents, and now we had our chance.

To do that, we installed the JanRain PHP OpenID library with the Google Apps Discovery extension. We’d already implemented Gmail OpenID and ironed out the kinks related to having multiple logins to a single account, so implementing this was a very straightforward process.

Lessons Learned

We quickly learned that while single sign-on is awesome, there was a high drop-off rate among admins installing Expensify into their domain. Digging deeper we determined it was due to the setup process being split: part of the setup was done from within Google Apps, but the final part had to be completed by signing in to our site. Not only that, a major part of the setup process was laboriously entering their employee’s emails. We decided to address each in turn by creating a setup wizard and importing the domain’s email list. We approached this change in two major ways:

First, when the Google Apps admin installs the Expensify application, we created a custom configuration step that creates what we call an 'expense policy'. This governs everything from who is part of the company, who can approve expenses, and ultimately who exports to QuickBooks to keep the general ledger in check. Previously this step had to be done after the application was already installed, usually when the admin first signed in. By making this step part of the install process, the entire setup felt much more intuitive and resulted in a higher completion rate.

Second, we used the Zend framework to connect to the Google Apps Provisioning API to fill the new expense policy with a list of all existing employees. This saved a ton of typing and resulted in a vast reduction in the time it took to deploy Expensify to the full company. With everything else in place, the code we used to do this looked something like this:
$oauthOptions = array(
'requestScheme' => Zend_Oauth::REQUEST_SCHEME_HEADER,
'version' => '1.0',
'signatureMethod' => 'HMAC-SHA1',
'consumerKey' => $CONSUMER_KEY,
'consumerSecret' => $CONSUMER_SECRET
$consumer = new Zend_Oauth_Consumer($oauthOptions);
$token = new Zend_Oauth_Token_Access();
$httpClient = $token->getHttpClient($oauthOptions);
$service = new Zend_Gdata_Gapps($httpClient, $domain );
$users = $service->retrieveAllUsers();
All of the users’ names and emails are presented in a table of employees that the person installing the app can use to set roles and quickly build an approval tree for all expenses.

Once the setup is completed, we automatically create accounts for all of the selected employees and send out a brief email with tips to get started.

Results: 3.5x more users sign up

Overall it was a fast and painless process, has increased the flow of high-quality leads, and has accelerated their rate of converting into real users. Domain admins now sign up 3.5x more users right away than they have been using the previous two-part setup! Feel free to install our app to see how the setup process works, and respond to this post with questions about your implementation -- we'll try to help out as best we can. And of course if you're still doing your expense reports the old sucky way, please come visit our website ( and we'd be happy to help ease your pain. Thanks for reading, let me know if there's anything I can help clarify!

Posted by Zhenya Grinshteyn, Expensify

Want to weigh in on this topic? Discuss on Buzz


[Gd] An Ingredients List for Testing - Part Two

| More

Google Testing Blog: An Ingredients List for Testing - Part Two

By James Whittaker

When are you finished testing? It’s the age old quality question and one that has never been adequately answered (other than the unhelpful answer of never). I argue it never will be answered until we have a definition of the size of the testing problem. How can you know you are finished if you don’t fully understand the task at hand?

Answers that deal with coverage of inputs or coverage of code are unhelpful. Testers can apply every input and cover every line of code in test cases and still the software can have very serious bugs. In fact, it’s actually likely to have serious bugs because inputs and code cannot be easily associated with what’s important in the software. What we need is a way to identify what parts of the product can be tested, a bill of materials if you will, and then map our actual testing back to each part so that we can measure progress against the overall testing goal.

This bill of materials represents everything that can be tested. We need it in a format that can be compared with actual testing so we know which parts have received enough testing and which parts are suspect.

We have a candidate format for this bill of materials we are experimenting with at Google and will be unveiling at GTAC this year.

[Gd] Chromium Graphics Overhaul

| More

Chromium Blog: Chromium Graphics Overhaul

For some time now, there’s been a lot of work going on to overhaul Chromium’s graphics system. New APIs and markup like WebGL and 3D CSS transforms are a major motivation for this work, but it also lets Chromium begin to take advantage of the GPU to speed up its entire drawing model, including many common 2D operations such as compositing and image scaling. As a lot of that work has been landing in tip-of-tree Chromium lately, we figured it was time for a primer.

At its core, this graphics work relies on a new process (yes, another one) called the GPU process. The GPU process accepts graphics commands from the renderer process and pushes them to OpenGL or Direct3D (via ANGLE). Normally, renderer processes wouldn’t be able to access these APIs, so the GPU process runs in a modified sandbox. Creating a specialized process like this allows Chromium’s sandbox to continue to contain as much as possbile: the renderer process is still unable to access the system’s graphics APIs, and the GPU process contains less logic.

With this basic piece of infrastructure, we’ve started accelerating some content in Chromium. A web page can naturally be divided into a number of more or less independent layers. Layers can contain text styled with CSS, images, videos, and WebGL or 2D canvases. Currently, most of the common layer contents, including text and images, are still rendered on the CPU and are simply handed off to the compositor for the final display. Other layers use the GPU to accelerate needed operations that touch a lot of pixels. Video layers, for example, can now do color conversion and scaling in a shader on the GPU. Finally, there are some layers that can be fully rendered on the GPU, such as those containing WebGL elements.

After these layers are rendered, there’s still a crucial last step to blend them all onto a single page as quickly as possible. Performing this last step on the CPU would have erased most of the performance gains achieved by accelerating individual layers, so Chromium now composites layers on the GPU when run with the --enable-accelerated-compositing flag.

If you’d like to read more about this work, take a look at this design doc which outlines Chromium’s accelerated compositing system. Over time, we’re looking into moving even more of the rendering from the CPU to the GPU to achieve impressive speedups.

Posted by Vangelis Kokkevis, Software Engineer

[Gd] JibJab + Google Site Search = more laughs

| More

Google Custom Search: JibJab + Google Site Search = more laughs

Today’s guest post comes from Chris Poe, Engineering Director at JibJab Media

The folks at JibJab are good at doing two things: Making people laugh and... Okay, so maybe weʼre REALLY good at one thing: Making people laugh. Finding the perfect birthday eCard for your friends and family has always been a priority for us here at JibJab. We all felt that search would be the perfect compliment to our existing browsing experience and then we discovered Google Site Search ... our wildest dreams were about to become reality.

Seriously. We get search functionality without having to build search functionality.

The beauty of Google Site Search is that it can all be done with a small addition to your web page markup and no change to the back end of your web application.

Using the PageMaps functionality Site Search provides, we are able to embed metadata in our web pages that will be returned in our Site Search query results. This lets us format the data you are looking for in a very JibJabby way.

With features like Autocompletions and Refinements (and the help of the big brains on the JibJab engineering team), we will be able to evolve the Site Search functionality on our site and help our users make people laugh for a long time to come.

Posted by: Chris Poe, Engineering Director at JibJab Media

Thursday, August 26, 2010

[Gd] Google Buzz API adds Track and some improvements

| More

Google Code Blog: Google Buzz API adds Track and some improvements

Let's say you're really interested in coffee and tea and would like to know every time someone talks about them. You've been able to do that for the web with Google Alerts. Now you will be able to do the same thing for Google Buzz with our latest feature: Track. Plus, you can restrict your search to a specific geographic area! This API will allow you to enter a search query and from then on receive any new public Google Buzz posts—in real time—that match that query. It uses PubSubHubbub, which is the same open standard used by our fire and garden hoses.

To start receiving updates, you only need to send a query to the track endpoint, subscribe to the returned link, and then start receiving updates. If you'd like to take it for a quick spin, simply subscribe to a track endpoint via Google Reader (which happens to support PubSubHubbub). For example, if you’d like to receive all the new public Google Buzz posts about coffee or tea, simply open Google Reader, click "Add a subscription," and paste in the following URL:

Two of our firehose partners, Gnip and SuperFeedr are already using this feature. Gnip was able to add the feature into their API aggregation service with only a couple hours of work; their service update should be live early next week.

We’re excited to see what you develop with this cool new feature. Please note that it’s experimental and we may make changes in response to its use.

Additionally, we’ve been looking for ways to make the development experience with the Google Buzz API easier. One of the things we think we can improve upon are error messages. So, over the next couple weeks we’ll be rolling out significantly improved error messaging.

For example, if you tried to read an activity without including the activity id before today, you’d receive an HTTP error code and nothing else. Starting today, you’d also get a detailed error message returned in the body of the response:

<errors xmlns="">
<location type="parameter">postId</location>
<internalReason>Post ID is required.</internalReason>

The count API we announced back in mid-July has been returning the the number of times a specified link was shared on Google Buzz. We have started including short links (e.g. in the count as well. Now you can specify the long link or any corresponding short link to get the total available count. This will give developers a much more complete count of links to a certain URL, however indirect.

Please visit the Google Buzz API documentation site for more details on these updates and swing by the Developer Forum if you have any questions.

By Ivaylo Popov, Google Buzz Team

[Gd] Demystifying the app ranking criteria in orkut

| More

Google Code Blog: Demystifying the app ranking criteria in orkut

Over the months, we’ve had many requests to explain the way we rank applications in the orkut directory. Developers often wonder why one of their very popular apps doesn’t appear as high up in the directory as they believe it should. Well, it’s not exactly magic but simple math, and we wanted to share with you how our algorithm works out the rankings.

As you’d expect, we rely heavily on stats that tell us not only the number of users who have installed your app but also the number of users who actively use it. The number of installations is further broken down into the number of weekly as well as total installs. We hope you’ll agree that counting the number of users who uninstall your app is also crucial, since that is an indication of which apps didn’t live up to user expectations in some way and could be improved, and we lower the ranking score by a few points to account for the weekly uninstalls.

However, it’s not enough to judge the popularity of an application by the number of its installations alone – how often it actually gets rendered is a definite index of how addictive, useful and well-designed it is, and you can surely expect us to feed those numbers back into the formula, too!

Besides these, we think apps that users find good enough to put up on their home page should be given some weight, thus the number of weekly renders of those apps in profile view figures into our calculations too. We then add one last parameter to this equation: a popularity index that is a function of the weekly renders of each app over the number of it’s total installations.

In short, the formula looks something like this:

Total Score = Base Score + Popularity Score

Base Score = Score (total installs) + Score (weekly installs, adjusted for weekly uninstalls) + Score (weekly renders in canvas and profile views)

Popularity Score = Score(weekly renders / total installs)

We hope this gives you a clue to the “mystery”. We look forward to hearing your comments and feedback on the forum!

By Prashant Tiwari and Tiago Silveira, orkut Team

[Gd] Gmail Contextual Gadgets: giving the gift of time

| More

Google Apps Developer Blog: Gmail Contextual Gadgets: giving the gift of time

Your users likely spend countless hours a week bouncing between their inbox and various business applications. However, they could be even more efficient if the correct information was presented to them and made actionable where they need it the most -- their inbox.

Gmail Contextual Gadgets enable this improved efficiency. As a developer, you need to create a small view of your application as a gadget and register a regular expression in your Google Apps Marketplace manifest file. If an email message in your customer’s mailbox matches the regular expression, your gadget appears below the e-mail and has access to the relevant email content. Contextual gadgets are just one step in helping your users eliminate the days when they need to open a new tab to look up a contact in their CRM system, fill out a time card, find more information out about a prospective customer from their LinkedIn profile or edit a project page. Gadgets on the Marketplace from Solve360, Harvest, Gist and Smartsheet already accomplish these use cases.

These companies and others have been successful in delivering rich features to their users with Gmail Contextual Gadgets. Read what they have to say:


“The holy grail of business applications and CRM in particular is to get staff to use them. Integrating valuable processes and best practices within email in such a contextual, non-obstructive way is nothing less than a breakthrough.”
- Steve Ireland, Solve360 President


“While some tout the virtues of relying less on email, that's a battle many have lost - multiple times. We live in our inboxes, so we should make business apps work inside them. Email is the horse, business apps are the cart.”
- Mark Mader, Smartsheet CEO


"So many actions and todos originate from emails. Today, with contextual gadgets, we deliver the user their timesheet so it's incredibly convenient for them to fill out."
- Danny Wen, Harvest Co-founder.

Head over to the Google Enterprise Blog if you want more detail on these applications.

Contextual Gadgets greatly accelerate user adoption by bringing the application directly to the user in context and in their normal work flow. Many great apps fail to gain user traction because they are separated from the normal workflow. Gmail Contextual Gadgets solve that problem for developers, and make it much easier for the end users to see the benefits.

If you think you’re ready to start saving time for the users of your application, then dive right into the Developer’s Guide for Gmail Contextual Gadgets. Since gadgets are based on the OpenSocial gadget specification, they’re developed in the technologies you’re already familiar with -- HTML, JavaScript and CSS. Get started now, and be sure to share what you build!

Posted by Ryan Boyd, Google Apps Marketplace Team

Want to weigh in on this topic? Discuss on Buzz


[Gd] Updated maven strategy for GWT

| More

Google Web Toolkit Blog: Updated maven strategy for GWT

As part of the GWT team's ongoing work to provide better maven support, we are now publishing GWT milestones and release candidates to the Google snapshot repository. GWT 2.1M3 is now available as version 2.1-SNAPSHOT. If you're using Spring Roo with GWT, you'll notice that the Roo-generated POMs for M3 still point to the SVN repo. For this milestone release, the GWT jars are available from both the SVN repo and the Google snapshot repo. Beginning with M4, we plan to use only the Google snapshot repo.

The GWT 2.1 release and minor point releases thereafter will be published to the maven central repository.

To use the Google snapshot repository, put this in your pom.xml:

<name>Google Maven Snapshot Repository</name>

[Gd] Google Apps Script Hackathon September 23rd in Mountain View

| More

Google Apps Developer Blog: Google Apps Script Hackathon September 23rd in Mountain View

We had a great time at the Google Apps Hackathon yesterday in Mountain View. There was a great turnout and lots of interest in doing it again. So, we have planned two more Hackathons in September.

If you want to learn more about Google Apps Script and meet the Apps Script team, here is your chance. We will be holding a Google Apps Script Hackathon in Mountain View, CA, on Thursday September 23rd from 2pm to 8pm.

After we cover the basics of Google Apps Script, you can code along with us as we build a complete script. You can also bring your own ideas and get some help from other hackers and the Apps Script team.

There will be food, drinks, wifi, power, and Apps Script experts available to help you throughout the day. See the event details here, and be sure to RSVP to reserve your slot.

NOTE: We are planning another weekend Hackathon in San Francisco on September 25th and 26th in partnership with the Techcrunch Disrupt conference. Watch this blog for more details.

Posted by Don Dodge, Google Apps Team

Want to weigh in on this topic? Discuss on Buzz


[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 7.0.503.0 for Windows, Mac and Chrome Frame; 7.0.503.1 for Linux.  Some of the updates:

  • [r56615] IP addresses typed into the omnibox now work when offline. (Issue: 39830)
  • More tweaks and polish to the Wrench menu (Issues 48679, 51643)
Chrome Frame
  • Many stability fixes
More details about additional changes are available in the svn revision log.  If you find new issues, please let us know by filing a bug.   Find out more about changing your Chrome channel.

Jason Kersey
Google Chrome

Wednesday, August 25, 2010

[Gd] GWT 2.1 Milestone 3 is now available

| More

Google Web Toolkit Blog: GWT 2.1 Milestone 3 is now available

Back in May, at Google IO, we announced an integration between VMware’s popular Spring framework for server-side development and GWT for the client-side. Since then we have been excited by the feedback and comments from customers building real world apps with this technology. In response to their feedback, and pushing towards delivering on our our promises form IO, we are very happy to announce release M3. Looking forward we expect our production quality, GA (general availability), drop to land in a few months.

Some key features included in this release are built-in history support in Activities and Places, relationship management within RequestFactory, and the ability to call instance methods on entities themselves. The overarching goal was to nail down the API and deliver on features and functionality that are vital to creating industry-grade business apps.

For the Spring Roo community, we're continuing to build-out the integrated stacks that we announced back at Google I/O. GWT 2.1 M3 includes a parallel Roo 1.1 M3 that will allow you to take advantage of all the features mentioned above. Also, in the spirit of co-operative and transparent development, you can find a full list of features and functionality over at Roo's issue tracker.

GWT 2.1 M3 is available on our Google Code download site. We’d love to hear your feedback and thoughts on this release, and our GWT Developer Forum would be the best place to post this information.


Tuesday, August 24, 2010

[Gd] Licensing Server News

| More

Android Developers Blog: Licensing Server News

It’s been reported that someone has figured out, and published, a way to hack some Android apps to bypass our new Android Market licensing server. We’ll be saying more on this, but there are a few points that deserve to be made right now:

  • The licensing service, while very young, is a significant step forward in terms of protection over the plain copy-protection facility that used to be the norm. In the how-to-pirate piece, its author wrote: “For now, Google’s Licensing Service is still, in my opinion, the best option for copy protection.”

  • The licensing service provides infrastructure that developers can use to write custom authentication checks for each of their applications. The first release shipped with the simplest, most transparent imaginable sample implementation, which was written to be easy to understand and modify, rather than security-focused.

  • Some developers are using this sample as-is, which makes their applications easier to attack. The attacks we’ve seen so far are also all on applications that have neglected to obfuscate their code, a practice that we strongly recommend. We’ll be publishing detailed instructions for developers on how to do this.

  • The number of apps that have migrated to the licensing server at this point in time is very small. It will grow, because the server is a step forward.

  • 100% piracy protection is never possible in any system that runs third-party code, but the licensing server, when correctly implemented and customized for your app, is designed to dramatically increase the cost and difficulty of pirating.

  • The best attack on pirates is to make their work more difficult and expensive, while simultaneously making the legal path to products straightforward, easy, and fast. Piracy is a bad business to be in when the user has a choice between easily purchasing the app and visiting an untrustworthy, black-market site.

Android Market is already a responsive, low-friction, safe way for developer to get their products to users. The licensing server makes it safer, and we will continue to improve it. The economics are already working for the developers and against the pirates, and are only going to tilt further in that direction.


[Gd] New Flock Browser Based On Chromium

| More

Chromium Blog: New Flock Browser Based On Chromium

Foreword: When we released Google Chrome almost two years ago, we also released the source code under an open-source license. Just as Firefox, WebKit, and other open source projects helped to drive the web forward, we wanted to follow suit and ensure that others could use the code we developed to make their products better. The Chromium codebase provides a complete browser to build on, so that if you want to focus on one particular piece, such as drastically changing the user interface, you can do that without having to worry about how to get amazing performance in the rest of the browser.

Recently, Flock released a new beta version of their browser built on top of the Chromium codebase. For those of us in the Chromium project, this is extremely exciting and encouraging. We believe that users having a choice between multiple browsers is a great thing, as it spurs innovation and competition, and lets users choose a browser that provides the best experience for them. Flock brings an innovative approach to their "social web browser," and we are glad to welcome them into the Chromium community. As part of that, we wanted to offer the team behind Flock an opportunity to talk about the ideas behind Flock, how Chromium helped them in achieving their goals, and their vision for the future. What follows is a perspective from Clayton Stark, VP Engineering at Flock.

When Flock began developing its first web browser five years ago, "the social web" was a small, niche market. Today social is the mainstream web, and this evolution in the market drove our development roadmap. With the new Flock browser, our engineering team focused on designing a straightforward and integrated social dashboard that delivers an experience simple enough for a mass audience. This is where the technology behind Chromium came into the picture for Flock. As Chromium emerged, we saw that not only was there significant improvements to performance, but also apparent was a simple and elegant user interface and architecture across all the various systems.

A core goal of new Flock is to keep our users in touch with all of their friends and feeds with a minimum of configuration, and at the same time, make it fun and simple. With all of the users’ feeds and social activity streams flowing into the scrolling sidebar, we knew the performance had to be first-rate, and that techniques we used for earlier versions of Flock were unlikely to perform at scale. With Chromium under the hood, we were able to leverage web workers, and that, combined with the raw horsepower of V8, allowed us to scale the use of the sidebar to manage very large data sets (in the first few weeks after the beta launched we saw a few hundred million activities flowing into Flock’s sidebar). Most importantly, benchmark testing shows us that New Flock with Chromium performs in the top-tier of all browsers available in the market.

Clearly the web is evolving very quickly, and we are seeing more and more people discovering content through their friends. The Flock team is energized by the big developments coming fast in this emerging, interest-graph-enabled web, and we have a roadmap in front of us that we are really excited about. The browsing platform needs to continue to mature at a rapid pace to support the dramatic changes in online user behavior. And, as it does, we already see the performance and power in Chromium that we need to allow us to focus on the innovations we want to bring forward, on top of the platform.

So, I’d like to send out a huge thanks on behalf of the Flock team to all those who have contributed to the Chromium project. Your work has made our project possible, and made new Flock our best release ever.

Clayton Stark, VP Engineering
Flock, Inc.

Posted by Ian Fette, Product Manager

Monday, August 23, 2010

[Gd] New in Google Chrome Beta: More Extension APIs, Free Hoodies

| More

Chromium Blog: New in Google Chrome Beta: More Extension APIs, Free Hoodies

Since we launched the Google Chrome extension system, one of the most frequent requests we’ve gotten is to add the ability to integrate with the context menu (the menu that pops up when you right-click on a link, image, or web page).

Now in Google Chrome Beta, developers can do just that. The new context menu API allows extension developers to register menu items for all pages or for a subset of pages. Developers can also register menu items for specific operations, like right-clicking on an image or movie. For example, you could create an extension that makes it easy for users to share interesting images from with their friends on Google Buzz.

Some users have lots of extensions installed. To help these users avoid ending up with gigantic unwieldy context menus, Google Chrome automatically groups multiple menu items from the same extension into a sub-menu.

We’d also like to announce two new experimental APIs. These APIs aren’t quite ready for prime-time yet, but we’re really excited about them and couldn’t wait to get your feedback.
  • The omnibox API allows extension developers to integrate with the browser’s omnibox. With this API, you can build custom search support for your favorite website, keyboard macros to automate tasks, or even a chat client right into the omnibox.
  • The infobars API allows extension developers to display infobars across the top of a tab. These infobars are built using normal HTML, so they can be heavily customized and interactive.
For the complete list of new extension APIs in Google Chrome beta, see the docs. And let us know if you make something cool. If we like it, we’ll send you a free extensions hoodie and may even feature you in the gallery.

We look forward to seeing what you come up with!

Posted by Aaron Boodman, Software Engineer