Posted:
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

Posted:
Marcin
Aaron

By Aaron Wheeler, Senior User Experience Prototyper, and Marcin Wichary, Senior User Experience Designer

Cross-posted with the Chromium Blog

It took approximately 2000 years for the original Rosetta Stone to be discovered, which helped translate the Egyptian Hieroglyphs. We couldn’t wait that long to bridge the Dart and JavaScript worlds, so today we are releasing the JavaScript to Dart Synonym app.

Like most web developers, we are familiar, comfortable, and productive with JavaScript. We were curious about Dart, and thanks to a recent Dart hackathon, we had the chance to play with the language and libraries. The problem was, as JavaScript developers, we didn’t know how to map common JavaScript idioms to Dart. Hence the idea for this synonym app was born.

We started with the basics that every JavaScript and jQuery developer knows: variables, arrays, functions, classes, DOM manipulation, and many more. Then, with the help of the Dart team, we recorded the corresponding Dart versions of each idiom. To practice what we learned, we wrote this app with Dart.



We hope our app that maps between JavaScript and Dart eases your introduction to Dart and gives you a sense of where the project is going. We know the team is eager to hear your feedback. Don’t hesitate to join the conversation or file a new issue for either Dart or the Synonym app. And remember, Dart isn’t set in stone, so your feedback counts.


Aaron Wheeler is a user experience prototyper working on special projects that go beyond the Web. He balances design and engineering outside of work as well, splitting time between artistic pursuits and bicycle maintenance.

Marcin Wichary is a user experience designer, currently working on the Chrome browser and thinking of the future of the Web platform. He also occasionally codes interactive homepage doodles, such as Pac-Man and Stanislaw Lem.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Rania Hadi, MENA Outreach Manager

View this post in Arabic

Building on a year packed with g|days throughout the Middle East and North Africa, today we are announcing Google MENA’s first 2012 event to kick off the new year. On March 24-25, Google, in collaboration with Badir Technology Incubator, will be hosting our second event in the Kingdom: g|saudi arabia 2.0.

We’re coming to Jeddah with a host of fresh sessions on all things technology and business. Google engineers, product managers, and business leaders will be there to not only deliver trainings but will be available for any questions, ideas, or discussions you may want to have. We’re also planning some new formats: hands-on workshops, dedicated sessions for women in technology, and chances to showcase Saudi’s finest developer talent.

So if you are a developer, programmer, IT professional, entrepreneur, or small business/start-up, you won’t want to miss this event! If you need more convincing, have a look at the fun, enthusiasm and energy from last year.




Rania Hadi has been with Google since 2004 and now works on Outreach in MENA. She focuses on building relationships and promoting Google technologies with the developer and tech communities.

Posted by Scott Knaster, Editor

Posted:
Author Photo
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.

Posted:
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

Posted:
Author Photo
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

Posted:
Author Photo
By Scott Knaster, Google Code Blog Editor

Last Wednesday, the web looked very different than it usually does. Dozens of popular sites went dark or were modified in some way. We censored the logo on our homepage. As you probably know by now, all this was done to call attention to prospective legislation being debated by the U.S. Congress: the Stop Online Piracy Act (SOPA) and the PROTECT IP Act (PIPA). These bills would censor the web, eliminate due process, and despite their titles, would not stop piracy.

We asked you to take action by signing a petition to Congress, and you responded. More than 7 million people in the U.S. added their names to the petition. We’re asking you to please keep sharing the petition with your friends at http://www.google.com/takeaction.

Let’s go from the U.S. Congress to the British Geological Survey, where Howard Falcon-Lang recently discovered a wooden cabinet tucked away in a corner. Inside the cabinet were rock samples with the signature C. Darwin, Esquire. As in Charles Darwin. It turns out that these samples were collected by Darwin during his HMS Beagle voyages in the 1830s, and had been misplaced for 165 years. Probably they’ll keep better track of the Darwin samples now.

Finally, for something that’s just really cool, please take a look at this video that zooms into an image of the Helix Nebula in the constellation Aquarius. Enjoy!




Fridaygram posts are generally just for fun, although we’ve put on our serious hat for the main item today. 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.

Posted:
Author Photo
By Nicolas Garnier, Developer Relations Team

Cross-posted from the Google Apps Developer Blog

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 the Google Apps Developer Blog.


Nicolas Garnier joined Google’s Developer Relations team in 2008 and lives in Zurich. He is a Developer Advocate focusing on Google Apps and Web APIs. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Navneet Joneja, Product Manager

Google Cloud Storage is a robust, high-performance service that enables developers and businesses to use Google’s infrastructure to store and serve their data. Today, we’re announcing a new feature that gives you greater control over concurrent writes to the same object, and the availability of an App Engine Files API that makes it easier to read and write data from Java App Engine applications.

Write concurrency control

A number of our customers have asked us for greater control over concurrent writes, in order to implement features like strongly consistent write operations and distributed locking semantics in the cloud. In response to your feedback, we’re announcing the release of version-based concurrency control. Every time you update an object, it gets assigned a 32-bit, monotonically increasing sequence number. This version number is returned as a header with every GET or HEAD request. You can then use a conditional write operation to manage concurrent updates to the object (for example, when you want read-modify-write semantics). This feature is currently experimental.

AppEngine Files API for Java applications

Last fall, we announced the ability to read and write your Google Cloud Storage data using the App Engine Files API for Python applications. Today, we’re making the Files API available to Java App Engine applications too. This feature is currently experimental, and we’ll continue to enhance it in the months to come.

As always, we welcome your feedback in our discussion group. If you haven’t tried Google Cloud Storage yet, you can sign up and get started here.


Navneet Joneja loves being at the forefront of the next generation of simple and reliable software infrastructure, the foundation on which next-generation technology is being built. When not working, he can usually be found dreaming up new ways to entertain his intensely curious almost-two-year-old.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Scott Knaster, Google Code Blog Editor

This week we launched the 2012 Google Science Fair for students ages 13 to 18. For the Science Fair, young scientists are asked to pose a question, answer it through scientific inquiry, and report the results online. We’ll pick 90 regional finalists, then choose the top 15 to come to Google in Mountain View, California. Nobel laureates and other distinguished folks will judge the finalists.



Grown-up scientists working in the Papua New Guinea rain forest recently heard what sounded like an insect call, then tried to find out what was making the noise. Eventually they bagged leaf litter from the forest floor and began to sort through it, when a tiny frog jumped out. It was Paedophryne amauensis, and at an average length of 7.7 millimeters, it’s said to be the world’s smallest vertebrate. So watch your step the next time you’re walking around the rain forest.

Finally, in celebration of today’s day and date, please take a look at these wonderful photos from a Friday the 13th party in 1940, where attendees tempted fate by breaking a mirror, walking under a ladder, and otherwise indulging in every superstition they could think of. After you’re done, cross your fingers and hope for a great weekend.


Happy new year! 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.

Posted:
Author Photo
By Melina Mattos, Program Manager, Google Africa

Cross-posted from the Google Africa Blog

2011 was a busy year for the Google Africa team. The g|Day developer and business conference visited Senegal, Ghana, Nigeria, Cameroon, Uganda, Kenya, South Africa, and Angola in 2011, expanding from 5 countries in 2010 and from 2 in 2009. Over the year, business professionals, entrepreneurs, and marketers have explored innovative technologies to get online and to serve their business needs. Developers and webmasters have had an in-depth look at Android, Chrome, App Engine, Maps, Webmaster Tools, and more.

While we are excited about all the activity growing in the local communities, we are always looking for opportunities to engage with new communities of developers, business leaders, and entrepreneurs who are as passionate about technology as we are. Therefore, we are excited to kick off the 2012 G-Day roadshow with G-Tanzania and G-Ethiopia.

G-Tanzania will be held on February 2nd and 3rd at Mlimani City Conference Center in Dar es Salaam, followed by G-Ethiopia on February 7th and 8th at the Hilton Hotel and Conference Center in Addis Ababa.

Registration is now open for these free events. Space is limited so be sure to register as soon as possible for G-Tanzania and G-Ethiopia to improve the chances of your application being accepted. We look forward to seeing you soon!


Melina Mattos is a Program Manager for the Sub-Saharan Africa Outreach team. When she's not busy working with developer and business communities in Africa, she's either exploring the great outdoors, sitting on a plane, or playing with her camera.

Posted by Scott Knaster, Editor

Posted:
Author Photo
By Raph Levien, Engineer, Google Web Fonts

One of Google’s core principles is that "fast is better than slow", and the Web Fonts team takes that to heart. We’re always looking for ways to make web fonts load faster, and that’s doubtless a key factor in our rapid user adoption. Today, we are announcing a new way to make web fonts smaller and faster, in collaboration with the Monotype Imaging Fonts.com Web Fonts team. Google Web Fonts now implements Monotype Imaging’s MicroType Express compression format, which yields an approximate 15% savings in file size over using gzip alone. This change will automatically speed up Google Web Fonts for Internet Explorer browsers (version 6 and up). We’re also actively working to offer improved compression with other modern browsers, including Google Chrome.

We’ve kept the interface simple, so designers don’t need to update their integrations in any way — we’ll automatically upgrade the CSS snippet and font files so that site designers and visitors get their fonts faster. We’ve done this for previous speed optimizations as well, such as automatically stripping the hints (metadata used for improving rendering quality on Windows) when serving fonts to Mac, iOS, and Android clients. We expect that most future optimizations will also be automatic and transparent.

Monotype Imaging has agreed to make MicroType Express available to the public at no cost; the license can be found at monotypeimaging.com/aboutus/mtx-license. We believe it’s friendly to both open source and proprietary implementations.

Today, we are also releasing an implementation of MicroType Express compression as part of the Embedded OpenType converter in the open-source sfntly library, adding to the existing WOFF compression. The sfntly library, developed by the Google Internationalization Engineering team, serves as the core conversion engine in Google Web Fonts for subsetting, hint stripping, and related functions of our dynamic serving path. We hope that all web font services, as well as people hosting their own web fonts, will use sfntly to optimize font serving across the web.

We are proud to be working with Monotype Imaging, and we look forward to learning more from designers, users, sites and other partners to advance the state of web fonts together!


Raph Levien is an expert on fonts and graphics technologies. Raph designed Inconsolata, one of the fonts available on the Web Font API. Raph enjoys photography and spending time with his family.

Posted by Scott Knaster, Editor