Friday, July 10, 2009

[Gd] Dev Channel Update: Usability and stability fixes

| More

Google Chrome Releases: Dev Channel Update: Usability and stability fixes

Google Chrome has been released to the Dev channel for Windows.

Highlights in this release:
  • Fixed issue 15199 where new windows are opened off screen, in certain conditions, for dual monitor users.
  • Fixed issue 16052 where a tab would close if a new url was navigated to too quickly during a page load.
  • Alerts/authentication windows are no longer wrapped by an OS window.
  • Windowed plugins like Flash no longer hang after a print dialog is displayed.
  • Updated V8 to to fix some crashes

More details are available in the release notes and the 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

Anthony Laforge
Google Chrome Program Manager

Thursday, July 9, 2009

[Gd] A Day in the Cloud, new articles on scaling, and fresh open source projects for App Engine

| More

Google App Engine Blog: A Day in the Cloud, new articles on scaling, and fresh open source projects for App Engine

The latest release of Python SDK 1.2.3, which introduced the Task Queue API and integrated support for Django 1.0, may have received a lot of attention, but there have been a number of other notable launches and events since our last update. Several of these are summarized below.

A Day in the Cloud

On June 24th, Google Apps and Virgin America invited people from around the world to participate in a one-day online scavenger hunt called Day in the Cloud. Competitors were each given one hour to solve various puzzles and find answers to a host of trivia questions, and prizes were awarded to the top five scorers. The site was hosted on App Engine's scalable infrastructure. For more information on the challenge, including photos and videos of participants competing mid-flight, check out the official Day in the Cloud Lounge.

Scaling series

App Engine enables you to deploy and run your Python- and Java-based web applications on Google's highly scalable infrastructure. There are a number of ways to optimize the performance of an application running on App Engine, some obvious and others more subtle. With this in mind, we recently released a series of articles promoting tips and tricks that you can use to make best use of resources like memcache and prevent potential issues such as datastore contention.

We also updated the articles listing since we recognized that the growing number of articles added since April 2008 (over 35 by last count) made it difficult to find content on a specific topic. The new listing allows you to filter the list of articles based on a particular tag or label, so you can easily find all articles related to the datastore, for example.

As always, we are interested in your comments, thoughts and suggestions for new articles, so please feel free to share.

GeoModel and geomodel-demo open sourced

Google Earth API support engineer Roman Nurrik recently open sourced his GeoModel project. GeoModel uses geohash-like objects called 'geocells' to provide a generalized solution for indexing and querying geospatial data in App Engine. GeoModel is optimized for the basic real estate finder/store locator use case, but can be adapted for use with large datasets.

Using GeoModel, developers can instantly geo-contextualize datastore models by simply inherting from the GeoModel class. Currently, entities can be associated with a single geographic point and subsequently indexed and filtered by either conformance to a bounding box or by proximity (nearest-n) to a search center point.

Other open source developments

  • GaeVFS: an Apache Commons VFS plugin which implements a virtual file system on top of the App Engine datastore, using the datastore and memcache APIs.
  • GraniteDS 2.0, now with support for App Engine for Java: Granite DS is an open source alternative to Adobe Lifecycle Data Services for Java EE application servers, and supports both server push and the persistence mechanism on App Engine for Java. For more information about the project and a link to a sample implementation, see the announcement post.
  • jiql: a JDBC-based wrapper of App Engine's low-level datastore API which provides distributed database access via an interface familiar to many developers.
  • pQg: a proof-of-concept PHP-based SQL to JDO wrapper plus sample application.

Posted by Jason Cooper, App Engine Team

Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.


[Gd] My Location on Google Maps

| More

Google Code Blog: My Location on Google Maps

We've blogged before about how much we like location-based services and at Google we want all developers to be able to build these cool applications. That's why we're so excited about the W3C Geolocation API, a browser API that provides a really easy way for web applications to get the user's location.

Today we're announcing the launch of My Location on Google Maps, the first major Google web application to make use of the Geolocation API. My Location on Google Maps offers the same functionality you're probably familiar with from Google Maps for Mobile - simply click a button and your location is shown on the map with a blue dot.

Until recently, providing this kind of functionality usually meant writing a native application, which is hard work if you want to deploy on lots of different platforms. What's great about the Geolocation API is that it can be used by any web application, in any web browser that supports it, in a totally cross-platform way. Both Google Chrome and Firefox 3.5 already provide geolocation in the browser, Opera 10 will soon add support and we're looking forward to other major browsers adding support soon. As an interim solution, Gears also provides an equivalent Geolocation API and can be installed on other browsers such as Internet Explorer.

We look forward to seeing lots more cool web applications make use of the Geolocation API!

By Steve Block, Software Engineer and Jonathan McPhie, Associate Product Manager

Wednesday, July 8, 2009

[Gd] Dev Channel Update: More progress on Mac and Linux

| More

Google Chrome Releases: Dev Channel Update: More progress on Mac and Linux

Google Chrome 3.0.192.x has been released to the Dev channel for Windows, Linux and Mac.

Highlights in this release:
  • (Mac) Enabled support for the Mac OS X spellchecking service.
  • (Mac) First cut at popup blocking for Mac.
  • (Linux) Accelerator keys like ctl-C for copy should work again.
  • (Linux) Initial support of complex text (e.g. Arabic). Bug reports welcome.
  • (Linux) Initial GTK theme support.
  • (Linux) IME support.
  • (Extensions) Breaking API Change: page_actions.icon renamed to
  • page_action.icons and changed from a single string to an array of
  • strings.
  • (All) Added support for exporting/ importing bookmarklet bookmarks, thanks to Thiago.
  • (All) Fixed Acid3 Test 48: LINKTEST

Known issues:
  • Issue 15199: New windows open off screen, in certain conditions, for dual montior users.
  • Issue 16052: Tab closes if a new url is navigated to quickly during a page load.

More details are available in the release notes and the 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

Anthony Laforge
Google Chrome Program Manager

[Gd] Google Wave Hackathon and Federation Day: July 20, 21 in Mountain View

| More

Google Wave Developer Blog: Google Wave Hackathon and Federation Day: July 20, 21 in Mountain View

On July 20th and 21st the Google Wave team is organizing a couple of events at the Googleplex that'll give you an opportunity to dive into hacking on the Google Wave APIs and learn more about the Google Wave Federation Protocol.

As described on the hackathon agenda, on Monday (July 20th), we'll kick things off exploring the various APIs for Google Wave (with demos, of course), we'll chat over lunch, and then have open time for hacking with the Google Wave team sitting just a chair or so over. If you'd like to attend the event, please check out this form.

Following that event, on Tuesday (July 21st), we have Google Wave Federation Day -- the inaugural event for people who are looking to get involved by providing their own wave services. We'll discuss in depth the underlying protocol and system architecture, and show some new demos that illustrate how the system works. After lunch, we'll have discussion sessions to brainstorm about some of the technology (e.g. Operational Transformation) and the challenges (e.g. Spam). If you are interested in attending, please submit this form.

Both events will be held at the Googleplex in Mountain View, CA. Lunch, wifi, and power will be provided.

Hope to see you there!

Posted by Dan Peterson, Product Manager, Google Wave

[Gd] Old habits die hard

| More

Google Testing Blog: Old habits die hard

by Stephen Ng and Noel Yap

Old habits die hard. Particularly when it comes to testing--once you get used to working in a project blanketed with lots of fast-running unit tests, it's hard to go back.

So when some of us at Google learned that we weren't able to use our favorite mocking libraries when writing for our favorite mobile platform (Android, naturally), we decided to do something about it.

As many of you already know (since you read this blog), mocking combined with dependency injection is a valuable technique for helping you write small, focused unit tests. And those tests in turn can help you structure your code so that it's loosely coupled, making it more readable and maintainable.

With a bit of setup, this can be done in Android, too. We've put together a tutorial describing our approach. It's the first installment in what we hope will be a series of articles on android app development and testing, from the perspective of Googlers who are not actually on the Android team. We'd love to hear whether you find it useful.

[Gd] Why are we embarrassed to admit that we don't know how to write tests?

| More

Google Testing Blog: Why are we embarrassed to admit that we don't know how to write tests?

Take your average developer and ask "do you know language/technology X?" None of us will feel any shame in admitting that we do not know X. After all there are so many languages, frameworks and technologies, how could you know them all? But what if X is writing testable code? Somehow we have trouble answering the question "do you know how to write tests?" Everyone says yes, whether or not we actually know it. It is as if there is some shame in admitting that you don't know how to write tests.

Now I am not suggesting that people knowingly lie here, it is just that they think there is nothing to it. We think: I know how to write code, I think my code is pretty good, therefore my code is testable!

I personally think that we would do a lot better if we would recognize testability as a skill in its own right. And as such skills are not innate and take years of practice to develop. We could than treat it as any other skill and freely admit that we don't know it. We could than do something about it. We could offer classes, or other materials to grow our developers, but instead we treat it like breathing. We think that any developer can write testable code.

It took me two years of writing tests first, where I had as much tests as production code, before I started to understand what is the difference between testable and hard to test code. Ask yourself, how long have you been writing tests? What percentage of the code you write is tests?

Here is a question which you can ask to prove my point: "How do you write hard to test code?" I like to ask this question in interviews and most of the time I get silence. Sometimes I get people to say, make things private. Well if visibility is your only problem, I have a RegExp for you which will solve all of your problems. The truth is a lot more complicated, the code is hard to test doe to its structure, not doe to its naming conventions or visibility. Do you know the answer?

We all start at the same place. When I first heard about testing I immediately thought about writing a framework which will pretend to be a user so that I can put the app through its paces. It is only natural to thing this way. This kind of tests are called end-to-end-tests (or scenario or large tests), and they should be the last kind of tests which you write not the first thing you think of. End-to-end-tests are great for locating wiring bugs but are pretty bad at locating logical bugs. And most of your mistakes are in logical bugs, those are the hard ones to find. I find it a bit amusing that to fight buggy code we write even more complex framework which will pretends to be the user, so now we have even more code to test.

Everyone is in search of some magic test framework, technology, the know-how, which will solve the testing woes. Well I have news for you: there is no such thing. The secret in tests is in writing testable code, not in knowing some magic on testing side. And it certainly is not in some company which will sell you some test automation framework. Let me make this super clear: The secret in testing is in writing testable-code! You need to go after your developers not your test-organization.

Now lets think about this. Most organizations have developers which write code and than a test organization to test it. So let me make sure I understand. There is a group of people which write untestable code and a group which desperately tries to put tests around the untestable code. (Oh and test-group is not allowed to change the production code.) The developers are where the mistakes are made, and testers are the ones who feel the pain. Do you think that the developers have any incentive to change their behavior if they don't feel the pain of their mistakes? Can the test-organization be effective if they can't change the production code?

It is so easy to hide behind a "framework" which needs to be built/bought and things will be better. But the root cause is the untestable code, and until we learn to admit that we don't know how to write testable code, nothing is going to change...


Tuesday, July 7, 2009

[Gd] Google Maps gadget: Help customers find their way

| More

Official Google Webmaster Central Blog: Google Maps gadget: Help customers find their way

Webmaster Level: All

With the new directions gadget from Google Maps, any business can offer customized Google Maps directions to their business locations. With the directions gadget, you no longer need to type and update multiple sets of text directions. Let's face it: customers are only looking for directions from their specific location.

Last week, I looked up directions to the hotel in Sacramento that I had booked for the 4th of July weekend. As I had never been to that part of the state before, I was puzzled by the limited directions offered by their website - I had no idea whether I was approaching from the North, South, East or West or where the major highways were. What I needed were step-by-step directions from my exact starting point to the hotel that I could easily print and go.

Google has made this process easy for you. By copying and pasting a single line of code, any website can offer customized door-to-door directions powered by Google Maps to their users.

The gadget allows you to pre-fill the "To" field with one or multiple addresses. Customers are able to print their directions with a single click. And for those who prefer not to drive, the gadget also provides walking and public transit directions.

If someone enters a vague starting address, they have the option to specify a more exact address, which will then fly into the "From" field.

Providing directions from Google Maps is very flexible; in addition to run-of-the-mill addresses, you can give your customers directions to everything from a generic ZIP code to a specific set of latitude-longitude coordinates for any of your locations.

Example destinations:
123 River St, Woods, MA
42.06782° N, 71.756963° W

You can also give your address an alias, or a name that everyone will understand. You can do this by putting the alias in parentheses just after the address:

42.06782° N, 71.756963° W (Grandma's House)

Take a look at how Legoland California, Emeril Lagasse, and Harvard University are using the gadget. And then test and create your own directions gadget here. For the many locations outside of the US, the gadget is available in 23 different languages.

Written by Julie Zhou, Product Marketing Manager, Google Maps

[Gd] Native Client Security Contest: The results are in!

| More

Google Code Blog: Native Client Security Contest: The results are in!

A few months ago, we challenged you to discover exploits in the Native Client system and more than 600 of you decided to take us up on our invitation. We're very pleased with the results: participants found bugs that enabled some really clever exploits, but nothing that pointed to a fundamental flaw in the design of Native Client. Our judges reviewed all entries very carefully and have selected five teams as the winners of the Native Client Security Contest.

The big winner of the contest was the team "Beached As", consisting of IBM researcher Mark Dowd and independent researcher Ben Hawkes. "Beached As" reported 12 valid issues, including vulnerabilities in the validator and multiple type-confusion attacks. The team "CJETM" (Chris Rohlf, Jason Carpenter, Eric Monti — all security professionals with Matasano Security) came in second by reporting three issues with a common theme of memory related defects, including an uninitialized vtable entry, an exception condition during new(), and a double delete bug. Gabriel Campana from Sogeti ESEC R&D Labs was selected as the third place, while for the fourth and fifth place we had a tie between independent researcher Daiki Fukumori and Rensselaer Polytechnic Institute student Alex Radocea. You can find a listing of all the issues the teams submitted at the Native Client Security Contest site.

The winners of the Native Client Security Contest, Team "Beached As"
Mark Dowd (left) and Ben Hawkes (right)

Winning teams were attracted to the contest by the potential of the Native Client technology. Mark Dowd, member of the winning team "Beached As", commented, "When I saw the press release announcing the product, I was intrigued by some of the ideas mentioned in the article. After reviewing the architecture a little, I thought the project adopted a novel approach to solving the problem of running native code securely, and was keen to take a closer look." Curiosity about what the technology could achieve also motivated the CJETM team, according to Chris Rohlf.

The real-world relevance of Native Client made this contest more interesting and challenging for participants. Contestant Alex Radocea stated, "Unlike most security challenges out there, the set of problems were not crafted. The tasks at hand were real and complex, as the real world is. I have no doubt that many unknown people eyed the code or attacked the applications and, frustratingly, found absolutely nothing wrong." Mark Dowd agreed: "Our goal was to create a convincing lead, to try and take the victory, and I think we did that. Having said that, the field was not soft. There were some tough contestants who were able to uncover a variety of interesting vulnerabilities."

We would like to thank all the contestants, the jury chair Ed Felten and all the security experts that judged the contest for helping us improve the security of our system. This contest helped us discover implementation errors in Native Client and some areas of our codebase we need to spend more time reviewing. More importantly, that no major architectural flaws were found provides evidence that Native Client can be made safe enough for widespread use. Toward that end, we're implementing additional security measures, such as an outer sandbox, but you can help by continuing to file bugs in Native Client. Community support and scrutiny has helped and will continue to help make Native Client more useful and more secure.

By Henry Bridge and Brad Chen, Native Client Team

[Gd] AdWords Downtime: July 11, 10am-2pm PDT

| More

AdWords API Blog: AdWords Downtime: July 11, 10am-2pm PDT

We'll be performing routine system maintenance on Saturday, July 11 from approximately 10:00am to 2:00pm 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.

-Jeffrey Posnick, AdWords API Team

[Gd] Webmaster Central YouTube update for June 29th - July 3rd

| More

Official Google Webmaster Central Blog: Webmaster Central YouTube update for June 29th - July 3rd

Want to see what's new on the Webmaster Central YouTube channel? Check out the answers to the latest Grab Bag questions:
Do you run a small business? Check out Matt's tips on how to attract visitors on a small budget:

Feel free to leave comments letting us know how you liked the videos, and if you have any specific questions, ask the experts in the Webmaster Help Forum.

Posted by Michael Wyszomierski, Search Quality Team

Monday, July 6, 2009

[Gd] Dev update: Animated GIF Fix

| More

Google Chrome Releases: Dev update: Animated GIF Fix

Google Chrome has been released to the Dev channel for Windows, Linux and Mac.

Highlights in this release:
  • Animated GIFs fixed.
  • Extensions changes, see Dev Channel Visible Changes post to the Chromium-Extensions mailing list.
  • Printing fixes for Windows.
  • Try out the New New Tab Page by using the command line switch --new-new-tab-page.  Don't wait for the new new new tab page, get yours today!
  • Linux now supports IME for non-roman script languages.
  • Fixes for misbehaving proxy servers.
  • "Save As" now available on Mac.
  • More details are available in the release notes and the log of all revisions.
Known issues:
  • Issue 15846: (Mac) Google docs : shortcut to save a document (Command+S) is not implemented
  • Issue 15844: (Linux) Bookmarks bar context menus disabled on first open of bookmark manager
  • Issue 15845: (Linux) Bookmarks that do not fit in the bookmarks bar cannot be accessed
  • Issue 15848: Thumbnails on New Tab Page don't have spacing in between

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

Jonathan Conradt
Engineering Program Manager
Google Chrome

[Gd] Separation anxiety?

| More

Google Testing Blog: Separation anxiety?

by Shyam Seshadri

We all have separation anxiety. Its a human tendency. We love inertia, and we don’t like change. But why should your code have separation anxiety ? Its not human (even though it might try and grow a brain of its own at times)!

I bring this up because I got the chance to work with someone who had some questions on how to test UI code. Fairly innocuous question, and in most cases, my response would have been, keep the UI code simple and free of any logic, and don’t worry too much about it. Or you could write some nice end to end / integration tests / browser based tests. So with that response set in mind, I set off into the unknown. Little was I to know was that was the least of my concerns. As I sat down to look at the code, I saw that there were already tests for the code. I was optimistic now, I mean, how bad could things be if there are already tests for it ?

Well, I should remember next time to actually look at the tests first. But anyways, there were tests, so I was curious what kinds of tests they wanted to write and what kind of help I could provide, if any. So it turns out, the class was some sort of GUI Component, which basically had some fields, and depending on whether they were set of not, displayed them as widgets inside of it. So there were, say, 5 fields, and differing combinations of what was set would produce different output. The nice thing was that the rendered data was returned as a nice Java object, so you could easily assert on what was set, and get a handle on the widgets inside of it, etc. So the method was something along the following lines :

public RenderedWidgetGroup render() {
RenderedWidgetGroup group =

if ( = null) {
return group;
group.addWidget(new TextWidget(;
new DateWidget(
this.updatedTimestamp == null ?
this.createdTimestamp : this.updatedTimestamp));
return group;

So far, so good, right ? Nice, clean, should be easy to test if we can set up this component with the right fields. After that, it should just be a few tests based on the different code paths defined by the conditionals. Yeah, thats what I thought too. So, me, being the naive guy that I was, said, yeah, that looks nice, should be easy to test. I don’t see the problem.

Well, then I was taken to the tests. The first thing I see is a huge test. Or atleast thats what I think it is. Then I read it more closely, and see its a private method. It seems to take in a bunch of fields (Fields with names that I distinctly remembered from just a while ago) and churn out a POJO (Plain Old Java Object). Except this POJO was not the GUI Component object I expected. So obviously, I was curious (and my testing sensors were starting to tingle). So I followed through to where it was called (which wasn’t very hard, it was a private method) and lo and behold, my worst fears confirmed.

The POJO object generated by the private method was passed in to the constructor of the GUI component, which (on following it further down the rabbit hole) in its constructor did something like the following :

public MyGUIComponent(ComponentId id,
Component parent,
MyDataContainingPOJO pojo) {
super(id, parent);

And of course, readData, as you would expect, is a :

  • Private method

  • Looks through the POJO

  • If it finds a field which is not null then it sets it in the Gui Component

And of course, without writing the exact opposite of this method in the unit test, it just wasn’t possible to write unit tests. And sudddenly, it became clear why they were having trouble unit testing their Gui Components. Because if they wanted to test render (Which was really their aim), they would have to set up this POJO with the correct fields (which of course, to make things more interesting / miserable, had sub POJOs with sub POJOs of their own. Yay!) to be exercised in their test.

The problem with this approach is two fold :

  1. I need tests to ensure that the parsing and reading from the POJO logic is sound, and that it correctly sets up the GUI Component.

  2. Every time I want to test the render logic, I end up testing (unintentionally, and definitely unwantedly) the parsing logic.

This also adds, as I saw, obviously complicated pre test setup logic which should not be required to test something completely different. This is a HUGE code smell. Unit testing a class should not be an arduous, painful task. It should be easy as setting up a POJO and testing a method. The minute you have to perform complicated setup to Unit test a class (Note, the keyword is unit test. You can have integration tests which need some non trivial setup.), stop! There is something wrong.

The problem here is that there is a mixing of concerns in the MyGuiComponent class. As it turns out, MyGuiComponent breaks a few fundamental rules of testability. One, it does work in the constructor. Two, it violates the law of demeter, which states that the class should ask for what it needs, not what it doesn’t need to get what it needs (Does that even make sense ?). Thirdly, it is mixing concerns. That is, it does too much. It knows both how to create itself as well as do the rendering logic. Let me break this down further :

Work in the constructor

If you scroll back up and look at the constructor for MyGuiComponent, you will see it calling readData(pojo). Now, the basic concept to test any class is that you have to create an instance of the class under test (unless it has static methods. Don’t get me started on that…). So now, every time you create an instance of MyGuiComponent, guess what ? readData(pojo) is going to get called. Every. Single. Time ! And it cannot be mocked out. Its a private method. And god forbid if you really didn’t care about the pojo and passed in a null. Guess what ? It most probably will blow up with a NullPointerException. So suddenly, that innocuous method in the constructor comes back to haunt you when you write yours tests (You are, aren’t you ?).

Law of Demeter

Furthermore, if you look at what readData(pojo) does, you would be even more concerned. At its base, MyGuiComponent only cares about 6 fields which it needs to render. Depending on the state of each of these fields, it adds widget. So why does the constructor ask for something totally unrelated ? This is a fundamental violation of the Law of Demeter. The Law of Demeter can be summed up as “Ask for what you need. If you need to go through one object to get what you need, you are breaking it.”. A much more fancier definition can be found on the web if you care, but the minute you see something like A.B().C() or something along those lines, there is a potential violation.

In this case, MyGuiComponent doesn’t really care about the POJO. It only cares about some fields in the POJO, which it then assigns to its own fields. But the constructor still asks for the POJO instead of directly asking for the fields. What this means is that instead of just creating an instance of MyGuiComponent with the required fields in my test, I now have to create the POJO with the required fields and pass that in instead of just setting it directly. Convoluted, anyone ?

Mixing Concerns

Finally, what could be considered an extension of the previous one, but deserves a rant of its own. What the fundamental problem with the above class is that it is mixing concerns. It knows both how to create itself as well as how to render itself once it has been created. And the way it has been coded enforces that the creation codepath is executed every single time. To provide an analogy for how ridiculous this is, it is like a a Car asking for an Engine Number and then using that number to create its own engine. Why the heck should a car have to know how to create its engine ? Or even a car itself ? Similarly, why should MyGuiComponent know how to create itself ? Which is exactly what is happening here.


Now that we had arrived at the root of the problem, we immediately went about trying to fix it. My immediate instinct was to pull out MyGuiComponent into the two classes that I was seeing. So we pulled out a MyGuiComponentFactory, which took up the responsibility of taking in the POJO and creating a GuiComponent out of it. Now this was independently testable. We also added a builder pattern to the MyGuiComponent, which the factory leveraged.

class MyGuiComponentFactory {
MyGuiComponent createFromPojo(ComponentId id,
Component parent,
MyDataContainingPOJO pojo) {
// Actual logic of converting from pojo to
// MyGuiComponent using the builder pattern

class MyGuiComponent {
public MyGuiComponent(ComponentId id,
Component parent) {
super(id, parent);

public MyGuiComponent setName(String name) { = name;
return this;


And now, suddenly (and expectedly, I would like to add), the constructor for MyGuiComponent becomse simple. There is no work in the constructor. The fields are set up through setters and the builder pattern. So now, we started writing the unit tests for the render methods. It took about a single line of setup to instantiate MyGuiComponent, and we could test the render method in isolation now. Hallelujah!!

Disclaimer :

No code was harmed / abused in the course of the above blog post. There were no separation issues whatsoever in the end, it was a clean mutual break!


[Gd] Google I/O Scavenger Hunt Winners

| More

Google Code Blog: Google I/O Scavenger Hunt Winners

The astute conference attendee would have noticed hidden QR codes around the conference, as well as the scannable QR codes on everyone's badge. We wanted to find a fun way for people to bond with their new phones, as well as network with other attendees, so we set about creating a scavenger hunt game using Google App Engine & Friend Connect. The app handled game logistics (a leaderboard, URL endpoints), and we printed up a bunch of custom QR code stickers that pointed to game URLs.

App Engine made writing the scavenger hunt app much easier than it otherwise would have been. The initial version of the app took one developer less than a day to turn out, and we continued to add functionality and tweak it as I/O approached and we tested it in real-world situations. The versioning deployment made it very easy to test and push out new versions without disrupting existing users.

The overall structure of the app was very straightforward: every QR-code had a unique URL, which was embedded into the generated QR code. A URL was associated with a number of points to be awarded and a destination URL (such as the user's profile information, in the case of a user's badge QR code). Users were signed in using Friend Connect, which allowed us to avoid concerns of authenticating users and managing sessions.

When a user visited a URL for the first time, we recorded that fact so they couldn't try and get extra points with repeat visits, then sent them to the destination URL. We also kept a running count of the user's score against the User entity, so as to not have to count up their points on every request. Generating the leaderboard was a simple matter of querying for the users with the most points and displaying them.

QR codes were generated using the Chart API, which simply takes a string of text and a few other parameters, and returns a fully formed QR code.

The three resourceful and persistent folks below beat out the competition to rise to the top of the scavenger hunt ranks - going to great lengths, including swag bribery, to gain points. A hearty (if belated) congratulations to the winners of the Google I/O mobile scavenger hunt!

1st Place - Abraham Williams
2nd Place - Waylon Flinn
3rd Place - Pete Richards

We hope everyone that participated learned how to use their Android phones a little better, met people they otherwise wouldn't have, and had some fun :)

By Stephanie Liu, Google Developer Programs