Thursday, August 18, 2011
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.
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
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.
Posted by Dave Wurtz, Product Manager, Google Web Fonts
Wednesday, August 17, 2011
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.
- 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.
- 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.
Posted by The App Engine Team
- A number of stability issues along with other bugs.
- Update ChromeVox with new version.
- Update the Netflix plugin to 1.1.4.
The Dev channel has been updated to 15.0.854.0 for Mac, Linux, and Chrome Frame. Windows will be updated soon.
- Updated V8 126.96.36.199
- [r96420] Fixed uninstalls for forced install extensions [Issue 86519]
- Fixed many known stability issues
- Unable to close tabs in Linux [Issue 93086]
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
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.
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 www.metmuseum.org/special/ as the top result, and its sitelinks are all from within the www.metmuseum.org/special section of the site. However, the rest of the results may be from other parts of the metmuseum.org domain, like store.metmuseum.org or blog.metmuseum.org/alexandermcqueen/about.
- 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.
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