Refresh

The node.js project has been getting a lot of good press and positive attention over the past few months. With good reason. If this is the first you’re hearing of node.js, it’s officially an “evented I/O for V8 JavaScript” but more generally it is used as a tool for writing non-blocking network servers. This means that it can easily be made into a JavaScript-based and highly efficient web server. If you’re curious, have a look at Simon Willison’s nice write-up.

Node is still in it’s infancy. For example, there’s is still a lot of discussion going on on the mailing list about core API (i.e. how to handle communication between and chaining of events or even how the final file API is going to look). Since node isn’t designed explicitly as a web server, there’s only low-level http support — and of course, there is no standard web application framework for handlings requests, sessions, cookies, and users.

The first question to be answered is if you’d actually want big web applications to run solely on node.js? But for now I’ve skipped that question entirely and simply asked how I’d approach writing such and application (hopefully reusing some of the code being currently being pushed by the node community)?

It seems as if every person in that community has written her or his own lightweight library for handling web requests. To name a few, there’s Djangode, Express, Coltrane, Vroom, and node-router). A lot of these are obviously inspired by the approaches taken by either Django or by Rails (it’s right there in the names), but taken as a whole they’re very limited in how they approach the task. Most of the frameworks are just different syntaxes for binding a JavaScript function() {} to a URL — without the modular approach taken by their more mature counterparts.

This means that you can easily use any of these frameworks if you need to write up a simple — and fast! — web app in a single file with a few hundred lines of code (in that case, I’d opt for Djangode), but you’d be stomped if wanted different, re-usable applications meshing into a single project. Benjamin Thomas has gone in designing mode in order to come up with a mini-framework which isn’t quite as mini as the ones listed above. His ambition is to build…

- The ability to bundle up a collection of controllers/views, models and templates into “apps” for easy portability and reuse.
- Smart defaults that hide a lot of the options/power/complexity. I think this is important for getting up and running quickly.
- A code base that is as small and simple as possible.
- I want it to feel javascript-like. Whatever that means.

The end result is Bomber. I like how Bomber creates simple URL routing to file-based (or rather node.js module-based) views, and how it lightly extends the core http.ServerRequest and http.ServerResponse objects. It feels almost native, but you see that enough of a foundation exists for this framework to actually include the ability to handle POSTs, sessions, cookies, multiple applications within a project and so on. There are no great ambitions where the framework will suddenly include a native XML parser (just a random example, sorry), but there’s enough room to grow and spread the webby wings a bit.

The Bomber project is very much in flux. In fact, it might even be dead since the last commit is a month old. And the entire project is build around an Action API which about to be deprecated. Hopefully to be replaced with DOJO-style, native Deferreds.

I’ve been playing around a bit by adding some extra stuff to Bomber through my own fork at github. I’ve already tweaked a little with the app structure to allow for multiple projects to be bootstrapped with different configurations from the same Bomber library, and there is some copy-paste and bug fixes in there as well. This will likely include experiments with multi-application projects, per-application media directories, cookie and session handling and templating (although I disagree with Benjamin that Bomber should include its own templating system; this could probably be left for the programmer to choose).

And now, back to Jersey Shore, bitches!

A while back a spent a little time creating a simple service that allows tune-tweeting with legible, short URL. For example, twune.net/DioDiver will play Holy Diver by Dio. And twune.net/BeatlesHand will give you The Beatles’ I Want To Hold Your Hand.

The scheme was inspired by some of the cool work that Morten Just has been doing by mashing up YouTube videos with different data sources — and I was happy Morten let me re-use some of his code.

The service works by parsing the search string from the url (using WikiWords or whatever you’d call them). It then tries to find a perfect match on Yahoo! Music which will be played in Yahoo’s video player. If that doesn’t work, the search is passed on to YouTube with the help of Morten’s player. It’s that simple.

The name of the service was suggested by @guan. I had originally wanted to call it Twack. Still unsure which is best?

I was surprised to learn that there’s no way to access a user’s location history in Fire Eagle. And, in fact, Yahoo only stores the most recent user location. This a really, really, really limits how Fire Eagle can be used from both a user perspective and from a developer point-of-view.

As a user I’d much, much rather have Fire Eagle store my history centrally (and even forbid developers for storing this history themselves). This would allow me to control which applications can (at least in theory) access my trail, and which parts of the trail is available. To me, relegating this responsibility to 3rd-party developers negates much of the purpose of FE, because then there’s no one-stop place for storing and accessing locations data.

As a developer, I’ll probably need to work around this limitation by building a FE-specific data model for storing locations and by polling for user locations every five minutes or so. This seems highly inefficient, since I won’t be the only developer facing this problem.

Read more in the Fire Eagle discussion group…

I’ve written about Fire Eagle before and it’s no secret that I had high hopes for the projects. A few hours ago the nice people at Yahoo sent me a beta invite, and greedily read through the developer docs to see what goodies awaited… The result, sadly, is that there aren’t many goodies at the moment.

Most importly, Fire Eagle doesn’t come with any applications yet, so it’s really hard to test the actual UI. I typed in my current location and it registered it. That’s it. Disappointing.

On the API front Fire Eagle doesn’t push too many boundaries either: You can set a user’s location, and you can get the user’s location. As has been reported before, Fire Eagle handles privacy in two ways. First, you need to verify an application’s access level (just as when you use the Flickr or 23 API), and depending on that level of access locations are returned more or less precisely. If, for instance, you only want a Facebook app to know your current city rather than the exact coords, Fire Eagle allows for that. Which is cool. It’s nice that you can upload coords from a GPS tracking thingy and still retain some intimacy.

I won’t make a point-by-point comparison of Fire Eagle to the Plazes API — but they are really similar in scope and ambition. The only difference is that Fire Eagle will see support in fifty apps by April 1st. Plazes won’t. Also, Fire Eagle is not trying to be a social network as well as a backend interface. It’s only the glue between locator apps and location apps.

As I probably mentioned in my previous post I have great hopes for Fire Eagle, but I’m largely underwhelmed by the beta. Hopefully, nice people on the interweb will prove me right in the upcoming weeks?

Update: Nice! While I was bitching about not being able to use Fire Eagle for something useful, Dopplr released support for the Eagle.

Yesterday I spent about ten minutes assembling the map of the s-trains in this nice mashup game. It gave me an urge to do something silly and utterly pointless myself, and the result is stunning: Spilletmedbyer.dk

If you clicked the link, you’d know exactly what I did: Something Google Maps and a bit of data, and you can now guess the location of Danish cities and towns. You’re welcome.

Cheat mode:

javascript:answer(new GLatLng(currentQ.latitude,
  currentQ.longitude))