Google

If you host or get code from Google Code then this will be of interest to you. Google code now has the availability of content licenses. This will help promote the best practice of licensing open source code.

The Google Code team is pleased to announce the availability of content licenses for projects hosted on code.google.com. Projects owners may now select from either the Creative Commons Attribution license or the Creative Commons Attribution-Share Alike license to indicate the terms under which their non-source code materials may be distributed.

You can read more about this here.

The Ext JS team has released version 1.0 of its SDK for developing GWT applications with the Ext JS library. Despite some controversy around Ext's licensing strategy (namely the switch from LGPL to GPL), Ext GWT is currently one of the better integrations between a Java web application framework and a JavaScript framework.

Ext GWT 1.0 has been compiled and tested against GWT 1.5 RC1. Downloads are located here.

Google has announced that they have added more real-time market data to Google Finance. This is great news for any user of Google Finance.

Below is an excerpt from the Google post announcing the change.

We're excited to let you know we're adding more real-time market data to Google Finance, Google.com and other Google properties. Starting today, you'll have access to real-time, last sale prices from the New York Stock Exchange (NYSE), along with those from NASDAQ, which we recently launched. Here's the NYSE press release.

What this means is that you can now get the latest real-time stock quotes on Google for free. Wondering what Ford (F) is trading at today? Search for it on Google or Google Finance and keep the page up to have the quotes stream live.

If you use iGoogle, add the Google Finance portfolio gadget to your homepage, and monitor all your NYSE and NASDAQ traded stocks in real time throughout the day.

You can read the full post here.

Google Finance is a very useful app to anybody following the stock market and anything that makes this app more useful is great.

It's interesting that I just finished up a post on keypress navigation, because I've come across a little gem called goosh [goo-sh], an Ajax-based UNIX-like Google search shell that enables you to use the Google search engine with only your keyboard. Sporting a variety of commands listed in its help menu, goosh is just what you need to make your Googling just that much quicker.

Google itself has seen the value in adding keystroke navigation to their search engine as shown in one of the experimental search tools in Google Labs [demo].

Check your mouse at the door and visit goosh.org

Google recently released Google Health. The application makes it easy for users to keep track of their medical records. Along with releasing Google Health they have also released the Google Health Data API.

Below is an excerpt about the Google Health Data API.

The Google Health Data API allows client applications to view and send Health content in the form of Google Data API feeds. Your client application can use the Health Data API to create new medical records, request a list of medical records and query for medical records that match particular criteria.

Here are some of the things you can do with the Health Data API:

• Upload patient medical records.
• Get patient medical data and provide personalized functionality based on that data.

How do I start?

If you're new to the Google Health Data API, here's how we recommend you get started:

1. Get familiar with the Google Data protocol.
2. Read the Google Health Developer's Guide.
3. Refer to the Reference Guide, as needed.
4. Read about the supported CCR elements.

You can learn more about Google's Health Data API here.

I can see a lot of uses of this API for medical related mash-ups.

Michael Podrazik has written an interesting post on what the next App Engine Language will be. If you don't know about App Engine it currently supports Python and you can read more about it here.

Below is an excerpt from the post.

So how reasonable would it be to offer a hosted Java environment? While almost any hosting provider currently gives you the option of running PHP, lots of 'em give you Perl, etc. virtually nobody except boutique hosting providers let you run Java. There's a good reason for this. First of all, Java is an enterprisey language and the apps that use Java on the server side are not especially well suited to run in a shared environment. Secondly, even if the market existed, there are technical limitations that make running Java in a shared resource pool problematic. While you can chroot PHP to prevent people from accessing the shared, underlying filesystem, with Java you can spawn threads and do lots of other things that make implementing resource consumption quotas problematic. The fact that you can't just run a Java program using an Apache module or through CGI, and the fact that there tends to be a mismatch in the skill sets that *nix ops people usually have and the skill set required to effectively manage a Java app just further muddies the waters.

What you would really need is a customizable JVM that let a hosting provider limit what hosted apps are allowed to do. You may be able to do this with a locked down SecurityManager, but doing the kinds of things that Google is doing with the App Engine Python implementation would be even better. Not very many people have the chops to write their own VM. Google is one of them, and oh yeah, they've already sorta done it. Twice.

GWT is interesting in that you write your applications in Java with certain elements of the API stripped out and the compiler translates your code to JavaScript. Android apps are written in Java with certain elements of the API stripped out and the compiler translate your code to run in Dalvik. Why not do something like this for App Engine and make it a trifecta?

Google is pouring a lot of resources into Java lately and in a public way. Guice is getting lots of attention lately as a Spring competitor.

You can read the full post here.

So, the post predicts that the next App Engine Language will be Java. However, it predicts that the API will be limited. I would love to hear your thoughts on this prediction, so leave your thoughts in the comments.

With the recent addition of 10 languages to the Google AJAX Language API, we have published an update to TubeSpy that includes support for Bulgarian, Croatian, Czech, Danish, Finnish, Hindi, Norwegian, Polish, Romanian and Swedish.

TubeSpy, a recent addition to Ajaxonomy Labs, is a YouTube Spy allowing you to see what videos others are watching on YouTube right now! TubeSpy was built using jQuery, the YouTube API, and more recently, the Google AJAX Language API to add support for other languages.

Visit TubeSpy

You may have been reading a lot about Google Friend Connect, but aren't clear exactly how it works. Well, over at the Google Friend Connect blog they have explained exactly how it works.

Below is an excerpt from the post.

We figured you might be tracking the conversations about Google Friend Connect and Facebook. We want to help you understand a bit more about how it works on the Friend Connect side with respect to users' information.

People find the relationships they've built on social networks really valuable, and they want the option of bringing those friends with them elsewhere on the web. Google Friend Connect is designed to keep users fully in control of their information at all times. Users choose what social networks to link to their Friend Connect account. (They can just as easily unlink them.) We never handle passwords from other sites, we never store social graph data from other sites, and we never pass users' social network IDs to Friend Connected sites or applications.

The only user information that we pass from a social networking site to third-party applications is the user's public photo, and even that is under user control.

That's the high-level view. But what about the details? Here is more information on exactly how Friend Connect interacts with third-party social networks and applications.

1. Google Friend Connect puts users in control over whether they're connected to their data on Facebook.
2. Google Friend Connect only reads a small amount of user data from Facebook, and does so using Facebook's public APIs. We read the Facebook numeric id, friendly name, and public photo URLs of the user and their friends. We read no other information.
3. The only user information that we pass from Facebook to third-party applications is the URL of the user's public photo.
4. Google Friend Connect does not permanently store any user data retrieved from Facebook.

You can read the full post here.

This is very useful information as I know that I was about confused as to exactly how it worked when I first heard of it.

Later today Google will be launching a new service called Friend Connect. Read Write Web has written an interesting post about the new service raising some concerns.

Below is an excerpt from the post.

You Can't Use it Yet

While the whole developer and publisher world is anxiously awaiting details from the launch tonight, Google is putting a damper on adoption by limiting the Friend Connect "preview release" to a handful of white listed apps and a short list of selected websites. The company says it has to prove it can scale the infrastructure (ooh, can Google scale? I don't know, better limit the approved users to just a tiny handful!) and it wants to see what kinds of features developers and site owners want to request. Apparently the company believes this feedback is best done by making said parties look from the outside and send emails guessing about what they'd like to see once they are let inside. This seems completely backwards to me.

You Can't Touch What's Inside the Magic Box

Site owners will be able to add Open Social apps to their web pages - sort of. They'll be able to display them inside an iframe, a separate web page inside a webpage. They won't be able to leverage that user data to change what they deliver themselves to their users.

Apps in an iframe may as well be a social sidebar ala Flock or Yoono. Those collections of social apps are probably more useful anyway.

Conversations Are Complicated

Google made it clear during their press call that they are aiming for the easiest, simplest and safest way to enable social apps to be integrated into other websites. It will take less than six months, they promise.

Let's be clear that it's not going to be easy to figure out how to enable all this user data to be mashed up in acceptably safe ways. We asked Google how they can assume that one user's friends on IMeem have permission to access their info out on other sites around the web. They said that users will have to be given the option whether to expose that info to third party sites or not, something we haven't seen any details on yet from the original source social networks. That would be even more difficult if the destination sites had read, much less write, access to that ported-in social networking data.

You can read the full post here.

While the post raises some interesting concerns, I think that the service may turn out better than the post states. While I think the initial release of the service may have some issues, Google has a proven track record that bodes well for the service over time. We can only wait and see what happens.

TubeSpy, our YouTube application from Ajaxonomy Labs, now supports 11 new languages. By utilizing the Google Language API, TubeSpy is now able to dynamically change the language used in the application.

Languages now supported by TubeSpy include:

• English
• Arabic
• Chinese
• Dutch
• French
• German
• Italian
• Japanese
• Korean
• Portuguese
• Russian
• Spanish

Here's a sample in Russian:

The app is still in beta, so be aware there may be some layout/formatting issues with the additional languages. In any case, please send us your comments, bugs, and feature requests.

Go to TubeSpy