Friday, May 4, 2012

[Gd] How we built a Social Network for Productivity on Top of Google Docs, Calendar, Contacts and Reader

| More

Google Apps Developer Blog: How we built a Social Network for Productivity on Top of Google Docs, Calendar, Contacts and Reader

Editor’s note: This is a guest post by Martin Böhringer, Co-Founder and CEO of Hojoki.
-- Steve Bazyl

Honestly, we love Google’s productivity tools. Back in 2010, when I was a computer science researcher at university, I was a heavy user of Google Docs, Google Calendar, Google Contacts and Google Reader. So it was the most natural thing to put these tools to the front for integrations into our startup, Hojoki.

Hojoki integrate productivity cloud apps into one newsfeed and enables sharing and discussions on top of the feed. We’ve integrated 17 apps now and counting, so it’s safe to say that we’re API addicts. Now it's Time to share with you what we learned about the Google Apps APIs!

The goal: a newsfeed

Our initial reason for building Hojoki was because of the fragmentation we experience in all of our cloud apps. And all those emails. Still, there was this feeling of “I don’t know what’s going on” in our distributed teamwork. So we decided to build something like a Google+ where streams get automatically filled by activities in the apps you use.

This leads to a comprehensive stream of everything that’s going on in your team combined with comments and microblogging. You can organize your stream into workspaces, which are basically places for discussions and collaboration with your team.

Information needs

To build this, we first need some kind of information on recent events. As we wanted to be able to aggregate similar activities and to provide a search, as well as splitting up the stream in workspaces, we also had to be able to sort events as unique objects like files, calendar entries and contacts.

Further, it’s crucial to not only know what has changed, but who did it. So providing unique identities is important for building federated feeds.

Google APIs

Google’s APIs share some basic architecture and structure, described in their Google Data Protocol. Based on that, application-specific APIs provide access to the application’s data. What we use is the following:

The basic call for Google Contacts for example looks like this:

This responds with a complete list of your contacts. Once we have this list all we have to do is to ask for the delta to our existing knowledge. For such use cases, Google’s APIs support query parameters as well as sorting parameters. So we can set “orderby” to “lastmodified” as well as “updated-min” to the timestamp of our last call. This way we are able to keep the traffic low and get quick results by only asking for things we might have missed.

If you want to develop using those APIs you should definitely have a look at the SDKs for them. We used the Google Docs SDK for an early prototype and loved it. Today, Hojoki uses its own generic connection handler for all our integrated systems so we don’t leverage the SDKs anymore.

Real world problems

If you’re into API development, you’ve probably already realized that our information needs don’t fit into many of the APIs out there. Most of the APIs are object centric. They can tell you what objects are included in a certain folder, but they can’t tell you which object in this folder has been changed recently. They just aren’t built with newsfeeds in mind.

Google Apps APIs support most of our information needs. Complete support of OAuth and very responsive APIs definitely make our lives easier.

However, the APIs are not built with Hojoki-like newsfeeds in mind. For example, ETags may change even if nothing happened to an object because of asynchronous processing on Google’s side (see Google’s comment on this). For us this means that, once we detect an altered ETag, in some cases we still have to check based on our existing data if there really have been relevant activities. Furthermore, we often have trouble with missing actors in our activities. For example, up to now we know when somebody changed a calendar event, but there is no way to find out who this was.

Another issue is the classification of updates. Google’s APIs tell us that something changed with an object. But to build a nice newsfeed you also want to know what exactly has been changed. So you’re looking for a verb like created, updated, shared, commented, moved or deleted. While Hojoki calls itself an aggregator for activities, technically we’re primarily an activity detector.

Final solution

You can think of Hojoki as a multi-layer platform. First of all, we try to get a complete overview on your meta-data of the connected app. In Google Docs, this means files and collections, and we retrieve URI and name as well as some additional information (not the content itself). This information fills a graph-based data storage (we use RDF, read more about it here).

At the moment, we subscribe to events in the integrated apps. If detected, they create a changeset for the existing data graph. This changeset is an activity for our newsfeed and related to the object representation. This allows us to provide a very flexible aggregation and filtering on the client side. See the following screenshot. You can filter the stream for a certain collection (“Analytics”) or only for the file history or for the Hojoki workspace where this file is added (“Hojoki Marketing”).

What’s really important in terms of such heavy API processing is to use asynchronous calls. We use the great Open Source project async-http-client for this task.

A wishlist

When I wrote that “we subscribe to events” this is a very nice euphemism for “we’re polling every 30s to see if something changed”. This is not really optimal and we’d love to change it. If Google Apps APIs would support a feed of user events modelled in a common standard like, combined with reliable ETags and maybe even a push API (e.g. Webhooks) this would also make life easier for lots of developers syncing their local files with Google and help to reduce traffic on both sides.

Martin Böhringer

Martin is Co-Founder and CEO of Hojoki. Hojoki integrates Google Docs, Calendar, Contacts and Reader next to other apps like Dropbox and Evernote into one newsfeed, showing changes by co-workers in one central place. Martin holds a PhD in information systems and likes to perform on stage at Tech Events.


[Gd] Dev Channel Update

| More

Chrome Releases: Dev Channel Update

The Dev channel has been updated to 20.0.1123.4 for Windows, Mac, Chrome Frame and Linux. This build contains fixes for rendering and stability. 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

[Gd] Beta Channel Update

| More

Chrome Releases: Beta Channel Update

The Beta channel has been updated to 19.0.1084.41 for Windows, Mac, Linux, and Chrome Frame. 

Take a look at the changelog to see what happened in this release.

If you'd like to get on the Beta channel, you can download it from our Beta download page. If you find a new issue, please let us know by filing a bug.

Anthony Laforge
Google Chrome

[Gd] Beta Update for Chromebooks

| More

Chrome Releases: Beta Update for Chromebooks

The Beta channel has been updated to 19.0.1084.41 (Platform version: 2046.68.0) for Chromebooks (Acer AC700 and Samsung Series 5)..

This release contains security and stability improvements.

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. Orit Mazor
Google Chrome

Wednesday, May 2, 2012

[Gd] Google BigQuery brings Big Data analytics to all businesses

| More

Google Developers Blog: Google BigQuery brings Big Data analytics to all businesses

Author Photo
By Ju-kay Kwek, Product Manager, BigQuery

BigQuery enables businesses and developers to gain real-time business insights from massive amounts of data without any upfront hardware or software investments. Imagine a big pharmaceutical company optimizing daily marketing spend using worldwide sales and advertisement data. Or think of a small online retailer that makes product recommendations based on user clicks. Today, we are making BigQuery publicly available, an important milestone in our effort to bring Big Data analytics to all businesses via the cloud.

Since announcing BigQuery in limited preview last November, many businesses and developers have started using it for real-time Big Data analytics in the cloud. Claritics, a social and mobile analytics company, built a web application for game developers to gain real-time insights into user behavior. Crystalloids, an Amsterdam-based analytics firm, built a cloud-based application to help a resort network analyze customer reservations, optimize marketing and maximize revenue. This just scratches the surface of use cases for BigQuery.

BigQuery is accessible via a simple UI or REST interface. It lets you take advantage of Google’s massive compute power, store as much data as needed and pay only for what you use. Your data is protected with multiple layers of security, replicated across multiple data centers and can be easily exported.

Developers and businesses can sign up for BigQuery online and query up to 100 GB of data per month for free. See our introductory pricing plan for storing and querying datasets of up to 2 TB. If you need more than that, contact a sales representative.

We hope you will be able to gain real-time business insights using BigQuery. Share your BigQuery use cases and feedback in our user forums or on our +Google Enterprise page.

Ju-kay Kwek is the Product Management Lead for Google's Cloud Big Data initiative. In this role, he focuses on creating services that enable businesses and developers to harness Google's unparalleled data processing infrastructure and algorithms to tackle Big Data needs.

Posted by Scott Knaster, Editor

[Gd] Google documents, now with web fonts!

| More

Google Web Fonts: Google documents, now with web fonts!

(Cross-posted from the Google Docs Blog)

In the past month we’ve made updates both big and small to Google Docs, and today we’re announcing one more: web fonts in Google documents. Often the best way to get your point across is to present your idea in a creative, captivating way. Today, we added over 450 new fonts to Google documents to make it easier for you to add a little something extra to whatever you create.

To use these new fonts, click on the font menu and select “Add fonts” at the very bottom, which will take you to a menu of all the Google Web Fonts available.

Once you’ve selected new fonts, you’ll be able to select them from the font menu.

Whether you’re looking for the perfect font for your first comic book or fancy handwriting for your wedding invitations, we hope you try out the new fonts and create some eye-catching documents.

In addition to hundreds of new fonts, we have a lot of other exciting updates to report:
  • Google Drive launched as a place where you can create, share, collaborate, and keep all your stuff. 
  • There are now a few more options for inserting images in Docs, including inserting from Google Drive, searching for images from the LIFE Photo archive, or taking a snapshot with your webcam. 
  • Charts in spreadsheets now has support for minor gridlines and options to customize the formats of axis labels 
  • Accessibility in Docs got better with support for screenreaders in presentations and with the addition of NVDA to our list of supported screenreaders
  • From File > Page setup... you can now set the default page size for your new documents. 
  • It's now easier for speakers of right-to-left languages by automatically showing bidirectional controls when you type in a language that might use them. 
  • Apps Script had many improvements, including 
    • A new ScriptService for programmatically publishing your scripts and controlling when they run. 
    • A new function to find the root folder of someone’s Drive. 
    • An increase in the allowed attachment size in emails from 5MB to 25MB. 
    • An increase in the size of docs files you can create from 2MB to 50MB. 
  • There are now over 60 new templates in our template gallery.
Posted by Isabella Ip, Software Engineer

    [Gd] Coding guidelines for HTML and CSS

    | More

    Official Google Webmaster Central Blog: Coding guidelines for HTML and CSS

    Webmaster level: All

    Great code has many attributes. It’s effective, efficient, maintainable, elegant. When working on code with many developers and teams and maybe even companies, great code needs to also be consistent and easy to understand. For that purpose there are style guides. We use style guides for a lot of languages, and our newest public style guide is the Google HTML and CSS Style Guide.

    Our HTML and CSS Style Guide, just like other Google style guides, deals with a lot of formatting-related matters. It also hints at best practices so to encourage developers to go beyond indentation. Many style guide authors know the underlying motivation from the question whether to describe the code they write—or to prescribe what code they want to write. Not surprisingly then, in our HTML and CSS style guide you’ll find both (as much as you’ll still find a lot of different development styles in our not entirely small code base).

    At this time we only want to introduce you to this new style guide. We hope to share more about its design decisions and future updates with you. In the meantime please share your thoughts and experiences, and as with the other style guides, feel free to use our style guide for your own projects, as you see fit.

    Written by Jens O. Meiert, Senior Web Architect, Google Webmaster Team

    [Gd] Dev Channel Update

    | More

    Chrome Releases: Dev Channel Update

    The Dev channel has been updated to 20.0.1123.1 for Windows, Mac, and Chrome Frame.  Linux will be updated tomorrow. This build contains following updates:

    • Updated V8 -
    • Fixed about:inducebrowsercrashforrealz (Issue: 124843)
    • [Windows] Visual refinements to the tab strip and toolbar icons, including a slightly wider new tab button (the “baby tab”) that is easier to click.
    • [Known Issues] Mouse over on apps/extensions makes place holder blank in web store. (Issue: 125777)

    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

    [Gd] Stable and Beta Update for Chromebooks

    | More

    Chrome Releases: Stable and Beta Update for Chromebooks

    The Stable channel has been updated to 18.0.1025.168 (Platform version: 1660.143.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48). Beta channel has been updated to the same version for Cr-48 systems.

    This release contains security and stability improvements.

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

    Danielle Drew
    Google Chrome

    Tuesday, May 1, 2012

    [Gd] Better code optimization decisions for V8

    | More

    Chromium Blog: Better code optimization decisions for V8

    As of current dev and beta channel releases, V8 uses a new algorithm based on counters to decide which functions to optimize. This greatly increases performance for small JavaScript programs. For example, on the SunSpider benchmark, which focuses on extremely short-running tests, V8's speed improved by about 25%.

    When executing JavaScript, V8 at first compiles it to machine code with a very fast compiler that doesn't optimize the code it produces. V8 has a second, optimizing compiler that generates much faster machine code, but takes much more time to do so, so it has to be used selectively. That's why V8 must try to predict which functions will benefit most from optimization, and carefully decide when to optimize them.

    In the past, V8 stopped once every millisecond to look at currently running functions, and eventually optimized them. For long-running programs, this worked great, but short-running programs often finished before they could benefit much from the optimizing compiler -- a single millisecond can be a long time to wait before optimizing! In addition, V8 often made different optimization decisions each time a JavaScript program ran, sometimes overlooking small but performance-critical functions.

    The new version of V8 makes earlier and more repeatable optimization decisions by analyzing the running program in more detail. It uses counters to keep track of how often JavaScript functions are called and loops are executed in a program, approximating the time spent inside each function. That way V8 is able to quickly gather fine-grained information about performance bottlenecks in a JavaScript program, and to make sure that the optimizing compiler's efforts are spent on those functions that deserve it most.

    The new algorithm is contained in the current beta channel releases -- go give it a spin now!

    Posted by Jakob Kummerow, Software Engineer

    [Gd] SPDY performance on mobile networks

    | More

    Google Developers Blog: SPDY performance on mobile networks

    By Matt Welsh, Ben Greenstein, and Michael Piatek,
    Mobile Web Performance Team

    SPDY is a replacement for HTTP, designed to speed up transfers of web pages by eliminating much of the overhead associated with HTTP. SPDY supports several optimizations that give it an edge over HTTP when it comes to speed. SPDY is gaining a great deal of traction -- it has been implemented in Chrome, Firefox, and Amazon Silk, has been deployed widely by Google, and there is now SPDY support for Apache through the mod_spdy module.

    We wondered what the performance of SPDY would be compared to HTTP for popular websites, using a Samsung Galaxy Nexus (running Android), a modern, SPDY-enabled browser (Chrome for Android), and a variety of pages from real websites (77 pages across 31 popular domains).

    The net result is that using SPDY produced a mean page load time improvement of 23% across these sites, compared to HTTP. This is equivalent to a speedup of 1.3x for SPDY over HTTP. Much more work can be done to improve SPDY performance on 3G and 4G cellular networks, but this is a promising start.

    The following graph shows the page load time for HTTP and SPDY, in milliseconds, across the 77 pages that were measured. As the graph shows, in all but one case, SPDY reduces load times, sometimes by as much as 50%.

    Check out the full article for more details on the measurement methodology and results.

    Matt Welsh, Ben Greenstein, and Michael Piatek are software engineers on Google’s Mobile Web Performance Team based in Seattle. They are working to speed up mobile web performance globally, and as part of their jobs, they run up impressive mobile bandwidth bills every month.

    Posted by Scott Knaster, Editor

    [Gd] More ways to measure your website's performance with User Timings

    | More

    Google Developers Blog: More ways to measure your website's performance with User Timings

    By Satish Kambala and Mustafa M. Tikir, Google Analytics Team

    Cross-posted from the Google Analytics Blog

    As part of our mission to make the web faster, Google Analytics provides Site Speed reports to analyze your site’s page load times. To help you measure and diagnose the speed of your pages in a finer grain, we’re happy to extend the collection of Site Speed reports in Google Analytics with User Timings.

    With User Timings, you can track and visualize user defined custom timings about websites. The report shows the execution speed or load time of any discrete hit, event, or user interaction that you want to track. This can include measuring how quickly specific images and/or resources load, how long it takes for your site to respond to specific button clicks, timings for AJAX actions before and after onLoad event, etc. User timings will not alter your pageview count, hence,  makes it the preferred method for tracking a variety of timings for actions in your site.

    To collect User Timings data, you'll need to add JavaScript timing code to the interactions you want to track using the new _trackTiming API included in ga.js (version 5.2.6+) for reporting custom timings. This API allows you to track timings of visitor actions that don't correspond directly to pageviews (like Event Tracking).  User timings are defined using a set of Categories, Variables, and optional Labels for better organization. You can create various categories and track several timings for each of these categories. Please refer to the developers guide for more details about the _trackTiming API.

    Here are some sample use cases for User Timings
    • To track timings for AJAX actions before and after onLoad event. 
    • A site can have their own definition of "User Perceived Load Time", which can be recorded and tracked with user timings.  As an example, news websites can record time for showing the above fold content as their main metric instead of onLoad time. 
    • Detailed performance measurement and optimization of sub components on a page, such as time to load all images, CSS or Javascript, download PDF files and time it takes to upload a file.
    Want to check out User Timings Report in your account?

    Go to the content section and click the User Timings report under Content section. There are three tabs within the User Timings report for you to review: Explorer, Performance, and Map Overlay. Each provides a slightly different view of user timings reported.

    The Explorer tab on the User Timings report shows the following metrics by Timing Category, Timing Variable, or Timing Label (all of which you define in your timing code).
    • Avg. User Timing—the average amount of time (in seconds) it takes for the timed code to execute
    • User Timing Sample—the number of samples taken
    The Explorer tab also provides controls that you can use to change the tabular data. For example, you can choose a secondary dimension—such as browser— to get an idea of how speed changes by browser.

    To learn more about which timings are most common for user timings, switch to the Performance tab. This tab shows timing buckets, providing you with more insight into how speed can vary for user reported timings for selected category, variable and label combinations. You may switch to Performance tab at any point of navigation in the Explorer tab, such as after drilling down on a specific category and variable, to visualize distribution of user reported timings.  The bucket boundaries for histograms in Performance Tab are chosen to be flexible so that users can analyze data at low values ranging from 10 milliseconds granularity to 1 minute granularity with addition of sub-bucketing for further analysis.

    The Map Overlay tab provides a view of your site speed experienced by users in different geographical regions (cities, countries, continents).

    Satish Kambala and Mustafa M. Tikir are on the Google Analytics Team.

    Posted by Scott Knaster, Editor

    [Gd] Debugging Web Workers with Chrome Developer Tools

    | More

    Chromium Blog: Debugging Web Workers with Chrome Developer Tools

    Like with other multithreaded applications, debugging Web Workers may be a tricky task and having good instruments makes this process much easier. Chrome Developer Tools provides full debugging support for scripts running in both dedicated and shared workers.

    You can now use the powerful Scripts, Timeline, Profiles and Console panels to develop Web Workers:

    All dedicated workers running in the inspected page are listed in the Scripts panel, under the Workers section. Clicking on a worker URL will open a new Developer Tools window attached to the worker. If you need to debug a dedicated worker’s initialization, there is also an option to pause workers on start. This will suspend the execution in all starting dedicated workers at the very first statement.

    Shared workers are more independent than dedicated ones as they can be used concurrently by several pages. All running shared workers can be discovered through the chrome://inspect page. Each shared worker listed there has inspect and terminate links next to its URL. These links allow you to launch a Developer Tools window attached to that worker or terminate the worker respectively.

    When you need to debug a shared worker initialization, it is enough to terminate the current instance of the worker leaving the Developer Tools window open and reload one of the worker clients. The worker will restart and Developer Tools window will automatically re-attach to the new instance.

    To learn more on Developer Tools check out our documentation or ask us a question on Google+ and our discussion group.

    Posted by Yury Semikhatsky, Software Engineer

    [Gd] Responsive design – harnessing the power of media queries

    | More

    Official Google Webmaster Central Blog: Responsive design – harnessing the power of media queries

    Webmaster Level: Intermediate / Advanced

    We love data, and spend a lot of time monitoring the analytics on our websites. Any web developer doing the same will have noticed the increase in traffic from mobile devices of late. Over the past year we’ve seen many key sites garner a significant percentage of pageviews from smartphones and tablets. These represent large numbers of visitors, with sophisticated browsers which support the latest HTML, CSS, and JavaScript, but which also have limited screen space with widths as narrow as 320 pixels.

    Our commitment to accessibility means we strive to provide a good browsing experience for all our users. We faced a stark choice between creating mobile specific websites, or adapting existing sites and new launches to render well on both desktop and mobile. Creating two sites would allow us to better target specific hardware, but maintaining a single shared site preserves a canonical URL, avoiding any complicated redirects, and simplifies the sharing of web addresses. With a mind towards maintainability we leant towards using the same pages for both, and started thinking about how we could fulfill the following guidelines:
    1. Our pages should render legibly at any screen resolution
    2. We mark up one set of content, making it viewable on any device
    3. We should never show a horizontal scrollbar, whatever the window size

    Stacked content, tweaked navigation and rescaled images – Chromebooks

    As a starting point; simple, semantic markup gives us pages which are more flexible and easier to reflow if the layout needs to be changed. By ensuring the stylesheet enables a liquid layout, we are already on the road to mobile-friendliness. Instead of specifying width for container elements, we started using max-width instead. In place of height we used min-height, so larger fonts or multi-line text don’t break the container’s boundaries. To prevent fixed width images “propping open” liquid columns, we apply the following CSS rule:

    img {
    max-width: 100%;

    Liquid layout is a good start, but can lack a certain finesse. Thankfully media queries are now well-supported in modern browsers including IE9+ and most mobile devices. These can make the difference between a site that degrades well on a mobile browser, to one that is enhanced to take advantage of the streamlined UI. But first we have to take into account how smartphones represent themselves to web servers.


    When is a pixel not a pixel? When it’s on a smartphone. By default, smartphone browsers pretend to be high-resolution desktop browsers, and lay out a page as if you were viewing it on a desktop monitor. This is why you get a tiny-text “overview mode” that’s impossible to read before zooming in. The default viewport width for the default Android browser is 800px, and 980px for iOS, regardless of the number of actual physical pixels on the screen.

    In order to trigger the browser to render your page at a more readable scale, you need to use the viewport meta element:

    <meta name="viewport" content="width=device-width, initial-scale=1">

    Mobile screen resolutions vary widely, but most modern smartphone browsers currently report a standard device-width in the region of 320px. If your mobile device actually has a width of 640 physical pixels, then a 320px wide image would be sized to the full width of the screen, using double the number of pixels in the process. This is also the reason why text looks so much crisper on the small screen – double the pixel density as compared to a standard desktop monitor.

    The useful thing about setting the width to device-width in the viewport meta tag is that it updates when the user changes the orientation of their smartphone or tablet. Combining this with media queries allows you to tweak the layout as the user rotates their device:

    @media screen and (min-width:480px) and (max-width:800px) {
      /* Target landscape smartphones, portrait tablets, narrow desktops


    @media screen and (max-width:479px) {
      /* Target portrait smartphones */

    In reality you may find you need to use different breakpoints depending on how your site flows and looks on various devices. You can also use the orientation media query to target specific orientations without referencing pixel dimensions, where supported.

    @media all and (orientation: landscape) {
      /* Target device in landscape mode */

    @media all and (orientation: portrait) {
      /* Target device in portrait mode */

    Stacked content, smaller images – Cultural Institute
    A media queries example

    We recently re-launched the About Google page. Apart from setting up a liquid layout, we added a few media queries to provide an improved experience on smaller screens, like those on a tablet or smartphone.

    Instead of targeting specific device resolutions we went with a relatively broad set of breakpoints. For a screen resolution wider than 1024 pixels, we render the page as it was originally designed, according to our 12-column grid. Between 801px and 1024px, you get to see a slightly squished version thanks to the liquid layout.

    Only if the screen resolution drops to 800 pixels will content that’s not considered core content be sent to the bottom of the page:

    @media screen and (max-width: 800px) {
    /* specific CSS */

    With a final media query we enter smartphone territory:

    @media screen and (max-width: 479px) {
    /* specific CSS */

    At this point, we’re not loading the large image anymore and we stack the content blocks. We also added additional whitespace between the content items so they are more easily identified as different sections.

    With these simple measures we made sure the site is usable on a wide range of devices.

    Stacked content and the removal of large image – About Google

    It’s worth bearing in mind that there’s no simple solution to making sites accessible on mobile devices and narrow viewports. Liquid layouts are a great starting point, but some design compromises may need to be made. Media queries are a useful way of adding polish for many devices, but remember that 25% of visits are made from those desktop browsers that do not currently support the technique and there are some performance implications. And if you have a fancy widget on your site, it might work beautifully with a mouse, but not so great on a touch device where fine control is more difficult.

    The key is to test early and test often. Any time spent surfing your own sites with a smartphone or tablet will prove invaluable. When you can’t test on real devices, use the Android SDK or iOS Simulator. Ask friends and colleagues to view your sites on their devices, and watch how they interact too.

    Mobile browsers are a great source of new traffic, and learning how best to support them is an exciting new area of professional development.

    Some more examples of responsive design at Google:

    Written by Rupert Breheny, Edward Jung, Matt Zürrer, Google Webmaster Team

    [Gd] Stable Channel Update

    | More

    Chrome Releases: Stable Channel Update

    The Chrome Stable channel has been updated to 18.0.1025.168 on 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.

    • [106413] High CVE-2011-3078: Use after free in floats handling. Credit to Google Chrome Security Team (Marty Barbella) and independent later discovery by miaubiz.
    • [117110] High CVE-2012-1521: Use after free in xml parser. Credit to Google Chrome Security Team (SkyLined) and independent later discovery by  wushi of team509 reported through iDefense VCP (V-874rcfpq7z).
    • [117627] Medium CVE-2011-3079: IPC validation failure. Credit to PinkiePie.
    • [121726] Medium CVE-2011-3080: Race condition in sandbox IPC. Credit to Willem Pinckaers of Matasano.
    • [$1000] [121899] High CVE-2011-3081: Use after free in floats handling. Credit to miaubiz.

    The bugs [106413], [117110] and [121899] were detected using AddressSanitizer.

    Full details about what changes are in this release are available in the SVN revision logInterested in hopping on the stable channel?  Find out how.  If you find a new issue, please let us know by filing a bug.

    Karen Grunberg
    Google Chrome


    Sunday, April 29, 2012

    [Gd] Fridaygram: translation birthday, photos in trees, giants on streets

    | More

    Google Developers Blog: Fridaygram: translation birthday, photos in trees, giants on streets

    Author Photo
    By Scott Knaster, Google Developers Blog Editor

    One of my favorite "living in the future" moments happens when I visit a webpage that’s not written in English. As you probably know, when this happens, Chrome figures out which language the page is using, and offers to translate it for me. That’s really cool. This week we celebrated the 6th anniversary of Google Translate’s statistical machine translation technology, which powers the Chrome translation scenario and many others.

    Google Translate now works across 64 different languages, with more added from time to time. From modest beginnings, Google Translate now performs most of the translation work on Earth, translating one million books’ worth of text every day.

    When words are not enough, we turn to pictures. What makes the LOOK3 Festival of the Photograph unusual is that it displays images high among the trees in an outdoor mall in Charlottesville, Virginia. Also known as "three days of peace, love and photography", this festival promotes environmental awareness and conservation, and also just looks really awesome.

    Finally, what’s more lifelike than words and pictures? How about giant marionettes walking through the streets of Liverpool to commemorate the 100th anniversary of the Titanic? There are plenty of YouTube videos of the giants’ visit for you to enjoy.

    Go Giants!

    Fridaygram posts are made for fun, not technical value. They have been designed for your Friday and weekend enjoyment. Items that are interesting to us nerds are published in these posts. By the way, today has been declared Passive Voice Day 2012, so make sure that fun is had!


    [Gd] Beta Channel Update for Chromebooks

    | More

    Chrome Releases: Beta Channel Update for Chromebooks

    The Beta channel has been updated to 19.0.1084.36 (Platform version: 2046.54.0 and 2046.55.0) for Chromebooks (Acer AC700 and Samsung Series 5).  This release contains stability improvements and bug fixes.

    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. Orit Mazor
    Google Chrome

    [Gd] Dev Channel Updates for Chromebooks

    | More

    Chrome Releases: Dev Channel Updates for Chromebooks

    The Dev channel has been updated to 20.0.1116.0 (Platform version: 2199.0.0) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48). This release contains functional, security and stability improvements.

    Release highlights:
    • Google Drive integrated into the file manager
    • 29370 - Fixed issue where audio was not heard on video playback when multiple tabs are open

    Known issues:
    • 29994 - File manager menu item is missing from the wrench menu. Workaround: Use the keyboard shortcut Ctrl-M or go to chrome://files to open the file manager.
    • 25619 - Power button is sometimes unresponsive. Workaround: Long press the power button to shutdown the system.
    • 30060 - Unable to enter CJK or other complex characters
    • 29981 - Unable to connect to GSM network
    • 29316 - Two-finger click sometimes fails on Mario
    • 29738 - Occasionally machine fails to detect ethernet connection. Workaround: Rebooting the machine often clears the problem
    • 29744 - Cannot add hidden WEP/WPA networks
    • 29957, 30059 - Audio is not heard when playing certain media file types when files are saved to the Chromebook
    If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching to the Beta channel? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu.

    Danielle Drew
    Google Chrome