Showing posts with label chrome. Show all posts
Showing posts with label chrome. Show all posts

Tuesday, 4 June 2013
Facebook StumbleUpon Twitter Google+ Pin It

A classic boardwalk game rolls from your phone to your computer—using only your browser

Author PhotoBy Pete LePage, Developer Advocate and Boardwalk King

Cross-posted from the Chromium Blog

Last week we launched Roll It, a Chrome Experiment that links phones to computers and gets people out of their chairs and swinging. We wanted to share how we built a physical game experience with no dedicated hardware. It requires just the web, your computer and a phone.

Here’s a look at the APIs and browser-based features we used to create it.


Roll It is a three-dimensional (3D) experience, from the swing of your phone’s accelerometer right up to the virtual models rendered on your computer’s HTML5 Canvas. On the phone side, we hooked into browser events like DeviceOrientation and DeviceMotion to detect the speed and direction of a swing. On the computer side we rendered our scene using Three.js and plugged in Physijs to add physics to the ball and environment.

To sync the phone to the computer we employed WebSockets which enable rapid two-way communication between devices via a central server.

For extra stability we built our backend on Google Cloud Platform:
We couldn’t have brought this experiment to life without a great team. The theme for Roll It was composed by Mr. Tim Healey. Legwork Studio developed the interfaces and game environment, and teamed up with Mode Set for the development.

To dig deeper into the technology behind Roll It, check out the HTML5 Rocks Case Study, or join the team for a Google Developers Live event this Friday, June 7, 2013 at 5pm GMT for an in-depth discussion.


Pete LePage is a Developer Advocate on the Google Chrome team and helps developers create great web applications and mobile web experiences.

Posted by Scott Knaster, Editor

Wednesday, 27 February 2013
Facebook StumbleUpon Twitter Google+ Pin It

On the track with Chrome Super Sync Sports

Author PhotoBy Paul Kinlan, Chrome Developer Relations

Cross-posted with the Chromium Blog

Earlier today we launched Chrome Super Sync Sports. It’s an interactive web game that enables up to four friends to compete in running, swimming and cycling events on a shared computer screen, using their smartphones or tablets as game controllers.



Chrome Super Sync Sports was built with the latest browser technologies:
  • Touch APIs to recognise gestures made on your smartphone and tablet. 
  • WebSockets are used to deliver immediate real-time playback across all the players in your group and to update the main game screen as you play. 
  • Finally, CSS3SVG and Canvas provide rich visuals and an immersive experience. 
In the next few weeks, we’ll be publishing an article on HTML5 Rocks with more information on how we built this experience. You can follow +Google Chrome Developers to learn when the article will be live.

In the meantime, enjoy competing with your friends at chrome.com/supersyncsports and be sure to open Chrome’s developer tools to see what happens under the track!


Paul Kinlan is a Developer Advocate in the UK on the Chrome team specialising on mobile. He lives in Liverpool and loves trying to progress the city's tech community from places like DoES Liverpool hack-space.

Posted by Scott Knaster, Editor

Tuesday, 5 February 2013
Facebook StumbleUpon Twitter Google+ Pin It

Introducing "Find Your Way to Oz", a new Chrome Experiment

Author Photo
By Max Heinritz, Associate Product Magician (Manager)

Cross-posted with the Chromium Blog

Today we unveiled "Find Your Way To Oz", a new Chrome Experiment inspired by the upcoming feature film Oz The Great and Powerful. Developed by UNIT9, this experiment brings together Disney’s unique storytelling tradition and the power of the web platform, allowing users to interact with the web in a completely new way.



The desktop version of "Find Your Way To Oz" uses many of the open web’s more advanced features:
  • Immersive Graphics: The experiment uses WebGL for the main 3D environment, CSS3 features such as CSS Transitions for various visual embellishments, and GLSL shaders for the tornado’s ominous look and feel.

  • Rich Audio: As the user explores the experiment, the 3D sound dynamically adapts thanks to the Web Audio API. The same API powers the experiment’s music composing section.

  • Camera-based interactions: Through WebRTC’s getUserMedia API, users can become circus characters or record their own mini-movies.
The experiment’s mobile web version also uses cutting-edge web technologies. These include graphics features such as accelerated 3D transforms and sprite sheets as well as mobile hardware features like camera, multi-touch, gyroscope and accelerometer. Together they create an experience that can normally only be found in native apps.

To learn more about how this experiment was built, read our technical case study and join us for a Google Developers Live event on February 11th at 11 a.m. GMT where we’ll be talking to the team behind the project. Alternatively, use Chrome’s developer tools to see how the experiment works on your own, perhaps finding in the process your own path to the yellow brick road.


Max Heinritz is an Associate Product Manager on the Chrome Web Platform team. He's helping the web reach its potential to become the universal application platform. On the weekends you can find him exploring the Northern California wilderness.

Posted by Scott Knaster, Editor

Wednesday, 19 December 2012
Facebook StumbleUpon Twitter Google+ Pin It

Putting Zürich before Århus

Author Photo
By Mark Davis, International Software Architect

Until now, it has been very difficult for web application designers to do something as simple as sort names correctly according to the user's language. And it matters: English readers wouldn’t expect Århus to sort below Zürich, but Danish speakers would.

Because linguistic sorting requires a sophisticated algorithm and lots of data, it was impractical to do this natively in JavaScript. Until now, the only full solution for sorting on the client side was to generate on a server a sortKey for every string that needed to be sorted, and send the sortkeys — base64-encoded — down to the client along with the strings. Pretty ugly! And what’s doubly frustrating is that the underlying operating systems have all been able to handle this, whether through International Components for Unicode (ICU) or Windows APIs.

The new internationalization specification for ECMAScript (the “official” name for JavaScript) changes this picture. It is already in the production version of Chrome, and is on track for other major browsers.

Linguistic sorting is not the only benefit—not only will users be able to see names sorted correctly, but also correct numeric values (“1,234.56” in English, but “1.234,56” in German), dates (“March 10, 2012” vs “10. März 2012”), and so on. While the results might not be precisely the same in every browser, they should be appropriate to the language, and are returned using a uniform API.

On any enabled browser — in its supported languages — web application developers can:
  • compare strings correctly: choosing whether or not to ignore accents, case differences, etc.
  • format numbers correctly: choosing decimal places, currencies, whether to use thousands-separator, etc.
  • format dates and times correctly: choosing decimal places, numeric vs named months, etc.
  • match locales: comparing the user’s desired locales (say Arabic and French) against the supported locales (say French, German, and English), to get the best match.
The API also allows for linguistic support in offline web applications, which wasn’t practical before. It builds on the industry standards BCP47 (for identifying languages and locales) and LDML (part of the Unicode Common Locale Data Repository (CLDR) project). For the gory details of the spec, see ECMA-402: ECMAScript Internationalization API Specification (just approved by the Ecma General Assembly).


Mark Davis is president and cofounder of the Unicode consortium, and founder of ICU and CLDR. Mark is fond of food, film, travel, and RPGs. Mark lived for 4 years in Switzerland, and is moving back in February.

Posted by Scott Knaster, Editor

Wednesday, 5 December 2012
Facebook StumbleUpon Twitter Google+ Pin It

Google HackFair in South Korea

Author Photo
By Soonson Kwon, Developer Relations Program Manager

For developers and engineers, the best way to learn something is to get your hands dirty and try making something. That is why Google hosts many hackathons around the world. Last November 17 and 18, we had a bigger experiment at Gangnam (yes, this is the very Gangnam in Gangnam Style!) in Seoul, South Korea which expanded a 1-2 day hackathon into a much longer one which we called Google HackFair.



The idea was to give developers enough time (2 months) to develop something bigger and provide a nice chance to showcase their projects. 153 developers submitted 92 projects, and 40 projects were chosen from among them and displayed. Developers used many different technologies, including Android, Chrome, App Engine, and HTML5, and they completed creative and interesting projects: a remote controlled car guided by Android, a serial terminal for Chrome, a braille printer using Go, and many more!


Besides the exhibition, we also prepared a mini-conference and GDG (Google Developers Group) booth where Googlers and community developers gave 27 sessions in total.


More than 1000 people attended and enjoyed the Google HackFair. Although the event is finished, developers continue updating and polishing their projects. It was a great time indeed.

If you are interested in details for the projects including full demos or source code, please check here.


Soonson Kwon is Developer Relations Program Manager and Country Lead for South Korea. His mission is to help Korean developers make better use of Google’s developer products. He is also passionate about Open Source.

Posted by Scott Knaster, Editor

Friday, 9 November 2012
Facebook StumbleUpon Twitter Google+ Pin It

Fridaygram: Chrome Jams, distant stars, building footprints

Author Photo
By Scott Knaster, Google Developers Blog Editor

Hey, wanna start a band? A new Chrome Experiment, JAM with Chrome, lets you play music in a web app and jam with others online in real time. You get to pick from 19 different instruments, including drums, guitars, and keyboards. Once you get really good, you can use shortcuts on your (computer) keyboard to play your instrument.



When you’ve had enough fun making music with your friends, you can explore how JAM with Chrome works. Take a look at the tools and technologies that were used to make this app, and for details, read the case study. Then you can decide whether you want to build the next great web app or become a rock star instead.

Speaking of stars, scientists have astonishingly figured out how to learn about light from every star that ever existed. Researchers used the orbiting Fermi Large Area Telescope to look at distant galaxies and measure photons from various places around the universe. This data goes back to the formation of the first stars more than 13 billion years ago.

Finally, back on our own planet, you might have noticed that Google Maps recently added more building footprints to map displays. In case you didn’t count them, over 25 million new building footprints have been added to both desktop and mobile versions of Google Maps. Maybe you’ll see the new footprints while exploring your favorite city this weekend.


On Fridays we detour slightly from our usual posts and publish a Fridaygram, a fun compilation of nerdy stuff to amuse you (and us). And how cool is it that we have orbiting telescopes?

Wednesday, 17 October 2012
Facebook StumbleUpon Twitter Google+ Pin It

A better developer experience for Native Client

Author PhotoBy Christian Stefansen, Native Client Team

Native Client (NaCl) enables you to write high-performance apps that run your C and C++ code in the browser. With the new Native Client add-in for Microsoft Visual Studio and the new Native Client debugger it just got a lot easier.

The Visual Studio add-in makes it easy to set up, build, run, and debug your app as a Pepper plug-in and as a Native Client module. If you are porting an existing application to Native Client, building as a Pepper plug-in is a convenient intermediate stage for development enabling you to gradually rewrite the app to use the Pepper APIs (video).


The Native Client debugger, affectionately called nacl-gdb, works on Windows, Mac, and Linux and is now available in the SDK. So whatever your development platform, you can now spend more time coding features and less time chasing bugs with printf.

Following the Native Client philosophy of being OS-independent and open source, nacl-gdb is based on... well... gdb! For those of you who are not excited by a text interface, the Visual Studio add-in makes interacting with the debugger easier. If you use a different development environment that can interact with gdb, you can point it to nacl-gdb and use the same commands plus some additional NaCl-specific commands.


Whether you’re an existing Native Client developer or thinking about using Native Client for your next project, now is a great time to grab the SDK, write an amazing app, and quickly squash any bugs you find. We look forward to questions on Stack Overflow and ideas and comments in the discussion forum.


Christian Stefansen is the Product Manager for Native Client and Pepper (PPAPI). When he is not busy planning new features for Native Client, he likes traveling and writing. He is currently writing a book about India.

Posted by Scott Knaster, Editor

Tuesday, 16 October 2012
Facebook StumbleUpon Twitter Google+ Pin It

Celebrating Dart’s birthday with the first release of the Dart SDK

Author PhotoBy Lars Bak, Software Engineer

A year ago we released a technology preview of Dart, a project that includes a modern language, libraries and tools for building complex web applications. Today, after plowing through thousands of bug reports and feature requests from the web community, a new, more stable and comprehensive version of Dart is now available and ready to use.



With this version of the Dart SDK, we’ve made several improvements and added many features:
Over the following months, we will continue to work hard to evolve the SDK, improve Dart’s robustness and performance, and fine-tune the language while maintaining backwards compatibility.

Dart birthday logo

You can download the Dart Editor from dartlang.org. It comes with a copy of the open-source SDK and Dartium. Thanks again for all your feedback – keep it coming.


Lars Bak is a veteran virtual machinist, leaving marks on several software systems: Beta, Self, Strongtalk, Sun's HotSpot and CLDC HI, OOVM Smalltalk, and V8.

Posted by Scott Knaster, Editor

Wednesday, 19 September 2012
Facebook StumbleUpon Twitter Google+ Pin It

Announcing Movi.Kanti.Revo, a new Chrome Experiment

Author PictureBy Pete LePage, Developer Advocate

Cross-posted with the Chromium Blog

Earlier this year at Google I/O, we gave developers a sneak peek at Movi.Kanti.Revo, a new sensory Chrome experiment crafted by Cirque du Soleil and developed by Subatomic Systems that brings the magic of Cirque du Soleil to the web through modern web technologies. The full experiment, which allows users to follow a mysterious character through a beautiful world of Cirque du Soleil performances, was launched today at the Big Tent event in New York City.



The experiment was created using just HTML5, and the environment is built entirely with markup and CSS. Like set pieces on stage, divs, images and other elements are positioned in a 3D space using CSS. To create movement, CSS animations and 3D transforms were applied making the elements appear closer and further away. Everything is positioned and scaled individually to create a highly realistic interactive environment. In addition, the experiment uses HTML5 <audio> to play music and sounds.

Movi.Kanti.Revo breaks with the tradition of keyboard or mouse navigation; instead users navigate through an interactive Cirque du Soleil world with their gestures. To accomplish this, the experiment asks users for permission to access their web cam using the new getUserMedia API. With this new API, the experiment renders the camera output to a small <video> element on the page. A facial detection JavaScript library then looks for movement and applies a CSS 3D transform to the elements on the page, making environment move with the user.


Because this experience was built using just markup, it works in the browser across all devices. The experiment takes advantage of the rich capabilities possible on mobile devices, like the accelerometer to navigate through the world.

To learn more about how this experiment was built, check out the new technical case study or join us for a special Google Developers Live Behind The Divs event on September 20th at 8:30am PDT /15:30 UTC where we’ll be talking to the engineers behind the project.

Head over to Movi.Kanti.Revo at www.movikantirevo.com to check things out, and be sure to open Chrome’s developer tools to see what’s going on behind the <div>s!


Pete LePage is a Developer Advocate on the Google Chrome team and works with developers to create great web applications for the Chrome Web Store. He recently helped launch the +Chrome Developers page on Google+.

Posted by Scott Knaster, Editor

Tuesday, 11 September 2012
Facebook StumbleUpon Twitter Google+ Pin It

Six strategies for building a great Chrome extension

Author Photo
This guest post was written by , CTO of Ecquire

Even though the words "browser extension" connote a one-trick feature, today’s browser extensions allow developers to accomplish some pretty amazing things. Entire companies are being funded and sold as extensions and providing serious value to users.

Here’s how you can make your browser extension a formidable product.

1. Use Your Superpowers

Developing an extension gives you advantages you may not have been aware of. Think of your extension as an abnormally powerful front end. I'll name a few features we've especially enjoyed:
  • Let your users install very slickly directly from your home website to increase conversions.
  • List on the Chrome Web Store for tens of thousands of free impressions. (Tip: For maximum exposure and traffic, invest time in beautiful graphic assets.)
  • Use localStorage as a super-easy store. Unlike in regular web applications, localStorage for extensions remains untouched even if users clear their cookies. (For more structured, asynchronous, client-side storage of large amounts of objects, take a look at IndexedDB.)
  • Let Chrome sync your extension across devices, including data you store in chrome.storage.sync.
Extensions are your chance to hack with any site you've wanted to improve beyond the limits of their API. There are many more very powerful advantages browser extensions have - these are just the lesser known ones.

Check out examples and look at what other apps (even silly ones) have done. If you find yourself asking “how did they do that?”, check out the source code.

2. Know What's Going On Inside Your App

Because extensions are front ends on steroids, you have your pick of almost any web analytics software you choose. We recommend choosing an event-based, not a page view-based model because the definition of a page view is hard to interpret in most extensions. Instead, track specific interactions.

We chose Mixpanel, but there's an official Chrome tutorial on using Google Analytics in an extension. The principles of implementation are the same no matter what you choose.

Solid analytics help you answer questions about what's going on inside your app using hard data instead of intuition and opinions. It will also undoubtedly reveal a few unexpected surprises about user behavior.

3. Connect to Third-Party APIs

Good apps avoid reinventing the wheel, and great apps connect users to the services they already like using. Extensions can request permission to connect with any domain. Just because you're an extension doesn't mean you can't use OAuth to authorize those requests.

If your extension has a server backend, then fantastic, you have plenty of resources to help you. If you want to directly make requests from the user's computer, that is completely possible. The initial handshake and exchange of access token is done from a light server, but after that you can save the tokens locally. This allows your extension to run all of its interactions client-side if you'd like to keep things simple.

4. Make Money

Accepting credit cards and making financial transactions via an extension can be just as ironclad and secure as anywhere else. There's no shortage of billing management services that provide hosted payment pages and APIs.

Simply direct users to secure hosted payment pages to accept credit card information, letting the billing service deal with compliance. We use Recurly, which conveniently allows our users to use coupon codes, receive invoices by email, and manage their billing info directly, saving us even more development time and headache.

Hosted payment pages may be simple to implement, but they are pretty powerful (see also Chargify and CheddarGetter). They allow very specific management of your paying customers. Hosted payment pages can make your extension aware of the user's subscription status, to deactivate or activate as appropriate. Your customers’ payment statuses can be accessed with APIs behind the scenes throughout the lifetime of your extensions.

If you prefer a super-streamlined flow for your customers - one where they potentially do not need to enter their credit card information - using a hosted payment page from Paypal or the recently announced Google Wallet for digital goods are your best bets for maximum coverage and quickest checkout.

Using hosted payment systems affords maximum functionality with the least amount of coding and testing - or any server-side billing logic. Most importantly, you have peace of mind that your customer's financial information is secure and compliant. No compromises.

5. Use Frontend Frameworks

Anywhere there's JavaScript, you can use JQuery, BackboneJS and CoffeeScript: any JS library or plugin you love. This applies across the extension architecture, from injected UI in content scripts to any background code. The entire platform is web frontend - you can run anything you would use in a web application.

6. Test All the Freaking Time

Okay, I admit it's a more fun motto to say than to do, but if you're a TATFTer, I have good news for you. Adrian Unger provides a how-to on using Jasmine BDD in browser extensions even in the sub-cockles of your content scripts, even in the context of a live, logged-in webpage.

Peace of mind about your code is important, but it's even more crucial in extensions where you don't control the webpages you may be injecting into. You can use Jasmine to assert that the DOM of your target web sites hasn't changed too much and that your code is still valid out in the wild web.

In summary, just when you thought you knew everything you could do on the web, new doors open up. This is just a small taste of our lessons learned about what puts browser extensions in the league of extraordinary platforms. Like any new platform, I can’t even imagine the innovation that has yet to launch.


is the CTO of Ecquire, a maker of CRM workflow automation software. Capture contacts from anywhere and Ecquire puts it in the right account for you. Read Tal’s guides on Chrome development and startup experiences on the Ecquire blog.

Posted by Scott Knaster, Editor

Friday, 10 August 2012
Facebook StumbleUpon Twitter Google+ Pin It

Behind the scenes: visualizing the evolution of the web

Deroy
Sergio

This guest post is by Sergio Alvarez, Vizzuality, and Deroy Peraza, Hyperakt, in collaboration with Min Li Chan, Chrome Team

At Google I/O this year, we launched a new version of The Evolution of the Web, a project visualizing the history and pace of innovation in web technologies and browsers. The Evolution of the Web traces how web technologies have evolved in the last two decades and highlights the web community’s continuous efforts to improve the web platform and enable developers to create new generations of immersive web experiences. In collaboration with the Google Chrome team, the team at Hyperakt designed the interactive visualization while Vizzuality built it using HTML5, SVG, and CSS3.


The visualization included 43 web technology "strands" across 7 browser timelines to represent major developments on the web platform. On hover or tap, each strand is highlighted to reveal intersections that tell the story of when browser support was implemented for each new web technology. To provide additional context, we developed a secondary visualization to illustrate the growth of Internet users and traffic.


In addition, this year's design includes the option for viewing the visualization in both day and night mode, making it ideal for large-screen projection.


For the teams working on this site, it was interesting to note that we used roughly 60% of the technologies highlighted in the timeline to build this visualization:
  • We used HTML5, SVG, and canvas to draw the visualization, alongside CSS3 transforms, rotation, and perspective for immersive animation and data interaction.
  • We used CSS3 to kick off the timeline with a 3D-like animation, as well as the panning and zooming functions, toggling between day and night modes.
  • Additionally, we took advantage of the D3 JavaScript library’s interaction and visual frameworks.
In working closely with the Chrome team, we tested multiple approaches to find the best way to bring to life initial design concepts and build a sleek, responsive visualization. In fact, during the project's development, the Vizzuality team came across an SVG rendering issue that prevented the animation from running smoothly. The Chrome team looked into this bug immediately and promptly enabled a fix the following day – a glimpse at the web evolving in real-time, if you will!

We're amazed at how much the web has advanced over the last several years, and the pace of development is only accelerating. Never in the web's history has it been as exciting to be a designer or web developer, and we hope that this visualization captures some of that spirit.


Deroy Peraza is a founding partner and creative director at Hyperakt, a New York City design firm that helps change-makers tell their stories. He was born in Havana, Cuba, and lives in Brooklyn with his wife Jenna and his son Luco.

Sergio Alvarez is co-founder and lead designer at Vizzuality and CartoDB, a NYC-based company working on data analysis and visualization on stories that matter, such as climate change or biodiversity loss. He is a good runner and loves to ride his long board.

Posted by Scott Knaster, Editor

Tuesday, 17 April 2012
Facebook StumbleUpon Twitter Google+ Pin It

Add SPDY support to your Apache server with mod_spdy

Author Photo
Bryan
Author Photo
Matthew

By Matthew Steele and Bryan McQuade,
PageSpeed Insights Team


At Google, we strive to make the whole web fast. Our work in this area includes PageSpeed, Google Chrome, and the SPDY protocol, among other efforts. In December of 2011, to make it easy for you to enable the SPDY (pronounced "SPeeDY") protocol on your sites, we released an early beta of mod_spdy, an Apache module that adds SPDY support to the Apache HTTPD server. We’ve spent the last few months working with our early adopters to fix bugs and tune performance of the module. Today, we’re launching a version of mod_spdy that we encourage you to try on your web server.

Installing mod_spdy

To install mod_spdy on your Apache 2.2 server, simply download the appropriate mod_spdy Debian or RPM package for your platform, or compile from source. Once installed, your Apache server will begin using SPDY to communicate with SPDY-compatible browsers (e.g. Google Chrome, Android, and recent versions of Firefox). SPDY runs over HTTPS, so any HTTP (non-HTTPS) traffic on your site will not be affected by mod_spdy. Further, since SPDY requires server-side support for the NPN TLS HTTPS extension, which is not available in most current Apache environments, a version of mod_ssl with NPN support is included with the mod_spdy packages.

Enabling SPDY for your site improves performance in several ways:
  • The server and browser can compress HTTP headers, saving bytes on the network.
  • Multiple resource requests can be multiplexed over a single TCP connection, saving connections on the network.
  • The browser can request all page resources at once instead of a few at a time, which reduces the number of network round-trips needed between server and client.
We've tested mod_spdy using locally-mirrored pages from popular websites, and have seen significant speedups compared to serving via plain HTTPS – comparable to the gains that Google’s own servers achieve by using SPDY – with no extra configuration and negligible effect on Apache’s CPU and memory usage. In extreme cases, for example, pages with many small resources, we’ve seen mod_spdy reduce load times by more than 50%.



How mod_spdy works in Apache

Implementing SPDY in Apache posed several interesting challenges. For example, multiplexing is an important performance feature of SPDY which allows for multiple requests in a single SPDY session to be processed concurrently, and their responses interleaved down the wire. However, due to the serialized nature of the HTTP/1.1 protocol, the Apache HTTP server provides a one-request-per-connection architecture. Apache’s connection and request processing normally happens in a single thread, like so:


single thread

This works well for HTTP, but it presents a problem for multiplexed protocols like SPDY because in this flow, each connection can only process one request at a time. Once Apache starts processing a request, control is transferred to the request handler and does not return to the connection handler until the request is complete.

To allow for SPDY multiplexing, mod_spdy separates connection processing and request processing into different threads. The connection thread is responsible for decoding SPDY frames and dispatching new SPDY requests to the mod_spdy request thread pool. Each request thread can process a different HTTP request concurrently. The diagram below shows the high-level architecture.


multiple threads

Happily, all this is almost completely invisible to users and server administrators alike--you can continue to use your existing Apache modules and configurations.

Download mod_spdy for your platform and give it a try, and let us know what you think on our mailing list. mod_spdy is an open-source project and we welcome contributions. We are continuing to add new features, tune performance, and improve support for up-and-coming versions of the SPDY protocol.


Matthew Steele and Bryan McQuade are Software Engineers on the Google PageSpeed Insights Team in Cambridge, MA. When not working on mod_spdy, they focus on developing tools to help site owners understand how to speed up their sites.

Posted by Scott Knaster, Editor

Friday, 13 April 2012
Facebook StumbleUpon Twitter Google+ Pin It

Fridaygram: Chrome tools, Goldberg machines, Lehrer songs

Author Photo
By Scott Knaster, Google Developers Blog Editor

If you use Google Chrome and you like to live on the edge, you might want to try Google Chrome Canary. There's a new version of Chrome Canary pretty much every day, and it gets the latest features. Of course, because it's built every day, sometimes it’s not very stable and it falls right off the leading edge it's balanced on. That’s why, for safety, you can install and run the stable version of Chrome alongside the Canary version.

Recent Canary builds have added cool new features to the developer tools section of Chrome. Specifically, you can now test mobile environments by simulating different screen sizes and by emulating touch events using the mouse. These features are on the Settings page of developer tools.


If you haven’t visited Chrome's developer tools before, you might be pleasantly surprised at all the nifty things available there. To get to developer tools, click the Wrench in Chrome, then choose Tools > Developer Tools. Have a look around – if you need a guide, see the documentation.

Some developers make hardware too, and a bunch of them competed in this year’s Rube Goldberg Machine Contest at Purdue University. The winning team broke a record – their own record – by building a machine that takes 300 steps to inflate and pop a balloon. When you consider that 14 people spent 5000 hours on this project, you realize the power of creativity mixed with craziness.

Finally, take a moment to celebrate Tom Lehrer's birthday week by listening to some of his classic tunes. As a math professor / musician / parodist, nobody expresses the spirit of Fridaygrams better than Tom Lehrer.


Fridaygram posts are just for fun. They're designed for your Friday and weekend enjoyment. Each Fridaygram item must pass only one test: it has to be interesting to us nerds. Disclaimer: we do not advocating poisoning pigeons, whether in the park or elsewhere.

Tuesday, 13 March 2012
Facebook StumbleUpon Twitter Google+ Pin It

Meet the web platform again for the first time

By Alex Komoroske, Product Manager

Cross-posted with the Chromium Blog

A few weeks ago one of my developer friends was gushing about the capabilities of his favorite native platform. After every point I felt obliged to point out that the web platform either already had or was actively developing precisely the same capabilities—and then some. He was incredulous. "Prove it," he said.

So I pulled together a few of my favorite examples from the cutting edge of the web platform and recorded three screencasts to help my friend—and others—meet the web platform again for the first time.

The first video, Building on Foundations, goes over how the web platform has been fixing various historical shortcomings and building upon its core strengths, like complicated graphical effects, composability, and advanced text layout.



The next video, Learning from Other Platforms, reviews how the web platform offers new capabilities inspired by successes on other platforms with things like push notifications, payment APIs, and web intents.



The last video, On the Cutting Edge, demonstrates some of the new tricks the web platform is learning, like webcam access, powerful audio APIs, and complicated 3D graphics.



If you're interested in learning more about the technology behind any of the demos, check out the Meet the Web Platform companion guide.

I hope these videos capture your imagination and begin to show what is possible on the web platform. The web platform is evolving at an enormous pace, and I just can't wait to see where it goes next!


Posted by Scott Knaster, Editor

Thursday, 8 March 2012
Facebook StumbleUpon Twitter Google+ Pin It

Introducing Page Speed mobile analysis, on Google Chrome for Android

Matthew
Libo

By Libo Song and Matthew Hillyard, Software Engineers

Nearly a year ago, we launched Page Speed for Chrome, which has enabled Chrome users to get Page Speed performance suggestions to make their desktop sites faster. Today, we are releasing an update to Page Speed for Chrome that supports mobile Page Speed analysis via Chrome for Android. With Page Speed for Chrome and Chrome for Android, you can perform Page Speed analysis on the mobile version of your web pages, as they are loaded in the Chrome for Android mobile browser.

Many web sites serve mobile-specific versions of their pages. Often, the mobile pages have very different Page Speed scores and Page Speed reports from their desktop counterparts. Page Speed on Chrome for Android makes it easy to analyze both the desktop and mobile versions of your web pages, so you can be sure that your pages load faster for the users of both your desktop and mobile sites.

When analyzing the mobile version of pages, Page Speed for Chrome tunes its analysis to reflect the unique performance characteristics of mobile devices and networks, suggesting the optimizations that will have the biggest impact on reducing load times for your mobile users. Using the powerful Chrome Developer Tools Extension APIs, Page Speed for Chrome can identify renderer performance optimizations that are especially relevant on mobile, such as removing unnecessary reflows and finding long-running scripts that slow down your pages. Page Speed for Chrome will also automatically minify and optimize your HTML, JavaScript, CSS, and image files and make them available for you to download, so you can easily deploy them on your web server.

To get started using Page Speed on Chrome for Android:
  • Follow the instructions to install the Page Speed for Chrome extension on your desktop Chrome browser.
  • Enable remote debugging in Chrome running on your Android device.
  • Navigate to the remote Chrome Developer Tools page in your desktop browser (localhost:9222) .
  • Select one of the Chrome tabs running on your Android device.
In addition to the full Chrome Developer Tools, you will see Page Speed in the Developer Tools panel. Click the Page Speed icon to switch to the Page Speed tab, then click Run Page Speed to generate mobile Page Speed suggestions for the web page that’s loaded on your Android device.


Page Speed screen shot

We hope you’ll give Page Speed for Chrome on Android a try. Please send us feedback via our discussion list and let us know what features you’d like to see us to add next. You may also be interested in watching our recent Google I/O talk on Page Speed performance best practices for mobile web sites.


Libo Song is a software engineer at Google Boston working on the Page Speed team to make the web faster.

Matthew Hillyard worked on the Page Speed team as an intern. He has since graduated with a Master’s degree in computer science from Johns Hopkins University and currently is a software engineer on the Google+ team.

Posted by Scott Knaster, Editor

Monday, 5 March 2012
Facebook StumbleUpon Twitter Google+ Pin It

1-up for web games

Author Photo
By David Glazer, Engineering Director, Google+

Hundreds of millions of users are already having fun playing games on the web. With GDC going on this week (#googlegdc), we wanted to give you an update on our efforts to improve the web ecosystem for game developers.

New technology capabilities

With HTML5, WebGL, and WebRTC, the browser has evolved into a feature-rich gaming platform. We are working closely with all browser vendors to further improve the web’s capabilities with new HTML5 APIs such as Gamepad, Mouse Lock, and Fullscreen.

Native Client (NaCl), a technology that enables console quality games in the browser, is also gaining traction. Starting today, the BlitzTech Gaming engine and the Havok Physics Engine have announced NaCl support, complementing a rich ecosystem of game middleware. Some of the latest games that take advantage of NaCl’s capabilities are Zombie Track Meat, Eets Munchies, Go Home Dinosaurs, Dark Legends, Air Mech, and Ubisoft’s From Dust. You can see an early preview of them at our GDC booth.


Improved distribution and monetization

Using social information in game play allows users to connect in more meaningful ways and developers to build even more compelling games. Google+ games continues to grow and attract exciting new games, including the exclusive launch of the epic fantasy title Kingdom Age last week. To help social game developers reach more users globally, all Google+ games will soon be available in the Chrome Web Store, providing an audience of hundreds of millions of users.

In addition, our In-App Payments solution recently added support for more currencies and optimized the payment flow to enable higher conversions.

Visit us at GDC and on the web

To get started working with us, you can now access a new site, developers.google.com/games, that pulls together all our technologies to help you build, distribute, promote, and monetize your games. And for those of you attending GDC this week, stop by our developer day and our booth. We are looking forward to continuing our collaboration with the gaming community and bringing the best games to hundreds of millions of Internet gamers.


David Glazer, Engineering Director for Google+ .

Posted by Scott Knaster, Editor

Tuesday, 28 February 2012
Facebook StumbleUpon Twitter Google+ Pin It

Introducing Technitone: Showcasing the Web Audio API, multiplayer and live in WebGL

Author Photo
By Paul Irish, Chrome Developer Relations

The Web Audio API, currently available in Chrome, provides a considerable amount of aural power to developers interested in integrating audio into their apps and games. Low latency audio playback, audio generation and realtime effects are available with a sensible API in Chrome stable.

We worked with gskinner.com to develop Technitone, a web audio experience that lets you join other players to plot tones on a grid, construct melodies and modify the output with a robust toolset of effects.


technitone logo

Click on over and poke around.
  • Your tone samples can come from your own recordings, or any of the available samples.
  • The left side Tools panel offers realtime audio filters, like echo reverb and pitch shift.
  • We keep you connected to other players in realtime using WebSockets and Node.js.
  • You can drop into solo mode or invite your friends to join you in a session.
  • Get inspired by others’ audio creations in the gallery.
If you’re interested in the techniques and software behind the project, take a look at the case study with plenty of sample code and demos on HTML5 Rocks: http://www.html5rocks.com/en/tutorials/casestudies/technitone/


Paul Irish helps developers build compelling apps for the web on the Chrome Team. He also works on HTML5 Boilerplate, Modernizr, and many bits and bobs of open source code.

Posted by Scott Knaster, Editor

Tuesday, 14 February 2012
Facebook StumbleUpon Twitter Google+ Pin It

Building Web Apps? Check out our Field Guide

Author Photo
By Pete LePage, Developer Advocate

Yesterday, the Chrome Developer Relations team launched several new resources, including the Field Guide to Web Applications. It’s a new resource that is designed to help web developers create great web apps. We’ve heard loud and clear from users that they want more and better web apps, and we hope this new field guide will enable you to create those web apps. Our fictitious author Bert Appward guides you through topics like the properties of web applications, design fundamentals, tips for creating great experiences, and a few case studies that put best practices to use. Whether you're building your first web app or are just looking for ways to improve your existing apps, I hope you'll find the field guide useful.




We built the field guide to embody the principles and best practices that it preaches. We stepped away from the normal webpage look, and instead designed the experience around a field guide. We used many CSS3 features like box-shadow, opacity, multiple backgrounds and more to provide a rich, visual experience. To make sure that it worked offline, we used AppCache and other than some URL rewriting techniques, didn't use any server-side code. We used the HTML5 History API to maintain page state even though everything is served from a single HTML page. We've started working on a new case study about the field guide, so check back soon for that!


Pete LePage is a Developer Advocate on the Google Chrome team and works with developers to create great web applications for the Chrome Web Store. He recently helped launch the +Chrome Developers page on Google+.

Posted by Scott Knaster, Editor

Tuesday, 31 January 2012
Facebook StumbleUpon Twitter Google+ Pin It

Angry Birds Chrome now uses the Web Audio API

Author Photo
By Fred Sauer, Developer Advocate

Cross-posted with the Google Web Toolkit Blog

Last week Angry Birds for Chrome was updated to use the Web Audio API for all its in-game audio for Chrome users, which means Chrome users get the full Angry Birds experience, without any plugins. The Web Audio API supports a wide variety of use cases, including the high fidelity and low latency requirements of games. Users of other supported browsers will still get sound via Flash or HTML5 audio.



How does this cross-browser audio magic work? As you may have seen or heard, Angry Birds was in no small part made possible by the cross-platform open source PlayN library. When building for the HTML platform, PlayN in turn relies heavily on Google Web Toolkit (GWT) to delivery a highly optimized web experience for users, and on gwt-voices to easily deliver a cross-browser audio experience.

The responsibility of choosing the appropriate audio API for the game's sound is (mostly) left up to gwt-voices, which chooses the audio API that will give the best experience. If you'd like to hear how other audio APIs perform, you can ask gwt-voices to try to use the Web Audio API, Flash, HTML5 Audio, or even native audio. Your mileage will vary by browser and platform and which plugins you have installed. Also, gwt-voices will select the best available fallback, if the desired audio API is not going to work at all in your environment.

Want to learn more? Check out the Web Audio API tutorial and don't let those pigs grunt too much.


Fred Sauer is a Developer Advocate at Google where most of his time is devoted to Google App Engine and Google Web Toolkit. He is the author of various GWT related open source projects including gwt-dnd (providing in browser Drag and Drop capabilities), gwt-log (an advanced logging framework) and gwt-voices (for cross browser sound support). Fred has dedicated much of his career to Java related development, with an increasing focus on HTML5.

Posted by Scott Knaster, Editor

Thursday, 26 January 2012
Facebook StumbleUpon Twitter Google+ Pin It

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