<M <Y
Y> M>

August Film Roundup: Not the blockbuster month as I was anticipating—I missed all of the museum's big-name Pacino/de Niro movies due to other committments—but a lot of interesting movies, and movies that were uninteresting in interesting ways, among the nine I did see.

This month and next the museum is showing every film Howard Hawks ever made, so search for his name on IMDB and prepare for the Cary Grant-fest. SEE IT BIG is also returning, and I'm looking forward to seeing the Howard Hawks Scarface on the 21st and then the Brian De Palma Scarface on the 22nd.

[Comments] (2) RESTful Web APIs!: After about a year of work, my and Mike Amundsen's new book RESTful Web APIs is going to the printer. It's a replacement for RESTful Web Services, a book that's now seven years old. The replacement may be overdue, but it's only been in the past couple years that technology and attitudes have advanced to the point where I could write the book I wanted to write.

In fact, there's one subfield (profiles) where you could argue this book is premature. The way RESTful Web Services was a little premature in describing an OAuth-like system before OAuth was released. But I don't think we can wait any longer.

Back in February I discussed the differences between APIs and Services. That hasn't changed much, though we have added more stuff:

This post is mainly my way of asking you to pre-order your copy of RESTful Web APIs through my O'Reilly affiliate link. That's a hypermedia-driven change in resource state which will get you the book in a couple weeks, and get me some extra cash. (I estimate about $1.70 extra. Don't do this if the shipping charge on a physical book is prohibitive, or whatever.)

But this post is also a back-door way for me to brag about what a great book Mike and I have written. You don't have to take my word for it. Here's the blurb we got from John Musser of ProgrammableWeb.

A terrific book! Covers a lot of new ground with lots of valuable specifics.

Here's Steve Klabnick of Designing Hypermedia APIs:

The entire time I read this book, I was cursing. I was cursing because as I read each explanation, I was worried that they were so good that it would be hard to find a better one to use in my own writing. You will not find another work that explores the topic so thoroughly yet explains the topic so clearly. Please, take these tools, build something fantastic, and share it with the rest of the world, okay?

You get the picture. I've tried to recreate the relevatory experience a lot of people got from RESTful Web Services, on a higher level, in a way that gives access to more powerful tools. Time will tell if I've succeeded, but I don't think I, or anyone, could have done much better. I'm really proud of this book, and I hope it helps you.

Awesome Dinosaurs Update:

  1. On Sunday I saw the 1926 Howard Hawks film Fig Leaves. I'll publish a full review in the roundup at the end of the month, but I couldn't wait to mention the dinosaurs! This movie (briefly) features two very cool-looking puppet dinosaurs. There's Adam's pet Apatosaurus, named Dobbin:

    Exactly as depicted in Genesis 2.

    More amazingly, there's also a budget-busting life-sized Triceratops that pulls a bus!

    Awesome! Not gonna spoil the review, but the first reel of this movie used all the good Flintstones jokes, thirty-four years before The Flintstones even premiered. Except for the unfortunate bus dinosaur saying "It's a living." in a morose voice. And I'm sure that's just because the joke would be really awkward if you had to do it with title cards.

    (Screen image simulated.)

  2. If you share my belief that dinosaurs are the most interesting part of any movie that includes dinosaurs, you'll love Kevin Maher's deleted scene from King Kong.
  3. A recent Ureddit course on narrative structure in short fiction used "Let Us Now Praise Awesome Dinosaurs" as one of its example stories. I thought this was a) a good choice, and b) pretty funny, because I deliberately wrote "Dinosaurs" to be opaque to traditional analyses of narrative structure.

    If you'll forgive me being serious about a very silly story, here's what I mean. Nearly every plot event in "Dinosaurs" is a red herring. It's actually a New Yorker type story, in which a series of insane infernokrusher interventions leads to Entippa's epiphany that humans are exploiting dinosaurs' tendency to get involved in insane infernokrusher interventions for their own entertainment. (Those humans including, in a bit of Hitchcock-type moralizing, you for reading the story and me for writing it.)

    I wrote the first scene to have something very close to a literal Chekhov's gun. It's Tark's gun, or at least his desire for a gun. Later on, Chekhov's gun goes off: Tark gets his gun! But as soon as the literal gun goes off, Tark discovers that literal guns are loud and painful, and he throws it away. The Chekhov's gun was fake. Sort of like the keys in my old text adventure Degeneracy, which don't unlock anything—you're supposed to melt them down for the metal.

    But! In the Reddit thread dissecting "Dinosaurs" and the other example stories, the person running the class proves my intellectual superior. It turns out there was also a real Chekhov's Gun in that first scene: Tark's "killing claws", which are in fact used to kill someone later in the story, just like they would in a regular story about dinosaurs killing humans.

    I didn't even notice that. I'd assumed the human-killing scene worked because everyone knows meat-eating dinosaurs have claws. I didn't even realize I'd made a big deal about the claws in the first scene. You win this round, literary analysis!

PS: Never forget.

RESTful Web APIs Monkeypatch: The RESTful Web APIs ebook came out earlier than we thought it would, and there are some important URLs in the book that don't work yet: the home page at restfulwebapis.org, and the example application at youtypeitwepostit.com. There's also one URL in the book (the book's GitHub repository) that will never work, because we wrote down the wrong URL.

I've submitted an erratum for the wrong URL, and I'm here to give you some temporary URLs that will work for the other stuff. They're temporary because Mike controls the DNS for restfulwebapis.org and youtypeitwepostit.com, and he's out of commission at the moment.

[Comments] (2) LCODC$SSU: At RESTfest last week I put on an old Mozilla shirt and my Al Gore campaign button and gave a talk from the year 2000: "LCODC$SSU and the coming automated web". I'll link to video when it goes up on Vimeo, and I'll also point to my five-minute talk about ALPS, which not only took five minutes to deliver, it took five minutes to put together.

But right now, there's some more stuff I want to say about "LCODC$SSU", and some stuff I couldn't say in the talk due to the framing device.

When I first mentioned this talk to Mike Amundsen, he told me about Bret Victor's talk from 1974, "The Future of Programming", which Victor gave in July and which had a similar conceit. Victor is also a much better actor than I am, but I went ahead with my talk because wanted to do something different with "LCODC$SSU" than happens in "The Future of Programming". I get a strong "You maniacs! You blew it up!" vibe from Victor's talk. And there's some of that at the end of "LCODC$SSU"—I really feel like we've spent thirteen years making five years worth of progress, as you can see from my frustration at the beginning of "How to Follow Instructions"—but I also wanted to do some new things in my talk.

While writing Appendix C of RESTful Web APIs I came to appreciate the Fielding dissertation as a record of the process used to solve an enormous engineering problem. Comments from RESTFest attendees confirm that seeing it this way helps folks grasp the dissertation's gem: the definition of LCODC$SSU (a.k.a. REST). Thinking about it this way doesn't require a historical-fiction framing device (Appendix C has no such framing device), but it does require you stop treating the Fielding dissertation as a prescient guide to the 21st century and see it as a historical record of the 1990s.

And once you do that, the missing stair we've been jumping over or falling through for thirteen years becomes visible. The Web works because it has four domain requirements that reinforce each other: low entry-barrier, distributed hypermedia, extensibility, and Internet scale. But there's also a fifth implicit requirement: the presence of a slow, expensive human being operating the client and making the final call on every single state transition. In the talk I identified the inverse of this implicit requirement as an explicit requirement: "machine legibility". In RESTful Web APIs we use the term "semantic gap" to describe what happens when you remove the implicit requirement.

Making the human unnecessary on a transition-by-transition basis (the goal of "Web APIs" as a field) is a really difficult problem, and it's partly because of the phenomenon I describe in the talk and in RWA Appendix C. Getting rid of the human raises the entry-barrier dramatically. Looking around for a cheap way to lower the entry-barrier, we decide to get rid of distributed hypermedia. But distributed hypermedia is the only thing that allows Internet-scale and extensibility to coexist! We must lose one or the other. We end up with an increasingly ugly system that can never be changed, or else a fascist dystopia.

And here's the bit I couldn't put in the talk because it would break the framing device. We've seen a decade-long obsession with lowering entry-barrier at any cost, and although the cost has been enormous I can't really say the obsession is misplaced. Low entry-barrier is the main reason why the Web succeeded over all other hypermedia systems. Low entry-barrier drives adoption. You get adoption first and you deal with the other problems (which will be enormous) down the road.

Well, we're down the road. The bills are coming due. If we want this to go more smoothly next time, we need to stop chasing entry-barrier local minima and come up with a better solution. We need to make change easier so we can make progress faster.

The "machine legibility" problem will still be very difficult, and frankly I can't see a way to a complete solution. But there's cause for optimism: every step forward we've taken so far has illuminated the space a little more and made the next step visible.

It's always been this way. That's how hypermedia works. That's why I called my now-infamous 2008 QCon talk "Justice Will Take Us Millions Of Intricate Moves" (after William Stafford), and that's why I take my motto from a Johnny Cash song that's probably not on most peoples' list of inspirational Johnny Cash songs.

I built it one piece at a time.

Smooth Unicode: For reasons of his own, Adam Parrish recently created the Unicode Ebooks Twitter bot. I offered some helpful suggestions for improving the visual appeal of the Unicode Ebooks, suggestions which Adam mocked as unworthy of his artistic vision of dumping a bunch of line noise onto Twitter every five minutes.

So I created my own Twitter bot: Smooth Unicode, the Lite FM to Adam's unending Einstürzende Neubauten concert. My bot does its best to construct aesthetically pleasing output by combining scripts that complement each other visually. The code is part of olipy and I'll be adding to it as I come up with more nice-looking ways to present gibberish.

Less talk. Less noise. More browser-visible glyphs. That's Smooth Unicode.


[Main]

Unless otherwise noted, all content licensed by Leonard Richardson
under a Creative Commons License.