Posts filed under 'Meta'
So, this blog will be going into deep-freeze for a while (and I’ll regrettably have to close all comments shortly, because I don’t want to deal with the spam; email if you want to chat about what you find here). While I launch Fictionsuit, Cornucopt is going to take some time off to have an identity crisis. See, back when I first thought of the name Cornucopt, I actually envisioned it as an easier-to-install Ecore. With some push-button setup options for common social-software patterns, and in PHP. That’s about it. Oddly, as I retrace the development of Wicker, now rechristened Cornucopt, it has gotten closer and closer to Ecore. Let me give you a hazy sketch of what I think Cornucopt might look like if I get around to it after Fictionsuit, here in the post-Ruby on Rails world, where there are monorails through wide, green public parks with nary a trace of litter or cramped tennis courts.
Like Ecore, we start on the barest of wiki foundations. You have a bunch of things called nodes, or pages, or whatever, and you can add text and link them easily. Drupal does something like this, only you start with a front page and stuff like threaded comments enabled, for a more slash-cloney shape. Cornucopt’s starting structure will likely be similar to Drupal’s, only with non-threaded comments (or perhaps differently threaded) and tags enabled by default.
The interesting stuff about Ecore (or Drupal) lies in what you do from there, and how you do it. Ecore provides not only a framework for building out a site’s content, but for doing your customization and programming within the Ecore environment itself. You can define a node with a nodetype of “nodetype,” and then just start writing code into a textarea that defines what nodes of your new nodetype will do, and how they will display. You’ve got certain objects you can read or manipulate - a user object, a session object, the page’s text, and suchlike - and you just code up what you want. In theory, I think you have access to all of Perl.
So, even before I was all making out with Ruby on Rails, I was starting to think that Corny’s scheme of pagetypes was kind of a half-measure. I mean, if you want to make something new, you’ve got to write a bunch of PHP into a file, set all your permissions and stuff in there, throw the file up into a poorly named and placed directory (I was gonna get around to fixing that, honest), and then start using it and hope it works. I guess the last step is more or less immutable. But having tried to build things in Ecore, I could see that there was a better way, even though Ecore was pretty much the better way gone wrong. I wanted more things built for me, and more things that could hook together interestingly, and more things that were open to the rest of the net. Ecore doesn’t have a closed culture, exactly… but it has the Perl culture in spades. “There’s more than one way to do it, so we can’t possibly presume to do anything for you. Here’s a textarea. Good luck!”
The real reasons I decided to abandon Ecore were not the above, though. They were my unfamiliarity with Perl and the difficulty (impossibility, actually) of installing Ecore on shared hosting. Ironically, Rails isn’t very friendly with most hosting companies either. But this choice reflects my new, corrected-for-reality notion of who’s going to use Cornucopt and how. I’ve decided to commit to the fact that someone who really wants to customize a wiki is going to write code of some kind. I think they’ll find Ruby code friendlier to write than Perl code. I think Corny’s built-in options will go a decent-enough way to fulfilling other, less extensive needs that I don’t feel as bad about requiring code for the serious kung fu. And I think that Rails is hot enough that Rails hosting will spread fast.
Plenty of design hurdles remain, however. Funny enough, security of executable code isn’t a big worry; Ruby has some sandboxing built in, so I’m not really concerned about restricting them to selected objects and methods. Figuring out what methods people will need, though, might get interesting. Also, these built-in things I’m waving my hands about - what will they be, precisely? How will they be architected, and how the hell do I think I’m gonna make them all snap-together easy? And is it wise to build an application framework on top of another application framework like this?
All of these are questions I’ll have on the back burner until this fall at the earliest. First I’ve got to launch Fictionsuit, then build features I have foolishly already planned for “soon after launch,” then whatever comes after that. Then I need to see if a big generalizing machine to enable other people’s creativity is still something I want to build at all.
If not… well, all this work has been fun. I’ve learned a lot, including the ability to let go of projects without all that guilt. :-) But mostly I’ve learned about my work habits and ability to take a large project to fruition (or something like it) without having it just loom over me, ignored, like a heartbroken pet zombie. Much.
April 18th, 2005
So there’s this interview with Alan Kay, an old-school Apple guy and frequent denigrator of today’s computers. Jes was talking the other day about how Kay’s metaphor of contemporary apps being like the pyramids - brute-force stacks of blocks made possible only by large numbers of Egyptian slaves - was so depressing for an ambitious coder. What we need is not more pyramids, but cathedrals. But no one has discovered the arch yet.
When the architects of Everything2 attempted to productize their core code (along with some other stuff), they named their company Blockstackers Intergalactic. In the best case, programming feels pretty much just like that: stacking blocks, like a happy or at least distracted kid sitting on a shag rug in the middle of the family room. In the worst cases, it feels a little more like being a slave in Egypt. Big fucking blocks, those were.
So that was on my mind when I concluded my post yesterday. I think I’ve been slacking off on 0.2 milestones because what’s left to do - adding a feature to the admin pages, then adding another one, et cetera - feels very much like mindlessly putting one thing on top of another. Many of the distractions I’ve been employing lately have actually been themed around (hopefully) eliminating some of this kind of busywork. Funny enough, not long ago I linked to one of them - Ruby on Rails, a web framework that promises, and seems to deliver, dramatically faster development of database-backed web apps - as a joke about the other context of “on rails:” that of being bored and having nothing to do but mindlessly move forward. I am hoping that RoR promises the opposite, but there’s no time to waste exploring it now.
Must. Stack. Blocks.
February 17th, 2005
Work is proceeding apace on the new hierarchy-related pagetypes, as well as the new-ish pagetype architecture (that is, the total rewrite of the one aspect of Cornucopt that really makes it unique… er, actually, the second total rewrite of said aspect). It turns out that when you make a new pagetype architecture, it’s a really good idea to finish it. Also, we (the assembled… currently three of us noodling about on the test site) have been distracted by shiny brain-destroyers of the PHP phylum.
You want hints about the seekrit projekt, don’t you. Fine.
December 21st, 2004
1) We now have in mind, and in the design process, the first major site that will be built on top of Cornucopt. Its needs are fairly specific, as the needs of most CoCo sites will be, so it will distort development in interesting ways.
2) Case in point: I’ll be developing hierarchy more fully for 0.2 instead of wikifying templates. (Work on the core pagetype architecture is complete for now, knock wood.)
November 20th, 2004
I’ll start this (long!) post with a dirty little secret: I’ve never really been an active user of any large wiki. The closest I’ve come is having been very active on Everything2. E2 is not really much like a wiki at all, but one thing it makes a big point of, and that it does still have in common with the Wiki Way, is its status as a kind of microcosm of the larger Internet. You can’t link outside of E2 in an E2 writeup; you can type in a URL but it won’t be hot. E2’s interface affords a lot of inlinks, and its culture and original mission statement encourage users to make a lot of internal resources rather than utilize resources at other sites. If you want to link to HyperCard, for example, you throw some square brackets and link to E2’s node on HyperCard, not the more complete page on Wikipedia. The rationale is that if you want to link to a better page on HyperCard, you (or the community in general) should make a better writeup on E2 rather than taking energy off the site.
Now, efficiency is not the king of humans, nor of the network. You don’t have to be psychotic about avoiding the duplication of effort. E2 has emotional reasons for having its own pages on things (some of those reasons are rather confused IMO, but that’s not the point). That’s fine; that’s what makes communities communities. But let’s widen the focus back out to wikis in general.
The most common forms of outward linking you see on wikis are 1) plain, old-fashioned HTML links to somewhere else (sometimes visually distinguished in the read view, sometimes written with a different syntax in the edit view, and sometimes just bare, visible URLs); 2) InterWiki links. The latter are much more systematized and “wiki-like” than the former (although plenty of folks do like to bicker about the best way to do syntax for outlinks, or for links in general). In a way, InterWiki was low-hanging fruit; if there are all these other sites that run on software that’s pretty similar to yours, you just have to do a bit of coordination to have them link to each other the way they link to themselves, then all the wikis in the world are one big wiki. That’s very cool, but it’s also a missed opportunity. Why stop at wikis?
Because it’s easier, is the largest part of the reason. But the whole point is that I’m not talking about building wikis out until they do everything. (Although it sometimes feels like that is what I’m doing with Cornucopt.) I’m talking about, how do we make better use of the rest of the net? How do we incorporate the best of “small pieces, loosely joined” without sacrificing the simplicity that we showed up for?
I’ll give you an example by hopping back to E2 for a second. A year ago I was still noding now and again, hoping to finally get up enough writeups to graduate to level 4, whereupon I’d be able to C! things. C!, pronounced “ching,” is E2’s way of letting users give a special shout-out to a node and to highlight to other users what they themselves think are the best writeups in the system. You don’t get to do it until you have enough writeups to earn it, which is what the level system was all about.
So no shit, there I was, writing like a functionary, like it was a job, for a small, insular audience and towards a confused cause, because I wanted to be able to tell people what I liked. And it dawned on me: why don’t I just tell people what I like? A del.icio.us account later, I was in business, and after a couple of posts to the E2 community diaspora, others were too. In fact, if I’d used E2’s C! system, I wouldn’t have had an RSS feed, annotation, or any of the other nice stuff I have at del.icio.us by default. E2’s information architecture sets C!s up as a carrot to reward user effort, but tastier carrots can be had for no effort. E2, like wikis, tends to forget that the rest of the net is there.
So how best to use the rest of the net on wikis? Just link to the rest of the net, might be the answer of a true-hearted wikizen. Keep it simple. But the key difference between InterWiki links and other outlinks is that you don’t have to type http://. InterWiki links incorporate the central thing about Wiki: linking is easy, or easier. (You still have to know the name of the Wiki you’re going to, and that it exists, and how it’s named in the InterWiki system, at which point you probably know enough to copy and paste a URL; that’s why I like SisterSite systems better, but moving on.) Linking is part of the interface. You don’t have to do it all yourself; the software bloody well does it for you, because that’s why we have software. When you write software, it matters that you build something in, and it matters how you do it.
These issues can be extraordinarily hard to think through, which (again) is a large part of why wikis don’t bother. They have other worries more central to their philosophy. In the weblog world (and elsewhere), you see a lot of chatter these days about Web Services, and building web applications as a layer over other web sites, and something called REST and a whole lot of other nonsense. The debate over how to apply these ideas to wikis is still pretty furious, and it’s gonna be even more of a headbreaker working out how to open all the disparate pagetypes and resources in Cornucopt to effective, non-exploitative use by the rest of the net. Figuring out how to do the reverse is not so bad by comparison, although it is giving me some agita (oh God, what about multiclassing? how the hell will I do that in a way anyone will understand? what about letting end-users use plug-ins to drop in external content? will that screw me?). But at least I have a consistent philosophy of “small pieces, loosely joined” to guide me (along with the fact that, at least half the time, Cornucopt installs are not going to be very much like wikis).
E2’s objections to outlinking are well-documented, and although wikis seem not to hate it as much, their tendency to “keep it in the family” anyway reflects a desire to privilege their own way of doing things. That’s one way to think about building any software feature: it will encourage certain behaviors and discourage others. Another way is: it will enable certain behaviors and disable others. I think the latter is what you need to focus on when your mission is to see what people do with your software. The point of opening things up is not to circumvent anyone’s ideals; the point is to take advantage of network effects we haven’t foreseen, and offer more ways to do things - more tools - as well as more emergent, unforeseen things to do. That’s also the point of Cornucopt.
September 14th, 2004
I feel particularly guilty for having these thoughts after finally getting Corny up on SourceForge. But: does this project still matter? To me, or anyone else?
It is not an exaggeration, or a negative statement in my view, to say that when Cornucopt is 1.0, the world will not care. I had a professor who, late in the thesis process for us senior art majors, did something I thought was brave and necessary. He told us all, “This stuff doesn’t change the world. It just doesn’t.” (Wait, actually I’m remembering that line from a Steve Jobs interview in Wired. So, as far as my art prof, I’m paraphrasing, but he did say the following:) “I remember the opening of my first gallery show in the city, in this tiny gallery. I had been sort of expecting the world to beat a path to my stuff as soon as the doors opened. And when nobody came into the gallery for half an hour I actually stormed down the stairs and out into the street, like I was looking for these people. Like I was gonna go and physically drag someone in. And it dawned on me that the world really just isn’t going to notice. I had to find a way to keep doing it anyway.”
Over the years, he did get noticed… just not by the world. And he built a career. But getting there has to be about something else. It is okay to want to get noticed, even to point yourself in that direction, but you have to know that it’s going to come slowly if it comes at all. And you have to build that into your approach. Successful projects in Corny’s vein (aimed at the overlap between geeks and non-, server-based, and having something to do with moving text around and onto a website) have been built out of that classic programmer’s need to “scratch an itch,” or out of passion. (Is there a difference?)
Whether Cornucopt will ever take off is unimportant to me (right now). The question that matters more is, do I still want this code badly enough? Why do I want to have a wiki with weblogs, or anything else I dream up, floating around in it?
I only have room for one programming project in my life at a time (not counting those I get paid to do). Right now, another one is calling my name again. I think I’m going to let Cornucopt cool for a while and see what happens when I want to come back.
Sorry to keep whipsawing like this. Yes, that’s a word.
August 3rd, 2004
First: http://sourceforge.net/projects/cornucopt/
Yes, you can check out the tree.
Second: Powered By WordPress. I am working on the conversion details, which is why you are not reading this right now. (Note: WordPress is, regrettably, not recommended overall.)
Third: I’m pretty sure I fixed the softlink bug, but I have been so busy with points one and two that I have not actually checked. I still need something for the big-database problem, where all the miniscule little bug-fix changes get stored as full text, and I am reviewing other Wikis to see what they do. Understanding their code is difficult - hell, that’s half the reason I’m still coding this thing - so this is taking time.
July 4th, 2004
Wicker is now Cornucopt.
Cornucopt is the language of the fictional land of Cornucopia, as described in the comic books of Dylan Horrocks. A cornucopia is also known as a horn of plenty. Cornucopt, née Wicker, will be a horn of plenty of language, a vessel made to increase the quantity and quality of that which flows through it.
I’m happy with this new name, which is actually an old name, although it took me a day or two to remember it. Besides increasing the pretension level of the whole project, it’s highly unlikely that anything else in open source will duplicate it. (Try it in Google.)
May 10th, 2004
Uh oh:
Wicker is a lightweight, modular Java application server, suitable for embedding in a web server, and intended as an alternative to the current standard of large-scale/monolithic application servers.
The project isn’t super-active, but still. “Application server” is close enough to what we do in the headspace of a comparatively tech-naive user that I am worried. Also, bigger projects than mine have had to change names due to conflicts with much smaller projects than themselves.
So if I had to call Wicker something else, what would I call it? WickerMan has come to mind, but it’s CamelCase, which ReallySucks, and it’s a bit… violent? So, suggestions more than welcome.
May 8th, 2004
So, TikiWiki. Yeah. Most insanely overdeveloped Wiki ever, but I’ve been surprised by my toy installation - I’ve been able to figure out how to do most things I want to do, quickly and easily. It even uses Smarty for templating, as Wicker does. What I haven’t done yet is look much at the Tiki code, but if that goes well, maybe I will just become a Tiki developer. Give them softlinks, give them dynamic blogs (an idea stolen from JSPWiki that would be fast to implement as a Wicker pagetype, although I’d likely call it something like a Topic… or just a Category, as it’d be an ideal way to do Wiki categories)… and give their CSS a few well-placed slaps on the backside.
But wow, do they ever have too many PHP files on the root level.
[Update: looks like they are fixing the latter problem, and some others, over here.]
April 19th, 2004
Previous Posts