Refresh

I’ve been playing around with a new web service called Stalkify for the past week or so. The notion is simple: Stalkify makes the social graph from Last.fm available in Spotify. So all the tracks you’re scrobbling to Last.fm (and have been for the past decade or so…) suddenly makes sense in the brave new world of Spotify.

Stalkify was inspired by @Claus’s Spotify DJ, which allows you to have peers listen into DJ sets. Classy clever used spotify: URIs and some Adobe Air magic to patch this piece of software together, but I figured that you could build the same live experience by using tracks recently scrobbled to Last.fm — and making a live-updated playlist in Spotify.

So that’s the first feature: You’ll key in a username (or your username) and you’ll get a live playlist of what’s being played by that user.

An awesome upside of using Last.fm as the data exchange is that you’ll also be able to stalk non-Spotify users. For example, my good friend PolleTheWonder is a heavy Last.fm user with a list of almost 20.000 listened tracks; but he isn’t a Spotify user. With Stalkify, I’ll still be able to listen live to what Paul is playing.

I have four years of Last.fm usage and 22.559 plays to my name, and Last.fm is pretty good at collating this information into a sense of my musical taste. For example, they compile lists of my favorite tracks (from both my Winamp, my iTunes and my Spotify days), which is something I’d love to have ready at hand in Spotify. Stalkify does that: It give me a list of daily updated list of what I’m listening to the most.

(I’ll be updating Stalkify to use more features from Last.fm in the future: Top albums, Recommended artists, Neighbouring users…)

For the geeks…

Stalkify is pieced together from The Last.fm API using pylast, from libspotify (0.0.3 because 0.0.4 is buggy in playlist handling) using greenstripes and Spotify’s Metadata API using spotimeta.

All the code is a) ugly and b) available at github.com/steffentchr/Stalkify.

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!

I’m beginning work on a project which requires users to be able to navigate the content of a web page using only the keyboard, and where switching focus using the standard method of tabbing is not an option either. To solve this problem, I’ve pieced together KeyboardFocus.

KeyboardFocus does one thing: Look through all elements on a web page with a given class name and make those elements selectable and clickable through the keyboard — using the arrow keys and the enter key.

Using the code is really quite easy:

• Add the CSS class name focusable to all the items you need to be addresseable with the keyboard.
• Add some CSS style for .focusable, for .focused and possibly for .hovered.
• Include the Prototype and KeyboardFocus scripts in your header.
• Add the line var kf = new KeyboardFocus(); somewhere in your code.

It could look something like this:

<html>
  <head>
    <script src="/script/prototype.js"></script>
    <script src="keyboardfocus.js"></script>
    <style type="text/css">
    a {color:#06c; text-decoration:none;}
    .focusable {border-bottom:1px solid #06c;}
    a.focused {background-color:#06c; color:white;}
    </style>
  </head>
  <body>
    <ul>
      <li>A link <a class="focusable"
          href="http://www.google.com">Google</a></li>
      <li>A <a class="focusable"
          href="http://refresh.dk">different link</a></li>
      <li>A <a href="http://www.yahoo.com">
          non-focusable link</a></li>
      <li>And something <a class="focusable"
          href="http://xkcd.com/">completely different</a>.</li>
    </ul>
    <script>
      new KeyboardFocus();
    </script>
  </body>
</html>

There’s also an example with random boxes.

Apparently many email systems, include gmail, support magic in the local part of an e-mail address. For example, if your mail address is mymail@gmail.com you’ll also receive mails from mymail+randomword@gmail.com.

The obvious use for this feature is some manual spam protection: When signing up for a web service you can easily include a unique address for that specific service. This might be something like mymail+twitter@gmail.com or mymail+homebanking@gmail.com. If you ever start receiving too much spam from a given service, just blacklist the unique address.

This is slightly off-topic (actually, quite a bit so!) but I’m writing a paper and just learned that you can do search-replace in Word with regular expressions. In my case, I had some inconsistencies in how inline citations were shown before or after punctuation. To solve this, I searched for:

(\([!\)]@ [!\)]@[0-9][!\)]@\)).

And replaced with (after checking the Use wilcards option):

. \1

There are at least three gotchas in the expression:

• The usual [^0-9] is replaced with [!0-9].
• Using + to give you one or more occurences of an expression won’t work. Instead, you use @ which makes no sense.
• Since * is being used to match any string of characters, the asterisk is unavailable to match zero or more occurences.

Having said that, the whole +/*/@ controversy can probably be avoided using {n,m} (ie. {0,} or {1,})

» Microsoft word wild-card reference

Since Plazes made the concious decison to start sucking and sucking badly, it’s been hard to be a free agent floating in space (or something like that). I never know where anyone is. Hopefully, Yahoo! is going to solve that problem soon.

The universe started in 1970. Anyone claiming to be over 38 is lying about their age.

John Resig has a nice overview of the upcoming Acid 3 test, which will designed to test browser compatibility with recent innovation in the world of JavaScript and the DOM. Of course, most browsers are nearing perfect rendering of the Acid 2 test, which stressed CSS support. Mostly, I wanted to post this absolutely extraordinary screenshot from Internet Explorer 7:

Considering that the reference rendering looks like this, Microsoft has some way to travel…

This:

The idea that a language should be designed from the ground up for the purpose of providing you with an experience of harmony, calm, and enjoyment is fundamentally alien to American programming culture, and when American programmers discuss why they prefer Ruby, the fact that it was designed for their enjoyment vanishes from their own vision even when it’s right in front of their eyes. The closest equivalent we have in this country is an idea that the language was designed to be fun – which is similar, but not the same thing.

… made me this of this:

No one (so far) has said “Well, I really like my job because what I do is fun, and I get to work with some really nice people.” So here’s the question: Is that typical? Is that really how most Americans view work – as a means to an end rather than something that could (and should!) be pleasant in itself? What do you think?

It nicely poses a question I cannot answer. And it makes me wonder why don’t I find Ruby particularly pleasurable in spite of my being Danish.

When we started building 23 in 2004 the advanced javascripting of today was still in its infancy, and accordingly much of what we did back then was based on a nice mix of server-side scripting, HTML and CSS with very little client scripting in the mix. Of course, time have changed dramatically since then, and along with every other web programmer I’ve become a practitioner of this web 2.0 and ajaxy thing. This blog is a stab at documenting the experiences made along the way.

In the first few posts I’m going to kick things off by writing a few posts about the simple tools the practitioner should always have in her toolkit: A good basic stylesheet that does a bit of resetting and specifies some commonly used classes — and a few JavaScript tricks that just makes everything easier. And frankly I’m probably going to make a few detours along the way.

A small disclaimer is probably warranted: By default and by habit I’m usually building on Prototype and Scriptaculous. To be honest this wasn’t a concious choice when I made it, but never really felt the need to force a change in habit.