Googland [dev]

[Gd] Dev Channel Update for Chromebooks

2012-01-27T23:50:00.001-08:00

Chrome Releases: Dev Channel Update for Chromebooks

The Dev channel has been updated to 18.0.1017.3 (Platform versions: 1625.0.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

This build contains a number of performance, stability and security improvements. Additional changes:

Fixes to login problems that users may have encountered on machines that were shipped with versions R11 and earlier.
Updated Pepper flash version.

Known issues:

25557 & 25559 - Hangouts will not display video of yourself or participants on Chromebooks. Audio does work, and other Hangout participants will be able to see you if video is enabled. This problem does not affect GTalk Video.
25509 - Occasionally when switching tabs, the screen will not redraw the content to the new tab. Workaround: Closing all tabs or restarting the machine resolves the issue.

If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu.

Danielle Drew
Google Chrome

URL: http://googlechromereleases.blogspot.com/2012/01/dev-channel-update-for-chromebooks_27.html

[Gd] Fridaygram: faster web, stronger machines, prettier planet

2012-01-27T16:39:00.001-08:00

The official Google Code blog: Fridaygram: faster web, stronger machines, prettier planet

By Scott Knaster, Google Code Blog Editor

Everybody likes a faster web, and that theme has been evident this week here on Google Code Blog. On Monday, Yuchung Cheng wrote about Google’s research into making TCP faster through various proposals and experiments. Yesterday, Roberto Peon and Will Chan blogged about SPDY (pronounced speedy), Google’s protocol for speeding up the web’s application layer historically handled by HTTP. In related news this week, the chairman of the HTTPbis Working Group announced support for SPDY in a public post.

At Google, these projects are part of our Make the Web Faster initiative, although TCP improvements and SPDY are efforts of the whole community. Even if you’re not working on TCP or SPDY, you can find lots of useful resources at our Make the Web Faster site. For example, there are articles on compression, caching, metrics, and more, a set of tools for measuring and optimizing pages, and several discussion forums for communicating with other interested folks.

Sometimes stronger is more important than faster. Scientists looking to improve the durability of machinery have been studying the yellow fattail scorpion, which uses bumps on its back to resist damage from sandstorms. Researchers hope to use the scorpion’s design to create erosion-resistant surfaces for blades, pipes, and similar parts. Or maybe they’ll make machines that look like giant yellow scorpions.

Finally, take a step back from everything on Earth and have a look at NASA’s latest "Blue Marble" images of our planet. We have a beautiful home.

Let’s say this fast: Fridaygram posts are just for fun. Fridaygrams are designed for your Friday afternoon and weekend enjoyment. Each Fridaygram item must pass only one test: it has to be interesting to us nerds. That definitely includes speed, space, and scorpions.

URL: http://googlecode.blogspot.com/2012/01/fridaygram-faster-web-stronger-machines.html

[Gd] Making the web speedier and safer with SPDY

2012-01-27T04:18:00.001-08:00

Chromium Blog: Making the web speedier and safer with SPDY

In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web.

Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search. Given that Google search results are some of the most highly optimized pages on the internet, this was a surprising and welcome result.

We’ve also seen widespread community uptake and participation. Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we're actively working on a full featured mod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.

Given SPDY's rapid adoption rate, we’re working hard on acceptance tests to help validate new implementations. Our best practices document can also help website operators make their sites as speedy as possible.

With the help of Mozilla and other contributors, we’re pushing hard to finalize and implement SPDY draft-3 in early 2012, as standardization discussions for SPDY will start at the next meeting of the IETF.

We look forward to working even closer with the community to improve SPDY and make the Web faster!

To learn more about SPDY, see the link to a Tech Talk here, with slides here.

Posted by Roberto Peon and Will Chan, Software Engineers

URL: http://blog.chromium.org/2012/01/making-web-speedier-and-safer-with-spdy.html

[Gd] More Options for Google+ Badges

2012-01-26T23:47:00.003-08:00

Official Google Webmaster Central Blog: More Options for Google+ Badges

Webmaster Level: All

When we launched Google+ pages in November, we also released Google+ badges to promote your Google+ presence right on your site. Starting today in developer preview (and soon available to all your users), we're adding more options for integrating the Google+ badge into your website. You can configure a badge with a width that fits your site design and choose a version that works better on darker sites. You'll also see that Google+ badges now include the unified +1 and circle count that we added to Pages last month.

If you’re still considering whether to add a Google+ badge on your website, consider this: We recently looked at top sites using the badge and found that, on average, the badge accounted for an additional 38% of followers. When you add the badge visitors to your website can discover your Google+ page and connect in a variety of ways: they can follow your Google+ page, +1 your site, share your site with their circles, see which of their friends have +1’d your site, and click through to visit your Google+ page.

The Google+ Badge makes it easy for your fans to find and follow you on Google+. With these additional options, we hope it's even easier to create a badge that fits your website.

Follow the conversation on Google+.

Posted by Lucy Hadden, Software Engineer, Google+

URL: http://googlewebmastercentral.blogspot.com/2012/01/new-google-badges.html

[Gd] What’s new with Sitemaps

2012-01-26T23:47:00.001-08:00

Official Google Webmaster Central Blog: What’s new with Sitemaps

Webmaster level: All

Sitemaps are a way to tell Google about pages on your site. Webmaster Tools’ Sitemaps feature gives you feedback on your submitted Sitemaps, such as how many Sitemap URLs have been indexed, or whether your Sitemaps have any errors. Recently, we’ve added even more information! Let’s check it out:

The Sitemaps page displays details based on content-type. Now statistics from Web, Videos, Images and News are featured prominently. This lets you see how many items of each type were submitted (if any), and for some content types, we also show how many items have been indexed. With these enhancements, the new Sitemaps page replaces the Video Sitemaps Labs feature, which will be retired.

Another improvement is the ability to test a Sitemap. Unlike an actual submission, testing does not submit your Sitemap to Google as it only checks it for errors. Testing requires a live fetch by Googlebot and usually takes a few seconds to complete. Note that the initial testing is not exhaustive and may not detect all issues; for example, errors that can only be identified once the URLs are downloaded are not be caught by the test.

In addition to on-the-spot testing, we’ve got a new way of displaying errors which better exposes what types of issues a Sitemap contains. Instead of repeating the same kind of error many times for one Sitemap, errors and warnings are now grouped, and a few examples are given. Likewise, for Sitemap index files, we’ve aggregated errors and warnings from the child Sitemaps that the Sitemap index encloses. No longer will you need to click through each child Sitemap one by one.

Finally, we’ve changed the way the “Delete” button works. Now, it removes the Sitemap from Webmaster Tools, both from your account and the accounts of the other owners of the site. Be aware that a Sitemap may still be read or processed by Google even if you delete if from Webmaster Tools. For example if you reference a Sitemap in your robots.txt file search engines may still attempt to process the Sitemap. To truly prevent a Sitemap from being processed, remove the file from your server or block it via robots.txt.

For more information on Sitemaps in Webmaster Tools and how Sitemaps work, visit our Help Center. If you have any questions, go to Webmaster Help Forum.

Written by Kamila Primke, Software Engineer, Webmaster Tools

URL: http://googlewebmastercentral.blogspot.com/2012/01/whats-new-with-sitemaps.html

[Gd] Reading Query Results from Calendar in Pages

2012-01-26T16:52:00.003-08:00

Google Apps Developer Blog: Reading Query Results from Calendar in Pages

What’s the difference between reality and theory? In theory, there is no difference. But reality often imposes unanticipated constraints on developers. These may come in the form of bandwidth restrictions, memory limits, timeouts, or other requirements of the systems that interact with your application.

My team recently built an application that helps us analyze the scheduling and usage of conference rooms at Google. We use the new Calendar API v3 on Google App Engine to read the rooms’ schedules, which we combine with actual occupancy data to calculate utilization and other metrics.

As you might imagine, Google has a lot of conference rooms (I believe the last official count was “more than twelve.”) And many of the rooms seem to be booked fairly solid. That means we need to read a lot of data from Calendar. So much, in fact, that our queries time out if we try to read an entire calendar at once. But the API team anticipated “Google scale” use and designed a mechanism that allows us to retrieve data in batches.

The idea is simple. When you create a request, you specify the page size: the maximum number of results you’d like Calendar to return in one batch. Calendar returns the data you requested, along with an opaque page token, which you can think of as a bookmark. To retrieve the next batch of data, you ask the API for the next page token and include the new token in your next request. The page token keeps track of the results you’ve already seen, so Calendar can send the next batch each time. You repeat this process until you’ve exhausted all the results.

Here’s how we did this in Java:


public void getRoomEvents(String roomEmail) throws IOException {
    // Create a request to list this room’s events (see code, below)
    Calendar.Events.List listRequest = getListRequest(roomEmail);
    do {
      // Retrieve one page of events
      Events events = executeListRequest(listRequest);
      List eventList = events.getItems();

      // Process each event
      for (Event event : eventList) {
        processEvent(event);
      }

      // Update the page token
      listRequest.setPageToken(events.getNextPageToken());

    // Stop when all results have been retrieved
    } while (listRequest.getPageToken() != null);
  }

  // Create a request to list the events for a room
  private Calendar.Events.List getListRequest(String roomEmail)
        throws IOException {
    return calendarClient.events().list(roomEmail)
        .setMaxResults(1000) // Limit each response to 1000 events
        .setPageToken(null)  // Start with the first page of results
        // Return an individual event for each instance occurrence of a
        // recurring event
        .setSingleEvents(true); 
  }

We call getRoomEvents() for each room, using the room’s email address to identify it to Calendar. (You can retrieve events from your own calendar by substituting your own email address.) Then getListRequest() creates a request that we will send to Calendar. The request asks for a list of up to 1000 events from the room’s calendar.

The remainder of getRoomEvents() is a loop that executes the request, processes the results, and updates the page token in preparation for the next request. The loop continues, retrieving and processing each subsequent page of results, until the entire list has been returned. The call to getNextPageToken() indicates the end of the results by returning a null value.

By paginating our requests we avoid timeouts and reduce memory requirements. As an added benefit, each request completes fairly quickly, which means it’s also quick to retry if an error should occur. And finally, a multithreaded application may be able to process one or more pages of results while it retrieves the next, speeding execution. These advantages have led developers at Google to adopt pagination as a best practice. Look for it in our APIs when you need to exchange large amounts of data, and consider adding it to your own services.

If you have questions about our services or APIs, or if you want to see what other developers are doing with Google Calendar, check the discussions and documentation in the Google Apps Calendar API forum.

Adam Liss profile

Adam is an engineer who believes that "technical" shouldn't necessarily mean "difficult." He enjoys building infrastructure and tools that make Googlers more productive. Before joining Google in 2010, he built network-security appliances and one of the first wireless application delivery platforms.

URL: http://googleappsdeveloper.blogspot.com/2012/01/reading-query-results-from-calendar-in.html

[Gd] My summer with the Google App Engine Team

2012-01-26T16:52:00.001-08:00

Google App Engine Blog: My summer with the Google App Engine Team

Today’s post is contributed by our Summer 2011 team intern, Chris Bunch. Chris did some great work on our Logs and MapReduce APIs and is also the first “App Engine Triple Crown” winner for developing the Experimental Logs Reader API in Python, Java and Go simultaneously.

Four years ago, I was a brand-new Ph.D. student at the University of California, Santa Barbara and when our research group (the RACELab) heard about Google App Engine, we were intrigued. We thought it presented a new model that enabled apps to scale the right way without severely constricting the types of programs users would write.

But we wanted to experiment with the core functionality of App Engine: the APIs, the scheduler, etc., and so we built AppScale, an open-source implementation of the Google App Engine APIs that allows users to deploy applications written in Python, Java, and Go to the infrastructure of their choice.

Wherever possible, we implement support for the App Engine APIs with alternative open-source technologies. We’ve added support for nine different databases, database-agnostic transactions, a REST interface that users of any programming language can communicate with (via an App Engine app), and the ability to run high performance computing programs over the whole thing and talk to it from your App Engine app. And here’s my favorite part - it all deploys automatically! You don’t need to tell it what block size you want for the distributed file system, or the size of the read buffers: we configure the necessary services automatically. Since AppScale is completely open source, if you don’t like the defaults, change them!

After creating our own system to run Google App Engine apps, I wanted to see how Google does it. Therefore, I decided to become an intern on the App Engine team and see if I could give them (and by extension, the App Engine community) something amazing over the summer. I started off with some work on the MapReduce API, making the sample app much easier to use and prettier all around. I also made a YouTube video showing how it all works and how easy it is to run MapReduce jobs over App Engine.

I then looked at a recurring question that App Engine users encounter: “How can I get my logging information for my application to answer data analytic questions?” It was an excellent problem to tackle, as we have users who want to be able to determine application-specific queries that Google Analytics or the Admin Console don’t answer. Currently users have to use appcfg to grab all their application’s data to a remote machine and run some analysis script over it.

To solve this problem, I created the Logs API, which gives applications programmatic access to their logs from within App Engine itself. Applications can use it to query small numbers of logs within a single request, and they can utilize the Pipeline, MapReduce, or Backends APIs if they have lots of logs they want to analyze. Logs contain both request-level information (e.g., the URL accessed, the HTTP response code returned) as well as logging info generated by the application (the logging module in Python, the Logger class in Java, and the logging methods that Go’s appengine package provides). The Logs API is available for use as of App Engine 1.6.1 by programmers using the Python, Java, or Go runtimes, in both the production environment and the local SDK.

I had a great time putting the Logs API together, and had a unique experience interning with the App Engine team. Programming in Python, Java, and Go on a daily basis was an exciting new challenge, and I loved it!

Interested in interning with the App Engine team? Check out google.com/students for more information on internships.

URL: http://googleappengine.blogspot.com/2012/01/my-summer-with-google-app-engine-team.html

[Gd] Say Goodbye to the Menu Button

2012-01-26T13:08:00.001-08:00

Android Developers Blog: Say Goodbye to the Menu Button

[This post is by Scott Main, lead tech writer for developer.android.com. — Tim Bray]

Before Android 3.0 (Honeycomb), all Android-powered devices included a dedicated Menu button. As a developer, you could use the Menu button to display whatever options were relevant to the user, often using the activity’s built-in options menu. Honeycomb removed the reliance on physical buttons, and introduced the ActionBar class as the standard solution to make actions from the user options immediately visible and quick to invoke. In order to provide the most intuitive and consistent user experience in your apps, you should migrate your designs away from using the Menu button and toward using the action bar. This isn’t a new concept — the action bar pattern has been around on Android even before Honeycomb — but as Ice Cream Sandwich rolls out to more devices, it’s important that you begin to migrate your designs to the action bar in order to promote a consistent Android user experience.

You might worry that it’s too much work to begin using the action bar, because you need to support versions of Android older than Honeycomb. However, it’s quite simple for most apps because you can continue to support the Menu button on pre-Honeycomb devices, but also provide the action bar on newer devices with only a few lines of code changes.

If I had to put this whole post into one sentence, it’d be: Set targetSdkVersion to 14 and, if you use the options menu, surface a few actions in the action bar with showAsAction="ifRoom".

Don’t call it a menu

Not only should your apps stop relying on the hardware Menu button, but you should stop thinking about your activities using a “menu button” at all. Your activities should provide buttons for important user actions directly in the action bar (or elsewhere on screen). Those that can’t fit in the action bar end up in the action overflow.

In the screenshot here, you can see an action button for Search and the action overflow on the right side of the action bar.

Even if your app is built to support versions of Android older than 3.0 (in which apps traditionally use the options menu panel to display user options/actions), when it runs on Android 3.0 and beyond, there’s no Menu button. The button that appears in the system/navigation bar represents the action overflow for legacy apps, which reveals actions and user options that have “overflowed off the screen.”

This might seem like splitting hairs over terminology, but the name action overflow promotes a different way of thinking. Instead of thinking about a menu that serves as a catch-all for various user options, you should think more about which user options you want to display on the screen as actions. Those that don't need to be on the screen can overflow off the screen. Users can reveal the overflow and other options by touching an overflow button that appears alongside the on-screen action buttons.

Action overflow button for legacy apps

If you’ve already developed an app to support Android 2.3 and lower, then you might have noticed that when it runs on a device without a hardware Menu button (such as a Honeycomb tablet or Galaxy Nexus), the system adds the action overflow button beside the system navigation.

This is a compatibility behavior for legacy apps designed to ensure that apps built to expect a Menu button remain functional. However, this button doesn’t provide an ideal user experience. In fact, in apps that don’t use an options menu anyway, this action overflow button does nothing and creates user confusion. So you should update your legacy apps to remove the action overflow from the navigation bar when running on Android 3.0+ and begin using the action bar if necessary. You can do so all while remaining backward compatible with the devices your apps currently support.

If your app runs on a device without a dedicated Menu button, the system decides whether to add the action overflow to the navigation bar based on which API levels you declare to support in the <uses-sdk> manifest element. The logic boils down to:

If you set either minSdkVersion or targetSdkVersion to 11 or higher, the system will not add the legacy overflow button.
Otherwise, the system will add the legacy overflow button when running on Android 3.0 or higher.
The only exception is that if you set minSdkVersion to 10 or lower, set targetSdkVersion to 11, 12, or 13, and you do not use ActionBar, the system will add the legacy overflow button when running your app on a handset with Android 4.0 or higher.

That exception might be a bit confusing, but it’s based on the belief that if you designed your app to support pre-Honeycomb handsets and Honeycomb tablets, it probably expects handset devices to include a Menu button (but it supports tablets that don’t have one).

So, to ensure that the overflow action button never appears beside the system navigation, you should set the targetSdkVersion to 14. (You can leave minSdkVersion at something much lower to continue supporting older devices.)

Migrating to the action bar

If you have activities that use the options menu (they implement onCreateOptionsMenu()), then once the legacy overflow button disappears from the system/navigation bar (because you’ve set targetSdkVersion to 14), you need to provide an alternative means for the user to access the activity’s actions and other options. Fortunately, the system provides such a means by default: the action bar.

Add showAsAction="ifRoom" to the <item> elements representing the activity’s most important actions to show them in the action bar when space is available. For help deciding how to prioritize which actions should appear in the action bar, see Android Design’s Action Bar guide.

To further provide a consistent user experience in the action bar, we suggest that you use action icons designed by the Android UX Team where appropriate. The available icons support common user actions such as Refresh, Delete, Attach, Star, Share and more, and are designed for the light and dark Holo themes. Here they are!

If these icons don’t accommodate your needs and you need to create your own, you should follow the Iconography design guide.

Removing the action bar

If you don’t need the action bar, you can remove it from your entire app or from individual activities. This is appropriate for apps that never used the options menu or for apps in which the action bar doesn’t meet design needs (such as games). You can remove the action bar using a theme such as Theme.Holo.NoActionBar or Theme.DeviceDefault.NoActionBar.

In order to use such a theme and remain backward compatible, you can use Android’s resource system to define different themes for different platform versions, as described by Adam Powell’s post, Holo Everywhere. All you need is your own theme, which you define to inherit different platform themes depending on the current platform version.

For example, here’s how you can declare a custom theme for your application:

<application android:theme="@style/NoActionBar">

Or you can instead declare the theme for individual <activity> elements.

For pre-Honeycomb devices, include the following theme in res/values/themes.xml that inherits the standard platform theme:

<resources>
    <style name="NoActionBar" parent="@android:style/Theme">
        <!-- Inherits the default theme for pre-HC (no action bar) -->
    </style>
</resources>

For Honeycomb and beyond, include the following theme in res/values-v11/themes.xml that inherits a NoActionBar theme:

<resources>
    <style name="NoActionBar" parent="@android:style/Theme.Holo.NoActionBar">
        <!-- Inherits the Holo theme with no action bar; no other styles needed. -->
    </style>
</resources>

At runtime, the system applies the appropriate version of the NoActionBar theme based on the system’s API version.

Summary

Android no longer requires a dedicated Menu button, some devices don’t have one, and you should migrate away from using it.
Set targetSdkVersion to 14, then test your app on Android 4.0.
Add showAsAction="ifRoom" to menu items you’d like to surface in the action bar.

If the ActionBar doesn’t work for your app, you can remove it with Theme.Holo.NoActionBar or Theme.DeviceDefault.NoActionBar.

For information about how you should design your action bar, see Android Design’s Action Bar guide. More information about implementing the action bar is also available in the Action Bar developer guide.

URL: http://android-developers.blogspot.com/2012/01/say-goodbye-to-menu-button.html

[Gd] Making the web speedier and safer with SPDY

2012-01-26T13:07:00.001-08:00

The official Google Code blog: Making the web speedier and safer with SPDY

Will

Roberto

By Roberto Peon and Will Chan, Software Engineers

Cross-posted with the Chromium Blog

In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web.

Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search. Given that Google search results are some of the most highly optimized pages on the internet, this was a surprising and welcome result.

We’ve also seen widespread community uptake and participation. Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we're actively working on a full featured mod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.

Given SPDY's rapid adoption rate, we’re working hard on acceptance tests to help validate new implementations. Our best practices document can also help website operators make their sites as speedy as possible.

With the help of Mozilla and other contributors, we’re pushing hard to finalize and implement SPDY draft-3 in early 2012, as standardization discussions for SPDY will start at the next meeting of the IETF.

We look forward to working even more closely with the community to improve SPDY and make the Web faster!

To learn more about SPDY, see the link to a Tech Talk here, with slides here.

Roberto Peon and Will Chan co-lead the SPDY effort at Google. Roberto leads SPDY server efforts and continues to tell people to be unafraid of trying to change the world for the better. Will works on the Chrome network stack and leads the Chrome SPDY efforts. Outside of work, Will enjoys traveling the world in search of cheap beer and absurd situations.

Posted by Scott Knaster, Editor

URL: http://googlecode.blogspot.com/2012/01/making-web-speedier-and-safer-with-spdy.html

[Gd] Beta Channel Update for Chromebooks

2012-01-26T03:18:00.003-08:00

Chrome Releases: Beta Channel Update for Chromebooks

The Beta channel has been updated to 17.0.963.43 (Platform versions: 1412.142) for Chromebooks (Samsung Series 5 , and Cr-48).

Highlights:

This update fixes a number of stability and UI issues.
Introduces new Verizon activation and top-up portal featuring many user-requested improvements:

Enables recurring billing as the default for pre-paid monthly plans
Greatly simplifies the Verizon activation and top-up process
Allows purchase of additional data prior to current bundle expiration
Eliminates credit card requirement for free 100MB plan

URL: http://googlechromereleases.blogspot.com/2012/01/beta-channel-update-for-chromebooks_25.html

[Gd] Beta Channel Update

2012-01-26T03:18:00.001-08:00

Chrome Releases: Beta Channel Update

The Beta channel has been updated to 17.0.963.44 for all platforms other than Chrome OS. This update fixes a number of stability and UI issues. Full details about what changes are in this build are available in the SVN revision log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.

Jason Kersey
Google Chrome

URL: http://googlechromereleases.blogspot.com/2012/01/beta-channel-update_25.html

[Gd] Making form-filling faster, easier and smarter

2012-01-25T23:41:00.001-08:00

Chromium Blog: Making form-filling faster, easier and smarter

One of my favorite features of Chrome got a boost earlier today, as we announced support for an experimental new “autocomplete type” attribute for form fields. The new attribute will allow web developers to unambiguously label text and select fields with common data types such as ‘full-name’ or ‘street-address’ and guarantee that their site’s forms work correctly with Chrome Autofill and other form-filling providers.

We’ve been working on this design in collaboration with several other autofill vendors. Like any early stage proposal we expect this will change and evolve as the web standards community provides feedback, but we believe this will serve as a good starting point for the discussion on how to best support autofillable forms in the HTML5 spec. For now, this new attribute is implemented in Chrome as x-autocompletetype to indicate that this is still experimental and not yet a standard, similar to the webkitspeech attribute we released last summer.

For more information, you can read the full text of the proposed specification, ask questions on the Webmaster help forum, or you can share your feedback in the standardization discussion!

Posted by Ilya Sherman, Software Engineer

URL: http://blog.chromium.org/2012/01/making-form-filling-faster-easier-and.html

[Gd] Update to Top Search Queries data

2012-01-25T20:03:00.001-08:00

Official Google Webmaster Central Blog: Update to Top Search Queries data

Webmaster level: All

Starting today, we’re updating our Top Search Queries feature to make it better match expectations about search engine rankings. Previously we reported the average position of all URLs from your site for a given query. As of today, we’ll instead average only the top position that a URL from your site appeared in.

An example
Let’s say Nick searched for [bacon] and URLs from your site appeared in positions 3, 6, and 12. Jane also searched for [bacon] and URLs from your site appeared in positions 5 and 9. Previously, we would have averaged all these positions together and shown an Average Position of 7. Going forward, we’ll only average the highest position your site appeared in for each search (3 for Nick’s search and 5 for Jane’s search), for an Average Position of 4.

We anticipate that this new method of calculation will more accurately match your expectations about how a link's position in Google Search results should be reported.

How will this affect my Top Search Queries data?
This change will affect your Top Search Queries data going forward. Historical data will not change. Note that the change in calculation means that the Average Position metric will usually stay the same or decrease, as we will no longer be averaging in lower-ranking URLs.

Check out the updated Top Search Queries data in the Your site on the web section of Webmaster Tools. And remember, you can also download Top Search Queries data programmatically!

We look forward to providing you a more representative picture of your Google Search data. Let us know what you think in our Webmaster Forum.

Posted by Chris Anderson, Google Analytics team, and Susan Moskwa, Webmaster Trends Analyst

URL: http://googlewebmastercentral.blogspot.com/2012/01/update-to-top-search-queries-data.html

[Gd] Making form-filling faster, easier and smarter

2012-01-25T12:34:00.007-08:00

Official Google Webmaster Central Blog: Making form-filling faster, easier and smarter

Webmaster Level: Intermediate

One of the biggest bottlenecks on any conversion funnel is filling out an online form – shopping and registration flows all rely on forms as a crucial and demanding step in accomplishing the goals of your site. For many users, online forms mean repeatedly typing common information like our names and addresses on different sites across the web – a tedious task that causes many to give up and abandon the flow entirely.

Chrome’s Autofill and other form-filling providers help to break down this barrier by remembering common profile information and pre-populating the form with those values. Unfortunately, up to now it has been difficult for webmasters to ensure that Chrome and other form-filling providers can parse their form correctly. Some standards exist; but they put onerous burdens on the implementation of the website, so they’re not used much in practice.

Today we’re pleased to announce support in Chrome for an experimental new “autocomplete type” attribute for form fields that allows web developers to unambiguously label text and select fields with common data types such as ‘full-name’ or ‘street-address’. With this attribute, web developers can drive conversions on their sites by marking their forms for auto-completion without changing the user interface or the backend.

Just add an attribute to the input element, for example an email address field might look like:

<input type=”text” name=”field1” x-autocompletetype=”email” />

We’ve been working on this design in collaboration with several other autofill vendors. Like any early stage proposal we expect this will change and evolve as the web standards community provides feedback, but we believe this will serve as a good starting point for the discussion on how to best support autofillable forms in the HTML5 spec. For now, this new attribute is implemented in Chrome as x-autocompletetype to indicate that this is still experimental and not yet a standard, similar to the webkitspeech attribute we released last summer.

For more information, you can read the full text of the proposed specification, ask questions on the Webmaster help forum, or you can share your feedback in the standardization discussion!

Posted by Ilya Sherman, Software Engineer

URL: http://googlewebmastercentral.blogspot.com/2012/01/making-form-filling-faster-easier-and.html

[Gd] Dev Channel Update

2012-01-25T12:34:00.005-08:00

Chrome Releases: Dev Channel Update

The Dev channel has been updated to 18.0.1017.2 for Windows, Mac, Linux and Chrome Frame. This build contains the following updates:

All

Updated V8 - 3.8.7.1
Enable linear scaling for Chrome Remote Desktop’s scale-to-fit feature. (issue 93451)
Fixed popup windows issue (Issue: 106967)
Fixed crashes in extension binding (Issue: 110694)
When Strict Transport Security mandates that HTTPS certificate errors must be fatal, add a string telling the user why. (Issue: 110191)

Mac

Fixed flashing window while deleting profile (Issue: 108801)

Full details about what changes are in this build are available in the SVN revision log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.

Dharani Govindan
Google Chrome

URL: http://googlechromereleases.blogspot.com/2012/01/dev-channel-update_24.html

[Gd] Stable Channel Update for Chromebooks

2012-01-25T12:34:00.003-08:00

Chrome Releases: Stable Channel Update for Chromebooks

The Dev channel has been updated to 16.0.912.77 (Platform versions: 1193.194.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

This build contains a number of performance, stability and security improvements. Additional fixes include:

24748 - Device not scanning for networks
23518 - No UI notification given on connection timeout

URL: http://googlechromereleases.blogspot.com/2012/01/stable-channel-update-for-chromebooks_24.html

[Gd] Watch History Comes to the API

2012-01-25T12:34:00.001-08:00

YouTube API Blog: Watch History Comes to the API

There’s a new entry in the growing list of video feeds supported by the YouTube Data API: the watch history feed. This feed allows authenticated API users to retrieve their own YouTube viewing histories—retrieving the watch history of any other user is not allowed. The information in this new feed corresponds to the viewing history exposed on the YouTube website.

The feed could enable interesting new functionality in your applications. If your site displays a list of recommended videos for an authenticated user to watch, you might consider excluding those videos that have been already viewed, for instance. Or you might want to include a video that you discover the user has been watching over and over again. Knowing the sorts of videos that a user watches makes it easier for your application to algorithmically suggest other videos that might interest your users.

As with any functionality related to the YouTube API, the best place to ask questions about the new watch history feed is the YouTube API developer forum.

Cheers,
—Jeff Posnick, YouTube API Team

URL: http://apiblog.youtube.com/2012/01/watch-history-comes-to-api.html

[Gd] A new and easy way to add new pages to your Custom Search Engine’s index

2012-01-25T03:48:00.001-08:00

Google Custom Search: A new and easy way to add new pages to your Custom Search Engine’s index

Our users have been telling us that while they love the concept of on-demand indexing, manually entering URLs or keeping a Sitemap up to date is too cumbersome. A new year brings a new and improved solution. If you are a Webmaster Tools verified site owner and have a page that links to your site’s latest content, simply provide us with that page’s URL and we will periodically visit it to discover your site’s new content.

For example, as the owners of this blog, we can provide the URL of the blog’s landing page, googlecustomsearch.blogspot.com, to our CSE. It will then periodically visit that URL and add any new links to content on this blog to our CSE’s index. Since this URL automatically links to all new content on this blog, our CSE’s index will always automatically get updated.

You can provide a URL(s) to your CSE via the URLs linked from a page feature in the Indexing page of your CSE’s Control Panel. Note that this feature is only for the discovery of new content and does not refresh content that has already been indexed.

To learn more about URLs linked from a page, please visit our help center. Let us know what you think in our discussion forum.

Posted by: Liqian Luo, Software Engineer

URL: http://googlecustomsearch.blogspot.com/2012/01/new-and-easy-way-to-add-new-pages-to.html

[Gd] Tips on using the APIs Discovery Service

2012-01-25T00:17:00.001-08:00

Google Apps Developer Blog: Tips on using the APIs Discovery Service

Our newest set of APIs - Tasks, Calendar v3, Google+ to name a few - are supported by the Google APIs Discovery Service. The Google APIs Discovery service offers an interface that allows developers to programmatically get API metadata such as:

A directory of supported APIs.
A list of API resource schemas based on JSON Schema.
A list of API methods and parameters for each method and their inline documentation.
A list of available OAuth 2.0 scopes.

The APIs Discovery Service is especially useful when building developer tools, as you can use it to automatically generate certain features. For instance we are using the APIs Discovery Service in our client libraries and in our APIs Explorer but also to generate some of our online API reference.

Because the APIs Discovery Service is itself an API, you can use features such as partial response which is a way to get only the information you need. Let’s look at some of the useful information that is available using the APIs Discovery Service and the partial response feature.

List the supported APIs

You can get the list of all the APIs that are supported by the discovery service by sending a GET request to the following endpoint:


https://www.googleapis.com/discovery/v1/apis?fields=items(title,discoveryLink)

Which will return a JSON feed that looks like this:


{
    "items": [
        …
        {
            "title": "Google+ API",
            "discoveryLink": "./apis/plus/v1/rest"
        },
        {
            "title": "Tasks API",
            "discoveryLink": "./apis/tasks/v1/rest"
        },
        {
            "title": "Calendar API",
            "discoveryLink": "./apis/calendar/v3/rest"
        },
        …
    ]
}

Using the discoveryLink attribute in the resources part of the feed above you can access the discovery document of each API. This is where a lot of useful information about the API can be accessed.

Get the OAuth 2.0 scopes of an API

Using the API-specific endpoint you can easily get the OAuth 2.0 scopes available for that API. For example, here is how to get the scopes of the Google Tasks API:


https://www.googleapis.com/discovery/v1/apis/tasks/v1/rest?fields=auth(oauth2(scopes))

This method returns the JSON output shown below, which indicates that https://www.googleapis.com/auth/tasks and https://www.googleapis.com/auth/tasks.readonly are the two scopes associated with the Tasks API.


{
    "auth": {
        "oauth2": {
            "scopes": {
                "https://www.googleapis.com/auth/tasks": {
                    "description": "Manage your tasks"
                },
                "https://www.googleapis.com/auth/tasks.readonly": {
                    "description": "View your tasks"
                }
            }
        }
    }
}

Using requests of this type you could detect which APIs do not support OAuth 2.0. For example, the Translate API does not support OAuth 2.0, as it does not provide access to OAuth protected resources such as user data. Because of this, a GET request to the following endpoint:


https://www.googleapis.com/discovery/v1/apis/translate/v2/rest?fields=auth(oauth2(scopes))

Returns:

{}

Getting scopes required for an API’s endpoints and methods

Using the API-specific endpoints again, you can get the lists of operations and API endpoints, along with the scopes required to perform those operations. Here is an example querying that information for the Google Tasks API:


https://www.googleapis.com/discovery/v1/apis/tasks/v1/rest?fields=resources/*/methods(*(path,scopes,httpMethod))

Which returns:


{
    "resources": {
        "tasklists": {
            "methods": {
                "get": {
                    "path": "users/@me/lists/{tasklist}",                         
                    "httpMethod": "GET",
                    "scopes": [
                        "https://www.googleapis.com/auth/tasks",
                        "https://www.googleapis.com/auth/tasks.readonly"
                    ]
                },
                "insert": {
                    "path": "users/@me/lists",
                    "httpMethod": "POST",
                    "scopes": [
                        "https://www.googleapis.com/auth/tasks"
                    ]
                },
                …
            }
        },
        "tasks": {
            …
        }
    }
}

This tells you that to perform a POST request to the users/@me/lists endpoint (to insert a new task) you need to have been authorized with the scope https://www.googleapis.com/auth/tasks and that to be able to do a GET request to the users/@me/lists/{tasklist} endpoint you need to have been authorized with either of the two Google Tasks scopes.

You could use this to do some automatic discovery of the scopes you need to authorize to perform all the operations that your applications does.

You could also use this information to detect which operations and which endpoints you can access given a specific authorization token ( OAuth 2.0, OAuth 1.0 or Authsub token). First, use either the Authsub Token Info service or the OAuth 2.0 Token Info Service to determine which scopes your token has access to (see below); and then deduct from the feed above which endpoints and operations requires access to these scopes.

                        
[Access Token] -----(Token Info)----> [Scopes] -----(APIs Discovery)----> [Operations/API Endpoints]

Example of using the OAuth 2.0 Token Info service:

Request:


GET /oauth2/v1/tokeninfo?access_token= HTTP/1.1
Host: www.googleapis.com

Response:


HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
…

{
    "issued_to": "1234567890.apps.googleusercontent.com",
    "audience": "1234567890.apps.googleusercontent.com",
    "scope": "https://www.google.com/m8/feeds/ 
              https://www.google.com/calendar/feeds/",
    "expires_in": 1038
}

There is a lot more you can do with the APIs Discovery Service so I invite you to have a deeper look at the documentation to find out more.

Nicolas Garnier profile | twitter | events

Nicolas joined Google’s Developer Relations in 2008. Since then he's worked on commerce oriented products such as Google Checkout and Google Base. Currently, he is working on Google Apps with a focus on the Google Calendar API, the Google Contacts API, and the Tasks API. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

URL: http://googleappsdeveloper.blogspot.com/2012/01/tips-on-using-apis-discovery-service.html

[Gd] Stable Channel Update

2012-01-23T21:38:00.001-08:00

Chrome Releases: Stable Channel Update

The Stable channel has been updated to 16.0.912.77 for Windows, Mac, Linux and Chrome Frame

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.

[$1000] [106484] High CVE-2011-3924: Use-after-free in DOM selections. Credit to Arthur Gerkis.
[$3133.7] [107182] Critical CVE-2011-3925: Use-after-free in Safe Browsing navigation. Credit to Chamal de Silva. *
[108461] High CVE-2011-3928: Use-after-free in DOM handling. Credit to wushi of team509 reported through ZDI (ZDI-CAN-1415).
[$1000] [108605] High CVE-2011-3927: Uninitialized value in Skia. Credit to miaubiz.
[$1000] [109556] High CVE-2011-3926: Heap-buffer-overflow in tree builder. Credit to Arthur Gerkis.

The bugs 106484, 107182, 108461, and 109556 were detected using AddressSanitizer.
* Bug 107182 was fixed in 16.0.912.75 but accidentally excluded from the release notes.

Full details about what changes have been made in this release are available in the SVN revisions log. Interested in switching to another channel? Find out how. If you find a new issue, please let us know by filing a bug.

Anthony Laforge
Google Chrome

URL: http://googlechromereleases.blogspot.com/2012/01/stable-channel-update_23.html

[Gd] Let's make TCP faster

2012-01-23T17:05:00.001-08:00

The official Google Code blog: Let's make TCP faster

By Yuchung Cheng, Make The Web Faster Team

Transmission Control Protocol (TCP), the workhorse of the Internet, is designed to deliver all the Web’s content and operate over a huge range of network types. To deliver content effectively, Web browsers typically open several dozen parallel TCP connections ahead of making actual requests. This strategy overcomes inherent TCP limitations but results in high latency in many situations and is not scalable.

Our research shows that the key to reducing latency is saving round trips. We’re experimenting with several improvements to TCP. Here’s a summary of some of our recommendations to make TCP faster:

1. Increase TCP initial congestion window to 10 (IW10). The amount of data sent at the beginning of a TCP connection is currently 3 packets, implying 3 round trips (RTT) to deliver a tiny 15KB-sized content. Our experiments indicate that IW10 reduces the network latency of Web transfers by over 10%.

2. Reduce the initial timeout from 3 seconds to 1 second. An RTT of 3 seconds was appropriate a couple of decades ago, but today’s Internet requires a much smaller timeout. Our rationale for this change is well documented here.

3. Use TCP Fast Open (TFO). For 33% of all HTTP requests, the browser needs to first spend one RTT to establish a TCP connection with the remote peer. Most HTTP responses fit in the initial TCP congestion window of 10 packets, doubling response time. TFO removes this overhead by including the HTTP request in the initial TCP SYN packet. We’ve demonstrated TFO reducing Page Load time by 10% on average, and over 40% in many situations. Our research paper and internet-draft address concerns such as dropped packets and DOS attacks when using TFO.

4. Use Proportional Rate Reduction for TCP (PRR). Packet losses indicate the network is in disorder or is congested. PRR, a new loss recovery algorithm, retransmits smoothly to recover losses during network congestion. The algorithm is faster than the current mechanism by adjusting the transmission rate according to the degree of losses. PRR is now part of the Linux kernel and is in the process of becoming part of the TCP standard.

In addition, we are developing algorithms to recover faster on noisy mobile networks, as well as a guaranteed 2-RTT delivery during startup. All our work on TCP is open-source and publicly available. We disseminate our innovations through the Linux kernel, IETF standards proposals, and research publications. Our goal is to partner with industry and academia to improve TCP for the whole Internet. Please watch this blog and http://code.google.com/speed/ for further information.

Yuchung Cheng works on the transport layer to make the Web faster. He believes the current transport layer badly needs an overhaul to catch up with other (networking) technologies. He can be reached at ycheng@google.com.

Posted by Scott Knaster, Editor

URL: http://googlecode.blogspot.com/2012/01/lets-make-tcp-faster.html

[Gd] Google Apps EMEA Developer Tour (continued)

2012-01-22T15:49:00.003-08:00

Google Apps Developer Blog: Google Apps EMEA Developer Tour (continued)

Two months ago we announced that a few of us from the Google Apps Developer Relations team would be going around EMEA to meet with developers and talk about Google Apps technologies. We have met great developers from Germany, France, Russia, Czech Republic, Egypt, Switzerland, Israel, and Spain during Google Developer Days, hackathons, developer conferences and GTUG meetings.

This year we are continuing the tour with a series of Google Apps Script hackathons taking place in Vienna, Milan, Madrid, Munich and Dublin over the next few months. These hackathons provide a fun and hands-on way to learn about Google Apps Script and a good opportunity to give us your feedback on this technology.

For more information about the tour and to register for these events, please visit the Google Apps EMEA Developer Tour website.

We plan to organize many other Google Apps events close to you in the near future. Look for updates on the Google Apps EMEA Developer Tour website or keep an eye out for further announcements on this blog.

Nicolas Garnier profile | twitter | events

URL: http://googleappsdeveloper.blogspot.com/2012/01/google-apps-emea-developer-tour.html

[Gd] Calendar API v3 Best Practices: Reminders

2012-01-22T15:49:00.001-08:00

Google Apps Developer Blog: Calendar API v3 Best Practices: Reminders

We recently posted some best practices for working with recurring events in Google Calendar API v3. In this blog post we’ll highlight another improved area in the v3 API: event reminders.

Reminders

Google Calendar API v3 offers developers flexible control over event reminders, including per-calendar default settings and custom overrides for individual events.

The user’s default reminders for events on a given calendar can be found in the corresponding entry in the Calendar List collection. The Calendar List collection acts a bit like a list of bookmarks, containing entries for the calendars that the user owns or has looked at in the past (it corresponds to the content of the "My Calendars" and "Other Calendars" list on the bottom left in the Web version of Google Calendar). Each entry is annotated with user-specific settings for the individual calendar, such as the preferred color in the UI and the default reminders.

Google Calendar currently supports three ways of reminding its users of events: "popup", prompting a message directly in the browser, mobile phone or desktop client, as well as "email" and "sms" for messages sent through the respective channels. To change the defaults, update the Calendar List entry and include the reminder method and how many minutes in advance the user should be alerted. In the following example, we set an email reminder to be sent 60 minutes before an event, and a popup reminder 10 minutes before.

{
 "summary": "Work Calendar",
 ...
 "defaultReminders": [
   {
     "method": "email",
     "minutes": 60
   },
   {
     "method": "popup",
     "minutes": 10
   }
 ]
}

A Calendar List entry with title and default reminders.

The default reminders will be applied to all existing and future events on this calendar, provided they don’t have custom reminders set already. In contrast to earlier versions of the API, newly created events will also have reminders set by default.

Sometimes, there are events that we want a special reminder for, or none at all. To override the defaults for a specific event, switch the useDefault flag in the reminders section to false, and include a set of custom reminders, or leave the list empty. When you define a set of override reminders for a recurring series, they are automatically applied to each of its occurrences, unless they have been overridden explicitly. Like the default reminders on the calendar, these are personal reminders for the user that is logged in, and will not influence the settings others might have for the same calendar or event. Here is an example that overrides the default reminders with a 15 minute SMS reminder for that specific event.

{
 "summary": "API Office Hours",
 ...
 "reminders": {
   "useDefault": false,
   "overrides": [
     {
       "method": "sms",
       "minutes": 15
     }
   ]
 }
}

An event representation with title and reminder overrides.

The defaults for the given calendar are included at the top of any event listing result. This way, reminder settings for all events in the result can be determined by the client without having to make the additional API call to the corresponding entry in the Calendar List collection.

In this post and an earlier post about best practices with recurring events, we have covered some improved areas of the latest version of the Google Calendar API. Have a look at the migration guide for a more complete view of other changes we made in the new version, and let us know what you think.

If you have any questions about handling reminders or other features of the new Calendar API, post them on the Calendar API forum.

Peter Lundblad profile

Peter joined Google in 2006. He's been leading the Calendar API team for the last 2 years. He's previously worked on video uploads for YouTube.

Fabian Schlup profile

Fabian is a Software Engineer at Google in Zürich, working on Calendar and Tasks, with a focus on APIs.

URL: http://googleappsdeveloper.blogspot.com/2012/01/calendar-api-v3-best-practices.html

[Gd] Real-time Communications in Chrome

2012-01-21T11:55:00.001-08:00

Chromium Blog: Real-time Communications in Chrome

Since we open sourced WebRTC this past summer, we’ve been working hard with browser vendors to integrate WebRTC technology in their products. Today, we reached an important milestone: WebRTC is now integrated in the Chrome browser available on the dev channel.

Building industry-leading voice and video capabilities into the browser makes it easier for web developers to incorporate real time communications in their apps. Instead of relying on custom, OS specific, proprietary plug-ins, they can now easily build and maintain their apps using a few simple JavaScript APIs and have the browser do the heavy lifting.

Even though WebRTC is still evolving, we are receiving feedback from the standards process in W3C and IETF and there are already plenty of apps in development. For example, companies like Polycom, Vonage, Vehix.com, Firespotter, Siemens, Nimbuzz and PCCW are currently actively developing browser based solutions using WebRTC.If you are interested to learn more on how you can use WebRTC in your app, review our documentation, join our developer discussion group and go to the WebRTC blog for more details. We are looking forward to seeing what you come up with!

Posted by Niklas Enbom, Software Engineer

URL: http://blog.chromium.org/2012/01/real-time-communications-in-chrome.html

[Gd] Dev Channel Update for Chromebooks

2012-01-21T02:38:00.003-08:00

Chrome Releases: Dev Channel Update for Chromebooks

The Dev channel has been updated to 18.0.1010.2 (Platform versions: 1590.2.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

This build contains a number of performance, stability and security improvements. Additional changes:

Improvement to wifi stability.
Improved system hardening [Yama support, etc]

Known issues:

25144 - External storage devices fail to automount. Workaround: Login using Guest mode and automount of the device will work.
Machines shipped with R11 and earlier versions may encounter problems with users being able to login to the machine. This may also occur after the user changes their password. Workaround: You may recover either from erasing the stateful partition or performing a machine recovery. Instructions can be found here.