July 17, 2009

Creating websites with builtin APIs

Whether or not its RESTian kosher I don't know, but the live Apollo 11 transcript is built natively around a JSON API. If you don't like mine - feel free to make your own.

Details: The API is at


http://www.classy.dk/cgi-bin/apollo_transcript.pl?q=transcript&jsonp=somejsonp_prefix

- note the jsonp parameter, which lets you call the api from JQuery and similar libraries without cross site worries. Don't need JSONP. Don't know what it is? just use

http://www.classy.dk/cgi-bin/apollo_transcript.pl?q=transcript

instead. If your javascript api needs the parameter, the doc will explain how to use it.
The output is quite simple: There's a 'now' parameter indicating server time (seconds since unix epoch), time of liftoff in same terms and notes from the log. The item 'current' is the latest transcript item before now. The item 'future' a list of the next events to occur.
The format of the events is an array with four elements: time, an id for the speaker, the actual text and a text representation of the time - relative to 'now'
If you build something using this script, please be conservative in how frequently you call the API - the future item gives you an idea of when it makes sense to call.

If something is unclear just view source on http://classy.dk/moon - which explains in source how to use it with JQuery, and gives tables describing the IDs of speakers.


This way of building websites: Presentation with HTML+CSS+JQuery and a pure API backend really appeals to me. Clearly there are fallback concerns for non-modern browsers etc. etc. but the separation of concerns is appealing - as is the instant availability of an API for other's to use.

Posted by Claus at 3:05 PM | Comments (0)

March 13, 2009

How much abstraction does it take to run Twitter

On Twitter, @tveskov asks, how many layers of abstraction does it take to run Twitter.
This is a really hard question, probably intractable - if you want to include the physics and signalling of lasers through the fiberoptic cables that sends Twitter's data to my home. There are simply too many different places along the route where the platform relies on some level of abstraction and comprehension, to do a full enumeration.
Instead, let's tackle a simpler question: How many technologies/abstractions are directly visible in Twitter's source code. I did a view source and tried to find all the technology that I could see from the source would be in use to run Twitter.
The rule here is that it there has to be text in the source file that does not make sense unless I know the abstraction/standard/software/API I'm referring to below.

Here my best shot at the list (in order of discovery (by me, while reading))


  • xhtml

  • DTD's

  • XML namespaces

  • XML

  • CSS

  • Browser DOM

  • utf8

  • ico file format

  • png file format

  • gif file format

  • jpg file format

  • HTTP

  • RSS

  • ATOM

  • URI scheme

  • HTML4 (I think. Seems the "bookmark" rel attribute comes from there)

  • "nofollow" microformat

  • "hcard" microformat

  • DNS

  • Javascript

  • JQuery API

  • There is some kind of anti-bot posting implementation - but I can't tell what the API for that is like

Notably absent: The email standards. While obviously employed by twitter (as are many other standards if the API is considered), I found no evidence of email in the source of the logged in front page.

Posted by Claus at 5:53 PM | Comments (0)

February 22, 2009

Keyboard remapping on Mac OS X

The Danish Keyboard mappings for the Mac are insane. The hack-necessary { and } keys are hidden away under a double modifier and various other keys have gone missing. Fortunately you can use Ukulele to remap the keyboard. Even this however is slightly insane, so here's how.
Btw: This is not the good way to do "functional remapping" (i.e. map this key to PageUp) other tools do that.


  1. Install and open Ukulele (this may not be bizarre to the mac savvy, but the app does not grab focus when you start it)

  2. File|New

  3. Choose 'copy from other layout'

  4. In the Ukulele distribution are copies of all the standard layouts. Danish is under the 'Roman' layouts

  5. Remember to give your layout a name in the Keyboard menu

  6. Here's the slightly insane part: The layout is organized by modifiers. The entire layout, that is, e.g. "here's how the keyboard looks when option key is down". You can't use a modifier combination that isn't already in the layout. (You can add new ones through an interface so lacking in intuititiveness that I didn't figure it out). I had little luck mapping cmd-single key to a new character as an example. Mapping stuff to alt-something however works fine, as there is already an alt- keyboard.

  7. Chose a modifier. Double click a key. Choose a value. Repeat

  8. Save the file in your ~/Library/Keyboard Layouts

  9. Go to System Preferences|International|Input Menu and enable your layout there. This is where you'll be sorry if you didn't rename distinctively.

  10. Log out and then in again

  11. You should now be done


This is just an intermediate fix so typing is actually possible. Now all I need is proper universal page down and up and other things the non-Mac world is used to.

Posted by Claus at 10:37 AM | Comments (0)

April 24, 2008

Fire Eagle is Plazes

It's good to see Plazes adapt to Fire Eagle, but really - isn't Fire Eagle really plazes. The infrastructure to share your location. Your social then happens where that is good, not necessarily on plazes.

Posted by Claus at 1:32 AM | Comments (0)

February 23, 2008

OOXML is too hard to implement

Amen to this. OOXML is a braindump of a 20 year history, not a standard. Braindumps are always messy. XML-ifying the mess Joel Spolsky describes here does not make for a nice implementable truly open standard.

Posted by Claus at 4:37 PM | Comments (0)

February 15, 2008

The problem with strongly typed languages is all the typing

(a joke I never thought of before -

Posted by Claus at 12:32 PM | Comments (0)

October 11, 2007

The routes to software suck

Taking a break from almost joky anecdotes of horrible software, Worse Than Failure - aka Daily WTF - has a nice essay on how projects end up sucking.

Good stuff. Many situations/problems mentioned that many of us have been in. I've certainly played both flattering and unflattering roles around problems like the described ones.

Posted by Claus at 7:17 PM | Comments (0)

October 7, 2007

REST, the web and disruption

Another non-technical way to look at it is from the viewpoint of Clayton Christensen’s classic book, The Innovator’s Dilemma. For quite a few years now, we’ve seen a series of sustaining innovations in the “object/service RPC” line of descent originally popularized by CORBA and COM, both of which built on earlier RPC, distributed object, and TP monitor technologies. RMI, EJB, SOAP, WS-*, and ESB are all offspring in that line, and there are surely more to come. I feel that REST, on the other hand, fits the definition of a disruptive innovation perfectly (and if you’re too lazy to read the book, then please at least follow the link, otherwise you won’t understand this at all). The proponents of the sustaining technologies look at REST and say, “well it can’t solve this and it can’t solve that” and voice numerous other complaints about it, precisely as Christensen predicts they would. But Chistensen also explains why, at the end of the day, any real or perceived technical shortcomings simply don’t matter (and in this case, they’re mostly perceived, not real).

- is the awesome pull out from a really good blog post.

Disruptive technologies, "view source", wikis, social media, it all plays together...

Posted by Claus at 9:12 PM | Comments (0)

September 30, 2007

Tool philosophy and bad UI

Not so long ago I came across a thread, where a Linux newbie was trying to engage the experts by asking "What are the most useful commands at the terminal?". The post language was slightly off, as you would expect from a non pro, but the understanding was functional if wrong. It didn't take long for a - polite and helpful - poster, to point out the errors in understanding, and this was when I couldn't help myself but think: With friends like this, who needs enemies.
Don't get me wrong - I like Linux and how the basic theory of operation is simple and consistent, which makes for few surprises and obvious fixes when you run into surprises, but insisting that any user needs to grok the theory of operation is the same as saying no to UI abstraction. Which in turn is the same as saying no to non-techie users. Hundreds of analogies from knowing how the electrical engine in a blender works to knowing how to repair your car engine comes to mind. None of this helps you blend or drive. And yet, it clearly helps you run Ubuntu to understand Unix basics.
The "simple theory of operation" combined with "minimal facade" - two goals that makes it easier to be a super user, are at odds with the experiential goals of any non techie user. Which is why the only way non-techie users get to enjoy these platforms is through the loving help of techie relatives (so the users Linux can get are the ones who just need an info appliance that has basically been done for the last 10 years. This appliance is so usefully shaped, through wear, that it can - even on Linux - be used as is.
Linux has a UI chasm: For users needing only 1995 computing, it's fine. For super users it's fine. For savvy inbetweeners it's just not there.

Posted by Claus at 11:31 PM | Comments (0)

August 19, 2007

How to Set Up And Run A Successful Hacker Studio

Guerilla rules on how to make a proper hacker loft. Heavy on the hacker ethic/hacker lifestyle necessities, but some good ground rules too.

Posted by Claus at 6:10 PM | Comments (0)

July 3, 2007

Why doesn't the Firefox spellchecker include a language categorizer for choice of dictionary?

E.g. a TextCat derivative. There's absolutely no reason to trouble us bilinguals with choosing a language in a form since its easy to figure the language out from text - particularly if we narrow the choice to the languages the user installs.
Hmm - we're supposed to contribute to open source on our own I guess - so I should probably check if this is XUL/Javascript (more hackable) or C (probably a bridge to far for me right now)

Posted by Claus at 1:40 PM | Comments (0)

June 25, 2007

James Clark blogs on XML

The father of Expat and Relax NG now has a blog where he talks a lot about XML and JSON.

Posted by Claus at 2:48 PM | Comments (0)

June 4, 2007

Citizens for a stateless web

The protocol version of the statement the web should be a public place is "HTTP is and should remain a stateless protocol". There are software reasons to make it so - and IMO digital freedom suggests its a good idea as well.

Posted by Claus at 2:05 PM | Comments (0)

May 17, 2007

Libraries, privacy

Thoughtful (and totally unrelated) couple of blog posts: Andy Oram on silos and why we have them and why we have the idiom "A small matter of programming". Bruce Schneier on memory, the fourth amendment and the right to forget.

(Bonus : Adam Greenfield on ubicomp ethics - all of this becoming rapidly more important on the co-created multi-siloed web)

Posted by Claus at 1:08 AM | Comments (0)

May 9, 2007

View it vs. Do it

Nice post on the web programming model.

Posted by Claus at 2:33 PM | Comments (0)

Tool != Service <=> Library != Application

Chris Heathcote's build tools not services is basically the old "write libraries, not applications" adage applied to interfaces. The problem here of course is that there's a discrepancy between the shiny-happy-user goal thinking and the notion of tool, not service. Heathcote adresses this in his piece, by I think the dynamics of product development get in the way of his counterargument.
His contention is that the usual user focus might work for a niche but not for a mass market - but aren't most (new) mass markets niches at the outset? I can see the "tool not a service" philosophy fit in as product develops through cycles - loosening its tie to the original user premise of the product, betting on people being already familiar with the tool-use-mechanics of the product and therefore gradually changing the design focus of the tool from the original user perspective to a tool centric focus on the use-mechanics instead.
I'm a hacker so I'm perfectly happy with products that are tool-first - but I doubt that it's true that they work best for mass adoption.

Posted by Claus at 12:50 PM | Comments (0)