Fortunately, the iPhone’s Safari supports bookmarklets, so I whipped up a little bookmarklet that makes it easy to see the real original page in Reader. Here’s how to use it:

1. On your desktop computer, drag the following link onto Safari’s bookmarks toolbar: Super See Original
2. Sync your iPhone
3. Once that’s done, go to Google Reader on your iPhone, and navigate to a blog entry.
4. Hit the bookmark icon at the bottom, then choose Bookmarks Bar > Super See Original
5. The original page for your blog entry should open in a new “tab”!

I have no doubt that the Reader team will eventually make a more iPhone-optimized version of Reader, but until then, hopefully some of you will find this useful.

As I was setting up the blog, found that I really wanted some kind of outboard brain that could help me keep all the people and sites straight, and hopefully provide a useful reference for others. For expediency’s sake, I just used the handy “one-click” install of MediaWiki that DreamHost provides and started typing away. A few weekends later, the Headway Wiki was starting to become something useful—but I was definitely chafing against MediaWiki’s limitations. I found that I generally wanted to represent the same kinds of things about each entry:

• the name of the site
• the web address
• who runs it
• when it was launched (often with some degree of fuzziness, because even the site’s creator doesn’t really remember)
• which agencies it serves

…and a few other miscellaneous things. Unfortunately, MediaWiki is really oriented towards prose—and in fact, I found myself using repetitive prose (with a smattering of bulleted lists) to express these things. Even worse, when I wanted to connect a entry about a third-party transit site to an entry on the agency that it was helping out, I had to manually maintain the link on both ends of the connection. That is, I couldn’t just tell the system that Boston Subway Station Map had information about the MBTA, and have it automatically display that in the MBTA entry—I had to go and edit the MBTA page by hand.

I did make use of MediaWiki’s (apparently) single structural feature: categories. Categories are basically simple tags that you can add to articles, so that the software can automatically generate an index of articles that all share a particular tag. Still, in the end it was far more work than I wanted to do.

There really should be a better way to put together a structured data collection like this, something in between limited expressiveness of MediaWiki and the programming involved in putting together a custom database-backed website using Ruby on Rails or what have you. I’m pretty sure that it’s possible, because I spent several years of my life working on tools like that for the MAYA Information Commons project. Sadly, that work still isn’t available to the general public, so it’s not really a contender here. However, there are a few intriguing new possibilities.

Enter Dabble DB. At first blush, it looked like just the thing that I was looking for. It has what’s probably the best available interface for experimenting with different ways of representing interconnected information. It’s pretty straightforward to create an item, add a few fields to it, and make some of those fields two-way links to other items. That’s no small feat, since my former co-workers and I spent the better part of 2004 building something similar (and if Dreaming in Code is to be believed, the folks on the respected Chandler team were at it for even longer, at around the same time). So far, so good. But after an evening trying to make the Headway data work in Dabble DB, I’ve run into a bunch of significant shortcomings.

No boolean fields

Starting with the smallest thing, there’s no straightforward way to represent a simple checkbox for things like “does this feed contain schedule information”? You can work around this by creating a multiple-choice field with the options “Yes” and “No”, but they’re missing an opportunity to make entering and displaying these fields simpler.

Limited spatial information

Here we are, a couple years after the Google Maps API catalyzed a geographic revolution on the web, and Dabble DB’s only location options are “US or Canadian state/province code” and “Country Code”. To their credit, they do automatically link to a Google Maps search for your term in some cases, but they could provide far more interesting map views if they simply had a lat/lon geocode field and just dumped it into Google maps.

Ontological limitations

It’s very cool that Dabble DB lets you put one item in multiple “categories” (schemas, basically). But in practice, their implementation is less handy than it would seem. Say you had two kinds of things, “websites” and “data providers”, both of which have names (of course) along with other more category-specific fields. If it turns out that you want to represent something that’s both a website and a data provider, and you put both categories on the same object, you end up with two name fields.

You could take a different tack and say that a “data provider” is a specific kind of “website”, so only the website category will have a name field. That’s great, but then there’s no easy way to have the system automatically add the “website” category when you go to create your next “data provider” item. Even worse, when you go to create a new view of your data based on “data providers”, there’s no way to choose to display the “name” field from the “websites” category in the table. (Note: this isn’t strictly true for the name field, since they special-case it so that you always have some kind of identifier, but it’s true for other attributes.)

Rudimentary public views

I could probably work around all those things, but there’s one thing that makes Dabble DB unusable for the Headway data set: the public view is horribly impoverished. Here are the results of my experiments: my lovingly interlinked data has been reduced to a box of yellowing printouts, metaphorically speaking. There’s no apparent way for the viewer to see a single entry laid out in a readable form, let alone follow links between items or search & filter by different attributes.

It’s a shame, because Dabble DB really is the best that I’ve seen so far in most other respects.

Freebase to the rescue?

There’s another contender on the horizon: the wonderfully named Freebase. Tim O’Reilly recently threw a debutante ball for it on his influential blog, and it’s easy to see why it stirred some excitement (and controversy) in the online community. It sounds quite a bit like the things I was working on at MAYA, but with a pleasantly simple web-based interface and without the radical peer-to-peer architecture. On the other hand, it’s hard to say for sure, since the alpha is currently only open to a few fortunate souls, and details are scarce. Hopefully I’ll get a chance to check it out soon.

In the meantime, Dabble DB has a lot of potential, especially since they recently launched their free Creative Commons version (which made it a viable option for Headway). Hopefully, with a few refinements, they’ll be able to turn it into a compelling alternative to developing custom code any time you want to share some interconnected information.

A few weeks ago, I went on a hike to Treasure Island, and I thought it’d be a good opportunity to try out the state of the art in simple photo geotagging, so that people could see photos of my trip on a map. My first test involved:

1. Uploading the photos to Flickr using FlickrExport for iPhoto
2. Finding the spot for each for photo in Google Earth, creating a placemark, and copying the latitude and longitude into geo:lat= and geo:lon= tags on the Flickr image.
3. Using Scott The Hobo’s Flickr Photoset Maps to turn the geotagged photoset into an online map.

The resulting map is pretty nice, sluggish Yahoo map aside, and the process wasn’t too painful. The worst pain point was the cut-and-paste geocoding process.

However, since Google just released a whole slew of geographic updates, not to mention a barebones (but snappy) photo hosting service, I thought I’d give it a try using Google tools.

First step: get the photos into Picasa, Google’s excellent free Windows photo organizer. I used FlickrDown to download the photoset from Flickr to my Windows box. It was simple, though I was sad that there was no way to preserve my photos’ tags. I then downloaded the new version of Picasa from the Picasa Web Albums site. (You need to get this specific version to be able to do the fancy stuff I’m about to describe.) Picasa immediately found and imported the downloaded photos—so far, so good.

Next, I went through and geotagged the photos using Picasa’s integration with Google Earth 4. I highlighted some photos in Picasa and selected the Geotag With Google Earth option hidden away in the Tools menu.

This took me to a slick geotagging interface in Earth.

Basically, you just drag and zoom around in Google Earth until the crosshairs (which are anchored to the middle of the display) are resting on the point that you want to tag the photo with. Then you just hit the Geotag button, the view bounces to give you visual feedback, and it moves on to the next photo. This was so much more pleasant than manually copying the location to Flickr. When I was done, it brought me back to Picasa. The photos all had little crosshair icons in the corner, indicating that they had been geotagged, and a quick look at the Properties dialog seemed to indicate that the location had been added to the image’s EXIF data.

Now that the images were geotagged, I found that I could use the View in Google Earth... option to see the photo on the map. It seems that this is implemented using some sort of dynamic folder in Google Earth called Picasa Link that constantly queries Picasa for images with geotags in their EXIF—so effectively, you can browse your Picasa library geographically using Earth! I tried adding a random geotagged phonecam image from the web, and sure enough, it showed up on Earth.

OK, so now that I had found geotagged image bliss, how could I share it? I tried the Export to Google Earth File option in the Tools → Geotag menu, which yielded a nice Google Earth KMZ file with the photos embedded.

Since Google Maps recently added support for viewing KML files, I decided to see if I could view my photos there. The results were not so hot.

As you can see, it wasn’t a total bust—the locations show up correctly—but the actual photos were nowhere to be found.

Since I’d seen examples of photos on maps, I was sure it could be done—maybe they just wanted the photos to be linked from the web. The Google Earth UI didn’t seem to give me any way to replace the photos with web links to photos. However, KML is a straightforward XML format—hand-editing ahoy!

(Incidentally, I was hoping that when I uploaded the images from Picasa to my Picasa Web Album account, it would do something smart. Sadly, Web Albums didn’t show any recognition that the images were geotagged, not even in the EXIF section. I’m sure that they’ll eventually sort that out, maybe by automatically generating KML links to Maps.)

Back to the hand-editing; first I had to unzip the KMZ file that Picasa had generated. (It’s just a normal zip file, rename the .kmz to .zip and you should be able to unzip it normally.) The only file that I needed was the doc.kml file; the rest of the archive just contained the photos and thumbnails. I stripped out all the style stuff at the top of the file, since Maps didn’t seem to be paying attention to the icons anyway. Then I replaced the contents of the description tag in each placemark with an image reference and link to the images on my Picasa Web Album. Then I uploaded the KML file, and it worked!

The result isn’t quite as nice as my original map, because I didn’t immediately see a way to get smaller images out of Web Album, but it does the job.

The verdict: geotagging with Picasa and Google is a dream, viewing geotagged Picasa photos is awesome, but the web mapping part of the Google photo story needs work.

(Incidentally, while you’re checking out my Treasure Island album be sure to try pressing the left and right arrow keys while you’re looking at pictures—you can flip through photos really quickly in Picasa Web Album!)

My teammates and I are proud to present Google Transit, a new Google Labs experiment focused on helping make public transit information more accessible and understandable. We’re starting with Portland, Oregon’s transit system, but we’ll be expanding it to support other cities soon.

For more information, check out the announcement, and if you have feedback or bug reports, we’d love to hear it at labs-transit_feedback@google.com!

1. Open regedit
2. Navigate to HKEY_CLASSES_ROOT –> Installer and select Products
3. Use the Find menu to find quicktime inside that part of the key
4. Delete the part of the tree that you find
5. You should now be able to install Quicktime and iTunes without incident

• You can now look for times near a particular address using the Location area under the map. In order to do this, I wrote a little proxy to feed addresses entered on this page to the wonderful geocoder.us free geocoding service, and return the results as JavaScript literals.
• The page now remembers your location, zoom level, and selected stop between visits.
• It now works in current versions of Internet Explorer.

At this point, it’s almost suitable for regular use. The biggest improvement that’s still on my list is to do a better job of handling stops that are too close together. Right now, stops can fall too close together on the map, making them difficult to click on individually. Automatically combining these stops would help the situation.

LuaJava requires Lua 5.0, so first we need to download the Lua 5.0 source and build it:

% tar xzvf lua-5.0.tar.gz
% cd lua-5.0
% make
% sudo make install

Next, we need to build LuaJava. Download LuaJava 1.0, then extract it and switch to its directory:

% tar xzvf luajava-1.0.tar.gz
% cd luajava-1.0

Since LuaJava’s config file comes set up for Linux by default, we need to edit it to Mac OS X-friendly settings. Comment the following lines:

#JDK= $(JAVA_HOME)
#LIB_EXT= .so
#LIB_OPTION= -shared
#DLLIB= -ldl

and uncomment the corresponding ones:

JDK=/Library/Java/Home
LIB_EXT= .jnilib
LIB_OPTION= -dynamiclib -all_load

We also need to change the LIB_LUA line to read:

LIB_LUA=/usr/local/lib/liblua.a /usr/local/lib/liblualib.a

With those changes in place, we can just type

% make

and apart from a few JavaDoc warnings, everything should go smoothly. To test it, we can fire up the LuaJava Console:

% java -cp "luajava-1.0.jar" org.keplerproject.luajava.Console
API Lua Java - console mode.
> print('Hello, world!')
Hello, world!
> exit

OK, that looks good. How about the included tests?

% cd test
% ./runawttest.sh
% ./runswingtest.sh

Again, working fine. There are a couple of other Lua test files in the test directory that we can run like so:

% java -cp "../luajava-1.0.jar" -Djava.library.path=.. 
    org.keplerproject.luajava.Console testMemory.lua

(replace testMemory.lua with the name of the file you want to run)

OK, let’s try creating a program of our own. There’s a decent Hello World on the LuaJava examples page, so (after switching back to the luajava-1.0 directory), create the Hello.java and hello.lua files depicted on the examples page. You’ll need to add an import line to the top of Hello.java so that Java knows where to find all the LuaJava objects:

import org.keplerproject.luajava.*;

Once you have the files, compile the Java class:

% javac -classpath luajava-1.0.jar Hello.java

Now run it:

% java -cp luajava-1.0.jar:. Hello

If everything is working correctly, you should see:

Hello World from Lua!
Hello World from Java!

Huzzah! Now we have all the pieces we need to start embedding Lua functionality in Java code.

The current state of the art looks a bit like this–effectively a callback-based state machine:

Snippet establishPreference = new Snippet() {
    // called when the result of requestData is available
    public void dataReceivedCallback(Data d) {
        if (d.getValue("likes_marmalade")) {
            serveToast.requestData("marmalade");
        } else {
            serveBagel.requestData("cream cheese");
        }            
    }
}

Snippet serveToast = new Snippet() {
    public void dataReceivedCallback(Data d) {
        spreadOnToast(d.getValue("spoonful_of_substance"));                  
    }
}

Snippet serveBagel = new Snippet() {
    public void dataReceivedCallback(Data d) {
        spreadOnBagel(d.getValue("spoonful_of_substance"));
    }
}

To kick off this process, you would call:

establishPreference.requestData("Joe Hughes");

And then depending on whether I liked marmalade or not, I would eventually get served either toast with marmalade or a bagel with cream cheese.

This works fine, but you can see how it could easily get convoluted once you do any kind of serious branching or looping. For the sake of easier creation and maintenance of these things, I’d really like to be able to express these operations more like this:

Data customer = requestData("Joe Hughes");
if (customer.getValue("likes_marmalade")) {
    Data topping = requestData("marmalade");
    spreadOnToast(topping.getValue("spoonful_of_substance"));
} else {
    Data topping = requestData("cream cheese");
    spreadOnBagel(topping.getValue("spoonful_of_substance"));
}

When you put it that way, it’s much easier to see what’s going on. The problem is that in order for this to work, you have to be able to pause this block of code whenever you go off to do a requestData() call, and then restart it with result when you receive it. It turns out that what I’m describing is a somewhat obscure programming language construct called a coroutine.

Unfortunately, not many modern programming languages natively support coroutines. Python does, somewhat (through Stackless and the new Generator construct). Ruby seems to. Io and Lua do. Java, however, doesn’t.

I’ve certainly been able to use threads to make things that look like coroutines:

public abstract class PseudoCoroutine 
    implements DataListener, Runnable {

    private Data response = null;

    /**
     * This method starts a thread to run the specified task.
     *
     * @param task the PseudoCoroutine subclass to be run.
     */

    public static void doTask(PseudoCoroutine task) {
        t = new Thread(task, task.getClass().getName());
        t.start();
    }

    /**
     * This is a callback method from the DataListener interface
     * provided to the DataService to call when it has retrieved the requested data.
     *
     * @param d the data received
     */

    synchronized public void dataReceived(Data d) {
        this.response = d;
        notifyAll();
    }

    /**
     * Provides a delayed-synchronous way to perform a data request.
     * This method call will block until the response
     * is received from the server. 
     *
     * @param dataID the ID of the data to be requested.
     * @return A Data object corresponding to the requested dataID.
     * @throws InterruptedException
     */

    protected Data requestData(String dataID) throws InterruptedException {
        // second parameter is used to pass this.dataReceived() as a callback
        DataService.getInstance().requestData(dataID, this);

        synchronized (this) {
            while (this.response == null) {
                wait();
            }
        }

        return this.response;
    }

    // to make this a Runnable that can be passed to a thread
    public void run() {
        taskBody();
    }

    /**
     * This is where the PseudoCoroutine subclass should perform its task.
     */

    public abstract void taskBody();
}

This class lets me just use the code I had written above:

private class ServeBreakfastBread extends PseudoCoroutine {
    private String customerID;

    public ServeBreakfastBread(String customerID) {
        this.customerID = customerID;
    }

    public void taskBody() {
        Data customer = requestData(customerID);
        if (customer.getValue("likes_marmalade")) {
            Data topping = requestData("marmalade");
            spreadOnToast(topping.getValue("spoonful_of_substance"));
        } else {
            Data topping = requestData("cream cheese");
            spreadOnBagel(topping.getValue("spoonful_of_substance"));
        }
    }    
}

...

PseudoCoroutine.doTask(new ServeBreakfastBread("Joe Hughes"));

This works fine, except that each of these things now requires an OS thread, with their attendant limitations (good luck getting more than a few thousand on a desktop VM). I’d also like to have the ability for several of these coroutines to be able to operate on common state information without lots of synchronization hassle, which I can’t do if each coroutine lives in its own thread.

So, where to now? Maybe I can embed another language interpreter within my Java system and express the coroutines in that. Unfortunately, Jython doesn’t support Generators yet. I’ll have to look into LuaJava and JRuby to see if they have anything to offer.

The typical setup in my office is that I have my G5 powering two monitors front and center, and the powerbook beside them, on a (modified) iCurve for ergonomic viewing. While this is great for the displays, it leaves the problem of controlling the laptop. At one point I had a KVM switch set up, but the hassle of plugging in a USB cable and flipping the switch led me to just type un-ergonomically on the laptop’s keyboard.

Then I came across Synergy. It’s a cross-platform tool that lets you send your keyboard and mouse commands to other machines on your network–sort of like VNC without the screen-sharing (since the other screen is right in front of you). The Synergy team’s most brilliant innovation, though, is the interface for switching machines. Basically, you can configure your machines so that when you roll your mouse pointer off the edge of one machine’s screen, it magically appears on the corresponding edge of a different machine’s screen. You can roll your mouse from your Linux box across your Windows box over to your Mac in one smooth motion. It’s like the way that multi-monitor setups work, except that under the hood it’s seamlessly switching to sending your input to another machine over the network.

I’ve been using Synergy for a few months now, but it’s not without its rough edges. Last time I did it, configuration was a text-editing affair, though the SynergyKM preference pane add-on for Mac OS X makes things much more automatic. I also tended to experience general glitchiness on OS X. A vestigial mouse pointer would often remain on my main monitor, twitching distractingly, as I controlled the laptop. It also didn’t handle modifier and function keys, meaning I still had to press the function keys on the laptop directly to trigger Exposé.

Enter Teleport. While (or perhaps because) it’s Mac-only, it solves most of the problems I had with Synergy. The configuration is a breeze (using Rendezvous AKA Bonjour), and input forwarding is smooth and comprehensive. It also seems to automatically sync clipboards well, something that I was using Erik Lagercrantz’s ClipboardSharing utility for until he failed to update it for Tiger.

So far, I only have a few minor critiques. First, it doesn’t appear to allow you to put two remote screens side-by-side–the remote screens must be adjacent to the main computer’s screens. Also, it seems to hit the disk every time I roll over the boundary between two machines, which is audibly distracting and causes an annoying delay in which mouse motion isn’t counted on the new screen. Even so, I think it will be a part of my desktop setup from now on. Thanks Julien!

Since Google so graciously released an API for their excellent mapper last week, I figured I’d take it for a spin. I had written some code to prise nearby stops and bus times from the MBTA’s handy trip planner a while back, and so I decided to glom them together and see what happened. Here’s the result.

Here’s how it works: You pan and zoom around the map until you find an area of Boston you’re interested in, and then click Recalculate Stops. The map will then update to show stops within a half-mile of the center of the map. You can click on any of these points to get the next three times for the routes at that stop. Seems to work for bus, subway, commuter rail, and ferry routes.

It’s vaguely useful for an afternoon’s work, though there are a few quirks:

• Stops which are too close to each other may be impossible to click on (sometimes you can tell because their shadows look darker)–I’d probably have to write some code to combine these into a single marker.
• The same subway line is often broken into separate listings. This is something that the trip planner does, perhaps to get around some sort of database limitation? In any case, this can probably be remedied with more code on my end.
• Other than the subways, each route is listed only once per map, at the nearest stop. This means that even though the 87 might stop in several places within the mile-wide area being searched, you’ll only see the stop that’s nearest to the center of the map.
• There’s no way to jump to a particular address. The Google Maps API currently doesn’t do geocoding, though I could integrate geocoder.us or the trip planner’s built-in geocoder given a little more time.
• Clicking the Recalculate Stops button isn’t the smoothest thing in the world. My first attempt updated the query automatically when you panned the map, but that made things a bit too jumpy as you panned around to get a better look at the stops and surroundings. Needs more work.
• The iconography and layout could be better.
• I have no official connection with the MBTA, and they could break the scraping code that this depends on at any time. I hope they’ll be more flattered than offended if they find this.

All in all, the Maps API is pleasant to work with, though the way that Google binds API keys to individual directories keeps you from being able to just copy the source files from your test directory to your deployment directory. But that’s the most minor of nitpicks, given that you can dispense keys for all the directories you want. They’ve done a great job, and I think we’re going to see an even bigger wave of new mapping apps in the coming weeks.