Some good stuff came out from my employer. First, we have the Gears 0.3 release which includes support for Firefox 3! I have been using it for awhile, and it has been great. The team wanted to get it out before the Firefox 3 launch (planned for June 17th). A plugin like Gears can get deep into browser internals, so it is a challenge to keep up to date as APIs change in beta releases, so it is great to be out there now and I we will take a close look at the final release!

As well as Firefox 3 support, Gears 0.3 includes:

• Ability to create desktop shortcuts with a snippet of JavaScript
• Improved support for customizing the installation flow and permission dialog
• Better support for sending complex objects to workers
• Detailed progress events for managed resource store updates
• And more…

Then, all of the videos from Google I/O sessions have been published.

I put together a playlist that includes Ajax and Gears related content:

Check out the great talks such as:

Gears

• Improving Browsers in New Ways: Gears++
• Google Gears for Mobile
• HTML 5, Brought to You by Gears
• Gears and MySpace – Search on the Client
• Taking Large-Scale Applications Offline
• Gears Case Studies

GWT

• Using GWT to Build a Diagramming Tool
• GWT and Client-Server Communication
• GWT Extreme by Ray Cromwell
• JavaScript and DOM Programming in GWT
• Resource Bundles and Linkers in GWT
• Deferred Binding with GWT

General Ajax

• Alex Russell on “Can We Get There from Here?”
• Spice up Your Apps with Google AJAX APIs
• Yours truly, Dion and Ben, State of Ajax: The Universe Is Expanding
• Steve Yegge on Server Side JavaScript

Wow, a lot of material there!

I just got to announce the Google AJAX Libraries API which exists to make Ajax applications that use popular frameworks such as Prototype, Script.aculo.us, jQuery, Dojo, and MooTools faster and easier for developers.

Whenever I wrote an application that uses one of these frameworks, I would picture a user accessing my application, having 33 copies of prototype.js, and yet downloading yet another one from my site. It would make me squirm. What a waste!

At the same time, I was reading research from Steve Souders and others in the performance space that showed just how badly we are doing at providing these libraries. As developers we should setup the caching correctly so we only send that file down when absolutely necessary. We should also gzip the files to browsers that accept them. Oh, and we should probably use a minified version to get that little bit more out of the system. We should also follow the practice of versioning the files nicely. Instead, we find a lot of jquery.js files with no version, that often have little tweaks added to the end of the fils, and caching is not setup well at all so the file keeps getting sent down for no reason.

When I joined Google I realised that we could help out here. What if we hosted these files? Everyone would see some instant benefits:

• Caching can be done correctly, and once, by us… and developers have to do nothing
• Gzip works
• We can serve minified versions
• The files are hosted by Google which has a distributed CDN at various points around the world, so the files are “close” to the user
• The servers are fast
• By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!
• A subtle performance (and security) issue revolves around the headers that you send up and down. Since you are using a special domain (NOTE: not google.com!), no cookies or other verbose headers will be sent up, saving precious bytes.

This is why we have released the AJAX Libraries API. We sat down with a few of the popular open source frameworks and they were all excited about the idea, so we got to work with them, and now you have access to their great work from our servers.

Details of what we are launching

You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.

The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.

For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:

The second way to access the scripts is via the Google AJAX API Loader’s google.load() method.

Here is an example using that technique to load and use jQuery for a simple search mashup:

You will notice that the version used was just “1″. This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.

Specifying a version of “1.8.2″ will select the obvious version. This is because a fully specified version was used. Specifying a version of “1.8″ would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for “1″ will end up loading version 1.9.1.

Note, these versioning semantics work the same way when using google.load and when using direct script urls.

By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the “uncompressed” parameter like so:

Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.

For a full listing of the currently supported libraries, see the documentation.

Here I am, talking about what we are doing in two short slides:

The Future

This is just the beginning. We obviously want to add more libraries as you find them useful. Also, if you squint a little you can see how this can extend even further.

If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT’d ones, from their local system. Thus, no network hit at all! Also, the browser could have the IP addresses for this service available, so they don’t have the hit of a DNS lookup. Longer lived special browser caches for JavaScript libraries could also use these URLs.

The bottom line, and what I am really excited about, is what this could all mean for Web developers if this happens. We could be removed of the constant burden of having to re-download our standard libraries all the time. What other platform makes you do this?! Imagine if you had to download the JRE everytime you ran a Java app! If we can remove this burden, we can spend more time flushing out functionality that we need, and less time worrying about the actual download bits. I am all for lean, but there is more to life.

Acknowledgements

I want to acknowledge the other work that has been done here. Some libraries such as jQuery and Dean Edwards Base were already kind of doing this by hot linking to their Google Code project hosting repository. We thought this was great, but we wanted to make it more official, and open it up to libraries that don’t use our project hosting facilities.

Also, AOL does a great job of hosting Dojo already. We recommend using them for your Dojo needs, but are proud to also offer the library. Choice is good. Finally, Yahoo! placed the YUI files on their own CDN for all to use.

Don’t they say good things come in threes? Well, regardless, we’ve heard from multiple sources that Google will launch a new product on Monday called “Friend Connect,” which will be a set of APIs for Open Social participants to pull profile information from social networks into third party websites.

MySpace launched Data Availability on Thursday, a competing product. Yesterday, in a suspiciously timed pre-release announcement, we heard about Facebook Connect, another similar product (with a nearly identical name to Google’s Friend Connect).

Like Data Availability and Facebook Connect, Google’s Friend Connect will be a way to securely send personal profile data, including friend lists, presence/status information, etc., to third party applications, say our sources. The primary benefit of these services is to allow users to maintain a single friends list and to coordinate social activities across different sites that perform different services. See my post on the Centralized Me for more of my thoughts on this.

The reason these companies are rushing to get products out the door is because whoever is a player in this space is likely to control user data over the long run. If users don’t have to put profile and friend information into multiple sites, they will gravitate towards one site that they identify with, and then allow other sites to access that data. The desire to own user identities over the long run is also causing the big Internet companies, in my opinion, to rush to become OpenID issuers (but not relying parties).

If what we hear is correct, Google’s offering may not be as attractive as MySpace’s and Facebook’s. Google may be keeping a tighter reign on data, requiring third parties to show it directly from Google’s servers in an iframe. By contract, MySpace and Facebook are sending data via an API and trusting third parties not to abuse it (with strict terms of service in case they violate that trust). That flexibility also allows those third parties to do more with the data, including combining it with their own data before displaying it.

We’ll have to wait until Monday for the exact details, though. But what’s clear is that Google wants to get in between social networks and the web sites that want to access their data. By controlling the flow through Open Social and the new Friend Connect product, they can effectively become a huge social network without actually having a, well, social network (unless you count Orkut).

Google’s been scrambling for partners to announce on Monday as well. So far our understanding is they have their own Orkut and Plaxo. Compare that to MySpace (Yahoo, eBay and Twitter, plus their own PhotoBucket) and Facebook, which announced Digg as an early partner.

Another limiting factor with Google’s product is that, unlike Facebook and MySpace, they do not already control user profiles for tens of millions of active users. That means they’ll quickly need to get big partners on board as well. Will MySpace help them? They may – MySpace is already part of Open Social and said on Thursday that they will adopt Open Social initiatives in this space once they are defined. We’ll see.

More details as they come in.

Crunch Network: CrunchBoard because it’s time for you to find a new Job2.0

Those of you who remember MeasureMap are long time readers of this blog. It was a blog-centered analytics service that first surfaced in August 2005. The service was created by San Francisco based Adaptive Path. The first details emerged in October 2005.

It was Google Analytics but just for blogs. It told you stats based on posts and other key blog features. By November 2005 Google had copied some of the features. And a couple of months later, before MeasureMap had even officially launched, they just bought it outright.

Since then, nothing. Founder Jeffrey Veen became the User Experience Manager and has been associated with a number of projects. Measure Map simply faded and was forgotten.

Except, not completely. Today Google emailed early MeasureMap users and said:

About your Measure Map account

Remember Measure Map? A couple of years ago, we gave you an account on an
early alpha test of our blog analytics software. Since then, a lot has
happened. We got acquired by Google, we redesigned their Analytics app, and
we’ve since rebuilt Measure Map from the ground up.

I’m writing you because we need to move everyone over from their Measure Map
accounts to the new version at Google. If you’re no longer interested, no
problem. You can stop reading this now. But if you’d like to try out the new
service, here’s how: [instructions followed]

I went through the signup process, which requires a Google Analytics account and tracking pixel. They then said “Great! You’re all set. We’ve got a few things to set up on our end. We’ll send you an email when we’re ready (soon!) and explain how to log in.”

I’m emailing Google now to see if they’ll give more details on the planned launch and how it will be different from Google Analytics.

Crunch Network: CrunchGear drool over the sexiest new gadgets and hardware.

Our live coverage of the Google App Engine launch event is here (Update: we’ve built and launched a test application here).

Google isn’t just talking about hosting applications in the cloud any more. Tonight at 9pm PT they’re launching Google App Engine (Update: The site is live), an ambitious new project that offers a full-stack, hosted, automatically scalable web application platform. It consists of Python application servers, BigTable database access (anticipated here and here) and GFS data store services.

At first blush this is a full on competitor to the suite of web services offered by Amazon, including S3 (storage), EC2 (virtual servers) and SimpleDB (database).

Unlike Amazon Web Services’ loosely coupled architecture, which consists of several essentially independent services that can optionally be tied together by developers, Google’s architecture is more unified but less flexible. For example, it is possible with Amazon to use their storage service S3 independently of any other services, while with Google using their BigTable service will require writing and deploying a Python script to their app servers, one that creates a web-accessible interface to BigTable.

What this all means: Google App Engine is designed for developers who want to run their entire application stack, soup to nuts, on Google resources. Amazon, by contrast, offers more of an a la carte offering with which developers can pick and choose what resources they want to use.

Google Product Manager Tom Stocky described the new service to me in an interview today. Developers simply upload their Python code to Google, launch the application, and can monitor usage and other metrics via a multi-platform desktop application.

More details from Google:

Today we’re announcing a preview release of Google App Engine, an application-hosting tool that developers can use to build scalable web apps on top of Google’s infrastructure. The goal is to make it easier for web developers to build and scale applications, instead of focusing on system administration and maintenance.

Leveraging Google App Engine, developers can:

• Write code once and deploy. Provisioning and configuring multiple machines for web serving and data storage can be expensive and time consuming. Google App Engine makes it easier to deploy web applications by dynamically providing computing resources as they are needed. Developers write the code, and Google App Engine takes care of the rest.
• Absorb spikes in traffic. When a web app surges in popularity, the sudden increase in traffic can be overwhelming for applications of all sizes, from startups to large companies that find themselves rearchitecting their databases and entire systems several times a year. With automatic replication and load balancing, Google App Engine makes it easier to scale from one user to one million by taking advantage of Bigtable and other components of Google’s scalable infrastructure.
• Easily integrate with other Google services. It’s unnecessary and inefficient for developers to write components like authentication and e-mail from scratch for each new application. Developers using Google App Engine can make use of built-in components and Google’s broader library of APIs that provide plug-and-play functionality for simple but important features.

Google App Engine: The Limitations

The service is launching in beta and has a number of limitations.

First, only the first 10,000 developers to sign up for the beta will be allowed to deploy applications.

The service is completely free during the beta period, but there are ceilings on usage. Applications cannot use more than 500 MB of total storage, 200 million megacycles/day CPU time, and 10 GB bandwidth (both ways) per day. We’re told this equates to about 5M pageviews/mo for the typical web app. After the beta period, those ceilings will be removed, but developers will need to pay for any overage. Google has not yet set pricing for the service.

One current limitation is a requirement that applications be written in Python, a popular scripting language for building modern web apps (Ruby and PHP are among others widely used). Google says that Python is just the first supported language, and that the entire infrastructure is designed to be language neutral. Google’s initial focus on Python makes sense because they use Python internally as their scripting language (and they hired Python creator Guido van Rossum in 2005).

Update: Here is Guido van Rossum at the launch event talking about App Engine:

Crunch Network: CrunchGear drool over the sexiest new gadgets and hardware.

Google may be releasing BigTable, its internal database system, as a web service to compete with Amazon SimpleDB, according to a source with knowledge of the launch. There are also rumors that press is being pre-briefed on the product, although we haven’t been contacted by Google.

BigTable is a highly scalable database system used internally by Google to support over 60 of its products and projects. A source says Google has plans to announce next week that it will make BigTable available to outside developers as a service. Amazon provides a similar service through SimpleDB, a cloud database solution announced in December.

Google started development on BigTable in early 2004 and began using it actively in February 2005. The non-relational, proprietary system was designed internally to fulfill Google’s peculiar need for access to massive amounts of data at very high speeds (millions of read/writes per second). BigTable is based on the Google File System (GFS) and designed for distribution across thousands of commodity servers that collectively store petabytes of data. Services that rely on it include Google Search, Google Earth and Maps, Google Finance, Google Print, Orkut, YouTube, and Blogger.

The decision to open up BigTable would seem to mark Google’s challenge to Amazon Web Services (AWS) suite, which also includes the Elastic Compute Cloud (EC2) for cloud processing power and Simple Storage Service (S3) for cloud storage. The Amazon triumvirate of SimpleDB, S3, and EC2 is meant solve the scalability needs of web developers with a utility-like model. Customers pay for just the storage, computations, and bandwidth they need, and none they don’t. While Google has yet to announce the pricing for BigTable, we presume it will share the same model as AWS.

If Google does indeed announce public access to BigTable next week, expect the company to follow up with cloud storage and processing solutions as well, since there are substantial synergies between the three.

For more information about BigTable, see a paper (PDF) that was written about it in 2006. You can also watch a talk about it given at the University of Washington in October 2005.

Crunch Network: MobileCrunch Mobile Gadgets and Applications, Delivered Daily.

While there may not be as much buzz about OpenSocial right now as there was at launch, lots of progress is being made by folks inside and outside of Google. This collaborative effort includes teams from Hi5, MySpace, Plaxo, Ning and a variety of other partners. The fruit of many of these efforts are going to start arriving publicly very soon, with major platforms like MySpace, Orkut and Hi5 set to move out of private beta this month and next.

And at last week’s O’Reilly Graphing Social Patterns West 2008 in San Diego there were some valuable sessions on social network platforms and OpenSocial. One very good example was a session lead by Google’s Patrick Chanezon, Kevin Marks and Chris Schalk as well as Lou Moore from Hi5. As Patrick notes is blog, “It was a great opportunity to have the 3 OpenSocial developer advocates from Google on stage at the same time, usually we all travel to different conferences. I made an introduction about OpenSocial, Chris described the API, showed code and did a demo of PixWall on Orkut, Kevin talked about Shindig and Caja, and demoed Shindig working in the Eclipse debugger.” As shown in the slides embedded below the session did indeed cover a lot of ground, from high-level overview to code snippets.

| View | Upload your own

Lou Moore, Hi5’s Director of Engineering, highlighted useful, platform-specific extensions to OpenSocial including functions for things like photos and online presence as well as a simple template/tag library. One of OpenSocial’s central benefits is its ability to help standardize common functionality at one level but still facilitate extensibility on a per-platform basis.

For more on OpenSocial see the OpenSocial spec, our OpenSocial profile, as well as the Caja and Shindig projects. And another good event to get the latest on OpenSocial will surely be Google I/O coming at the end of May in San Francisco.

Share This

No search engine since Google has been able to captivate me for more than a few seconds. But this morning I found one that I sorta kinda maybe liked. A bit. And that is huge news!

The service I am talking about is ManagedQ, a Palo Alto based startup company founded by engineers from Stanford. ManagedQ is officially in ‘deep stealth’ right now but apparently not THAT deep because anyone can use it.

ManagedQ is not a Search Engine, or so they say. They aspire to become the first Search Application. The difference? Well according to their blog “A Search Application is dedicated to helping you manage your entire Search Experience: from the keyword, to results, to previewing, to refinement and repeating with a new query”.

Their story is that regular search engines are not helping you much. It is simply a matter of entering a search query and getting a bunch of results spat back without any form of interaction beyond that. This makes the Search engines of today little more than front-ends to large databases. ManagedQ wants to guide you through the whole search process by showing you a large screenshot of every result from your query and then create an ‘Executive Summary’ of each link they found. Then they shows you Persons, Places and Things that are related to your query. By hovering over menus you see new results clustered around your query. This works amazingly well.

As Pete Warden (The guy who first discovered ManagedQ) describes:

Traditionally you do a search and then click through to the results pages, eyeballing each one for the information you want. If the results aren’t good enough, you’ll go back and refine your query, doing a complete new search.

With ManagedQ, you’ve suddenly got an interactive refinement stage that lets you poke and prod the result set and easily get a lot more information. You can instantly narrow your search by ignoring bad results that don’t contain terms you want, without throwing away all the others that could be interesting. You can get a quick feel for whether the results are worth exploring by throwing in good indicator terms that are likely to be in the ones you want.

So will I trade in Google for ManagedQ? Probably not. But I might use it to visualize connections between people, things and places connected to stuff.

UPDATE: I got a message from the management team at ManagedQ with some comments:

The reason we call ourselves a Search Application is because we actually run on top of Google. So you’re still getting the exact same Google results except with a radically improved Search Experience. So for all the Google users out there, you’re not going to suffer any reduction in Search quality, only a drastic improvement in the Search process.

Additionally, the back-end is modular so we can connect it to Yahoo, Powerset, enterprise search engines, or any combination of the above.

We know we’re still brand new to the game, and Rome wasn’t built in a day. But we are constantly improving ManagedQ and with the help of the community we’re going to have the best Search Product.

With some time Boris, we hope to win over all of your Searches. But for today, thank you for searching with ManagedQ.

Reposted from my blog

Would you like to be able to make a quick call to get a JSON response that ties together a social graph made up of resources available on the Web?

Brad Fitzpatrick, Kevin Marks, and others at Google have released a new Social Graph API that does just that:

The new Social Graph API makes information about the public connections between people on the Web easily available and useful. You can make it easy for users to bring their existing social connections into a new website and as a result, users will spend less time rebuilding their social networks and more time giving your app the love it deserves.

Here’s how it works: we crawl the Web to find publicly declared relationships between people’s accounts, just like Google crawls the Web for links between pages. But instead of returning links to HTML documents, the API returns JSON data structures representing the social relationships we discovered from all the XFN and FOAF. When a user signs up for your app, you can use the API to remind them who they’ve said they’re friends with on other sites and ask them if they want to be friends on your new site.

This is exciting to me as:

• It actually uses the microformat standards such as XFN
• The API is a simple URL, like the Chart Server API. E.g. http://socialgraph.apis.google.com/lookup?q=bradfitz.com&edo=1&pretty=1&callback=onDataLoaded
• Brad uses a resource that others do not have access too…. he uses the Google crawler. Genius!

I gave it a quick test drive, and when I say quick, I mean 5 minutes :)

I built a tiny JavaScript library that takes a base URL, and it graphs out the relationships using Canvas.

You get to call loadGraph(URL, { width: w, height: h }) and the graph will be injected away.

It needs to be nicely abstracted and isolated so you can call it willy-nilly, but it works.

Watch the introduction video: