jerakeen.org

Google bookmarks doesn’t really have an API. Which is annoying. It doesn’t even seem to obey any of the many many Google authentication systems, so to use it I have to screen-scrape the login dialog.

However, it will serve all the bookmarks as a mozilla bookmarks html file, so I can write a script that pulls the bookmarks down to the local machine and puts them somewhere predicable, so I can use Launchbar to access them quickly. And I get a backup.

All in all, it’s not a bad solution to the ‘I want to put my bookmarks in the cloud’ problem I’ve been trying to solve recently.

http://lnkr.mobi/lnkr/google_bookmarks_api/

Google G1 developer purchase programme - you can now buy SIM-unlocked and flashable G1 phones for a mere $400 + shipping. Which isn’t too bad.

http://code.google.com/android/dev-devices.html

http://twitter.com/andypiper/statuses/950991782

I will be attending Ruby Manor on Saturday November 22

http://upcoming.yahoo.com/event/1110036/

I find this vaguely unsettling.

http://flickr.com/photos/jerakeen/2869955413

http://twitter.com/jerakeen/statuses/923152737

Apparently , “internet maps such as Google and Multimap were good for driving but left out crucial data people need to understand a landscape”. Which is rubbish. Firstly, as blech says, “if the OS had licenced its data to Google Maps, then maybe people would use it”. But mostly I hate this old-fashioned attitude that there’s only one possible view of a map, and that it therefore has to contain everything. As Google say in the article, churches, shops, landmarks, etc, are on the map. They’re just in an information layer that’s not visible by default. The ability to see a custom map with the information relevant to me at a particular moment is great. The interface for displaying this stuff is lacking. But I’d much rather approach the problem from this direction than trying to deal with a single map for all purposes.

http://news.bbc.co.uk/1/hi/uk/7586789.stm

the google appengine uploader isn’t unicode aware. Grrr. Easily fixable, but still an irritating oversight.

http://code.google.com/p/googleappengine/issues/detail?id...

The current trunk version of Shelf uses the Google Social Graph API to figure out who owns the web page you’re looking at. If it can’t find a person in the local address book who owns the URL, Shelf can now ask Google if there are any other pages on the internet that link to that page with a rel=”me” relation, and look for those pages in the local address book. So for instance, if I visit my linkedin profile page, Shelf will display context about me, as linkedin links to http://jerakeen.org/. Likewise, any page that I link to from jerakeen.org will be considered mine as well. This elevates Shelf’s context-finding ability to practically magical levels in some cases.

Alas, there are disadvantages. Most superficially, the context-deriving part of Shelf was never designed to make long-running network queries, and so lives in the GUI code. Calling the Google API blocks the GUI thread. This sucks. Fixable, of course, but it makes the current development version somewhat choppy.

More serious is that Shelf now sends the URL of every web page I visit, and the homepages of everyone who’s twitters I read, and the base URLs of every RSS feed I read, to Google. I want to look for context in the email signatures of people that send me mail too, so soon it’ll be sending the homepages of everyone who mails me as well. Some people would consider this creepy. Actually most people would consider it creepy. And I don’t blame them. I don’t really have a solution for this one either, other than a big clearly-labeled option to turn it on.

On the API

For this sort of use the Social Graph API is great. Although all this information is available through just fetching the source of the current page and looking for links myself, there’s no way I’d want Shelf as a local GUI app to be doing that sort of thing. Google aren’t exposing anything I couldn’t have found out myself, but they’re doing it in a simple and fast manner, and using the API is trivially easy. No API keys, dealing with XML, registering my app or anything. I love that they just went with JSON as the format, and hang everything else.

Where’s the next release?

On a related note, Shelf development has been a little slow recently. Partially I’ve been distracted by shipping important features for Dopplr, but mostly it’s because I’ve hit a sort of psychic barrier of progression. Shelf needs a decent caching layer. And a threaded context discovery layer. And a much better event-driven model for display stuff, so it makes a more controlled number of network requests to fetch RSS feeds. Basically, now I’ve explored the problem, I want to rewrite the whole thing to take advantage of my understanding. And that’s boring. So I’m not doing anything. I’ll get over it.

Google docs presentations. Meh. I just really like the video about it. Very silly style.

http://googleblog.blogspot.com/2007/09/our-feature-presen...

I’ve moved the DjangoKit source and documentation (such as it is) into Google Code at the request of Rob Hudson, so other people can work on it. Other people? Work on my code? Crazy.

Thanks to a combination of dopplr, XML, mattb and Zimki, you can now display the locations of your Dopplr fellow travelers in Google Earth.

http://flickr.com/photos/mbiddulph/506393746/

http://desktop.google.com/script.html