Thursday, August 18, 2011

[Gd] GTAC Speakers and Attendees Finalized

| More

Google Testing Blog: GTAC Speakers and Attendees Finalized

We've completed the agenda for GTAC 2011 and are in the process of notifying accepted speakers and attendees. Once we have firm accepts we'll be publicizing the agenda.

[Gd] Native Client brings sandboxed native code to Chrome Web Store apps

| More

The official Google Code blog: Native Client brings sandboxed native code to Chrome Web Store apps

By Christian Stefansen, Native Client Team

Wouldn’t it be great if you could create web apps using your existing C and C++ code? Native Client lets you do just that, and it is now enabled for Chrome Web Store apps in Google Chrome’s beta channel.

Native Client apps live on the web platform, so you don’t need to create separate versions of your app for each operating system. Rather than relying on OS-specific APIs, Native Client apps use Pepper, a set of interfaces that provide C and C++ bindings to the capabilities of HTML5. This means that once you’ve ported your code to Native Client, it will work across different operating systems, and you only need to maintain one code base.

Today Native Client supports the Pepper APIs for 2D graphics, stereo audio, URL fetching, sandboxed local file access (File API), and asynchronous message passing to and from JavaScript. In future releases we will be adding support for hardware accelerated 3D graphics (OpenGL ES 2.0), fullscreen mode, networking (WebSockets and peer-to-peer connections), and much more. As new capabilities are added to HTML5 and Pepper, they will become available to Native Client.

This functionality does not come at the expense of security. To ensure that Native Client is as safe as JavaScript, Native Client code is isolated from the operating system by two nested security sandboxes: the Native Client sandbox and the Chrome sandbox. And unlike NPAPI plugins or ActiveX controls, Native Client apps do not have access to the underlying OS APIs.

We encourage you to start developing apps with Native Client. You can download the SDK and find tutorials, examples, API documentation, and our FAQ on the Native Client site. Once version 14 of Chrome hits stable channel, you’ll be able to upload your Native Client apps to the Chrome Web Store, where you can reach Chrome’s 160 million users.

The next milestone for Native Client is architecture independence: Portable Native Client (PNaCl) will achieve this by using LLVM bitcode as the basis for the distribution format for Native Client content, translating it to the actual target instruction set before running. Until then the Chrome Web Store will be the only distribution channel for Native Client apps. This will help us ensure that all Native Client apps are updated to PNaCl when it’s ready – and in the meantime avoid the spread of instruction set architecture dependent apps on the web. We’ll be providing updates on the progress of PNaCl on this blog.

Christian Stefansen is the Product Manager for Native Client. In his spare time, when he is not writing Native Client apps for fun, he likes playing tennis, playing the piano, and living as a travel writer in India for a couple of weeks at a time

Posted by Scott Knaster, Editor


[Gd] Vote Now! OpenSocial and Open Source Presentations at SXSW

| More

OpenSocial API Blog: Vote Now! OpenSocial and Open Source Presentations at SXSW

As a followup to our OpenSocial and SXSW Interactive 2012 post last month, we wanted to make available the links to the OpenSocial and associated technology proposals that have been submitted to the conference.

We would all greatly appreciate it if you could vote up these proposals to ensure that we have a technology presence at the conference next year, presenting the extensive new technology stack that is inherent within OpenSocial 2.0. There are a total of 3178 proposals in for this year and 30% of the decision-making process is up to community votes, so the more votes and comments we can get the better.

The proposals that we have available are:
If you have a proposal on the technology or features behind OpenSocial I'd be glad to add it into this blog post - please comment on this post with the details.

Thanks everyone.

Jonathan LeBlanc
Jonathan LeBlanc (@jcleblanc)

Jonathan LeBlanc is a principal developer evangelist with X.commerce. Jonathan has been a member of the OpenSocial community for over three years and is the author of O'Reilly's "Programming Social Applications".

[Gd] Help Improve Web Typography with ttfautohint

| More

Google Web Fonts: Help Improve Web Typography with ttfautohint

Deep in the systems layer of many computers lives the FreeType system for rendering text. This software powers Android and ChromeOS, iPhones and iPads, PalmOS, GNU/Linux computers like the OLPC XO, Fedora and Ubuntu, and even applications like the font editors FontForge and FontLab.

FreeType includes an excellent autohinting feature that ensures fonts are drawn cleanly on screen and display well at all sizes. But computers without FreeType, like Windows, cannot leverage these benefits and instead require hinting inside the font files themselves.

Hinting font files by hand is a slow process that requires a lot of both time and skill. Many web font designers can’t do it themselves, or afford third party services, so many web fonts have poor or even no hinting.

That’s why Google Web Fonts has supported Werner Lemberg’s project to build an autohinting system that could insert hints directly into TrueType Fonts: ttfautohint.

Google has helped get this project started, and our team believe the early results of the project are very promising. But it needs your support to continue. If you care about web typography and would like to see the quality of web fonts improve, including the Google Web Fonts you use today, please consider donating what you can.

$100 will go a long way to help the ttfautohint project reach its goals.

Visit Pledgie to donate now.

Click here to lend your support to: ttfautohint and make a donation at!

Posted by Dave Wurtz, Product Manager, Google Web Fonts

Wednesday, August 17, 2011

[Gd] App Engine 1.5.3 SDK Released

| More

Google App Engine Blog: App Engine 1.5.3 SDK Released

We’re pleased to announce another App Engine release today. You might have noticed that the rate of releases has gone up slightly in the past few months. We’ve made some changes internally so we are looking to push out a new release every month. This month includes a few Datastore updates, some changes to Blobstore API and Memcache API, and finally a new feature for the Java developers.

Python and Java Changes

  • Blobstore API - We’ve removed the limits on the size of blob uploads. You can now upload files of any size, allowing your app to serve images, video, or anything your internet connection can handle.

Datastore Changes

  • Index retrieval - We’ve added the ability for you to programmatically retrieve the list of indexes you’ve currently defined in the datastore, as well as their statuses.

  • Datastore Admin - You can now enable the Datastore Admin function from the Admin Console. This will allow Java users to make use of this functionality, like deleting all entities of a certain kind, without having to upload a Python version of their application. And for Python developers, you no longer need to enable this in your app.yaml file.

  • HRD Migration Trusted Testers - We are seeking early adopters to try out an improved HRD migration tool that requires a read-only period relative to your datastore write rate (as opposed to your datastore size, which is how the current version behaves). Please see the release notes for more information.

Python Updates

  • Memcache API - We now support the CAS (compare-and-swap) operation in our Python Memcache API (Java already had it). This can be used to update a value in Memcache only if no other requests have updated it between when the value was retrieved and when you go to update it.

  • Download app - Using the AppCfg download_app command, you can download any files that were uploaded from your war directory when you last updated the app version.

This release also contains small updates and bugfixes for both Python and Java so be sure to check out the full release notes. Feedback, discussion, and questions can be posted in our Google Group.

Posted by The App Engine Team

[Gd] Dev Channel Updates for Chromebooks

| More

Google Chrome Releases: Dev Channel Updates for Chromebooks

The Google Chrome team is happy to announce the release of Chrome 14.0.835.98 (Platform version: 811.47) on the Dev Channel for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).
  • A number of stability issues along with other bugs.
  • Update ChromeVox with new version.
  • Update the Netflix plugin to 1.1.4.
Known issues:
  • System reboots or stuck with black screen on closing and opening the lid quickly for few times (16922).
  • Feedback tool no longer finds existing screenshots (18227).
  • 3G activate successfully but with connection error (18875).

If you find new issues, please let us know by visiting our help site or filing a bug. You can also submit feedback using "Report an issue" under the wrench icon. Interested in switching to the Beta channel? Find out how.

Orit Mazor

Google Chrome

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

Update: Chrome for Windows has been push to Dev as 15.0.854.0

The Dev channel has been updated to 15.0.854.0 for Mac, Linux, and Chrome Frame. Windows will be updated soon.

  • Updated V8
  • [r96420] Fixed uninstalls for forced install extensions [Issue 86519]
  • Fixed many known stability issues
  • [r96518] Fixed import success message when user cancels the import [Issue 88947]
Known Issues
  • Unable to close tabs in Linux [Issue 93086]
Full details about what changes are in this build are available in the SVN revision log.  Interested in switching to the Beta or Stable channels?  Find out how.  If you find a new issue, please let us know by filing a bug.

Dharani Govindan
Google Chrome

[Gd] Pretotyping: A Different Type of Testing

| More

Google Testing Blog: Pretotyping: A Different Type of Testing

Have you ever poured your heart and soul and blood, sweat and tears to help test and perfect a product that, after launch, flopped miserably? Not because it was not working right (you tested the snot out of it), but because it was not the right product.

Are you currently wasting your time testing a new product or feature that, in the end, nobody will use?

Testing typically revolves around making sure that we have built something right. Testing activities can be roughly described as “verifying that something works as intended, or as specified.” This is critical. However, before we take steps and invest time and effort to make sure that something built right, we should make sure that the thing we are testing, whether its a new feature or a whole new product, is the right thing to build in the first place.

Spending time, money and effort to test something that nobody ends up using is a waste of time.

For the past couple of years, I’ve been thinking about, and working on, a concept called pretotyping.

What is pretotyping? Here’s a somewhat formal definition – the dry and boring kind you’d find in a dictionary:

Pretotyping [pree-tuh-tahy-ping], verb: Testing the initial appeal and actual usage of a potential new product by simulating its core experience with the smallest possible investment of time and money.

Here’s a less formal definition:

Pretotyping is a way to test an idea quickly and inexpensively by creating extremely simplified, mocked or virtual versions of that product to help validate the premise that "If we build it, they will use it."

My favorite definition of pretotyping, however, is this:

Make sure – as quickly and as cheaply as you can – that you are building the right it before you build it right.

My thinking on pretotyping evolved from my positive experiences with Agile and Test Driven Development. Pretotyping applies some of the core ideas from these two models and applies them further upstream in the development cycle.

I’ve just finished writing the first draft of a booklet on pretotyping called “Pretotype It”:

You can download a PDF of the booklet from Google Docs or Scribd.

The "Pretotype It" booklet is itself a pretotype and test. I wrote this first-draft to test my (possibly optimistic) assumption that people would be interested in it, so please let me know what you think of it.

You can follow my pretotyping work on my pretotyping blog.

Post contentPosted by Alberto Savoia

Tuesday, August 16, 2011

[Gd] Introducing new and improved sitelinks

| More

Official Google Webmaster Central Blog: Introducing new and improved sitelinks

Webmaster level: All

This week we launched an update to sitelinks to improve the organization and quality of our search results. Sitelinks are the two columns of links that appear under some search results and ads that help users easily navigate deeper into the site. Sitelinks haven’t changed fundamentally: they’re still generated and ranked algorithmically based on the link structure of your site, and they’ll only appear if useful for a particular query.

Sitelinks before today’s changes

Here’s how we’ve improved sitelinks with today’s launch:

  • Visibility. The links have been boosted to full-sized text, and augmented with a green URL and one line of text snippet, much like regular search results. This increases the prominence of both the individual sitelinks and the top site overall, making them easier to find.

  • Flexibility. Until now, each site had a fixed list of sitelinks that would either all appear or not appear; there was no query-specific ranking of the links. With today’s launch, sitelink selection and ranking can change from query to query, allowing more optimized results. In addition, the maximum number of sitelinks that can appear for a site has been raised from eight to 12, and the number shown also varies by query.

  • Clarity. Previously, pages from your site could either appear in the sitelinks, in the regular results, or both. Now we’re making the separation between the top domain and other domains a bit clearer. If sitelinks appear for the top result, then the rest of the results below them will be from other domains. One exception to this is if the top result for a query is a subpart of a domain. For instance, the query [the met exhibitions] has as the top result, and its sitelinks are all from within the section of the site. However, the rest of the results may be from other parts of the domain, like or

  • Quality. These user-visible changes are accompanied by quality improvements behind the scenes. The core improvement is that we’ve combined the signals we use for sitelinks generation and ranking -- like the link structure of your site -- with our more traditional ranking system, creating a better, unified algorithm. From a ranking perspective, there’s really no separation between “regular” results and sitelinks anymore.

Sitelinks after today’s changes

These changes are also reflected in Webmaster Tools, where you can manage the sitelinks that appear for your site. You can now suggest a demotion to a sitelink if it’s inappropriate or incorrect, and the algorithms will take these demotions into account when showing and ranking the links (although removal is not guaranteed). Since sitelinks can vary over time and by query, it no longer makes sense to select from a set list of links -- now, you can suggest a demotion of any URL for any parent page. Up to 100 demotions will be allowed per site. Finally, all current sitelink blocks in Webmaster Tools will automatically be converted to the demotions system. More information can be found in our Webmaster Tools Help Center.

It’s also worth mentioning a few things that haven’t changed. One-line sitelinks, where sitelinks can appear as a row of links on multiple results, and sitelinks on ads aren’t affected. Existing best practices for the link structure of your site are still relevant today, both for generating good quality sitelinks and to make it easier for your visitors. And, as always, you can raise any questions or comments in our Webmaster Help Forum.

Written by Harvey Jones, Software Engineer, & Raj Krishnan, Product Manager, Sitelinks team

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

The Beta channel has been updated to 14.0.835.94 for Windows, Mac, Linux, and Chrome Frame.  This release contains fixes for a number of stability issues along with other bugs.  Full details about what changes are in this build are available in the SVN revision log.  Interested in switching to the Beta channel?  Find out how.  If you find a new issue, please let us know by filing a bug.

Jason Kersey
Google Chrome