Unit Tests are short and tightly focused tests that check the behavior of a specific object in the program. Over the past decade, unit tests have become central to a lot of programming practice. It’s common, for instance, to write tests before the object to be tested has been written. Tinderbox has about a thousand unit tests.

I’m working on wrapping up a draft of my school story to submit to the Creative track at this year’s hypertext conference, and I’m building some unit tests to make sure things behave as they should.

Some tests simply check for consistency and plausibility.

• are large parts missing?
• are obviously-crucial notes and links missing?
• if I open the book at a particular point, do I see what I expect?

These need to be rough and ready, because lots of revisions remain, but they create some protection against a last-minute blunder.

Other tests double-check my own convenience and assumptions.

• do some sections have duplicate titles?
• are some notes inconveniently long?

Finally, I’ve set up a mechanical reader that doesn’t understand anything in the text but merely follows links at random. People have done this before – I’ve done it before myself – as a way to study finished hypertexts. I expect that this sort of Markov process has been used to inform composition before, but I can’t think of an example.

If you know any published work on unit testing hypertext narratives, interactive fiction, or digital stories, I’d love to know about it. Email me.

Interactive Fiction legend Em Short and I talk about Storyspace and Getting Started With Hypertext Narrative.

The most important book about new media in a decade is in print again, after a hiatus of several years.

Lars Spuybroek, an architect and a philosopher of design, examines “the digital nature of gothic” in light of the aesthetics of John Ruskin. Ruskin’s ideas about art and society are crucial, and if he lost favor in the 20th century’s rush to Modernism (and its embrace of Fascism and Communism), by the late age of print we were ready for another look. It’s not a coincidence that George P. Landow, the author of Hypertext, started out by working on Ruskin.

Spuybroek wrestles with new media problems in the context of designing buildings. His problems are our problems. He is not satisfied with superficial embrace of digital motifs: pasting a swoosh onto the roofline of a neoclassical box in architecture, simulacra of books and TV episodes in new media. He joins Ruskin in opposition to mass production but, unlike Ruskin, he’s got an alternative: we can generate a host of unique (though similar) things almost as easily as we can replicate identical things, and each of us can choose from this host the things that appeal to us, those that excite our sympathy.

Instead of the false promise of the holodeck’s game on rails, we have the real promise of the book that adapts to us, that changes for us on each reading. Spuybroek makes a powerful argument for generative art that gets outside the white box of academic reception. And, uniquely, he appreciates how much meaning lies in our encounter and relation with animate machinery – “our slaves of steel” – and the crucial importance of our sympathy with objects.

This is a difficult book. It’s not going to tell you what font to use on your Web site or how to optimize click-through. I’ve been praising it to New Media and Hypertext people for four years. To highlight it, I wrote a workshop paper in the form of a dramatic dialogue. I’m not sure I’ve gotten any of you to read it yet.

Drop everything.

Brent Simmons says a bunch of smart things about Performance These Days.

For twenty years, people have been saying that machines are so fast, you hardly ever need to think about speed. Yes, you could write a ton of your code in any slow, interpreted language you name, and nobody would notice. “Making things fast has to do with choosing fast data structures and algorithms,” Brent says, and “moving things off the main thread.” And he is not wrong.

But there’s more to it than that, too.

Nothing will save you from a really bad algorithm, but a fast compiler can often make a naive implementation Fast Enough. Tinderbox used to do horrendously tricky things for caching the screen; now, the framework and the hardware handles all that. Storyspace used to use a ghastly file format that had the sole virtue of being really fast and really compact; now, we use XML – slow and verbose – and everything’s fast anyway.

There’s also a very interesting chasm between things that take about a second and things that take, say, a 60th of a second. A whole second interrupts your work; you don’t like that one bit. 1/60th of a second? Well, that might drop a frame of animation, making your nice animated transactions stutter slightly. If we need to, we can live with that.

I’m currently thinking about a big project for Tinderbox that might be able to do some remarkable things – but those things need to be done during the drag. The difference between 1ms and 10ms in this case is probably the difference between “that’s sort of amazing” and “it didn’t work.” Algorithms matter, but once you’ve got the algorithms down, speed matters too.

by Jack Viertel

Get the book.

A fascinating and anecdotal account of the structure shared by many successful American musicals. Viertel draws on a vast range of theater but returns, time and again, to an interesting set: Oklahoma!, Guys and Dolls, Gypsy, Carousel, A Funny Thing Happened On The Way To The Forum, The King and I, Fiddler on the Roof, and My Fair Lady. It’s fascinating to see how what seems to be a very rigid and specific form like the Bench Song -- the conditional love song that follows the rollicking number known as The Noise – shows up all over the place. Viertel believes that small changes in the placement or tempo of songs can make all the difference, and provides plenty of anecdotes about good shows and bad and how they came to be structured the way they are.

It’s really hard to help Wikipedia, even if you want to. And since Gamergate is trying vary hard to get rid of me at Wikipedia, with plenty of help from various Wikipedia administrators, it’s a mystery why I’d want to help.

Still, yesterday afternoon I happened across a death threat directed at a Wikipedia administrator — a threat that posited my own demise as a potential bonus. It was the usual rot, though it had some circumstantial details that might conceivably suggest some knowledge of my travel plans. I grabbed a screen shot, deleted the threat, and notified the primary victim, the Wikipedia emergency address (which must be notified regarding threats) and the oversight department.

Since then, about 18 hours have elapsed. Here’s what I’ve received:

• Promptly: a six-word acknowledgment from the Wikipedia emergency account: “Thanks Mark, we're looking into it.”
• 12 hours later: an email from the oversight account - responsible for deleting threats and libel – that the threat had been erased.

That’s it from Wikipedia. Isn’t that terrific?!

The primary target filed a report with Comcast, the miscreant’s ISP. They answered promptly that “We are a legal compliance department of Comcast providing responses to subpoenas and search warrants from law enforcement. Unfortunately, as such we are unable to take any action with your request. This is a matter that you should report to your local police authority.”

Writing about Gamergate, I’ve adopted an orotund, Miltonian manner. Partly this is for fun, and to make fun of Gamergate’s illiteracy. “Wikipedia is all bias,” Gamergate complains again and again; they’re a movement that has lost its past participles along with its present principles.

Partly, the style a concession to some Wikipedia administrators who greatly prefer euphemism to plain speaking. My many troubles began when I observed that people who support or excuse rape threats are supporting and excusing rape; this is true but, I admit, it's not very friendly. Milton’s example of allusive indirection keeps me out of trouble. Milton wrote with sympathy but without approval of another very bad crew – a bunch who wanted to wreak havoc for lulz; Wikipedia needs to be reminded time and again that some compromises are intolerable; you either call a software developer a prostitute, as Gamergate so frequently wants, or you don’t.

Wikipedia places a high value on assuming good faith, and when it comes to assuming good faith, it's hard to beat the man who wrote:

And after all, what is the subject of Paradise Lost if not the limits of assuming good faith?

But, seriously, this is a hell of a way to treat a volunteer, especially one who is trying (with very indifferent success) to limit the use of Wikipedia for threatening Gamergate’s victims.

I just noticed that this Tinderbox file recently crossed the milestone of a million words. It only contains the last three or four years of the weblog – there’s another 1.5M or so in the archives – but it’s sort of interesting to see the number.

Of course, if it weren’t in Tinderbox, I’d have no idea at all.

Jeffrey Zeldman’s A List Apart is among the oldest and most influential sources of information about the Web and digital culture. Its reach is long; the crusade for Web standards began there, as did the current movement for adaptive design that transforms fluidly from pocket screens to laptops and to living-room walls. I’m proud to have written there; my piece on writing for weblogs is probably more widely read, cited, anthologized, and assigned to more students, than anything else I’ve done.

A List Apart has spawned an itinerant conference, An Event Apart, that’s coming to Boston this year on May 16-18. It’s got some great program components.

• Eric Meyer on Compassionate Design
• Rachel Andrews on CSS Grids
• Josh Clark on The Physical Interface
• and lots more.

You can save $100 on this event (or on events in other cities) with coupon code AEABERN.

Brent Simmons offers a thoughtful piece about one of the great mysteries of the software scene today. It’s now clear that it’s extremely difficult to make money crafting well-designed and well-implemented software for iOS. Macintosh software, on the other hand, is challenging but clearly viable.

Nevertheless, lots of people want to write for iOS rather than for OS X. Why is that?

Brent thinks it’s the extra layer of difficulty in the Mac.

Were Macs to get some form of UIKit, it would have to be extended with all the things Macs need. Let’s assume we’ll still have multiple, resizable, movable windows; we’ll still have a menubar; we’ll still have AppleScript and Services and similar.

Anybody bringing an iOS app to the Mac is going to have to learn those things and handle them.

...

The additional stuff — menus, live resizing, AppleScript, etc. — is enough of a burden that people just don’t want to do it.

But you know what? You don’t need that stuff. Well, you do need menus, but basic menu handling is trivial. Live resizing looks nice, and looking nice is always pleasant, but if you’re doing something that people need, who cares if it looks nice? I bought a rake yesterday; it doesn't look particularly wonderful but, when you need a rake, a rake is what you need. (Plus, with a cake, you can have cake on a rake.)

AppleScript can be a pain to support, and twenty years ago you needed it or the influential magazines would dock you a mouse. Then, a couple of people discovered that hardly anyone really needed scripting support. The magazines all collapsed, anyway, and here we are. If you don’t want to support scripting, if it’s not central to the way you’re helping people, then you don’t need it. If services aren’t central to what you’re offering, you don’t need them, either.

My guess is that the problem isn’t that Mac software is ineffably less fun to write. Nor is the problem, really, that iPhones are sexier platforms. A lot of people still think that some tiny little application -- a game they dash off in a few evenings, a trivial utility like a flashlight – will sell a million copies in the app store. Why not? That’s less than 1% of the potential market.

But it’s not going to happen. Lightning strikes sometimes, but it doesn’t appear to strike the meritorious or the clever, the people with skill or fashion sense or any other discernible quality. Even Flappy Bird was only doing a fraction of that business, and that was only for a month or two.

Tinderbox 6.5 is out now. Lots of important new stuff: gorgeous word clouds, broad links, ring indicators for your dashboards, and lots mote. There’s lots of new infrastructure as well, helping to make Tinderbox fast without draining your battery.

This version requires OS X 10.10 or later. If you're still using 10.9, we can likely make provisions for you; Email me..