Friday, May 14, 2010

[Gd] Spiral Spreads to 80 Countries in 20 Weeks. Thanks, GWT!

| More

Google Code Blog: Spiral Spreads to 80 Countries in 20 Weeks. Thanks, GWT!

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Reuben S. Kerben, CEO of Spiral Universe who will be demoing as part of the Developer Sandbox.

When we started working on a new school information management system a couple of years ago, we wanted to make it available to all schools around the world even if they could not pay for it. Cloud architecture was the only way to go. The key challenge was to build a user interface that could work with any modern browser, support any language, and did not require any plugins. We chose Google Web Toolkit (GWT). There were other RIA frameworks available, but few matched the scalability, performance and flexibility of the Java + GWT combo.

GWT was in its infancy at that time, and our first "webtop" UI was sluggish. It took a leap of faith to stick with the webtop concept. We hoped that advances in web browsers and the GWT compiler would improve our UI performance by the time we hit the market. The GWT team delivered! Once we upgraded to GWT 2.0, the UI became very responsive, and now it closely mimics the desktop experience.

We also must thank Darrel Meyer and the Ext GWT team for improving their library, on which we rely heavily, and the entire Chrome team for raising the performance bar so quickly. After more than two years of coding, we released our beta to the public this January. Today, our system is already used by schools in 80 countries! We are proud to participate in Google I/O to show off our technology and, hopefully, inspire other developers to rethink their approach to UI. We also plan to shop for apps that we can integrate with our system. If your company has a cool product or service that schools, teachers, students or parents will be interested in, send us a note, or come talk to us at the Developer Sandbox.

posted by Reuben S. Kerben, CEO, Spiral Universe

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 6.0.401.1 for Windows, Linux and Mac platforms

  • Don’t prepend scheme on copying an incomplete hostname. (Issue 43585)
  • Much better display/eliding of RTL and mixed-direction strings in the omnibox dropdown. (Issue 41716)
  • Make sure scheme is prepended to addresses that are cut (as opposed to copied) from the omnibox. (Issue 43569)
  • Fixed rendering of monospaced fonts on Linux (Issue 43252)

Known Issues
  • Hitting enter in some form fields does not submit the form. This will be fixed in the next Dev release.

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

Karen Grunberg

Google Chrome

Thursday, May 13, 2010

[Gd] OSAPI on iGoogle

| More

iGoogle Developer Blog: OSAPI on iGoogle

The OpenSocial 0.9 specification introduced a simpler API called OS Lite (also known as OSAPI) which uses a syntax that's friendlier for Javascript developers.

Some steely eyed developers have already noticed that iGoogle works with most OpenSocial 0.9 features. The implementation of OSAPI should work as documented at

Here's a basic example to play with so you can get started with the OS Lite API. In this example we will execute a request to fetch and display a list of the user's friends.

 <ModulePrefs height="800" title="osapi friends" title_url="">
  <Require feature="opensocial-0.9" />
  <Require feature="osapi" />
 <Content type="html" view="home">
   var result = '';
    osapi.people.get({userId:'@owner', groupId:'@friends'}).execute(function(response) {
    result += 'You have ' + response.list.length + ' friends:<ul>';
    for (item in response.list) {
     result += '<li>' + response.list[item]';
    document.getElementById("output").innerHTML = result + '</ul>';

To keep it short we've omitted detailed error handling in our example. It should be pretty clear what the script is doing but it's good to check response.error and gracefully handle problems.
The first call, osapi.people.get({userId: '@owner', groupId: '@friends'}) constructs a request object to get a list of people for the current user from their friends group. The call to execute will make a call to the service, passing the results to a callback function. Our callback is a simple anonymous function that across the result set.
When running the code, look at the JSON response from iGoogle and you'll see that the data structure is pretty straightforward. Use some of the tools built into your browser such as:
  • Firebug if you are using Firefox
  • Chrome or Safari Developer tools.
  • Opera Dragonfly
  • Internet Explorer 8's debugger

These tools help debug your Javascript but also can show you the HTTP messages that are going to iGoogle from your gadget and the responses iGoogle sends back. There's also the OpenSocial Developer App which is a gadget that will build arbitrary messages that you can incorporate in test code.

As we get more OpenSocial 0.9 tested out on iGoogle, we'll update the documentation to reflect the current functionality.

If you like OSAPI and you're going to be at Google I/O 2010, you can find us in the Hack Alcove on May 20 2010 from 2-3:30pm. We'll give a walk through of a gadget built with osapi for iGoogle gadget developers. There's also a talk for iGoogle developers at I/O on May 20 2010 at 10:15am.

Posted by Rob Russell and Paul Kinlan, Developer Relations

[Gd] Meet your technical writers at I/O

| More

Google Code Blog: Meet your technical writers at I/O

The Google technical writers who write for and will be attending Google I/O—and we’re eager to meet the developers who use Google APIs. Look out for us at Google I/O. We’ll be wearing spiffy colorful T-shirts that say “I can explain Google to you.”

Stop us in the hallways or drop by one of our office hour sessions for a chat. We want to hear how you learn about an API, what’s missing from our docs, and how we can help you code faster and smarter. See you at I/O!

posted by the Google EngDocs writing team

[Gd] Updates To .NET Library For The Google Analytics API

| More

Google Code Blog: Updates To .NET Library For The Google Analytics API

We’re incredibly proud of the diversity of applications and tools making use of the Google Analytics Export API. We also know that several of you have been asking about our .NET client library and requesting sample code.

So we’re happy to announce we’ve updated the .NET Google Data client library to support all our recent features.

In addition, we’ve added 2 reference examples for both the Account Feed and Data Feed which show how to pull advanced segment, custom variable, and goal data from the API. As you can see from the examples, this client library makes pulling data from the Export API incredibly easy.

Now that the .NET developers among you have this library, what will you use it for? Fancy visualizations? Automated reporting? Extreme data mining? Let us know in the comments, or bounce a few ideas off your peers in the Google Analytics Data Export API group!

By Alexander Lucas, Google Analytics API Team

[Gd] Contextual Discovery: The Next Generation of Location-Based Services

| More

Google Code Blog: Contextual Discovery: The Next Generation of Location-Based Services

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Aloqa’s Head of Client Development Matthias Schicker who will be demoing as part of the Developer Sandbox.

In the last few years, the mobile industry has overcome several infrastructure hurdles that location-based services (LBS) have historically faced -- cheap, small GPS receivers have become ubiquitous, CellID / Wifi positioning has become available on platforms like Android and iPhone, and some carriers have even started to make location information available. Not surprisingly, a wave of LBSs has been unleashed in the market. Yet LBS has still not lived up to its much vaunted promise.

The reason, we believe, is that most location services are still "reactive" -- they treat the phone like a PC. The user is required to launch an application that returns information based on the user's location. While these "finder" services are certainly useful, with Aloqa, we believe we are striking at the core of three things that are fundamentally wrong with mobile LBS today:

1. Mobile phones shouldn't have to be used as browsers. A phone is an interrupt-based device that is intended to alert you - ring when someone calls or buzz when an SMS comes in. It should "proactively notify" you, as obtrusively or unobtrusively as you'd like, of content, people, and places in your surroundings. So you never miss an opportunity to socialize, play, work, shop, watch a show, or just grab a coffee with a friend.

2. Location is only one part of a user's current "context". Historically, "location" has been used a little too simplistically by mobile apps. The canonical LBS example is to walk by a Starbucks and get a coupon sent to your phone. Even ignoring the fact that Starbucks doesn't even have coupons, if all we got all day from mobile apps is aggressive ads of various kinds, of course we would hate "LBS" too.

Location is just one component of a user's context. Who the user is, what they like, the time of day, their social graph - these are all important inputs to context as well. Your phone can be trained in a much smarter way to know you and therefore is a perfect device to give you "Context Based Services".

3. Point applications are good but it's getting beaten to death by a thousand apps. Restaurants, toilets, bars, music, events, even friend finders - why have separate apps for them? This information should just be available to users at their fingertips and at once, and without having to launch individual applications and type into them.

Aloqa is a mobile service that proactively notifies you of a variety of interesting opportunities around you: places, events, bargains, friends and activities. A kind of universal "context based inbox" for all the world's location relevant content and services.
  • Instead of having to search, you can just look at your phone and see your local hotspots, events of interest, and recommended bargains.
  • Users can customize Aloqa and decide which Aloqa "channels" they want from our "channel store".
  • Using our API, publishers can create a channel and use our universal inbox for context relevant notifications, be it for biking trails, or popular bars where Pittsburgh Steelers fans congregate.

If you have an Android phone, you can download Aloqa through the Android Market or scan this QR code to the left. To try our dev tools, go to We’d love to hear your feedback, and if you’re going to I/O, be sure to stop by the Developer Sandbox to see our demo!

posted by Matthias Schicker, Head of Client Development at Aloqa

[Gd] AdWords Downtime: May 13th, 6:00pm - 6:30pm PDT

| More

AdWords API Blog: AdWords Downtime: May 13th, 6:00pm - 6:30pm PDT

We'll be performing routine system maintenance on Thursday, May 13th from approximately 6:00pm to 6:30pm PDT. You won't be able to access AdWords or the API during this time frame, but your ads will continue to run as normal.

While, AdWords system maintenance typically occurs on the second Saturday of each month, this update was delayed due to the Mother's Day holiday in the U.S. last weekend. We apologize for the late notice.

- Eric Koleda, AdWords API Team

[Gd] Announcing Eclipse Labs

| More

Google Code Blog: Announcing Eclipse Labs

Many of us here at Google, along with the open source community, use the Eclipse IDE when we develop for Android, App Engine, and Google Chrome. We also have a lot of Google engineers that use Eclipse to build our own internal products. So, when the Eclipse Foundation approached us with an idea to encourage the Eclipse ecosystem, we were very happy to help.

Today, we’re excited to announce the result of our collaboration: a Beta version of Eclipse Labs powered by Google Project Hosting, a single place where anyone can start and maintain their open source projects based on the Eclipse platform with just a few clicks.

The goal of Eclipse Labs is to improve the visibility of unofficial add-on projects. We hope that this will help Eclipse users find those projects quickly and that it will help popular projects get on the path to becoming Eclipse Foundation projects. For more information, see the Eclipse Foundation’s blog post.

To get this community started, we’re eager to seed Eclipse Labs with Eclipse add-on projects currently on Google Code. If you have an add-on for Eclipse that you would like to move to Eclipse Labs from Google Code, please let us know by filing a migration request.

Here are a few projects that have already migrated:Let us know what you think in our developer forum and if you’re attending Google I/O, be sure to drop by the Developer Sandbox for Eclipse or visit the Google Project Hosting team during office hours.

By Ali Pasha, Product Manager, Google Project Hosting

[Gd] Google Apps Marketplace - We want your suggestions

| More

Google Apps Developer Blog: Google Apps Marketplace - We want your suggestions

The Google Apps Marketplace launched last month with over 50 integrated business applications. In less than 2 months, more than 1 million Google Apps users now have access to integrated cloud apps that their organization’s IT administrators have installed through the Google Apps Marketplace. More businesses are adding their applications to the Marketplace every week. Google Apps are used by more than 25 million users at over 2 million businesses, and growing very fast.

The Google Apps Marketplace is growing, and we want your suggestions on how to make it bigger and better. Here is your chance to submit your big ideas and small suggestions on Google Apps Marketplace and the APIs used to create installable apps. You can also see existing ideas and what others have to say. Vote up the ideas you like the most. You tell us what's important.

We have set up two Product Ideas sites; one for improvements to the Marketplace itself, and another for applications you would like to see available for sale in the Marketplace. There are already lots of ideas and over 300 votes. Take a look at the ideas and add yours to the list.

Thank you from the Google Apps Marketplace team.

Wednesday, May 12, 2010

[Gd] Twitter for Android: A closer look at Android’s evolving UI patterns

| More

Android Developers Blog: Twitter for Android: A closer look at Android’s evolving UI patterns

[This post is by Chris Nesladek, Interaction Designer, Richard Fulcher, Interaction Designer, and Virgil Dobjanschi, Software Engineer — Tim Bray]

Along with our regular updates of the Android platform, we like to build example applications that showcase best practices for UI features and behavior patterns, to help our 3rd party developers create even richer applications.

For example, the Twitter for Android application that we worked with Twitter to design gives you, the 3rd party developer, a working example of how you can customize and build an application that’s both fun and highly functional. This blog post is meant to showcase these patterns along with some recommended implementations as you start to develop your applications around them.

Let’s get started and explore these patterns in more detail now.

Pattern 1: Contacts Sync with Address book at Sign in

One of the most important intents we added to Twitter for Android was the ability to sync your Twitter contacts into the phone. This integration also allowed us to give Twitter users with an Android phone the use of the QuickContact widget, which gives users a choice of ways to contact their followers.

We recommend:

  • Using this activity upon first signing into an application.

  • If your app has no sign-in, showing this screen at first launch to improve discoverability of contact sync.

Pattern 2: Twitter account integration with QuickContact for Android

The good news for developers is you get this highly functional contacts feature for free if users choose to sync contact information into your app. QuickContact for Android provides instant access to a contact's information and communication modes. For example, a user can tap a contact photo and with one more tap launch a call, SMS, or email to that person. Other applications such as Email, Messaging, and Calendar can also reveal the QuickContact widget when you touch a contact photo or status icon.

Pattern 3: Dashboard

The dashboard pattern serves as a home orientation activity for your users. It is meant to include the categories or features of your application. We recommend including an Action bar on this screen as well.

The dashboard can be static or dynamic. For example, in the case of our dashboard for Twitter, we used the goodness of Live Wallpapers introduced in 2.1 to create an animated dashboard complete with real-time trend bubbles and the Twitter bird silhouette.

We recommend:

  • Using this pattern to showcase the most prominent features of your app.

  • Adding some unexpected delight to this screen, making it engaging without overwhelming the user.

  • Exercising caution - for some apps, the user will want to jump directly into the meat of the application. For others, this sort of welcoming dashboard will be the right starting place.

Pattern 4: Action Bar

The Action bar gives your users onscreen access to the most frequently used actions in your application. We recommend you use this pattern if you want to dedicate screen real estate for common actions. Using this pattern replaces the title bar. It works with the Dashboard, as the upper left portion of the Action bar is where we recommend you place a quick link back to the dashboard or other app home screen.

We recommend:

  • Placing an Action bar at the top of the screen to house the most common actions for your application that work across all activities.

  • Using no more than 3 onscreen actions for the Action bar. Use the main menu as overflow for actions that are less important. The balance between Action bar and main menu will ensure the richness of interaction that is Android.

  • Making the left-hand region actionable, offering one-touch return to your dashboard or other app home.

Pattern 5: Search Bar

The Search bar pattern gives you a fast way to switch between resources that are searchable by your application. For example, with Twitter for Android, we used the pattern to support searching within Tweets as well as People. When triggered, this pattern sits on top of the Action bar.

We recommend:

  • You support suggestions.

  • You keep a search history so users upon returning to the search activity can have quick one-button access to previous searches.

Additionally, you can feel free to use the Search bar selection mechanism as a replacement for tabs since it’s really just a fast pivot on a data set. If you have more than 3 data sets, tabs become problematic since no more than 3 can be onscreen at once. For example, look at how we implemented the Profile switching mechanism below:

Pattern 6: QuickActions

QuickActions is our newest UI pattern. Currently, it has been implemented as a fast, engaging, popup triggered by an onscreen UI element that identifies it in as minimally disruptive way as possible. We recommend you use this pattern for list views that are data intensive where items inside the list have contextual actions associated with them. QuickActions can be used as a replacement for our traditional dialog invoked by long press.

By choosing to use this pattern as part of a list, we made it easier for Twitter users to take action on the information in the list view by keeping the item and associated actions in context. We also took the extra step of making it easier to target links in list views by turning off the list view button element as a secondary component to making this pattern even more usable. This way users of Twitter for Android can view links with one tap and/or see the posted tweet on a map by tapping the tweet meta data directly.

We recommend:

  • Creating a UI element that is minimal and recognizable as an action popup; either a frame around an image or an icon in a list item.

  • Only using this pattern in applications where the data is intensive.

  • Placing the action popup below or above the information you wish to allow users to take relevant contextual actions on. This will make it easier to associate the actions with the content in view.

  • Turning off the entire list view button element so that regions can be easily targeted for the user.

Pattern 7: Companion Widget

The companion widget pattern is something we recommend all developers think about deeply. The widget you create should be more than a big button link into your app. Used correctly, it can provide a place on a home screen that personalizes, albeit in a small window, your application.

In the case of Twitter for Android, we designed and built small and large-sized widgets to support different types of functionality. Both widgets let a user view his/her tweetstream. However, the smaller widget hands off to the application to create a reply to a tweet from the stream, whereas the larger one gives direct access to the Tweet compose activity.

We recommend:

  • Identify your application in the widget with a brand icon

  • Make this more than a button into your app. Give your user an action or view into the app itself.

  • Keep the activity stateful so that on exiting the application and re-entering a user is returned to the same context in the activity, minimizing the impact of using the dashboard if it is used.

Don’t think we quite got something right? As many of you know, we’ll soon be open sourcing this application code under the Android Open Source Project. We look forward to seeing what you can build starting from this code these UI patterns. In the meantime, Happy Tweeting!

Twitter for Android is available in Android Market for immediate download. It is compatible with Android 2.1/2.0 devices, with support coming soon for more.

Come check out the Android UI patterns session at Google I/O next week to learn more about how this applies across our framework and not just in the Twitter app.


[Gd] New features for Robots: Bundled Annotations, Inline Blips, Read-Only Roles

| More

Google Wave Developer Blog: New features for Robots: Bundled Annotations, Inline Blips, Read-Only Roles

Over the last few releases, we've been rolling out incremental improvements to the robots API, based on the feedback from all of you developers. For those of you who haven't been reading the forum waves and changelogs, here's a summary of the new features:

Bundled Annotations:

When you're adding new text to a blip, you often want to annotate that text with a particular set of annotations. In the past, you had to calculate the range of that text and use the annotate operation, like so:

blip.append('New text')
blip.range(len(blip.text), len(blip.text)+8).annotate('style/fontWeight', 'bold')

This often led to off-by-1 errors and frustration. Now with bundled annotations, you can specify both the content to append and the annotation(s) to apply to that content, all in the same operation, like so:

blip.append('New Text', bundled_annotations=[('style/fontWeight', 'bold')])

For more information, read the announcement wave.

Inline Blip Positions:

Several robots produce alternate rendering of waves, like Mr. Ray and its "Wave Lite" view, and those robots needed to know the positions of inline blips inside other blips for a more accurate rendering. To help with this, we introduced a new attribute to the Blip classes to let robots access that position. For more info, see the Python or Java reference.

Read Only Roles:

A few months ago Google Wave launched the ability to have "Read-only" participants, which lets the creator of a wave set access rights for the other participants as either "full access" (the default) or "read only". We now offer that same ability in the API, so a robot that creates a wave can set the access rights of all the participants on the wave, like so:

new_wave.participants.set_role('', wavelet.Participants.ROLE_READ_ONLY)

For more information, read the announcement wave.

Check out the new features, and let us know in the forum how you're using them in your robots.

Posted by Pamela Fox, Developer Relations


[Gd] [Libraries][Update] YUI 2.8.1

| More

Google AJAX API Alerts: [Libraries][Update] YUI 2.8.1

YUI was updated with version 2.8.1

[Gd] A sneak peek at the Native Client SDK

| More

Chromium Blog: A sneak peek at the Native Client SDK

Today, we’re happy to make available a developer preview of the Native Client SDK – an important first step in making Native Client more accessible as a tool for developing real web applications.

When we released the research version of Native Client a year ago, we offered a snapshot of our source tree that developers could download and tinker with, but the download was big and cumbersome to use. The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes: a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code, ports of popular open source projects like zlib, Lua, and libjpeg, and a few samples that will help you get you started developing with the NPAPI Pepper Extensions. Taken together, the SDK lets you write C/C++ code that works seamlessly in Chromium and gives you access to powerful APIs to build your web app.

To get started with the SDK preview, grab a copy of the download at You’ll also need a recent build of Chromium started with the --enable-nacl command-line flag to test the samples and your apps. Because the SDK relies on NPAPI Pepper extensions that are currently only available in Chromium, the SDK won’t work with the Native Client browser plug-ins.

We’ll be updating the SDK rapidly in the next few months, so download a copy, develop some cool apps, share them with the community and send us your feedback! If you build useful libraries in the process, please also consider submitting a patch to the SDK packages directory – chances are, what’s been useful to you will be useful to others. Finally, if you’re attending Google I/O, come to our Beyond JavaScript session, or meet the team at the Developer Sandbox.

Posted by David Springer, Senior Software Engineer

Tuesday, May 11, 2010

[Gd] Announcing Google Moderator’s API, powering a Wave Extension and Android App

| More

Google Code Blog: Announcing Google Moderator’s API, powering a Wave Extension and Android App

Google Moderator is used extensively within Google for meetings and to collect feedback from Googlers on events or happenings within the company. It is also used at conferences and other events to organize and draw upon the collective wisdom of the participants.

Many users have asked us for a formal API, and today, we’re excited to announce the Google Moderator API. You can use the API to access, update, and participate in Google Moderator from custom interfaces.

Here's a quick look at what you can do with Google Moderator’s API:
  • Create: You can create new series, topics, submissions, or votes on behalf of the currently authenticated user.

  • Vote: You can allow authenticated users to vote on submissions, or to review their own votes on submissions in a series.

  • Discover: You can retrieve topics in a series, or submissions in a particular topic or series. You can also track the current aggregate status of votes.
Here are some projects that are using the API today:

Rajiv Bammi whipped up a gadget for Google Wave that will be at Google I/O to allow attendees to ask questions:

Jim Blackler, a Google software engineer, spent some of his 20% time to build Google Moderator for Android, an open source project.

When Moderator was used by the White House, we used the Maps API to plot on a map where submissions were coming from:

We’re curious to see what you build, and we’re eager to get your feedback on new features. To get started, check out the documentation and join our Google Group!

By Colby Ranger, Google Moderator Team

[Gd] [Libraries][Update] Dojo 1.4.3

| More

Google AJAX API Alerts: [Libraries][Update] Dojo 1.4.3

Dojo was updated with versions 1.4.3

[Gd] We are pleased to announce updates to the Google API

| More

Google Web Toolkit Blog:

We are pleased to announce updates to the Google API

We are pleased to announce updates to the Google API Libraries for the Google Web Toolkit project. The Google API Libraries for GWT project allows GWT developers to access some of Google's popular JavaScript APIs. This release includes updates of five libraries: Visualization, Gears, Gadgets, Search, Language, and AjaxLoader.

Highlights of this release include:

  • Libraries updated to GWT 2.0 compatibility

  • Samples refactored to use war project structure

  • Added Eclipse project files and ant script to all samples


  • Added support for all image-charts: ImageAreaChart, ImageBarChart, ImageLineChart, ImagePieChart, ImageSparklineChart

  • Added wrapper for Toolbar

  • Updated Visualization API bindings to be up-to-date with published documentation


  • Added support for the BlobBuilder class and Blob.getBytes() method

  • Added support for the Gears Canvas and Desktop's BlobMetaData object


  • Added support for multiple views and the Views API mapping


  • Added support for new languages (Amharic, Greek, Persian, Russian, Sanskrit, Serbian, Tigrinya, Yiddish)


  • Added support for the google.loader.ClientLocation API

  • Added support for custom hostnames for enterprise users

For more detailed information please refer to the release notes.

These updates are now available for download at the Google API Libraries for GWT project hosted on Google Code.


[Gd] Better performance in App Engine with new Lisp language Clojure

| More

Google Code Blog: Better performance in App Engine with new Lisp language Clojure

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Stefan Richter, founder of technologies and creator of TheDeadline, an intelligent to-do manager running on Google App Engine. TheDeadline will be demoing as part of the Developer Sandbox.

On Google App Engine, Google's cloud computing platform, developers can officially choose between two languages -- Python and Java -- and both run on the Java Virtual Machine (JVM). In the last couple of years, a large number of new programming languages were created and existing popular languages like Ruby were ported to run on the JVM. The good news: now almost any programming language that runs on the JVM should run under Google App Engine, too.

When I read Paul Graham's Book "Hackers & Painters" back in 2004, I was especially fascinated by his essay "Beating the averages" about his start-up company that was using Lisp as the main programming language.

In 2009, when we started TheDeadline, we chose Clojure, a new Lisp language running on the JVM, as our main programming language, and we decided to use the Google App Engine Cloud Computing infrastructure to run our system.

Paul Graham was right. Here is what we have learned:

1. Functional Programming with Clojure really makes you more productive. We have a small team of three people with a background in Haskell and Common Lisp. We release a new version once a week and we estimate that we only write 30% of the code we would have to write in Java and about 50% of the code we would have to write in Python. Writing less code requires less time.

2. Clojure gives you powerful functional abstractions over simple data structures. Writing less code means that this code must be much more powerful. As opposed to object-oriented programming where you build complex object-graphs using inheritance and composition, in functional programming, you are using simple data structures and powerful functional operators that work on these data structures. Internally TheDeadline uses a set of specialized mini-languages, also called Domain Specific Languages (DSL). We are using these mini-languages as the higher-level building blocks for our application.

3. Using Clojure on Google App Engine feels very natural. It is very easy to access the App Engine SDK from Clojure as well as to integrate other existing Java libraries. App Engine's datastore fits especially well with Clojure as we use simple maps as data structures. These can be stored directly into Google's distributed key-value datastore.

If you want to learn more, I invite you to read a more detailed technical posting on our Hackers with Attitude blog about a very simple Clojure mini-language to access the App Engine datastore.

Clojure in combination with Google App Engine became a competitive advantage for us. We are able to build new features quickly with a small team. With Google App Engine we have a zero-maintenance, low-cost cloud computing infrastructure designed for large-scale applications.

If you are curious now and would like to try out TheDeadline, you can sign up here. For more Clojure and App Engine related posts, you can follow our blog H.W.A. If you're attending Google I/O 2010, you can chat with us about Google App Engine, Clojure and the Universe in the Developer Sandbox on May 19 and 20. We look forward to seeing you there.

by Stefan Richter, founder of

Monday, May 10, 2010

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

Google Chrome 5.0.375.38 has been released to the Beta channel for Mac and Windows.

In addition to crash and stability fixes, this release also includes a localization refresh of our strings.  If you spot any issues, please let us know:

Anthony Laforge
Google Chrome Team

[Gd] Building Rich Enterprise Web Apps in the Cloud

| More

Google Code Blog: Building Rich Enterprise Web Apps in the Cloud

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Benjamin Mestrallet, CEO of eXo, who will be demoing his platform for enabling enterprise web apps as part of the Developer Sandbox.

In 2002, I wrote the first JSR 168 portlet container when I was a student in Paris. It is now considered legacy because most enterprises have their intranets built on top of this technology. Today, a lighter weight model has replaced it.

Gadgets – the New User Interface
Gadgets and other influential consumer web technologies can dramatically improve enterprise applications. Unlike portlets, gadgets are client-side code that exchange structured data with the server using REST APIs that return JSON or xml objects. By leveraging JavaScript, HTML and CSS gadgets are not only easier to use and develop than portlets, they are also universal. Everyone can write a web app these days.

The portlet container I built 8 years ago eventually led to me to found eXo, where we built a next-generation platform for Java with Google technologies like Gadgets, OpenSocial, GWT and Android. Our vision is simple: provide a platform for building applications with rich user experiences in the cloud. This means that the entire process of building an enterprise web application can be done online, from its development in a web IDE to its deployment and monitoring within a tenant of a cloud platform.

Use-Case – Marketing Mashup
To demonstrate how remarkably different the enterprise web application development process has become, let's look at a real-life use case with a Marketing Mashup application you can download (link to source code is at the end of the tutorial). Many marketing managers struggle to compile and integrate website analytics manually. Using the eXo Platform with Google Gadgets, we create a single mashup of these different sources of data in a single gadget.

This integration approach is the new, lightweight generation of SOA. We can expose a service’s data as a JSON object through a REST API. In our use case, we combined the existing Google Analytics data and created two new services: one to take the downloads data directly from our project forge sites and another created in groovy to list our press releases. We were able to quickly create this application online using the GWT-based eXo web IDE.

A web IDE means you no longer have to build, test, package and deploy the application. Within this environment, you can use REST APIs using Groovy and OpenSocial gadgets, and deployment options are plenty, whether as a gadget in the platform dashboard, in another OpenSocial container such as iGoogle, and even in mobile apps like the ones we built for Android and the iPhone.

Building and distributing applications has become a lot easier, and the features formerly associated with the consumer web are going to drastically improve the usefulness and usability of enterprise applications.

Posted by Benjamin Mestrallet, CEO of eXo


[Gd] Images In RSS Around the World

| More

iGoogle Developer Blog: Images In RSS Around the World

We announced a couple weeks ago that iGoogle now supports images in RSS. The initial launch was for the US only, but we're launching globally over the next few days. All users will now be able to use our two new views (headline and lead story and slideshow) to display images directly on iGoogle for any feed using MediaRSS or enclosures. If you're a feed provider, have a look at the iGoogle Feed Gadgets Publishers Guide to engage users with your feed.

Post content Posted by Rob Russell, Developer Relations

[Gd] A new species of I/O speaker: VCs who can code

| More

Google Code Blog: A new species of I/O speaker: VCs who can code

With Google I/O less than 2 weeks away, we’re working hard on putting the finishing touches on the 85+ technical sessions we have in store for developers. We’re thrilled for the 180+ speakers who’ll be joining us at I/O, all of whom are talented, technical, and brilliant in their own right. One group of speakers I’m particularly excited about and would like to shine the spotlight on: the venture capital crowd.

This is the first time we’re having VCs speak at I/O. We’re excited about the ones who’ll be participating in I/O sessions. Not only are their insights on technology highly regarded, but most of them are also programmers by trade, have been in the shoes of many I/O attendees (as a developer or entrepreneur), and still tinker with code in their spare time. They’ve got strong opinions on developer tools and technology and often don’t agree with each other, which should make for exciting sessions:
  • Technology, innovation, computer science, & more: VC panel
    Albert Wenger (Union Square Ventures), Chris Dixon (Hunch), Dave McClure (500 Hats), Brad Feld (Foundry Group), Paul Graham (Y Combinator), Dick Costolo (Twitter; moderator)

    What do notable tech-minded VCs think about big trends happening today? In this session, you'll get to hear from and ask questions to a panel of well-respected investors, all of whom are programmers by trade. Albert Wenger, Chris Dixon, Dave McClure, Paul Graham, and Brad Feld will duke it out on a number of hot tech topics with Dick Costolo moderating. **Check out Albert’s
    recent guest post on the “Business of Code”

  • Making Freemium work - converting free users to paying customers
    Brad Feld (Foundry Group), Dave McClure (500 Hats), Jeff Clavier (SoftTech VC), Matt Holleran (Emergence Capital Partners), Joe Kraus (Google Ventures), Don Dodge (Google; moderator)

    A panel of prominent venture capital leaders will help you understand how to build free apps that can be upgraded to paid & how to build products that can be profitable.

We're looking forward to adding the VC perspective to I/O this year. With just 9 days left, the countdown continues!

Posted by Christine Tsai, Google Developer Team