The Google Data team is holding a local event for developers Thursday, December 13th, 5:00pm-10:30pm at the Googleplex (Mountain View, CA). It'll be part hackathon, part unconference, part user group, part food, and part fabulous prizes.

Besides a short kick-off session, everything else will be up to you. We'll provide the wi-fi, power and food, and you can utilize the time however you want -- whether it's to pick the brain of someone on the GData team, meet other local developers, hack away on your current project, sit in on impromptu sessions about things like GData + Gears and GME, or hold your own lightning talk about the project you're working on.

For about two years now, people have been writing gadgets for Google Desktop onWindows and for iGoogle on the web. Today, with the announcement of GoogleGadgets for Mac OS X, Google Desktop users on the Mac can now run the sameWindows and web-based gadgets in Apple's Dashboard with zero (or very few)changes. Check it out for yourself.

Google Gadgets for the Mac uses WebKit's JavaScript engine inside Dashboard, sothe majority of gadgets just work if they're written properly. The rest can befixed by following a few guidelines:

Use JavaScript, not JScript

WebKit is case-sensitive, JScript is not, which can lead to problems if you assume can you do things like interchange SetTimeOut() and setTimeout().

Avoid JScript-only features like collections and ActiveX.

Avoid IE-specific DOM extensions, just as if you were writing a multi-browser web application.

Avoid Windows-specific APIs

You shouldn't assume ActiveX or certain DLLs are available. Neither WebKit nor Mac OS X supports ActiveX, so these gadgets must be rewritten.

Avoid Windows-only APIs such as Google Talk. These APIs are not (yet) available on Mac OS X.

Understand how Dashboard is different

The Dashboard environment is very different from a web page or the Desktop sidebar on Windows in that it comes and goes as the user activates it. Don't rely on your gadget always being visible. Your gadget won't run or update when Dashboard isn't in the foreground.

Don't rely on access to the file system. The security model for Dashboard doesn't allow arbitrary file access to the hard disk, although your gadget does have access to files in its own archive. Things like file pickers won't work. Note that while restricted file system access is a departure from how gadgets work on Windows, it's consistent with Dashboard's security model and the behavior of other widgets developed for Mac OS X.

If you're interested in developing your own gadget, visit the Gadgets API homepage. If you're already a gadget developer, download the beta today to test your gadget and ensure that it works correctly.

Portable, Chronoscope is not tied to GWT, can be used to render from servlets, applets, or other environments.

What is particularly interesting is how the Chronoscope team was able to take their existing Java source code, add 8 hours of Android exploration, and ended up with the same charting and visualization library that works on Android using their graphics support.

This is one area that GWT truly shines. The fact that you write your code in the Java programming language means that you can reuse it in other places where Java runs. Being able to write one application and quickly have it run on Android and the iPhone is pretty compelling.

The Google Summer of Code program has been a joint labor of love between Google and the open source community for the past three years, and the results have been spectacular: hundreds of college students have been introduced to open source software, thousands of people across the globe have begun development together and millions of lines of open code have been produced, 4 million last year alone. We've been particularly proud of this program and how much it has helped the community and we've spent a lot of time thinking about ways we can continue helping open source projects find even more contributors. Today, we're pleased to announce the Google Highly Open Participation Contest, our new effort to get pre-university students involved in all aspects of open source development, from fixing bugs to writing documentation and doing user experience research.

While we're very excited about many aspects of the contest, the best part is that everyone can participate. Contestants must meet the eligibility requirements, but anyone interested in helping out can simply suggest a task to be included in the contest. Our contestants have a chance to win t-shirts, cash prizes, and a visit the Googleplex for a day of technical talks, delicious food and a photo with our very own Stan T. Rex.

Want to learn more? Check out the contest FAQs and tell your favorite pre-college students to pick a task or two to complete. You can always visit our discussion group to get help or share your thoughts.

By Sean Owen, Google Print Ads TeamRecently in the New York Times, we placed a small graphic as part of a Google Print Ad. You aren't looking at one of those eye focus games (It's a sailboat! Or a shark!) but a two-dimensional barcode. Those of us who already know what it is pulled out our phones and "clicked" it with the camera, and were connected to the advertiser's web site. "Wha?", you say? See http://www.google.com/printads/barcode. While this kind of thing has been a common sight in Asia for years, this ad is one of many signs that the technology is arriving in Europe and North America.

But Advertising is only part of the story here. Engineering is also involved and we want to improve the quality and availability of barcode reader software available to developers and end users. So today I would like to announce the "ZXing" (from: "zebra crossing") project, an open-source, Java, multi-format 1D/2D barcode reader which can be built into a reader application for Java and Java ME -- and later, Android.

This project began as a 20% project and is not yet complete, so opening it up is a bit of an experiment. It's not yet the Best Barcode Reader Ever, but it's looking pretty good. For now we want to find those those who can make use of and help improve what's here, so that those good ideas are shared to all developers and everybody wins.

Developers can find the ZXing project on Google Code, and we hope you'll join us on our Google Group and tell us about what you like and don't like about the code.

I just have to take a breath as I start this posting. The last couple of weeks have been a real trip as we first announced OpenSocial and then Android, both announcements that have drawn a lot of interest.

Let's start with Android. We started out announcing the Open Handset Alliance and made sure people realise that this effort is bigger than a Google Phone. It is a mobile platform, with many phones to come! After some of the initial surprise we released the part that you, as a developer, care about: Android SDK.

There are a couple of fun new open source projects announced: AxsJAX aims to make accessible Ajax applications more possible, and nsscache is an open source named services system.

We put together a nice piece on a spider's view of Web 2.0 which discusses SEO principles and how Web 2.0 practices affect, or do not affect them. What about Web -1.0? That is discussed in this great tech talk on the Web that wasn't. A nice history lesson.

I got to host my first tech talk at Google. I was lucky enough to pull in Steve Souders, Chief Performance Yahoo!, to discuss High Performance Web Sites and YSlow. If you want to make sure your sites run well, check out his core principles.

Oh, and one other thing. The Google Code team did a huge amount of work in revamping Google Code which coincided with the major launches. We believe that the site is a lot cleaner now, and gives us a base to work on as we move forward to do a better job at serving all developers out there. Thanks for joining us so far.

With hundreds (if not thousands) of popular email clients and mail servers out there, importing email into another service can be challenge, especially when you consider the troves of old email most people save. To ease this pain, we created the Google Apps Email Migration API.

This new API is available in Google Apps Premier, Partner, and Education Editions, and you can use it to migrate your existing email from anywhere into Google Apps. Let's say, for example, you want to import email from your Obscurix Email Server v2.0001715. Just write some parsing code and use our simple API to upload that email into the desired mailbox. For convenience, you can authenticate to the API not only as the end user of the destination mailbox, but also as a Google Apps administrator, and target any mailbox in the domain. This API uses the Google data API protocol, which means there are a host of client libraries to make importing even easier.

As the developer behind Fire Vox I've always wanted to make AJAX web applications truly usable for the blind and visually impaired. The challenge is that these users have to deal with a much higher learning curve than sighted users. Instead of simply learning the controls for a web application, they have to also learn how to get their assistive technology of choice to go to the interesting parts of that application to find out what is currently there.

When I started as a Noogler, I was extraordinarily impressed with the tools that T.V. Raman had built into Emacspeak for efficiently performing specific tasks. An insight that I gained from watching him use Emacspeak is that the application should just say the right thing in response to user actions; users should not have to do an action in the application and then use their assistive technology to go hunting around the screen to figure out what happened.

In my first week at Google, I discovered Google Reader a highly optimized feed reader with very good keyboard support. For my starter project at Google, I decided to access-enable this application using W3C ARIA. Using Greasemonkey, I could inject JavaScript code to add the needed ARIA bits to make Google Reader say the right things at the right time.

Connecting The Dots

Based on the experience of access-enabling Reader, we have now refactored the code to come up with a common JavaScript framework for enhancing the accessibility of AJAX applications. This framework is called AxsJAX, and it was refined in the process of access-enabling Web Search.

We're now excited to open-source this framework since we believe that there is nothing Google-specific in the techniques we have implemented. We invite the Web developer community to help us collectively define a robust framework for rapid prototyping of accessibility enhancements to Web 2.0 applications.

The ability to rapidly prototype end-user interaction has led to an explosion in the number of AJAX applications; until now, visually impaired users have been left behind in this process. We hope that the AxsJAX framework encourages the Web community to bring the power of Web 2.0 development to solving the problem of accessing rich Web interaction in an eyes-free environment.

Many of those subscribed to this blog have heard our recent announcement about the Open Handset Alliance, and we thought we'd bring everyone up to date. Today, the team released an early look at the Android SDK for developers interested in building applications for Android.

By the way, we've released more than just the SDK. Those of you who follow the development of the Linux kernel on ARM may have seen that we released our initial patches that provide kernel support for the QualcommMSM7K. This release means that support in the Linux kernel is now available for the on board serial, i2c, timer, NAND flash controller, MDP/MDDI framebuffer, gpio controller, and high speed USB client controller. This code also provides access to the baseband features of the chip. The announcement to the kernel developer community can be found on the ARM Linux mailing list. Like all proper Linux kernel code, these patches were released under v2 of the GNU GPL. Stay tuned for more open source related details.

We're really excited about all of these developments and can't wait to see what results. To help get things started, we've also announced the Android Developer Challenge, a $10 million challenge to reward developers for working with the platform. Head over the Android Developers blog to find out more about this exciting mobile platform.

Remember remember the fifth of november, especially if you have to manage unix Named Services (NSS) on a lot of workstations! We're releasing a small python utility, called nsscache, that is used to cache remote NSS maps locally on a given host. Combined with cron, it provides a simple and effective way to remove a critical network dependency from your hosts and potentially speed things up a bit.

You'd be surprised how upset a system can get with a slow, unresponsive, or missing NSS.

This initial release supports pulling passwd, shadow, and group maps from an RFC 2307 LDAP schema and storing them in either nssdb or flat text files. In a wee bit, we'll also release support for netgroup and automount maps as well. The utility is fairly plug and play; our hope is that folks who use it with other data sources (sql databases, soap, etc) and possibly other data stores will extend our codebase and share their extensions with the rest of the open source community.

Why you may be interested?

As soon as you have more than one machine in your network, you want to share usernames between those systems. Linux administrators have been brought up on the convention of LDAP or NIS as a directory service, and /etc/nsswitch.conf, nss_ldap.so, and nscd to manage their nameservice lookups.

Even small networks will have experienced intermittent name lookup failures, such as a mail receiver sometimes returning "User not found" on a mailbox destination because of a slow socket over a congested network, or erratic cache behaviour by nscd. To combat this problem, we have separated the network from the NSS lookup codepath, instead using an asynchronous cron job and a glorified script, improving the speed and reliability of NSS lookups.

We'll be giving a small presentation about our motivations and experiences at the upcoming linux.conf.au event in Melbourne Australia, if you happen to be down under in February!

Patrick is easy to talk too, and I think that comes across in the interview itself. There has been a lot of pre-release speculation on what OpenSocial really is, and the press has put out wildly different ideas over the last couple of weeks. Patrick lays out the facts of the announcement.

He covers a lot, including:

What has actually been released

What OpenSocial isn't

Details on the various APIs:

People Data API: You can get access to owners and viewers, and their friends

Also, check out video from the Campfire One event and interviews with a subset of the partners involved in the OpenSocial launch. Having a large number of application developers and container vendors show what they have already done gives you a glimpse to the future.

When Vic asked me to organize a campfire on campus, at first I thought he was joking. But when he kept asking how big the fire was going to be, I quickly realized he wasn't. Thus Campfire One was lit.

Campfire One is a means to share product announcements with lots of people in a way which keeps pace with Google's release cycle. We invite a few people to campus and record our news for the web. There's no Campfire Two, just another Campfire One in the future. The 'One' signals that we've flipped the bit on something we think is worth sharing.

Tonight at Campfire One we were very excited to introduce OpenSocial, a common set of APIs for building social applications across the web. With OpenSocial, developers have less to learn in order to build for multiple websites. There are a number of companies already working on the OpenSocial APIs, including those who presented with us tonight: MySpace, Ning, hi5, iLike, FotoFlexer, RockYou, Slide, Viadeo, Flixster, LinkedIn, Ning, Salesforce, Theikos, and Virtual Tourist. Watch Campfire One from earlier this evening:

By the way, did you know that oak on a campfire is supposed to smoke less than fir? I don't think some of our presenters believe it. You might say we had a bit of a real 'smoke test' before rolling the cameras.

In 2005 we launched Google Code to provide a home for our developer and open source programs. Two years, dozens of new products and new programs, and one major redesign later, Google Code is bigger and more dynamic than ever. With today's relaunch we've added a new search auto-complete feature (to help you find your favorite products with a keystroke or two in the search box), an expanded and improved search results page, a cleaner and more comprehensive site directory, new blog and group gadgets, and a simplified and unified look and feel for product documentation.

To get a sense of how far things have come you can take a look at the first version of Google Code, back when the whole site almost fit on one page. Today we have thousands and thousands of pages of content on Google Code, and we've added the new site directory and new search features to help you navigate them.

One of the most exciting things about the redesign is that everything you see here was built using technology and APIs that are available to everyone. The pages we're serving don't rely on any secret back-end tricks; the site is built on plain HTML, JavaScript and CSS, each using our public APIs. In fact, all of the techniques used on Google Code can be duplicated on your own site.

But the best thing about Google Code hasn't changed: And that's you, the developer, our never-ending source of inspiration. Your projects provide countless examples for the Featured Projects feeds, your words and wisdom power the developer groups, and your accomplishments and ideas never cease to amaze us with the possibilities and potential for a better web. This redesign was for you, and I want to personally thank all of you for being such an integral part of Google Code. Together we're capable of doing something very special.

Please join us on the Google Code Blog, (where we'll be enabling comments for this and future posts), and let us know where you're headed and how we can help you get there.