Saturday, February 11, 2012

[Gd] Dev Channel Update for Chromebooks

| More

Chrome Releases: Dev Channel Update for Chromebooks

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

This build contains a number of stability improvements. Additional changes:
  • Updated Pepper Flash version
  • 25865 - Fixes to crashes generated and blank screen being seen after browser crash
  • Improvements to video playback from File Browser
Known issues:
  • Issue on signing out: Please note that in some circumstances if you are connected via a proxy, signing out of your Chrome OS session may not work. Users may see 8 or more seconds of a blank screen followed by being returned to the previous signed in state. If you encounter this problem, please submit a feedback report (Wrench > Report an Issue) mentioning this issue. Please include the tag '#CantSignOut' and the approximate time you encountered this issue.  Workaround: Shutdown the machine using either the power button or the Wrench menu > Sign out option, and restart the machine to login as a different user. 
  • 26127: Videos do not play in full screen mode. This affects multiple sites including YouTube and others.
If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu.

Danielle Drew
Google Chrome

[Gd] Dev Channel Update

| More

Chrome Releases: Dev Channel Update

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

  • Updated V8 -
  • Fix: open incognito windows at exit created extra normal windows when the session was restored [r120554]
  • Show spelling suggestions for misspelled words from the online spellchecker provided by Google (only after users opt into sending text to the service) (r120959).
  • When translating a page, get the code and translation via HTTPS. (r120113)
  • Fix a visual artifact when UI bubbles fade [r119916]
  • Fix an infrequent crash on repaint [r120196]
  • Fix 3D acceleration on computers with NVIDIA Optimus graphics [r120651]
  • Use Google’s online spellchecker to identify misspelled words as well as provide suggestions, for pasted text only. (r120959).
  • Fixed a crash that could occur if a page was closed while playing audio [r120749].
  • Use Google’s online spellchecker to identify misspelled words as well as provide suggestions, for pasted text only. (r120959).
Known Issues
  • Sub-dialogs do not work in Settings [Issue: 113505, et al].
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

Friday, February 10, 2012

[Gd] The Future of JavaScript – take a peek today!

| More

Chromium Blog: The Future of JavaScript – take a peek today!

The ECMA committee is working hard on designing the next version of JavaScript, also known as "Harmony". It is due by the end of next year and it is going to be the most comprehensive upgrade in the history of this language.

Chrome and V8 are committed to pushing JavaScript forward and have already started implementing the new features. You can try some of them today in the latest dev channel release. Here’s a summary:

  • Lexical scoping. Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour. Function declarations are now officially allowed in local scope as well, and also obey lexical scoping. (Note: Lexical scoping is only available in ES strict mode.)
  • Collections. Efficient maps and sets will make your life easier. Any value can be used as a key or element, including objects. No surprises, no more need to abuse objects as dictionaries. (Caveat: Iteration over collections is not yet specified.)
  • Weak maps. A special kind of map for which the garbage collector determines when a key is no longer reachable, so that the key-value pair can be removed from the map automatically. This goes a long way towards avoiding memory leaks in long-lived tables and relieves the developer from worrying about stale entries.
  • Proxies. A proxy simulates a JavaScript object or function, and can customize just about any aspect of their behaviour that you can imagine. This is a real power feature, that takes reflection to a new level and can be used to implement various advanced abstractions and interfaces
 ...and there is a lot more to come, as the V8 team will continue working on bringing new Harmony features to you.

To enable Harmony features in the latest dev channel release of Chrome, go to chrome://flags and toggle on "Experimental JavaScript features". We encourage you to try them out and give us feedback!

Posted by Andreas Rossberg and Michael Starzinger, Software Engineers

[Gd] Fridaygram: Unicode, ancient lake, very ancient sound

| More

The official Google Code blog: Fridaygram: Unicode, ancient lake, very ancient sound

Author Photo
By Scott Knaster, Google Code Blog Editor

Unicode was created with the ambitious goal of representing every human language, with room left over for a whole bunch of symbols, too. More than 20 years after Unicode was started, over 60% of the pages on the web are now encoded in Unicode. That’s pretty good growth when you consider that Unicode’s coverage was less than 5% of the web in 2005. Having a standard like Unicode is important because, as Mark Davis writes, "The more documents that are in Unicode, the less likely you will see mangled characters (what Japanese call mojibake) when you're surfing the web."

In news of older stuff, a Russian expedition that has been working for 10 years has finally drilled through Antarctic ice and reached Lake Vostok, a huge freshwater lake more than 12,000 feet below the surface. The ice has covered this lake for at least 15 million years, which is well before the work on Unicode began. Eventually the team will take samples of the lake water, looking for signs of life and other ancient treasures.

Finally, you can go back even further in time and listen to the song of a cricket that was around during the Jurassic period, 165 million years ago. That cricket really sounds great for its age.

On Fridays we take a break and do a Fridaygram post just for fun. Each Fridaygram item must pass only one test: it has to be interesting to us nerds.


[Gd] Chrome Beta Release

| More

Chrome Releases: Chrome Beta Release

The Chrome team is happy to announce the arrival of Chrome 18.0.1025.11 to the Beta Channel for Windows, Mac, Linux, and Chrome Frame.

Chrome 18 contains some really great improvements including GPU accelerating 2D Canvas, and enabling 3D content for older GPUs. More on what's new at the Official Chrome Blog and the Chromium Blog.

You can find full details about the changes that are in Chrome 18 in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Karen Grunberg
Google Chrome

[Gd] GPU accelerating 2D Canvas and enabling 3D content for older GPUs

| More

Chromium Blog: GPU accelerating 2D Canvas and enabling 3D content for older GPUs

Today’s Beta release brings 2D Canvas improvements and a software rasterizer to Chrome.

For most Windows and Mac users, we’ve enabled GPU-accelerated rendering of 2D Canvas content, so that canvas-based games and animations run faster and feel smoother. You can go to chrome://gpu to see which features are being accelerated. This is a tricky area to optimize, due to the wide variety of hardware and operating system configurations found in the wild. We’ve made a series of small improvements to the way this acceleration works in the latest release, and we're seeking feedback on it from our Beta users. If you notice performance problems with 2D Canvas graphics content, particularly if you’re a web developer using 2D Canvas on your site, please file a bug.

At the same time, we recognize that many people with older GPUs and graphics drivers have not been able to experience the rich content provided by technologies such as WebGL. Chrome is now able to display 3D content via SwiftShader, a software rasterizer we licensed from TransGaming, Inc. Although SwiftShader won’t perform as well as a real GPU, it will be an improvement for many of our users on older operating systems such as Windows XP.

SwiftShader automatically kicks in for those users who cannot run content on the GPU. If you want to take a peek at what the performance is like with SwiftShader, you can use the --blacklist-accelerated-compositing and --blacklist-webgl flags, wait a few minutes for the automatic download to complete, and then load the relevant web page.

As always, we appreciate your willingness to try out our creaky Beta software and look forward to your feedback and bug reports.

Posted by John Bauman and Brian Salomon, Software and Pixel Engineers

[Gd] Expanding the Chromium Security Rewards Program

| More

Chromium Blog: Expanding the Chromium Security Rewards Program

It’s hard for us to believe, but it’s been just over two years since we first announced the Chromium Security Rewards Program.

We’ve been delighted with the program’s success; we’ve issued well over $300,000 of rewards across hundreds of qualifying bugs, all of which we promptly fixed. It also helped inspire a wave of similar efforts from companies across the web, including Google’s own vulnerability reward program for web properties, which has also been a big hit.

We’ve been fascinated by the variety and ingenuity of bugs submitted by dozens of researchers. We’ve received bugs in roughly every component, ranging from system software (Windows kernel / Mac OS X graphics libraries / GNU libc) to Chromium / WebKit code and to popular open source libraries (libxml, ffmpeg). Chromium is a more stable and robust browser thanks to the efforts of the wider security community.

Today we’re expanding the scope of the Chromium program to formally include more items that deserve recognition:
  • High-severity Chromium OS security bugs are now in scope. Chromium OS includes much more than just the Chromium browser, so we’re rewarding security bugs across the whole system, as long as they are high severity and present when “developer mode” is switched off. Examples of issues that may generate a reward could include (but are not limited to): 
    • Renderer sandbox escapes via Linux kernel bugs. 
    • Memory corruptions or cross-origin issues inside the Pepper Flash plug-in. 
    • Serious cross-origin or memory corruption issues in default-installed apps, extensions or plug-ins. 
    • Violations of the verified boot path. 
    • Web- or network-reachable vulnerabilities in system libraries, daemons or drivers.
Chromium OS security bugs should be reported in the Chromium OS bug tracker, whilst security bugs affecting the desktop Chromium browser should be reported in the Chromium bug tracker.
  • We may elect to issue “bonuses” ranging from $500 to $1000 if a bug reporter takes on fixing the bug they have found themselves. For eligibility, this process involves working with the Chromium community to produce a peer reviewed patch. These bonuses are granted on top of the base reward, which typically runs between $500 and $3133.70. 
  • The base reward for a well-reported and significant cross-origin bug (for example a so-called UXSS or “Universal XSS”) is now $2000. 
Perhaps most importantly, this program reflects several of our core security principles: engaging the community, building defense in depth, and particularly making the web safer for everyone.

Related to this third core principle, we’re particularly excited by all the work that has been done on shared components. For example, a more robust WebKit not only helps users of two major desktop browsers, but also a variety of tablet and mobile browsers.

Posted by Chris Evans, Google Chrome Security

Thursday, February 9, 2012

[Gd] Preparing your site for a traffic spike

| More

Official Google Webmaster Central Blog: Preparing your site for a traffic spike

Webmaster level: Intermediate

It’s a moment any site owner both looks forward to, and dreads: a huge surge in traffic to your site (yay!) can often cause your site to crash (boo!). Maybe you’ll create a piece of viral content, or get Slashdotted, or maybe Larry Page will get a tattoo and your site on tech tattoos will be suddenly in vogue.

Many people go online immediately after a noteworthy event—a political debate, the death of a celebrity, or a natural disaster—to get news and information about that event. This can cause a rapid increase in traffic to websites that provide relevant information, and may even cause sites to crash at the moment they’re becoming most popular. While it’s not always possible to anticipate such events, you can prepare your site in a variety of ways so that you’ll be ready to handle a sudden surge in traffic if one should occur:
  • Prepare a lightweight version of your site.
    Consider maintaining a lightweight version of your website; you can then switch all of your traffic over to this lightweight version if you start to experience a spike in traffic. One good way to do this is to have a mobile version of your site, and to make the mobile site available to desktop/PC users during periods of high traffic. Another low-effort option is to just maintain a lightweight version of your homepage, since the homepage is often the most-requested page of a site as visitors start there and then navigate out to the specific area of the site that they’re interested in. If a particular article or picture on your site has gone viral, you could similarly create a lightweight version of just that page.
    A couple tips for creating lightweight pages:
    • Exclude decorative elements like images or Flash wherever possible; use text instead of images in the site navigation and chrome, and put most of the content in HTML.
    • Use static HTML pages rather than dynamic ones; the latter place more load on your servers. You can also cache the static output of dynamic pages to reduce server load.
  • Take advantage of stable third-party services.
    Another alternative is to host a copy of your site on a third-party service that you know will be able to withstand a heavy stream of traffic. For example, you could create a copy of your site—or a pared-down version with a focus on information relevant to the spike—on a platform like Google Sites or Blogger; use services like Google Docs to host documents or forms; or use a content delivery network (CDN).
  • Use lightweight file formats.
    If you offer downloadable information, try to make the downloaded files as small as possible by using lightweight file formats. For example, offering the same data as a plain text file rather than a PDF can allow users to download the exact same content at a fraction of the filesize (thereby lightening the load on your servers). Also keep in mind that, if it’s not possible to use plain text files, PDFs generated from textual content are more lightweight than PDFs with images in them. Text-based PDFs are also easier for Google to understand and index fully.
  • Make tabular data available in CSV and XML formats.
    If you offer numerical or tabular data (data displayed in tables), we recommend also providing it in CSV and/or XML format. These filetypes are relatively lightweight and make it easy for external developers to use your data in external applications or services in cases where you want the data to reach as many people as possible, such as in the wake of a natural disaster.
We’d love to hear your tips and tricks for weathering traffic spikes—come join us in our Webmaster Help Forum.

Posted by , Webmaster Trends Analyst

[Gd] Share With Intents

| More

Android Developers Blog: Share With Intents

[This post is by Alexander Lucas, an Android Developer Advocate bent on saving the world 5 minutes. —Tim Bray]

[Please join the discussion on Google+.]

Intents are awesome. They are my favorite feature of Android development. They make all sorts of stuff easier. Want to scan a barcode? In the olden platforms, if you were lucky, this involved time and effort finding and comparing barcode-scanning libraries that handled as much as possible of camera interaction, image processing, an internal database of barcode formats, and UI cues to the user of what was going on. If you weren’t lucky, it was a few months of research & haphazard coding to figure out how to do that yourself.

On Android, it’s a declaration to the system that you would like to scan a barcode.

public void scanSomething() {
// I need things done! Do I have any volunteers?
Intent intent = new Intent("");

// This flag clears the called app from the activity stack, so users arrive in the expected
// place next time this application is restarted.

intent.putExtra("SCAN_MODE", "QR_CODE_MODE");
startActivityForResult(intent, 0);
public void onActivityResult(int requestCode, int resultCode, Intent intent) {
if (requestCode == 0) {
if (resultCode == RESULT_OK) {
// The Intents Fairy has delivered us some data!
String contents = intent.getStringExtra("SCAN_RESULT");
String format = intent.getStringExtra("SCAN_RESULT_FORMAT");
// Handle successful scan
} else if (resultCode == RESULT_CANCELED) {
// Handle cancel

See that? That’s nothing. That’s 5 minutes of coding, 3 of which were just to look up the name of the result you wanted to pull. And that was made possible because the Barcode Scanner application is designed to be able to scan barcodes for whatever other applications may need it.

More important, our app is completely decoupled from the BarcodeScanner app. There’s no integration- in fact, neither application is checking to verify that the other exists. If the user preferred, they could remove “Barcode Scanner” and replace it with a competing app. As long as that app supported the same intent, functionality would remain the same. This decoupling is important. It’s the easy way. It’s the lazy way. It’s the Android way.

Sharing Data Using Intents

One of the most inherently useful Android intents is the Share intent. You can let the user share data to any service they want, without writing the sharing code yourself, simply by creating a share intent.

Intent intent=new Intent(android.content.Intent.ACTION_SEND);

// Add data to the intent, the receiving app will decide what to do with it.
intent.putExtra(Intent.EXTRA_SUBJECT, “Some Subject Line”);
intent.putExtra(Intent.EXTRA_TEXT, “Body of the message, woot!”);

... and starting it with a chooser:

startActivity(Intent.createChooser(intent, “How do you want to share?”));

With these 5 lines of code, you get to bypass authenticating, credential storage/management, web API interaction via http posts, all sorts of things. Where by “bypass”, I mean “have something else take care of.” Like the barcode scanning intent, all you really had to do was declare that you have something you’d like to share, and let the user choose from a list of takers. You’re not limited to sending text, either. Here’s how you’d create an intent to share an image:

private Intent createShareIntent() {
Intent shareIntent = new Intent(Intent.ACTION_SEND);

// For a file in shared storage. For data in private storage, use a ContentProvider.
Uri uri = Uri.fromFile(getFileStreamPath(pathToImage));
shareIntent.putExtra(Intent.EXTRA_STREAM, uri);
return shareIntent;

Note that just by using setType() to set a MIME type, you’ve filtered down the list of apps to those that will know what to do with an image file.

Intents over Integration

Think about this for a second. By making the simple assumption that any user of any service (Task Manager, Social Network, Photo sharing site) already has some app on their phone that can share to that service, you can leverage the code that they’ve already written. This has several awesome implications:

  • Less UI — You don’t have to clog up your UI with customized, clickable badges of services you support. Just add a “share” button. It’s okay, we’ve made sure all your users know what it does [insert smiley here].

  • Leveraged UI — You can bet that every high-quality web service out there has spent serious time on the UI of their Android app’s “share” activity. Don’t reinvent the wheel! Just grab a couple and go for a ride.

  • Filtered for the user — If I don’t have a Foo-posting app on my phone, there’s a good chance I don’t care about posting to Foo. Now I won’t see Foo icons everywhere that are useless to me.

  • Client App Ecosystem — Much like an email client, anyone can write a client for any service. Users will use the ones they want, uninstall the ones they don’t. Your app supports them all.

  • Forward Compatible with new services — If some swanky new service springs up out of nowhere with an Android Application, as long as that application knows how to receive the share intent, you already support it. You don’t spend time in meetings discussing whether or not to wedge support for the new service into your impending Next Release(tm), you don’t burn engineering resources on implementing support as fast as possible, you don’t even upload a new version of anything to Android Market. Above all, you don’t do any of that again next week, when another new service launches and the whole process threatens to repeat itself. You just hang back and let your users download an application that makes yours even more useful.

Avoid One-Off Integrations

For each pro of the Intent approach, integrating support to post to these services one-at-a-time has a corresponding con.

  • Bad for UI — If your photo-sharing app has a Foo icon, what you might not immediately understand is that while you’re trying to tell the user “We post to Foo!” what you’re really saying is “We don’t post to Bar, Baz, or let you send the photo over email, sms, or bluetooth. If we did, there would be icons. In fact, we probably axed those features because of the space the icons would take on our home screen. Oh, and we’ll probably use some weird custom UI and make you authenticate through a browser, instead of the Foo client you already have installed.” I’m not going to name names, but a lot of you are guilty of this. It’s time to stop. (I mean it. Stop.)

  • Potentially wasted effort — Let’s say you chose one service, and integrated it into your UI perfectly. Through weeks of back-and-forth with Foo’s staff, you’ve got the API and authentication mechanisms down pat, the flow is seamless, everything’s great. Only problem is that you just wasted all that effort, because none of your user-base particularly cares for Foo. Ouch!

  • Not forward compatible for existing services — Any breaking changes in the API are your responsibility to fix, quickly, and that fix won’t be active until your users download a newer version of your app.

  • Won’t detect new services — This one really hurts. If a brand new service Baz comes out, and you’ve actually got the engineering cycles to burn, you need to get the SDK, work out the bugs, develop a sharing UI, have an artist draw up your own “edgy” (ugh) but legally distinct version of the app’s logo so you can plaster it on your home screen, work out all the bugs, and launch.

You will be judged harshly by your users. And deservedly so.

Ice Cream Sandwich makes it even easier

With the release of ICS, a useful tool for sharing called ShareActionProvider was added to the framework, making the sharing of data across Android applications even easier. ShareActionProviders let you populate lists of custom views representing ACTION_SEND targets, facilitating (for instance) adding a “share” menu to the ActionBar, and connecting it to whatever data the user might want to send.

Doing so is pretty easy. Configure the menu items in your Activity’s onCreateOptionsMenu method, like so:

public boolean onCreateOptionsMenu(Menu menu) {
// Get the menu item.
MenuItem menuItem = menu.findItem(;
// Get the provider and hold onto it to set/change the share intent.
mShareActionProvider = (ShareActionProvider) menuItem.getActionProvider();

// Attach an intent to this ShareActionProvider. You can update this at any time,
// like when the user selects a new piece of data they might like to share.

// This line chooses a custom shared history xml file. Omit the line if using
// the default share history file is desired.
. . .

Note that you can specify a history file, which will adapt the ordering of share targets based on past user choices. One shared history file can be used throughout an application, or different history files can be used within the same application, if you want to use a separate history based on what kind of data the user wants to share. In the above example, a custom history file is used. If you wish to use the default history for the application, you can omit that line entirely.

This will help optimize for an important feature of the ShareActionProvider: The user’s most common ways to share float to the top of the drop-down, with the least used ones disappearing below the fold of the “See More” button. The most commonly selected app will even become a shortcut right next to the dropdown, for easy one-click access!

You’ll also need to define a custom menu item in XML. Here’s an example from the ActionBar Dev Guide.

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="">
<item android:id="@+id/menu_share"
android:actionProviderClass="android.widget.ShareActionProvider" />

And with that, you can have an easy sharing dropdown that will look like the screenshot here. Note that you get the nice standard three-dots-two-lines “Share” glyph for free.

Remember: Smart and Easy

The share intent is the preferred method of sharing throughout the Android ecosystem. It’s how you share images from Gallery, links from the browser, and apps from Android Market. Intents are the easiest path to writing flexible applications that can participate in a rapidly expanding ecosystem, but they’re also the smart path to writing applications that will stay relevant to your users, letting them share their data to any service they want, no matter how often their preferences change over time. So take a step back and stop worrying about if your user wants to tweet, digg, post, email, im, mms, bluetooth, NFC, foo, bar or baz something. Just remember that they want to share it. Android can take it from there.


[Gd] Stable Channel Update

| More

Chrome Releases: Stable Channel Update

The Chrome team is excited to announce the release of Chrome 17 to the Stable Channel for Windows, Mac, Linux and Chrome Frame.  17.0.963.46 contains a number of new features including:
  • New Extensions APIs
  • Updated Omnibox Prerendering
  • Download Scanning Protection
  • Many other small changes
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

  • [73478] Low CVE-2011-3953: Avoid clipboard monitoring after paste event. Credit to Daniel Cheng of the Chromium development community.
  • [92550] Low CVE-2011-3954: Crash with excessive database usage. Credit to Collin Payne.
  • [93106] High CVE-2011-3955: Crash aborting an IndexDB transaction. Credit to David Grogan of the Chromium development community.
  • [103630] Low CVE-2011-3956: Incorrect handling of sandboxed origins inside extensions. Credit to Devdatta Akhawe, UC Berkeley.
  • [$1000] [104056] High CVE-2011-3957: Use-after-free in PDF garbage collection. Credit to Aki Helin of OUSPG.
  • [$2000] [105459] High CVE-2011-3958: Bad casts with column spans. Credit to miaubiz.
  • [$1000] [106441] High CVE-2011-3959: Buffer overflow in locale handling. Credit to Aki Helin of OUSPG.
  • [$500] [108416] Medium CVE-2011-3960: Out-of-bounds read in audio decoding. Credit to Aki Helin of OUSPG.
  • [$1000] [108871] Critical CVE-2011-3961: Race condition after crash of utility process. Credit to Shawn Goertzen.
  • [$500] [108901] Medium CVE-2011-3962: Out-of-bounds read in path clipping. Credit to Aki Helin of OUSPG.
  • [109094] Medium CVE-2011-3963: Out-of-bounds read in PDF fax image handling. Credit to Atte Kettunen of OUSPG.
  • [109245] Low CVE-2011-3964: URL bar confusion after drag + drop. Credit to Code Audit Labs of
  • [109664] Low CVE-2011-3965: Crash in signature check. Credit to Sławomir Błażek.
  • [$1000] [109716] High CVE-2011-3966: Use-after-free in stylesheet error handling. Credit to Aki Helin of OUSPG.
  • [109717] Low CVE-2011-3967: Crash with unusual certificate. Credit to Ben Carrillo.
  • [$1000] [109743] High CVE-2011-3968: Use-after-free in CSS handling. Credit to Arthur Gerkis.
  • [$1000] [110112] High CVE-2011-3969: Use-after-free in SVG layout. Credit to Arthur Gerkis.
  • [$500] [110277] Medium CVE-2011-3970: Out-of-bounds read in libxslt. Credit to Aki Helin of OUSPG.
  • [$1000] [110374] High CVE-2011-3971: Use-after-free with mousemove events. Credit to Arthur Gerkis.
  • [110559] Medium CVE-2011-3972: Out-of-bounds read in shader translator. Credit to Google Chrome Security Team (Inferno).
The bugs [105459], [106441], [108416], [108901], [109716], [109743], [110112], [110277], [110374]  and [110559] were detected using AddressSanitizer.

In addition, we would like to thank miaubiz, Drew Yao and Braden Thomas of Apple, Sławomir Błażek, Aki Helin of OUSPG, Chamal de Silva and Atte Kettunen of OUSPG for working with us in the development cycle and preventing bugs from ever reaching the stable channel. Various rewards were issued, including a top $3133.70 reward to Aki Helin.

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

Jason Kersey
Google Chrome

[Gd] Charts, Gmail, Maps and Properties Services Graduating from Experimental

| More

Google Apps Developer Blog: Charts, Gmail, Maps and Properties Services Graduating from Experimental

The Google Apps Script team strives to achieve a very high level of responsiveness to our community. We iterate fast to deliver new features and functionality. Releasing new Apps Script services under the “Experimental” flag allows us to gather valuable feedback from you. Real world exposure to these new experimental Apps Script services makes it easy for us to prioritize features, improve API design and documentation, and identify bugs and use cases. On top of that, experimental releases give us a way to support our more advanced users, who are perfectly happy to live on the cutting edge and get their hands on cool new Apps Script services as early as possible.

We put thorough consideration into the use of the Experimental flag. Not every new Apps Script service that we launch is experimental. In October, we launched the Lock and Cache service as non-experimental. We believed that these two services were fundamentally mature, and thus able to be launched as non-experimental.

Today, we are graduating four services from experimental status:
  1. Charts Service
  2. Gmail Service
  3. Maps Service
  4. Properties Service
You can expect us to continue on this path of careful deliberation in deciding when to use the experimental flag. We will continue to evaluate the design, documentation, and overall strengths of each experimental API and continue to work hard to graduate them to fully supported APIs. We welcome your feedback in helping us make Apps Script better. You can post your feature requests on our tracker and ask any question in our forum. If you are curious on how to use the above mentioned APIs then check out the tutorials for the Charts and Gmail Services, the Maps Service and excellent example of using Properties Service.

The Apps Script team is standing by to help you!

Saurabh Gupta profile | twitter | blog

Saurabh is a Developer Programs Engineer at Google. He works closely with Google Apps Script developers to help them extend Google Apps. Over the last 10 years, he has worked in the financial services industry in different roles. His current mission is to bring automation and collaboration to Google Apps users.


[Gd] The BugSense hybrid app: experiences using Clojure on Google App Engine

| More

Google App Engine Blog: The BugSense hybrid app: experiences using Clojure on Google App Engine

Today’s post comes to us from Jon Vlachogiannis and Panos Papadopoulos, founders of BugSense, a mobile error analytics service. We hope you find their insights on using Clojure on Google App Engine informative.

BugSense is a cross-platform error analytics infrastructures for mobile devices. BugSense uses Google App Engine to power its backend, processing more than 1.6 million daily errors, generated by more than 45 million devices around the world. Chances are one of the applications installed on your smart phone (like SoundCloud or Trulia) is already using BugSense.

The Problem
Lots of our clients want to optimize and protect their mobile apps (through code obfuscation) using ProGuard. ProGuard creates more compact code, resulting in faster transfer across networks, faster loading, and smaller memory footprints. On top of that it makes programs and libraries harder to reverse-engineer.

However, because the Android Market doesn't automatically de-obfuscate of stack traces from ProGuard-ed apps, developers who want to analyse errors from their apps must get the stack trace from the Market, format it and use ProGuard locally. The whole process for just a single error could take more than 3 minutes, so we decided to add support for ProGuard to BugSense to make debugging easier and faster.

The Solution: Clojure and Python
The main data-serving portion of our app is written in Python, our language of choice, but ProGuard is an open source project in Java. For easier development, we ported parts of ProGuard to Clojure, a dynamic language belonging to the Lisp family that runs on the JVM. This allows us to “beat the averages” by exploiting all the great features that a LISP language offers (such as macros  and exploratory programming). Using Clojure and having access to a vast number of Java libraries assisted us in tackling the difficult problem of de-obfuscation, with great results.

Once we were done, we deployed using AppEngineMagic and now it's trivial (one click) for our users to de-obfuscate their stacktraces. Now we have the best of two worlds: Python for serving data and Java/Clojure for doing calculations, all in the same Google App Engine application. And it scales automatically and runs even faster than running ProGuard on your laptop!

Practically, that means that we can have a heterogeneous app on Google App Engine so that we can keep programming in our favourite language, Python, but still harness the tremendous wealth of Java libraries using Clojure. Running a hybrid app on App Engine is trivial since they share the same resources task queues, Datastore, and memcache.

However, because our app is implemented in multiple languages, we need to start two different local instances (one for Python and one for Clojure). We use a combination of mocks for both of the instances in order to emulate the hybrid app and their interaction in a local environment for development and testing.

Google App Engine, a success factor
We started as a two-developer startup and our product rapidly became popular across the world. Building on Google App Engine helped us focus on product development and forget about infrastructure and administration, thus enabling us to focus more on our customers' needs. (And sleep tight at night.) Furthermore it helped us to keep costs low and iterate quickly.

To learn more about BugSense, check out our website. If you have comments or questions about this post or just want to reach out directly, you can find us at +jonromero or +bugsense.


[Gd] Beta Channel Update for Chromebooks

| More

Chrome Releases: Beta Channel Update for Chromebooks

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

This update fixes a number of stability and UI issues.

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 Update

| More

Chrome Releases: Dev Channel Update

The Dev channel has been updated to 18.0.1025.7 for Windows, Mac, Linux and Chrome Frame.  This build contains following stability and bug fixes:

  • Users can now sync NTP icons to their profile and keep their order across different instances of chrome. [Issues: 111277, 100737, 61447]
  • Pointer Lock / Mouse Lock is implemented behind a flag (see about:flags). Mac only bug fix when closing a tab. [Issue: 111860]
  • Fixed stability crashes [Issue: 112590, 112116, 111968, 110909]
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