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
http://www.classy.dk/cgi-bin/apollo_transcript.pl?q=transcript
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.
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))
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.
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.
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.
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.
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.
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...
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.
Guerilla rules on how to make a proper hacker loft. Heavy on the hacker ethic/hacker lifestyle necessities, but some good ground rules too.
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)
The father of Expat and Relax NG now has a blog where he talks a lot about XML and JSON.
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.
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)
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.