Lee Sedol of Korea reclaims Fujitsu Cup

Go / weiqi / baduk news: Lee Sedol 9 dan of Korea defeated Choi Cheolhan 9 dan also of Korea to win the 18th international Fujitsu Cup. This is Lee Sedol's third Fujitsu Cup win in four years. View the game record here.

AJAX + JSON - XML = AJAJ?

It might be fun, but is it a good idea? The open-ils project has been proud of its AJAX-like architecture with a twist - they see XML as too heavy so they use JSON. (AJAJ?)

"We've taken XMLHTTPRequest one step further and added JSON to the mix. JSON (mentioned in this blog previously) is a 'lightweight data-interchange format' (see json.org). It gives us a way to turn program objects into strings, or serialize them. JSON is great for us because it's a lot lighter than XML. It allows us to encode our data with practically no extraneous data clogging the lines. As a quick example, an array converted to JSON would look something like this: [ 1, 2, 3]. Whereas in XML it might appear like so: <array> <item>1</item> <item>2</item> <item>3</item> </array>. Even with a small dataset you see an immediate difference in the number of characters required to encode the object."

I am not quite sure what to make of this. It reminds me of a number of conversations that I have had mainly with older more experienced colleagues who approach me to explain the "XML thing" to them. Almost invariably, they are horrified at the overhead that XML carries with it. Almost invariably, I try to explain that it is worth it.

The open-ils team has also extended JSON with something they call "class hints".

"JSON parsers exist in many languages, and we've developed our own parsers in C, Perl, and Javascript. Why did we write our own, you ask? You guessed it - we took JSON one step further as well. We added what we call class hints to the JSON format. This allows us to parse a JSON string and determine what type of object we're looking at based on a hint encoded as a comment within the object. So, for example, the Javascript JSON parser might receive a JSON string from the server that is encoded with a class hint of 'user'. The JSON parser will then be able to turn the JSON string into a full blown Javascript 'user' object that knows how to access and update the data it contains."

It goes without saying that had they stuck with XML, all of their data objects would have been self describing. In fact, they had to break the JSON standard precisely because it is too concise to be self describing. Was it worth it? Are the open-ils guys and gals just being conservative in putting data optimization before usability, or are they on to something that the AJAX crowd is missing?

Google Maps icons

I just completed my first hack with the new Google Maps API. It is a work in progress supporting my daughter's fundraising hikes in Elk Island National Park (click the static image below to go to the interactive map).



The new API is very slick and easy to work with. The one area of complexity is around custom icons. Although it is well documented in the API docs, I discovered this complexity when I wanted to use two colors of numbered markers in place the of the standard "pinkish" lettered markers used by Google (RTFM, Chris). To save myself much grief, I created my own set of pink and red numbered markers based on the pinky lettered Google ones. This way I could rely on the default shadow images and other icon defaults. And here they are for you to use too.




Requests to the web community and/or Google:

• Someone needs to build a repository of freely accessible Google Maps icons, including the necessary shadow images, image maps, and JavaScript constructor code in order to properly use the icons.
• Someone needs to build a Google Map polyline drawer as I, for one, would rather trace polylines using my mouse than hand code the points on a path.