Unit Tests: A Reliable Friend

Posted on Published by Eugene Eric Kim

Mike Mell and I were IMing today about a project we’re working on together, and he said off-hand that he’d like to be more rigorous about writing unit tests. His comment struck me, because I’ve been hacking PurpleWiki again after being away for literally months, and once again, unit testing has made my life considerably easier.    (JUO)

I’ve written about unit tests before, using PurpleWiki as an example. Writing them can be a serious pain, especially when you’re on a coding roll, and I’ve been known to cheat. But the more you refactor or code intermittently (as I’m prone to do), the less inclined you are to cheat in the future.    (JUP)

Unit tests are the ultimate in peace of mind. There’s just no reason not to use them.    (JUQ)

Tim Bray on Purple Numbers

Posted on Published by Eugene Eric Kim

I’ve long been a fan of Tim Bray‘s work, and although we had never crossed paths before, I had always assumed it would be instigated by me making some comment about something he had done or written about. (A few months back, I emailed him about ballparks in the Bay Area, because we seem to share a love for the sport, but that doesn’t count.) So I was surprised and pleased to see that Tim had made first contact and had (temporarily, as it turned out) implemented Purple Numbers on his blog. Not surprisingly, this is starting to generate some talk in the blogosphere. In particular, see:    (1G9)

Chris has done an excellent job of quickly addressing many of these issues. I’ll just toss in a few thoughts and references here and will look forward to more feedback.    (1GE)

Stable, Immutable IDs    (1GF)

Several people have pointed out that the IDs need to be stable. In other words, as the paragraphs move around or as new ones are added or deleted, the IDs stick to their original paragraphs. This was a fundamental motivation for Engelbart’s statement identifiers (SIDs), which we have renamed node identifiers (NID).    (1GG)

Both Purple (which needs updating) and PurpleWiki handle this correctly. You’ll notice that the addresses are stable on my blog and on Chris’s, as well as on all of the PurpleWiki installations (e.g. Collab:HomePage, PurpleWiki:HomePage). It’s because we use plugins for our respective blog software that call PurpleWiki‘s parser, which manages NIDs for us.    (1GH)

By using PurpleWiki to handle the purpling, blog content has NIDs unique to both the blog and the Wiki, which allows us to do fun stuff like transclude between the two. We get a similar effect with perplog, the excellent IRC logger written by Paul Visscher and other members of The Canonical Hackers. For example, check out Planetwork:Main Page and the chat logs over there.    (1GI)

Mark Nottingham noted that even if the NIDs are stable in the sense that they are attached to certain paragraphs, the paragraphs themselves are not semantically stable. This is a point on which I’ve ruminated in the past, and we still don’t have a good solution to it.    (1GJ)

History and Other Worthy Projects    (1GK)

I’ve written up my own brief history of Purple Numbers, which fills in some holes in Chris’s account. In it, I mention Murray Altheim‘s plink. Plink is no longer available on the net, because it has been subsumed into his latest project, Ceryle. Everything that I’ve seen about Ceryle so far kicks butt, so if you’d like to see it too, please drop Murray an email and encourage him to hurry up and finish his thesis so that he can make Ceryle available! You can tell him I sent you, and you can forward him the link to this paragraph; he’ll understand.    (1GL)

Matt Schneider is the creator of the PurpleSlurple purple numbering proxy, which will add Purple Numbers to any (well, most) documents on the Web. PurpleSlurple deserves a lot of credit for spreading the meme.    (1GM)

Mike Mell implemented Purple Numbers in ZWiki for last year’s Planetwork Conference (see ZWiki:ZwikiAndPurpleNumbers), which in turn influenced the evolution of Purple Numbers in PurpleWiki. Mike and Matt have both experimented with JavaScript for making the numbers less intrusive.    (1GN)

The latest version of the Compendium Dialogue Mapping tool exports HTML maps with Purple Numbers.    (1GO)

In addition to Murray, Matt, and Mike, several other members of the Blue Oxen Associates Collaboration Collaboratory have contributed to the evolution of Purple Numbers, especially Peter Jones, Jack Park, and Bill Seitz. In addition to his contributions to the technical and philosophical discussions, Peter wrote the hilarious Hymn of the Church Of Purple and excerpts of the Book of the Church Of Purple.    (1GP)

Finally, many good folks in the blogosphere have helped spread the meme in many subtle ways, particularly those noted connectors Seb Paquet and Clay Shirky.    (1GQ)

Evangelism and The Big Picture    (1GR)

Okay, that last section was starting to sound like an award acceptance speech, and although none of us have won any awards, one thing is clear: The contributions of many have vastly improved this simple, but valuable tool. I’m hoping that momentum picks up even more with these recent perturbances. I’m especially heartened to see experiments for improving the look-and-feel.    (1GS)

I want to quibble with one thing that Chris Dent said in his most recent account. (When we have distributed Purple Numbers, I’ll be able to transclude it, but for now, you’ll just have to live with the cut-and-paste):    (1GT)

When he [Eugene] and I got together to do PurpleWiki, we were primarily shooting for granular addressability. Once we got that working, I started getting all jazzed about somehow, maybe, someday, being able to do Transclusion. Eugene was into the idea but I felt somehow that he didn’t quite get it. Since then we’ve implemented Transclusion and new people have come along with ideas of things to do that I’m sure I don’t quite get, but are probably a next step that will be great.    (1GU)

There are many things I don’t quite get, but Transclusions are not one of them, at least at the level we first implemented them. That’s okay, though. Ted Nelson felt the same way about my understanding of Transclusions as Chris did, although for different reasons. (And, I suspect that Ted would have had the same opinions of Chris.) I mention this here not so much because I want to correct the record, but because it gives me an excuse to tell some anecdotes and to reveal a bit about myself.    (1GV)

Anyone who knows Doug Engelbart knows that he complains a lot. The beauty of being an acknowledged pioneer and visionary is that people pay attention, even if they they don’t think much of those complaints. When I first began working with Doug in early 2000, I would occasionally write up small papers and put them on the Web. Doug would complain that they didn’t have Purple Numbers. At the time, I recognized the value of granular addresses, but didn’t think they were worth the trouble to add them to my documents. I also didn’t think they were the “right” solution. Nevertheless, because Doug was Doug, I decided to throw him a bone. So I spent a few hours writing Purple (most of which was spent learning XSLT), and started posting documents with Purple Numbers.    (1GW)

Then, a funny thing happened. I got used to them. I got so used to them, I wanted them everywhere.    (1GX)

A few people just get Purple Numbers right away. Murray was probably the first of those not originally in the Engelbart crowd to do so; Chris followed soon thereafter, as did Matt. The vast majority of folks get the concept, but don’t really find them important until they start using them. Then, like me, they want them everywhere. Getting people past that first step is crucial.    (1GY)

A few nights ago, I had a late night conversation with Gabe Wachob (chair of the OASIS XRI committee) on IRC. (This eventually led to a conversation between Chris and me, which led to Chris’s blog entry, which led to Tim discovering Purple Numbers, which led to this entry. Think Out Loud is an amazing thing.) Gabe knew what Purple Numbers were, but hadn’t thought twice about them. I had wanted to ask him some questions about using XRI addresses as identifiers, and in order to do so, I gave him a quick demonstration of Transclusions. The light bulb went off; all of a sudden, he really, truly got it.    (1GZ)

Richard Gabriel, one of our advisors, is well known for his Worse Is Better essays (among other things). I think Purple Numbers are an outstanding example of Worse Is Better. They fulfill an immediate need, and they cause us to think more deeply about some of the underlying issues. I’d like to see Purple Numbers all over the place, but I’d also like to see a group of deep thinkers and tinkerers consider and evolve the concept. It’s part of a larger philosophy that I like to call The Blue Oxen Way.    (1H0)

This last point is extremely important. Chris has thankfully been a much more enthusiastic evangelist of Purple Numbers than I have, and in the past he’s called me “ambivalent” about Purple Numbers. That’s not so far from the truth. It’s not that I’m any less enthusiastic about Purple Numbers themselves — I am a card-carrying member of the Church Of Purple, and the current attention and potential for wider usage thrill me. However, I’m cautious about evangelizing Purple Numbers, because I don’t want people to get too caught up in the tool itself and forget about the bigger picture. It’s the reason I didn’t mention Purple Numbers at all in my manifesto.    (1H1)

At the Planetwork forum two weeks ago, Fen Labalme, Victor Grey, and I gave the first public demo of a working Identity Commons Single Sign-On system. We were tickled pink by the demo, which to everyone else looked just like any other login system. The reason we were so excited was that we knew the system used an underlying infrastructure that would eventually enable much greater things. The demo itself, unfortunately, didn’t convey that to anyone who didn’t already understand this.    (1H2)

I’m probably a bit oversensitive about this sort of thing, and I’m constantly seeking better balance. But it’s always in the back of my mind. When I talk to people about Blue Oxen Associates, I usually spend more time talking about the sociological aspect of collaboration rather than the tools, even though I have plenty to say about the latter. Can Purple Numbers make the world a better place? I truly, honestly, believe that they can. (This is a topic for another day.) But when I see groups that excel in collaboration (or conversely, those that stink at it), Purple Numbers are usually the furthest thing from my mind. Much more important is the need to identify and understand these patterns of collaboration (of which tool usage is an important part).    (1H3)

Response to Marc Canter

Posted on Published by Eugene Eric Kim

I meet a lot of interesting people in this business, but a few stand out more than others. Anyone who’s met Marc Canter knows what I’m talking about. Marc is a big, boisterous fellow, mostly good-natured, and very outspoken. The guy is sharp and passionate, and has a proven track record of getting things done in the Valley, including cofounding MacroMind (which became Macromedia). He’s also got an incredibly cute baby daughter, which is a bit unfair, because it makes it difficult for me to get mad at him.    (B5)

Marc recently complained about Blue Oxen Associates. Among his complaints were:    (B6)

Now I have nothing againist Eugene Kim and his stalwarts, but what they created and what they do is pretty lame – compared to what’s going on out there – for free, everyday. What was it about Blue Oxen that Socialtext, Phil Pearson, Dave Winer, Paolo Valdemarin, Clay Shirky, Cory Doctorow, Danny Ayers, Dan Brickley, Lisa Rein, Mitch Kapor, Mark Pilgrim, Aaron Swartz, and hundreds more aren’t doing everyday?    (B7)

Why did we need a white paper on why open source is a good thing? Why do we need yet another Wiki – ever if it is purple?    (B8)

I just really think that Pierre’s money could be put to better use.    (B9)

There are lots of problems with what Marc says, the biggest being that he’s got most of his facts wrong.    (BA)

First, Omidyar Foundation has not invested in us. They funded our first research report on the open source software community. We are completely self-funded (by me), surviving on my initial investment and on clients.    (BB)

Second, we are not in the business of open source software development. As a company that uses, evangelizes, and works to better understand collaborative tools, we naturally do some development. Our policy is that everything we produce is open source, be it software or research. PurpleWiki happens to be the first of those tools, and so we make it available.    (BC)

Is PurpleWiki the Wiki to end all Wikis? That’s not our intent. Our intent is to understand and explore ideas that will help us improve collaboration, and then to disseminate those ideas as widely as possible. PurpleWiki is more than a bunch of purple hash marks spread out on a page. There is a lot of deep thinking behind its architecture, much of which was inspired by Doug Engelbart‘s earlier work. The Purple Numbers are the most visible manifestation, but there are others that will become more apparent eventually. The point is, we want to make those ideas accessible, and if they are useful, we want to help spread those ideas. That goes for all collaborative tools, not just Wikis.    (BD)

We’ve done this. For example, we worked closely with Mike Mell who worked closely with Simon Michael to implement Purple Numbers in ZWiki. We host an active community of tool developers who are working together to make their tools more useful and interoperable. We’re always exploring new ways to make a difference.    (BE)

Third, our research report was not about why open source software is a good thing. It was a preliminary exploration into why open source communities work. We’re not the first to explore this question, but I think we are especially qualified to explore it for a number of reasons. More importantly, our target audience is not open source developers. These folks don’t need persuading. Our audience is people who know nothing about open source software, except perhaps that it exists. There is an enormous language and experience barrier that prevents these folks from understanding what makes open source communities tick. Our thesis is that all communities — independent of their domain — could benefit from understanding and emulating open source communities. In order to test this thesis, we first have to overcome the language barrier.    (BF)

Fourth, Marc listed a bunch of people doing great work in this space as if they were our competitors. They are not. I know several of these folks, have worked with some of them, and hope to work with many more. Our goal at Blue Oxen Associates is to better understand collaboration, so we can help improve it. In order to do that, we need to put our money where our mouths are and collaborate with others working towards the same goal.    (BG)

When I founded Blue Oxen Associates, I consciously avoided seeking seed money and going for the big splash up-front. Some of the things we’re trying to accomplish are not obvious, and require further thinking and development. Starting small and growing slowly means we have to focus, sometimes at the expense of interesting projects and work, often at the expense of attention.    (BH)

Nevertheless, I’m surprised and flattered by the attention we’ve received thus far. The participants in the communities that we host are incredibly supportive. We have an amazing advisory board. I constantly run into people who know about us and compliment us on our work. And, the blogging community has said some great things about us as well. I’m even flattered that Marc thought enough of us to devote some space on his blog to call us “lame.” Like I said, it’s hard to get mad at a guy who means well and has a cute baby daughter. I hope he’ll continue to follow our work; perhaps “lame” will evolve into something better once he actually understands what we do.    (BI)