Redundancy in Web App Architecture

I’m not sure I understand Brent Simmons’ problem, here.

If you need the same code running on two or three small specialized web-servers, just write it once in a library and include it in each of them. The repetition of running instances isn’t worth worrying about.

I’m wondering if his problem is really a lack of an obvious “include” for common html components in a world of single-page node.js apps? In which case, is this really a package management question?

Mark Bernstein :

It’s easy to add generality to a spec. It makes you look really smart, especially when someone else is going to do the coding. But too much generality too soon makes the code age prematurely; you can get old, brittle, confusing code that looks like it’s yellowed with age, even though it’s not even finished yet.

My post yesterday on Composing, about Geeks, Suits and Abstraction is relevant to SDI philosophy too.

Executive Summary : Geeks, by definition, have to be good at shifting their thinking between different levels of abstraction; Suits, by temperament, believe in the rigid separation of levels into the corporate hierarchy and would love for technology to enforce that.

Listen everyone, I gotta come out to you all …

I am now officially an outliner.

For a long time I thought that outlines, like all hierarchical documents, were limited and inferior to graph-shaped wikis.

Now I get it.

The point of the outliner is not the hierarachical structure as a navigation aid – free-form hypertext is still superior.

No, the point of the outliner is the collapse which lets you manage and manipulate bundles of items at the same time. That’s something I never managed to get right in SdiDesk. Although I perceived the need for a “PageSet” to create a bundle that could be used for, say, exporting etc. I a) never got that working technically, which was partly because b) I never really made sense of it “conceptually” to myself.

What’s great about the outliner is its “scale-free” / “fractal” / “recursive” / “self-similar” nature – which means the same operations (collapse, copy, move, publish) can work on anything from a short list, to a chapter to a volume composed of multiple chapters. I’ve really started to realize this over the last few months as I’ve used the OPML editor for more things that I’d have once used SdiDesk for.

Now, don’t get me wrong. I still love wiki. It’s still my favouritest type of software in the world, ever. And I still use SdiDesk every day. But now, I’m starting to appreciate that there’s a need to manage a hierarchy of scales, and until I find out how to combine that with wiki-nature (and into SdiDesk), I’ll probably be outlining most days too.

(In my day-job I also spend a whole lot of time with spreadsheets, but that’s another story. SdiDesk was always meant to handle grid-shaped data, it just wasn’t developed enough to be really usable.)