Friday, August 6, 2010

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Chrome Dev Channel has been updated to 6.0.472.25 for all platforms. It includes the following changes:
  • UI Updates
  • Stability Fixes
    • (Issue 50577) Launching Chrome after installing may not work correctly if other browsers are running and set as default
    Known Issues

    More details about additional changes are available in the svn log of all revisions.

    You can find out about getting on the Dev channel here:
    If you find new issues, please let us know by filing a bug at

    Jason Kersey
    Google Chrome

    [Gd] Freemium model for enterprise software?

    | More

    Google Apps Developer Blog: Freemium model for enterprise software?

    The Freemium business model is normal for consumer applications, but can it work for enterprise software? Freemium usually means a free service with an "up sell" to paid premium subscriptions. Examples include Skype, LinkedIn, Flickr,, Typepad, Dropbox, and many others. Freemium differs from Free Trial in that a free trial is the fully functional product but only for a limited time. Freemium is always free, but you can purchase additional features or service for a premium price.

    Freemium business models usually involve a Free service, sometimes time limited or feature limited, supported by advertising. The ads rarely cover costs. The goal is to convert these free users to paid subscriptions. Most consumer services start with a $10 per user per month subscription and scale up to $20 or $50 per month based on a small, medium, large usage scale.

    Enterprise software is also using the Freemium model, sometimes with higher prices commensurate with the power and functionality of the product. They all have slightly different measurements and cut-off points, but most have some notion of small, medium, large.

    Most companies see a 1.5% to 5% conversion rates, with most of them averaging around 3%. That doesn't sound like much but they are reaching tens of thousands to hundreds of thousands of users...sometimes millions.

    Here is some math. 100,000 free users convert to 3,000 paid users. If they pay $50 per user per month, that is $150K a month or $1.8M per year. That is an excellent revenue stream for small startups that typically have 3 to 5 employees. And, it is an annuity stream that continues to grow every year. By the 3rd or 4th year these small companies can be generating $5M to $10M a year, still with less than 10 employees. Most of these small companies don't take Venture Capital so they own the whole company. It is a pretty good cash flow business.

    Recently at Google IO I moderated an all-star panel of VCs on the subject of Freemium in the enterprise.
    Making Freemium work - converting free users to paying customers - Venture Capitalists, Brad Feld (Foundry Group), Dave McClure (500 Startups), Jeff Clavier (SoftTech VC), Matt Holleran (Emergence Capital) and Joe Kraus (Google Ventures) discussed strategies for building free products that can be upgraded to paid versions.

    Some key points from the panel;

    • Your initial thoughts about how much customers will pay, and how much they will pay, is probably wrong
    • Start collecting usage statistics from day one, even if you don't have time to analyze them. These stats will help you understand which features customers really use, and what they are likely to pay for.
    • Customers tend to optimize for "least surprise" so they tend to purchase a service level one above what they think they will need. Think cell phone pricing models.
    • Gmail Enterprise is a good example of an enterprise Freemium product based on usage limits. The first 50 users are free, but convert to paid subscription over that.
    • Freemium works best where there is a "network effect" or where more free users contributing content or data makes the service more valuable.
    • Put your business model in beta at the same time you put your product in beta. Test several business model scenarios to see what works best.
    • Consumers don't pay for additional features, turning off advertisements, analytics, etc...but businesses may be very happy to pay for these things
    • Google Apps Marketplace is a great channel to get your product to Google Apps business customers.

    Watch the video for more details and insight. This group of VCs has built lots of companies based on the Freemium business model. They have some great insights.

    Posted by Don Dodge, Google Apps Marketplace Team

    [Gd] Test Driven Code Review

    | More

    Google Testing Blog: Test Driven Code Review

    By Philip Zembrod

    In my quest to explore TDD I recently found another propery of TDD-written code that I hadn't expected: When reviewing or just reading such code, it's often best to first read the tests.

    When I look at new code or a code change, I ask: What is this about? What is it supposed to do? Questions that tests often have a good answer for. They expose interfaces and state use cases. This is cool, I thought, and decided to establish test-first reading as my code-reviewing routine. Of course this just applies the specification aspect of tests: Reading the specs before reading the code.

    Only it didn't always work. From some tests I just failed to learn the point and intention of the tested code. Often, though not always, these were tests that were heavy with mocks and mock expectations.

    Mocks aren't always a helpful tool, was my first conclusion. The phrase "Good mocks, bad mocks" popped up in my mind. I began to appreciate fakes again - and the people who write them. But soon I realized that this was about more than mocks vs. fakes vs. dummies vs. other Friends You Can Depend On. I was really looking at how well tests fulfill their role as specification.

    TDD teaches that tests are a better specification than prose. Tests are automatically enforced, and get stale less easily. But not all tests work equally well as specification! That's what test driven code reviewing taught me.

    I began to call them well-specifying tests and poorly-specifying tests. And the specification aspect isn't just some additional benefit, it's a really crucial property of tests. The more I thought about it, the more I saw: It is connected to a lot of things that first weren't obvious to me:
    • If tests are poorly-specifying, then possibly the tested product is poorly specified or documented. After all, it's the tests that really make sure how a product behaves. If they don't clearly state what they test, then it's less clear how the product works. That's a problem.
    • Well-specifying tests are more robust. If a test just does and verifies things of which the architect or product manager will readily say "yes, we need that" then the test will survive refactorings or new features. Simply because "yes, we need that." The test's use case is needed, its conditions must hold. It needn't be adapted to new code, new code must pass it. False positives are less likely.
    Corollary: Well-specifying tests have higher authority. If a test fails, a natural reaction is to ask "is this serious?" If a test is poorly-specifying, if you don't really understand what it is testing, then you may say "well, maybe it's nothing". And you may even be right! If a test is well-specifying, you'll easily see that its failing is serious. And you'll make sure the code gets fixed.

    I'm now thinking about an authority rank between 0 and 1 as a property of tests. It could be used to augment test coverage metrics. Code that is just covered by poorly-specifying tests would have poor authority coverage, even if the coverage is high. Quantifying an authority rank would be a conceptual challenge, of course, but part of it could be how well test driven code reviewing works with a given test.

    P.S. If anyone suspects that I'm having some fun inventing terms beginning with "test driven," I'll plead guilty as charged. :-)

    Thursday, August 5, 2010

    [Gd] Rapid cloud development using App Engine for the Cycle Hire Widget Android application

    | More

    Google App Engine Blog: Rapid cloud development using App Engine for the Cycle Hire Widget Android application

    This post is another entry in our ongoing series of guest posts contributed by App Engine developers. Today we partner with Little Fluffy Toys Ltd to tell the story of how they were able to learn App Engine (plus Python) and launched their service paired with their Android application in less than a week!


    Last week, Little Fluffy Toys Ltd (LFT) launched an Android app to help its users find bicycles and rental locations in London. While this story doesn't sound particularly phenomenal, how they accomplished this using Google App Engine (and Android) makes their application and its launch one of the most exciting success stories so far in 2010.

    The development team at LFT were able to quickly come up-to-speed on learning a new programming language and development environment in order to build and launch the App Engine backend service for their Android mobile app to the world in less than one week. The executive summary:

    • Attended 1-hour Thursday night presentation on Google App Engine (Jul 22)
    • Started to learn Python and App Engine on Saturday afternoon
    • Launched live service Wednesday, announcing their Android app with an App Engine backend (Jul 28)

    Before we get to the good stuff, a brief backgrounder on the project which spawned the application: metropolitan bicycle-sharing systems, specifically London's. Based on the success and popularity of the Paris VĂ©lib' system, the Barclays Cycle Hire scheme originated mid-November back in 2008 from its mayor, a strong cycling proponent.

    The system launched on July 30, 2010; however a month before the project neared its completion, a call for apps was given by the mayor seeking independent developers so that there would be a variety of mobile and web apps available by show time. Enter Little Fluffy Toys Ltd, creator of Cycle Hire Widget app for Android. Shortly after announcing their app and London's bicycle system going live, I had a chance to discuss how their project came together with the help of App Engine.

    NOTE: Cycle Hire Widget is only available in the Android Market if you are located within the UK. If you wish to view the application from outside the UK, please download and install it from within your Android browser via this link — bear in mind that the distances to your nearest rental/hire location will be ridiculous!

    App Engine and LFT

    As we mentioned above, the sole purpose of their App Engine app is to receive data from and provide data to the Android app running on users' mobile phones. The App Engine stored data is "global" for all mobile clients out there, and this includes names, locations, and dynamic specifics related to each bike station such as the data found in the app's screenshot below. Take note all the valuable data that is provided in real-time by App Engine:

    If you're a bit familiar with App Engine, you would no doubt have heard about it as a platform for web applications, but this is a use case highlighting App Engine for a non web-based server-side application where no part of the app is user-facing save for what gets sent back to the mobile app. While this type of app doesn’t get much press, it’s more common than people think.

    I met Kenton Price, the director and chief architect of Little Fluffy Toys Ltd, at a developer event recently, and he seemed to think that App Engine would be the right tool for Cycle Hire Widget. It turned out to be true(!), and when I asked about LFT's needs and how they were met by App Engine after their successful product launch, here is what he had to say:

    "As you know we were massively against the clock with the launch of the cycle hire scheme, and we needed something we could get going with fast that would effortlessly scale to perhaps tens of thousands of mobile users. App Engine seemed the perfect choice from what we had read of it before the meeting, and after your presentation it was obviously the way to go. Your recommendation to use Python was scary given neither of us knew a thing about it, but then again we only knew Java from Android not from web development so we didn't have the domain knowledge of building Java web services. So we went with Python, and it worked out really well. I'm astounded how we actually delivered this product in a very short space of time when we both have full schedules working on projects for our clients and other demanding outside interests. Particularly satisfying was having a solution that was agile and flexible enough to enable us to display live cycle availability data within hours of it becoming unexpectedly available at the launch, so we were live in the field with real-time data that very same launch morning, a feature our competitors are still struggling to replicate."

    Development experience

    Reuben Harris, LFT's chief technical officer, is the lead App Engine developer for the Cycle Hire Widget. He had a great experience even though he was new to Python as well as App Engine. What excited him the most, and what was his development experience like? He tells his story here:

    "The single coolest thing about this project is that it was possible to go from a state of knowing nothing whatsoever about App Engine or Python (other than the mile-high view) to having a working and useful application inside of eight hours. We're long-time geeks but we're not geniuses. For us to pick up a new language, a new SDK, a new environment, a new way of doing things, and produce anything of value at all in such a short time speaks volumes about the value, potential, and quality of App Engine and Python.

    After installing the App Engine SDK, yes, the very first thing I did was your online tutorial. I did "Hello World" to find my feet then continued into webapp, since a clean URL handler with easy ways to get at HTTP variables seemed essential. Then I immediately jumped into learning about data storage. And wow, what an enlightenment that turned out to be! Goodbye SQL, don't think I'm going to miss ya.... :-)

    Since the app's purpose is to manage just ~400 simple objects representing Cycle Hire Stations, each of which contains only Plain Old Data types — no object references or anything possibly messy — I felt I knew enough to implement it now, and so I dived in. And it was so easy! I started with a handler to rebuild the datastore from scratch. Then I wrote a "get" type of handler to retrieve information about groups of hire stations (returning the data in JSON). Finally I wrote an "update" handler so that updated information about cycle hire stations could be posted, and that was it. Job done.

    One thing that initially confounded me was an HTTP 500 error caused by our "reset" handler exceeding the 30-second request limit. For a while I was ready to despair; HTTP 500s to anyone with much ASP experience usually means a hideous low-level bug somewhere! However, once we discovered the problem, this was easy to fix by splitting the work into multiple requests (/reset1, /reset2, etc.) It's an admin function that only we'd ever be using, so no harm done and no need to work out anything more clever.

    I know we've barely scratched the surface of what can be done with App Engine. We've yet to use Memcache, background tasks, batched updates, or anything beyond simple cloud-based data storage. But that simple thing alone seemed then, and still seems, not far short of miraculous. To not have to worry about databases, servers, uptime, upgrades and above all scaling... to not have to think about any of that at all is such an immense freedom. I'm completely hooked on it and am unlikely to go back to my traditional server tools of MySQL and PHP.

    To see Reuben's work in action, check out this video demonstrating how to use the Cycle Hire Widget app while roaming the streets of London seeking a bike to rent:


    Since the launch, the Cycle Hire Widget has gotten rave reviews from CNET, The Guardian, and The Londonist. They have even been featured by the Press Association of the UK and Ireland! One user commented on Android Market: "Can't really think of a way to make it better," a sentiment reflected in its very high feedback rating. It certainly does sound like quite a success. What does the future look like? I asked Kenton about how LFT came about as well as how they're looking to improve their succeeding offerings, and here's what he had to say:

    "We formed Little Fluffy Toys Ltd as a vehicle for Android development where we do consultancy work as well as our own stuff like the Cycle Hire Widget and Social Wallpaper. Whilst all custom development enquiries are very welcome, we're also interested in hearing from people or organisations that would like us to customise Cycle Hire Widget for their particular domain, whether it's cycles with availability in another city, coffee shops with opening hours in a geographic region, or dieting group meetings at pertinent times nearby. You name it, there are a gazillion applications for it!"

    Well here on the App Engine team, we're happy for Kenton and his team on being able to implement the server-side solution they needed in such a short period of time on App Engine, and better yet, to help out a worthy cause. Google itself is a socially responsible company that applauds efforts like Barclays Cycle Hire, so we're proud that technologies we provide such as Android and App Engine can be used to help make London and the Earth more sustainable!

    Posted by Kenton Price & Reuben Harris, Little Fluffy Toys Ltd, and Wesley Chun, App Engine team

    [Gd] Nexus One Developer Phone

    | More

    Android Developers Blog: Nexus One Developer Phone

    We've always offered unlocked phones for direct sale to registered Android Developers. As of today, the Developer Phone is the Nexus One, at a price of $529. To see the details or order a phone, you need to sign in to your Android developer account and click on the "Development Phones" link.

    The Nexus One combines an up-to-the-minute platform (Android 2.2), modern hardware, and the pure Google Experience software suite. It's a good choice both for people who want to build Android applications using either the SDK or the NDK, and those who want to experiment with modified versions of the Android platform. Note that the Nexus One still ships with Android 2.1 but will download 2.2 soon after you turn it on; make sure you’re near a fast network.

    As well as being an outstanding developer platform, it's a really nice everyday phone; we're really happy to have connected the right dots to make this happen.


    [Gd] Best Practices for Handling Android User Data

    | More

    Android Developers Blog: Best Practices for Handling Android User Data

    [This post is by Nick Kralevich, an engineer on the Android Security Team. — Tim Bray]

    As the use of mobile applications grows, people are paying more attention to how these applications use their data. While the Android platform contains extensive permissions designed to protect users, application developers are ultimately responsible for how they handle users’ information. It’s important for developers to understand the code they include, and consider the permissions they request, as mishandling these issues can result in users perceiving a violation of trust.

    Maintaining a healthy and trustworthy ecosystem is in every Android developer’s best interest.

    Here are a few tips for writing trustworthy Android applications:

    1. Maintain a privacy policy

    2. Minimize permissions

    3. Give your users a choice regarding data collection

    4. Don’t collect unnecessary information

    5. Don’t send data off the device

    6. ... but if you have to, use encryption and data minimization

    7. Don’t use code you don’t understand

    8. Don’t log device or user specific information.

    Maintain a privacy policy

    Trustworthy applications are up-front about the data they collect and the reasons for collecting it. Users are generally happy to share information via such apps if they believe they will personally benefit. A clear and concise privacy policy, with details about the type of information collected and how it’s used, goes a long way towards generating trust and good will.

    Minimize permissions

    Android is unique among mobile operating systems for its simple, straightforward, operating-system-enforced permission model. All Android applications must declare the permissions they require, and users must approve these permissions before the application is installed. Users tend to distrust applications that require excessive permissions.

    For example, a user installing this tic-tac-toe game might reasonably wonder why it needs to take pictures.

    Give your users a choice regarding data collection

    It’s called the paradox of privacy [PDF, 890K]. Users are often happy to share their information, but they want control over that sharing. Trustworthy applications give users control over their information. For example, the Android Browser has privacy settings which enable users to control how their information is shared.

    Don’t collect unnecessary information

    Trustworthy applications limit the kinds of data they collect. Collecting unnecessary information, especially if you never use it, just invites suspicion. When in doubt, don’t collect it.

    Don’t send data off the device

    If you have to handle user data, ensure that the data remains on the device whenever possible. Users are comforted knowing that their private information strictly resides in the phone. Sending data outside the phone, even if done for the user’s benefit, tends to draw suspicion.

    ... but if you have to, use encryption and data minimization

    Sometimes, the collection of data is necessary. In that case, applications need to ensure that it is handled safely. A privacy policy will avoid leading to surprised and irritated users; in some cases, it may be advisable to prompt the user before transmitting data off-device.

    First, minimize the amount of data you collect. Do you really need the user’s full phone number, or would the area code be sufficient? Can you use a one-way cryptographic hash function on the data before sending it to the server to help protect the user’s confidential information?

    A case study: User Favorites

    Suppose you want your app to maintain a list of “favorites” for each of your users, without going through a full registration process. In theory, you could do this by sending your server some combination of their phone number, device ID, or SIM ID. But why take the chance of worrying people about privacy issues; why not send a one-way hashed signature of whatever the identifying information is? Or even better, create a random unique id and store it on the phone, and use this unique id as the registration key for your application.

    In the end, you’ll will still be able to retrieve their favorites, but you won’t need to send or store anything sensitive.

    Second, encryption is critical to the safe handling of user data. Phones often operate on untrusted networks where attackers can sniff confidential traffic. Encrypting data in transit is a critical part of protecting user information.

    Finally, when communicating with a server over HTTP, it’s a good idea to avoid encoding user information in a URL that is used with HTTP GET; rather, POST it in a message body. While using POST doesn’t guarantee that your information won’t be sniffed, putting it in the URL increases the likelihood that it will be automatically logged; out of the box, most web server software logs all the URLs that are received.

    Don’t use code you don’t understand

    In the open-source Android environment, it’s common (and good) practice to rely heavily on other people’s code, in the form of libraries and frameworks. But if that code is handling your users’ information inappropriately, it’s your problem. So make a point of checking code before you rely on it.

    Don’t log user or device specific information

    Application developers should be careful about on-device logs. Android makes it easy to write to the phone’s log, and anyone who has looked at “logcat” output knows that it is full of important but seemingly random debugging information from many applications. In Android, logs are a shared resource, and are available to an application with the READ_LOGS permission (only with user consent, of course!). Even though the phone log data is temporary and erased on reboot, inappropriate logging of user information could inadvertently leak user data to other applications.


    [Gd] Dev Channel Update

    | More

    Google Chrome Releases: Dev Channel Update

    The Chrome Dev Channel has been updated to 6.0.472.22 for all platforms.  It includes the following changes:

    All Platforms
    • UI Updates
    • Stability Fixes
    • (Issue 49493) Fix some problems with SSL connections through HTTP proxies.

    • (Issue 49621) - some downloaded files are saved with double extension (ex: file.arj.arj)

    Known Issues
    • (Issue 50577) Launching Chrome after installing may not work correctly if other browsers are running and set as default
    • (Issue 51187) Drag and Drop of large file may result in crash

    More details about additional changes are available in the svn log of all revisions.

    You can find out how to use the dev channel at

    If you find new issues, please let us know by filing a bug at

    Jason Kersey
    Google Chrome

    Tuesday, August 3, 2010

    [Gd] Upcoming Wave Talks: Michigan & Washington, DC

    | More

    Google Wave Developer Blog: Upcoming Wave Talks: Michigan & Washington, DC

    Every so often, I leave this beautiful city of Sydney, Australia and depart for foreign lands to meet developers from around the world. This time, I'm heading to the states and dropping by two GTUGs (Google Technology User Groups) to talk about Google Wave and the APIs:

    After the GTUG talks, I'll also be swinging by the HTML5 GTUG campout in San Francisco, setting up waves for the teams to document their progress and ask questions.

    If you're in the area, I hope to see you there!

    Posted by Pamela Fox, Developer Relations

    Monday, August 2, 2010

    [Gd] Google Chrome in a Coal Mine

    | More

    Chromium Blog: Google Chrome in a Coal Mine

    Since Google Chrome launched almost 2 years ago, the team has embraced the “launch early and often” strategy by releasing Dev channel builds almost weekly. But sometimes, such as when we’re in the process of moving a Dev channel release to the Beta channel, we’re unable to release a new Dev channel build, and other times, even a week is too long to wait to get feedback from the field on a change.

    The team considered updating the Dev channel more frequently, but doing so would require us to forgo our manual testing pass on these builds. Even though the Dev channel is often rough around the edges, we realized that this lack of testing would result in a Dev channel that’s too unstable even for early adopters and developers. That’s why, a few days ago, we released a new experimental version of Google Chrome called Google Chrome Canary Build. We plan to update the Canary Build more frequently than the Dev channel, with riskier changes, and usually without a human being ever verifying that it works, so the Canary Build is only for users who want to help test Google Chrome and are comfortable using a highly unstable browser that will often break entirely. To enable you to continue using the same browser you love when the canary croaks, we’ve made it possible to install the Canary Build in addition to the Dev, Beta or Stable channel versions of Google Chrome.

    The Canary Build is still brand new so it currently has a few limitations. Currently, it’s only available for Windows and cannot be set as your default browser. You can star the issues for Mac and Linux support, as well as the issue for default browser support to cast your vote and be notified of progress there.

    If you like to live on the bleeding edge, give the Google Chrome Canary Build a shot and let us know what you think. The early feedback on crashes, performance regressions, broken features and other problems is incredibly valuable to us, so thanks!

    Posted by Henry Bridge, Product Manager

    Sunday, August 1, 2010

    [Gd] Introducing the Closure Library Editor

    | More

    Closure Tools Blog: Introducing the Closure Library Editor

    One of the many UI widgets included in the Closure Library is a full-featured rich text editor.

    All modern browsers have rich text editing functionality built in — unfortunately this functionality is at best inconsistent and, at worst, broken. Closure Library’s editor is a sub-project within Closure. It provides a common, powerful, and extensible interface that abstracts the cross-browser inconsistencies and shortcomings of rich text editing.

    We use the Closure editor in Gmail, Google Sites, Google Groups, and many other Google products. We’re very happy to be able to share this editor with you as part of the Closure Library.

    Using the editor in your project

    A demo of the basic editor functionality is included in the source distribution, and can be tried here.

    The most important code is as follows. First, we create an editable field and attach it to an element with the id editMe.

    // Create an editable field.
    var myField = new goog.editor.Field('editMe');

    Next, we register editing plugins. The rich text editor uses a plugin-based architecture in order to support many products with different feature sets. For example, in Gmail, the tab key moves the cursor to the send button, while in Google Sites it either adds 4 spaces or indents the current bulleted list. Plugins allow us to create modular features for the Editor and let each application pick and choose which ones they need or want. This ensures each application only brings in the code it needs, helping to minimize code size and latency.

    // Create and register all of the editing plugins you want to use.
    myField.registerPlugin(new goog.editor.plugins.BasicTextFormatter());
    myField.registerPlugin(new goog.editor.plugins.RemoveFormatting());
    myField.registerPlugin(new goog.editor.plugins.UndoRedo());
    myField.registerPlugin(new goog.editor.plugins.ListTabHandler());
    myField.registerPlugin(new goog.editor.plugins.SpacesTabHandler());
    myField.registerPlugin(new goog.editor.plugins.EnterHandler());
    myField.registerPlugin(new goog.editor.plugins.HeaderFormatter());
    new goog.editor.plugins.LoremIpsum('Click here to edit'));
    new goog.editor.plugins.LinkDialogPlugin());

    In a future post, we’ll discuss how you can use the plugin system to add your own custom functionality to your editor.

    Next we set up our toolbar:

    // Specify the buttons to add to the toolbar, using built in default buttons.
    var buttons = [
    var myToolbar = goog.ui.editor.DefaultToolbar.makeToolbar(buttons,

    // Hook the toolbar into the field.
    var myToolbarController =
    new goog.ui.editor.ToolbarController(myField, myToolbar);

    And finally, we turn on editing:


    When we open the file in the browser, we get an HTML editor:

    Let us know in the comments if you’ve used or plan to use the Closure Library rich text editor in your project. If you have questions, please post them to the discussion group.

    Posted by Robby Walker, Software Engineer

    [Gd] Closure Compiler at O'Reilly Velocity Conference 2010

    | More

    Closure Tools Blog: Closure Compiler at O'Reilly Velocity Conference 2010

    I would like to thank everyone who stuck around the booth area for my whiteboard presentation on Closure Compiler last week. It was fun meeting all the developers who share the same passion for making fast and awesome web applications! I hope everyone would continue to find Closure Compiler useful in speeding up your applications.

    For those who did not get a chance to attend the conference, I wanted to share the slides with you:

    Thanks again, and if you have questions, please drop us a note on the Closure Compiler discussion list.

    Alan Leung, Software Engineer, Closure Compiler team

    [Gd] Closure Library Tech Talk at Google I/O, now on YouTube

    | More

    Closure Tools Blog: Closure Library Tech Talk at Google I/O, now on YouTube

    The video of our talk at Google I/O, Opening Up Closure Library, has been posted.

    The session slides are also available as a PDF.

    Posted by Nathan Naze, Closure Tools Team

    [Gd] Closure Tools: Open for Business

    | More

    Closure Tools Blog: Closure Tools: Open for Business

    When we open sourced the Closure Tools, we were ecstatic to be getting such great and useful code out to the world. And since then, we’ve seen people do great stuff with Closure Tools. And then we got a little nervous. You see, the more cool stuff you do with Closure Tools, the more work we figured we should put into their open sourcing. Today, we’d like to describe our latest work making the Closure Tools even more open.

    I’m a member of the Open Source Programs Office at Google, which means I help teams that are open sourcing Google code do it better and more easily. I’ve built a toolkit to help these teams called “Make Open Easy” (shameless plug: I’ll be presenting my work in more detail at OSCON this year). It automates the processes of maintaining an open source codebase of Google code: publishing updates, merging patches made in subversion back into our internal source control, and keeping track of who’s done what. We’ve now “MOEified” Closure Compiler and Library. What does this mean for you?

    First, we’re going to push updates more often, regularly, and with descriptions of the changes. Updating the public version with the changes made at Google now takes minutes. For now, we’re not setting a schedule, but we expect that we shouldn’t go more than two weeks without updating the codebase in public Subversion. We hope you’ll appreciate getting code that’s fresh off the press.

    Second, we now want your patches! Since MOE has made merging patches written against the public codebase so easy, we want public contrubtions to the compiler and library. If there are bugs you’d like to fix or features you’d like to implement, feel free to send us a patch. We’re still going to hold patches to a high level of quality, design, and style, so consider talking to us first on our “discuss” lists (closure-library-discuss and closure-compiler-discuss). And, as before, if you have ideas but not code, we still welcome your thoughts. We’d like to work with you to shape Closure Tools.)

    The Closure Tools team is committed to being more transparent and collaborative but sometimes there still might be issues with releasing or accepting code. Please be patient as we work out kinks in the process.

    So, what’s the next feature for Closure Tools? Now’s your chance to show us!

    Posted by Dan Bentley, Open Source Programs Office

    [Gd] Welcome to the Closure Tools blog

    | More

    Closure Tools Blog: Welcome to the Closure Tools blog

    Last November, we released Closure Tools as open source software. These web development tools encompass three major components: a compiler, a library, and a templating system. Google engineers use these three tools to put together some of our largest web applications: Gmail, Google Docs, Google Sites, and many others.

    The response has been heartening. A number of projects have adopted Closure Compiler, both for its excellent performance as a minifier, but also for its compile-time optimizations and type checking. Many folks have picked up Closure Library and Closure Templates as the basis for their new web projects. Traffic on the three discussion lists has been growing.

    In conjunction with our events for the library and compiler at Google I/O, we’re taking a few steps to help encourage that nascent community. The first to mention is this blog, on which we plan to publish notes, tips, and helpful articles from engineers working on Closure Tools. We’ve also started a Twitter account that you can follow. And, as of today, Closure Library joins Closure Compiler as a project that can take external patches from developers outside of Google.

    So add this blog to your feed reader (perhaps Google Reader, built with Closure Tools), follow us on Twitter, and, just maybe, submit a patch. Thanks!

    Posted by Nathan Naze, Closure Tools Team