Wordyard

Hand-forged posts since 2002

Archives

About

Greatest hits

Building a book site with WordPress

by

It probably says something about me that, after completing years of work on my book, one of the things I most looked forward to was…building the Web site for the book. Aside from my work at Salon and my launching of various blogs, it had been years since I built a Web site on my own, and I relished the chance to look around at all the new tools for content management that have emerged in the interim.

But pretty quickly I realized that learning any new tool takes time, and I didn’t have a lot of time. And then I also realized that I’d spent a lot of time last summer learning to use WordPress as the new platform for my blog, and there was no reason under the sun I couldn’t use WordPress to build the book site for Dreaming in Code. WordPress lets you publish static pages; all I had to do was customize some templates, and voila! — blog software without the blog.

I am, as I admit at the start of Dreaming in Code, barely a programmer myself. But I can find my way around a template, I can borrow snippets of code and mess with a system that already works just enough to get it to do what I need it to do. This approach was, once upon a time, called “end-user programming”: the idea of enabling sophisticated users to extend and adapt a powerful piece of software without their needing to master complex programming languages. Spreadsheets depend on end-user programming; back in its day, Hypercard did, too. (Bonnie Nardi’s 1993 book A Small Matter of Programming is a good outline of the concept, focusing on spreadsheets and CAD systems.) A good blogging tool like WordPress is an invitation to end-user programming. And I admit it: I had fun!

The part that wasn’t fun was wrestling with CSS. I know that CSS achieved a Good Thing in helping Web designers clean up HTML and separate content from presentation and all that. But making a Web site look exactly the way you want it to look was a hell of a lot easier back in the days of tables and simple HTML than it is today. There are still a few elements of my site that aren’t aligned exactly the way I want them; I gave up trying to figure out why — life is too short! CSS was a step forward for designers’ control of their Web work but a step backward for the end-user programming that made the Web what it is today.

The “invention” of RSS and the snowball effect

by

The arguments over the history of RSS are interminable and overheated, and I wouldn’t fault anyone for tuning them out. RSS is the technology (really, that’s a glorified label for what is a relatively simple file-format specification) that lets you subscribe to feeds from blogs and other Web publishers. Early adopters on the Net have embraced RSS whole hog; today it’s how I take in most of the information I read online. Yet much of the general public is still awaiting a basic introduction to this incredibly useful tool. Back in 2003 I wrote that, with RSS, it felt like we were about where we were in 1994 with the Web itself; today we’re maybe in 1996 or 1997.

RSS is important, and so technology industry leaders and pundits have already devoted a remarkable amount of energy toward arguing about its origins — including, most recently, debating a controversial patent filing by Microsoft. (The idea of patenting anything to do with RSS strikes me as ridiculous and counter-productive, but my grasp of patents is limited, and it’s always been hard for me to understand the idea of any kind of software patent.)

Even if you’ve tuned out the RSS debate, though, I’d recommend checking out Dave Winer’s post from today, “RSS Wasn’t Invented.” Dave argues that what matters in the RSS story isn’t the (non-existent) moment that the idea for the technology was conceived, but rather the complex and slowly-unfolding process by which RSS tools came into wide use. Discovery of the value and purpose of RSS, you might say, took place long after the specifics of its technical functionality were first imagined.

The “invention” of RSS, muddied as it was by prior art, wasn’t responsible for its uptake. Rather there were several significant moments along the way: support by individual publications, individual bloggers, then blogging tools, then a small number of aggregators and readers, then a few very large publishers, then a flood of publishing and reading tools, followed by a flood of content.

I can vouch for Winer’s argument because I recall the early adoption of RSS at Salon, in, I believe, late 1999 or early 2000. We needed a simple tool to circulate our daily list of headlines and links to partner sites, and one of our engineers chose an XML file format he was familiar with through its use by Netscape. We didn’t know it by the name “RSS,” and we weren’t adopting it for any purpose relating to blogging. We just grabbed a handy format that looked easy for our partners to receive and put it to use. Later on, the rise of blogs — based on publishing tools that Winer, and the folks at Blogger, and later the folks at Movable Type and others, had produced — created a demand from the general public for subscribable RSS feeds. When I went to our engineering team and said, “We need to provide an RSS feed for Salon,” we realized that we had one already, we just weren’t calling it that.

RSS was simple for developers to produce and gradually got easier for non-technical users to consume. The complex and murky (and contentious) story of how its technical specifics gradually coalesced is far less important than the social process by which a “virtuous circle” or snowball effect spread its adoption. I know I’m striding into choppy waters here, but I can vouch for it, because I witnessed so much of the story: Winer deserves credit for a central role in getting that snowball started.

In any case, what’s more important is his argument today — that the tech industry needs to study and learn from the story of how successes like RSS unfold:

If it had been left at the “invention” stage, it would be where many other XML-related technologies are today, invented, but not much-used. Something new was done with the cloud of content, tools, aggregators, and that allowed a lot more people to use it, or hear about it, or decide it was finally time to support it.

[tags]rss, blogging, dave winer[/tags]

Code Reads #6: Mitch Kapor’s Software Design Manifesto

by

Code ReadsThis is the sixth edition of Code Reads, an aspiring-to-weekly discussion of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s thefull Code Reads archive.

Mitch Kapor first presented his Software Design Manifesto at PC Forum in 1990. It got published in Dr. Dobbs’ Journal in 1991, and later appeared as the first chapter of Terry Winograd’s book Bringing Design to Software (much of the book is available in online form now). At a point roughly midway between the start of the personal-computing revolution in the mid-’70s and the present, Kapor threw down a gauntlet: Computers were too hard to work with. “Everyone I know (including me) feels the urge to throw that infuriating machine through the window at least once a week,” Kapor wrote.

The PC revolution’s promises of “personal empowerment” remained unfulfilled because the software that drove the miraculous new machines was simply not well-enough shaped. The people who made it weren’t thinking clearly enough about how their products would be used. Somebody had to do that work; Kapor argued that programmers probably weren’t the best people to take it on, and proposed the creation of a new discipline of “Software Designer” to wear this mantle.
[Read more…]

Open source: Linux TVs and “virtual piecework”

by

I recently joined the legions of Americans upgrading their TV sets, trading in my trusty and still functional (but awfully faded) 20-year-old RCA box for a fancy new Pioneer plasma display. I’m the sort of consumer-electronics purchaser who actually reads the manual; flipping through the Pioneer’s book, I nearly jumped out of my seat when I discovered the entire text of the GNU Public License. Yes, it seems that somewhere in its innards, this TV is running Linux!

In other open-source news, the Wall Street Journal ran an interesting lead piece the other day about Zimbra — the open-source challenger to Microsoft Outlook ‘n’ Exchange. I’ve followed the Zimbra saga from afar because the product is in certain ways a competitor to Chandler, the project whose story I tell in my book. (Yes, Zimbra’s name derives from the Talking Heads song, which is in turn a borrowing from Dada poet Hugo Ball.) The Journal piece, by Robert Guth, was a thorough description of how a modest-sized startup company is leveraging the work of an open-source community.

What I found strange about it wasn’t the idea that, nearly a decade after the concept of open-source software development was first introduced to the mainstream (and almost as many years after Andrew Leonard’s groundbreaking work on the subject at Salon, that I was proud to edit), the whole idea can still be framed as a novelty. No, what was really off about the piece was its headlines: “Virtual Piecework…Trolling the Web for Free Labor.”

I suppose there is still a faction in the software world that dismisses the complex social and behavioral structures that have created substantial software products like Firefox, Apache and the Linux in my TV set; in this view, open-source developers are simply chumps who give away “free labor.” And I suppose I shouldn’t be surprised to find that stance echoed in the Journal. But I was anyway. Guth’s piece was a smart introduction to the process — at once idealistic and pragmatic — of distributed open-source software development; the reductive headline was jarringly disconnected from the content that followed.
[tags]open source, linux, plasma tvs, wall street journal[/tags]

Code Reads #5: Knuth’s “Structured Programming with go to Statements”

by

Code ReadsThis is the fifth edition of Code Reads, a weekly discussion of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.

I have felt for a long time that a talent for programming consists largely of the ability to switch readily from microscopic to macroscopic views of things, i.e., to change levels of abstraction fluently.
— Donald Knuth, “Structured Programming with go to Statements”

We’ve been looking at Edsger Dijkstra’s principles of structured programming for some time now. Today we’ll conclude that phase of this series with a look at Donald Knuth’s “Structured Programming with go to Statements” (1974). Since “Go To Statement Considered Harmful” was the most famous declaration of the structured programming ethos, Knuth’s title itself was a kind of provocative joke — like naming a paper “Judaism with Idols” or “Vegetarianism with Pork Chops.” And that combination of playfulness and attentive humor extends throughout the article, from the epigraphic references to Bob Dylan (and a laxative advertisement!) on. In the middle of a complex analysis of an algorithm in ALGOL, in which Knuth is reviewing ideas for new ways to notate a particular kind of loop, he interjects:

Readers who remember 1967 will also appreciate [this] second suggestion,
turn on begin S; when B drop out; T; end.

The levity’s a good thing, because, I confess, as a non-mathematician and only a rudimentary programmer I approached Knuth’s formula-laden text with trepidation. And there remain parts of “Structured Programming with go to Statements” that are beyond me. But for the most part, this text bears out Knuth’s reputation for brilliant clarity — it’s surprisingly accessible.

[Read more…]

Web 2.0 launch pad

by

While we clink glasses over House victories and bite fingernails over squeaker Senate races, here are some notes from today’s sessions at Web 2.0.

Thirteen new companies offered five-minute pitches for new products and services at the “Launchpad” event here.

The one that jumped out at me, unsurprisingly, given my history of interest in personal-information managers and the focus of my book on one such project, was Stikkit. It’s a personal-information manager (and sharing tool) built around a sticky-note metaphor. It looks like it has a heritage stretching all the way back to the old-fashioned “terminate and stay resident” note-taking programs like Sidekick and free-form PIMs like Lotus Agenda. Stikkit is led by Rael Dornfest, who I know from his work organizing many editions of the O’Reilly Emerging Technology Conference. I made a note to myself to explore it further tonight, but it appears to be down at the moment. More later!

I was also intrigued by Klostu, an attempt to create a “super-social network” linking together the separate islands of the “Boardscape” — the thousands of disconnected message boards across the Net. This strikes me as smart: there were tons of communities sharing stuff online long before anyone had coined the term Web 2.0, and it makes a lot of sense to serve them.

The presenter for Instructables, a site featuring user-contributed “how-to” projects, repeatedly emphasized that his service’s most important feature is the passion of his users. He’s right: more than spiffy software or innovative business models, that’s what makes any Web venture — “2.0” or not — matter.

Here are the rest of the projects:

Omnidrive and Sharpcast: Two different approaches to syncing stores of content across multiple machines and devices.

Turn: Automated ad targeting.

Sphere: “Less geeky” blog search.

Adify: Instant advertising networks.

3B: Three-dimensional, walk-through Web browser.

ODesk: Hiring market and distributed management system for software developers.

Venyo: Reputation management service for bloggers.

Timebridge: Outlook add-on for meeting scheduling.
[tags]web 2.0, web2con, launch pad, stikkit, klostu, instructables[/tags]

Code Reads #4: Dijkstra’s “Notes on Structured Programming”

by

Code ReadsThis is the fourth edition of Code Reads, a weekly discussion of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.

The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.”
— Edsger Dijkstra, “Notes on Structured Programming”

“Notes on Structured Programming” (1970) is the third and, for now, final Edsger Dijkstra work this series will look at. The paper fills out the terse observations in “Go To Statement Considered Harmful” and the historical overview of “The Humble Programmer” — and offers some detailed examples of the disciplined sort of approach to programming Dijkstra was advocating at the time.

In his 2001 “What led to ‘Notes on Structured Programming'” Dijkstra recalled that he wrote the original “Notes” while emerging from a depression; he felt that his previous work on ALGOL and other systems had “only been agility exercises” and he now faced tackling “the real problem of How to Do Difficult Things.”

[Read more…]

Crash in Iraq; Grove’s “shift left”

by

Sometimes when I tell people I’ve written a book about how difficult it is to make software well, I get a blank stare, as if to say, “What could be further from mattering to me?” And I repeat my now well-rehearsed remarks about the way our lives increasingly move through a vast web of programming products — way beyond what we encounter when we’re online. Sometimes the stares even resolve into interest.

So when I read items like this in the news I’m reminded of why these questions still matter. This is from a longer New York Times piece on how the U.S. seems to have lost track of hundreds of millions of dollars worth of materiel in Iraq:

Mr. Bowen found that the American military was not able to say how many Iraqi logistics personnel it had trained — in this case because, the military told the inspector general, a computer network crash erased records. Those problems have occurred even though the United States has spent $133 million on the weapons program and $666 million on Iraqi logistics capabilities.

What — no backup? No paper records? How about, you know, asking the people whose job it was to train those Iraqi logistics personnel? Now it could be that this is a “dog ate my homework” sort of excuse, and that in fact the fruits of $666 million did not disappear in a network crash but rather into various people’s pockets, on the U.S. or the Iraqi side. But even at face value, that’s a pretty expensive crash.

(Peter Neumann’s Risks Digest tracks endless amounts of stuff like this on a regular basis.)

It’s hard to analyze this particular disaster without more detail. But military software tends to be big, complex, sometimes bloated. I thought of that, reading today’s fascinating Journal column by Lee Gomes about Intel’s Andy Grove and his latest cause — improving the health care system and its record-keeping. Grove is advocating a simple approach — plain text.

To explain “Shift left,” Mr. Grove describes the bottom axis of a scale in which products and services grow more full-featured, complicated and expensive as you move to the right. To “Shift left” on this scale is to, in effect, “Keep it simple, stupid.”

…Rather than designing an elaborate and technically sophisticated medical-database system, something practically every tech company is now trying to do, Mr. Grove suggests the exact opposite. Shift left; keep the record of a patient’s visit in, for example, a generic but Web-accessible word-processing file.

Just like the early personal computer, it will be far from ideal, but it will be a start, and it can get better over time. The alternative, he says, is to wait endlessly for a perfect technology.

That last sentence should be etched onto the monitors of CTOs and development managers around the globe.

Off to OOPSLA

by

I’ll be heading up to the OOPSLA conference next week (I’ll be there all day Tuesday and Wednesday). It’s in one of my favorite cities in the world, Portland; and it’s a chance for me to brush up on the software realm as my book nears publication.

OOPSLA stands for “object-oriented programming, systems, languages and applications”; it’s a venerable conference dating back about 20 years, and it serves as something of an epicenter for the more visionary or radical tradition in the software development world.

I attended OOPSLA two years ago, and it was one of the highlights of my book research — with presentations from all sorts of interesting people, including Alan Kay, Jaron Lanier, Ward Cunningham and Richard Gabriel. This year’s speakers include Brenda Laurel and Charles Simonyi.

If you’re at the conference and want to chat, leave a comment here or drop me an email.
[tags]oopsla, portland[/tags]

Code Reads #3: Edsger Dijkstra’s “The Humble Programmer”

by

Code ReadsThis is the third edition of Code Reads, a weekly discussion of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.

This will be a briefer entry than I originally planned. I’ve fallen behind a bit this week! So rather than post about all three essays I mentioned last week, I’m going to confine myself to “The Humble Programmer,” Edsger Dijkstra’s Turing Lecture, delivered in 1972.

In “The Humble Programmer” (text, PDF) Dijkstra offers an overview of the programming universe as he saw it in 1972. In the ’50s and early ’60s, programming pioneers struggled against the “painfully pinching shoe” of inadequate equipment. Then they got the more powerful machines they longed for. “But instead of finding ourselves in the state of eternal bliss of all progamming problems solved,” Dijkstra wrote, “We found ourselves up to our necks in the software crisis!” The problem was that the upward curve of ambition driven by new hardware capacity outran the improvements in software:

As the power of available machines grew by a factor of more than a thousand, society’s ambition to apply these machines grew in proportion, and it was the poor programmer who found his job in this exploded field of tension between ends and means. The increased power of the hardware, together with the perhaps even more dramatic increase in its reliability, made solutions feasible that the programmer had not dared to dream about a few years before. And now, a few years later, he had to dream about them and, even worse, he had to transform such dreams into reality!

From its title to the repetition of phrases like “the poor programmer” to its references to “the intrinsic limitations of the human mind,” the essay presents a chastened vision of the human capacity to create software: the programmer, Dijkstra says, must be “fully aware of the strictly limited size of his own skull.”

[Read more…]