by Lily Koppel

Get the book.

Lily Koppel, a celebrity reporter for the New York Times, moved into a room on Riverside Drive just as building management was cleaning out the storage room. In a dumpster, she finds old hatboxes and suitcases and the battered leather diary that a teenage girl named Florence Wolfson has kept from 1929 to 1934. At the start of the diary, Florence is fourteen and a high school student; at the end, she’s graduated from college and toured Europe and started to host literary parties that attracted Delmore Schwartz, Erica Jong’s mother, and a host of New York poets.

Florence lives for love – boys or girls, she doesn’t much care which, though she wonders about that a lot. She lives for art. And she lives a long time: in 2009, it turns out she’s alive and well and moving back and forth between Florida and Connecticut, and she’s quite willing to flesh out the details from the diary.

It’s a limited account, to be sure. While Florence was editor of the Hunter Echo, her staff apparently rebelled and the revolution was only quieted with considerable difficulty. The problem may have been staff suspicion that Wolfson was a lesbian, or resentment that she was too butch, or conceivably resistance to what they perceived as their editor’s sexual exploitation of the staff. In the nature of the thing, the details are unrecoverable, but all the interest of the episode really lies in the details. Yet this is fascinating social history, told by a young rebel who was determined to be unconventional just like her friends.

I’m interviewed by Corey Pressman on hypertext literature and its discontents.

In object-oriented design, the single responsibility principle states that a class should do one thing, or more specifically that a class should have one reason to change. This has been much discussed lately, for example in this discussion of controllers, or in the premiere issue of the estimable objc.io. It’s a touchstone of refactoring and a central rubric of clean code.

And it’s a true headache.

Take Tinderbox Six and its map view.

The framework expects that the view do several things:

• draw itself, which primarily means drawing the links and the focus indicator.
• manage its subviews, creating them as they scroll into view, recycling them when they are removed from sight, and handling the timer and view controller for the hover expression.
• receive mouse clicks and other events.
• handle things dragged and pasted from other windows or applications.

If you let TbxMap do all those things, it becomes a monster class. Refactoring should be capable of fixing things. But can it?

Simplifying a View

In Tinderbox Six, I began by moving all the event-handling logic from TbxMap to its controller. That’s a win, though a bunch of small methods need to remain in TbxMap to forward events it receives to the controller. (The controller is quickly bloated by this refactoring, of course, and moves all those command handlers to dedicated helper objects — each requiring a tiny stub of its own.)

Then, I moved lots of drawing logic to dedicated classes. The drag highlights that appear when dragging a note over a container move to DragHighlighter. All the layout and drawing of links moves to LinkAnimator. All the logic for figuring out what the user is dragging into Tinderbox and what to do with the stuff moves to a class cluster behind TbxDrag. This slims TbxMap down considerably. Again, tiny stub methods must be left behind because the framework, or other classes in Tinderbox, expect the view to receive them, but all the work is done by small dedicated classes.

More recently, I pulled just about all the remaining logic from TbxMap into a collection of helper classes known only to the map view.

Click here for full size

Remember, this is just the part of Tinderbox that draws maps and outlines and charts.

The helper classes are the blue lozenges; I've suppressed lots of detail for (comparative) clarity. The Layout helper knows where things go; the Valet knows how to put them away when they’re off-screen and how to fetch them again when needed, the Locator knows how to locate them for the Find Bar, the Selector knows how to select them. They each talk mostly to the TbxMap (and the underlying data, of course). TbxMap is now, essentially, a hollow shell, with almost no logic beyond relaying incoming methods to the appropriate helper. It’s a collection of stubs, plus some initialization and teardown logic.

To be precise, it’s a collection of 182 stubs.

182 stubs!

This is madness, of course, but it’s the natural tendency of the natural refactorings. Sprouted classes need to use the original class as a Facade so other classes can use them. So each sprout removes a pile of logic and replaces it with a few simple methods. Those methods pile up. The helpers often need to interact with other helpers; if you don’t want a terrible tangle of interdependent helper classes, you’re going to need to use the TbxMap as a Facade between the helpers.

The alternative is to provide other classes with direct access to the helper class. This means we only need one or two accessors for the helper, but now the clients need to depend on the helper class. And they still need TbxMap, because that’s where they get the helper. And every time they use the helper, they smell of feature envy and indecent exposure and they violate the Law of Demeter.

It’s not just Cocoa. Every window system that ever lived suffers from something like this affliction. Either the system routes everything through the view (or the controller) , which leaves a complex view looking like an old-fashioned switchboard operator, or instantiating a simple pane makes you create a whole slew of of handlers and delegates and thumgummies, and that drives programmers bats. Remember OpenDoc?

A Path Forward?

I can envision some ways to make this better. TbxMap is acting as a Facade or Mediator between lots of disparate classes; we might split out the role of coordinating the helpers into one object and the role of serving the Controller and the rest of the system into another. That might help — or might just entangle all the helpers with each other.

I can envision that I’ve simply hit the wrong set of abstractions, and that some other collection of helpers would suggest a natural way for the helpers to work together without knowing too much about each other. But I’m skeptical.

It’s possible that the Tinderbox Map is just too complicated. Again, though, I’m skeptical: it hardly seems that complex; it’s just shapes and links and annotations.

I’m really surprised that there’s not more literature on this conflict between proliferating sprouted classes and the Law of Demeter. I’ve read the obvious sources: Fowler, Beck, Feathers, Kerievsky, Bob Martin, the Pragmatics. Surely, someone has a more extensive discussion?

Someone at Apple – possibly an NSA mole or possibly just an inattentive programmer – made a mistake and left a security hole in iPhone and Macintosh software. The new iPhone update closes the hole; a Mac update is doubtless en route.

Here’s the code. The key passage is:

if(…the certificate checks out…) 
     goto fail;
     goto fail;

Things to keep in mind:

• Whether or not it was the work of a double agent, this coding blunder will be a legend, a staple of Introduction to Programming for decades to come.
• It’s interesting that we’re at a point where we can talk about an engineer at a computer company as a double agent, and everyone understands.
• This is not likely to affect your privacy. The bug makes it easier for the government to spy on your computer, but it’s not trivial: it probably means a team of people whose job is to bring you down. If the feds want you that badly, it’s likely that they could burgle your house, blackmail your maiden aunt, or threaten your kids.
• But of course, if your computer has secrets that the government would pay serious money to know, this is another reminder.
• I’m with Gruber: the most likely scenario is that someone got sloppy, and an automated testing program at NSA noticed the mistake and said “Look! They forgot to latch the door.”
• I never got onto the Structured Programming bandwagon, but it’s been a decade since I used a goto. There are no gotos in Tinderbox. I do use the unbracketed if statement, which is subject to the same kind of blunder, and actually need to fix one of these every year or two.
• This is an example of a particularly insidious class of bugs. Most of the time, this kind of mistake (a) won’t compile, or (b) crashes right away. Some of the time, this kind of mistake makes no difference. Whoever did this was really unlucky.

by Simon Mawer

Get the book.

A haunting tribute to the British intelligence services of World War II, set as what seems to be a melodrama which nevertheless veers away — often at the last moment — from the trite and the familiar.

Much depends on dinner. This one was vegetarian; fortunately, fish was allowed.

• fennel broth, parisian gnocchi ❧ onion shiitake focaccia
• seared scallops on a bed of asparagus purée
• cod and portobellos baked in poblano creme, tomatillo-chipotle salsa ❧ chess soufflé
• salad
• apple tart ❧ cherry jelly

The poblano crema was a lovely green and turned out to be less hot than I’d originally feared. It went nicely with the sweetness of the fish, and paired nicely with a chardonnay.

Some disaster befell the cherry jelly, which failed to gel. No idea what went wrong, but something went badly astray.

Eroica, an ambitious new hypermedia fiction, by Eugene Garber et al.

by Peter F. Havill

Get the book.

A good if overly convoluted police procedural, set in the southeast corner of New Mexico and introducing an attractive young under sherif in a police department in which a surprising number of officers seem to be young women.

by Ellen Kushner

Get the book.

Interesting early urban fantasy, set in a (fairly) realistic world in which noble duels are commonplace and where duels are typically conducted by hiring a professional surrogate swordsman to literally fight one’s battles. This is the story of one such professional and his friend, a failed academic. The book is now fairly conventional, but its frank homosexual undercurrents doubtless raised eyebrows and hackles when it was newer and it retains a certain raw sincerity about reclaiming Manners for the rest of us.

In his Daring Fireball, John Gruber has mastered a highly characteristic style of tight writing. Here, on Mozilla’s announcement that they plan to add ads to Firefox:

Go to Mozilla’s own weblog, where they announced this with the headline “Publisher Transformation with Users at the Center”. What a pile of obtuse horseshit. If you want to sell ads, sell ads. Own it. Don’t try to coat it with a layer of frosting and tell me it’s a fucking cupcake.

No holds barred.

Jeff Vogel: Why Indie Developers Go Insane.

Marco Arment offers sensible agreement. “Flappy Bird was a cultural tragedy, and the tragedy has nothing to do with the game.”

Albert Ransom gives up. He writes to the makers of Candy Crush Saga, “I have spent over three years working on this game as an independent app developer. I learned how to code on my own after my mother passed and CandySwipe was my first and most successful game; it's my livelihood, and you are now attempting to take that away from me. ”

David Smith: “Never, ever, ever share revenue numbers publicly.”

by Erica E.Hirschler

A joint biography of the four daughters of Edward Darley Boit, and of John Singer Sargent’s wonderful painting.

Boit was a wealthy American painter — his wife was a Cushing. Like Sargent, the Boits moved freely between London, Paris, Rome; the girls learned lots of languages. None of them married, and we know surprisingly little about them.

But they were interesting people. Florie, the eldest girl, the one who is not looking at us, was probably responsible for introducing golf to the US. She had a Boston marriage, played the violin, suffered some sort of psychiatric episode during the war years, and died in 1919, probably of influenza.

Janie, who stands next to her, went mad: she was already difficult in 1882 when the picture was made and became much more difficult in the coming years. Just what the difficulty was, unfortunately, seems to be unknown: in surviving letters and records, everyone is worried, annoyed, anxious, and upset, but nobody really explains. She played the piano compulsively, was in and out of institutions, and in the end lived in a Paris apartment with two attendants, at enormous expense.

Issa, the girl in red, seems to have left little trace 0r memory.

Little Julia took up watercolors, settled in Newport, and died in the 1960s a cheerful and well-loved old lady, a local character.

Lots happening backstage at Tinderbox Six. We’re had 33 backstage releases so far, and a ton of fascinating discussions and wild demonstrations.

Lately, we’ve had a bunch of knotty little problems, all involving complex classes that are close to the user interface and that are, in consequence, quite tricky to get properly under test. Brad Grzesiak has a nice new article on splitting complex controller classes, of which Tinderbox has a few.

The end result of all of these loci of change can be characterized as a 900-line file of application and business logic in a form much resembling spaghetti. And perhaps "900 lines" is too charitable. The only type of file that may have 900 lines is one that is never intended for human consumption—binary files and database dumps.

Some of this is reflex: “spaghetti” is irrelevant, a tired old charge leveled at coding practices of the 1970s. But the underlying point is sound: big classes are hard to understand, hard to maintain, and hard to test.

On the other hand, splitting has its own costs: you may have smaller classes, but now you’ve got lots of classes. It’s easy enough to sprout a new class to replace a method, but if you’re not careful you’ll wake up to find that you’ve got a folder of 90 little classes. Plus 90 little test classes, naturally. A small object is easier to understand than a big one, but is an object with a dozen helper objects, each with its own specialized class, still small?

Again, it surprises me that discussion of issues like these is so thin. The entire monograph literature of TDD and Refactoring will fit on one shelf, and that shelf is going to be full of repetition and even fuller of sample code. Worse, discussion always winds up repeating the same old debate we originally fought over Structured Programming, in which the New Idea must forever be defended against people who don’t want to change what’s always worked for them.

That never gets anywhere: software engineering, like science, advances funeral by funeral.