A Trifle Absurd

Open Source: The Next Generation

Has there ever been a better time to be an application developer? Just look at the wealth of open-source components out there: languages, web servers, databases, GUI toolkits… To my eye, they’re just itching to be pulled together into great apps.

I’ve always leaned toward the user-facing side of things—writing a library or an OS just doesn’t appeal to me, though I have plenty of respect for those who do it. I’d just rather write an app, and spend my time fine-tuning the user experience. Now, with all these components ready at hand, I can do just that, without having to build up the low-level stuff from scratch.

The first generation of open-source tools was all about programmers scratching their itches. Thus, we got editors, compilers, languages, libraries, and databases—all stuff that programmers need and use. But now we’re seeing the beginnings of a new generation: real, polished, usable apps that aren’t just for programmers anymore. Firefox and Thunderbird are early examples, but there’s more to come, such as Chandler.

Without the X

The “Ajax” moniker seems to be catching hold, and I don’t mind too much—it’s nice to have a name for it. As others have already pointed out, though, the “X” (for XML) is a misnomer. Many Ajax applications (e.g. GMail) don’t use XML for their back channel. If you send data as JavaScript, then a simple eval() does all the parsing work on the receiving side.

I’ve bootstrapped Trifle as a simple read-only tagbase browser. The client receives data as JavaScript, which works great. Now I need to handle the other direction: JavaScript code posting updates to the server. But whatever code is running on the server, it probably won’t be JavaScript, so sending data in JavaScript form is pointless.

I could try to get sneaky and take advantage of the extreme similarity of JavaScript and Python data notation: lists, dictionaries, strings, and numbers have almost identical syntax. That would inevitably bite back, though, especially the “almost”.

So what other format would be easy for JavaScript to generate and for your average text-munging language to parse? Yes, there’s XML, but the DOM (for generating it) isn’t what I’d call convenient. Maybe a simple line-based text format will fit the bill. A general “verb url data” syntax could cover everything I need.

And no, it’s not like I’m abandoning XML. I’ll eventually extend the server side of Trifle to accept and generate XML, so that it plays well with others. For direct server-to-JavaScript-client communication, though, XML doesn’t cut it in this case.

Bookmarkability

Modern-day web applications are hard to make bookmarkable. If you’re using script trickery behind the scenes to get new data without reloading the page, the page updates—but the address bar doesn’t. Bookmarking the ‘new’ page will grab the address of the old page instead.

Some apps, like GMail, just ignore the problem, and thus prevent deep linking. Google Maps uses a workaround: a link on the page itself that gives you a bookmarkable version of the current page. But can we do better?

There is a way to change the URL in the address bar without causing a reload: just set location.hash. The value is tacked on to the displayed URL (plus a ‘#’, of course), and gets saved in bookmarks. When a bookmark is used, that part of the URL isn’t sent to the server, but we’re assuming a script-heavy web application anyway: just check for the location.hash value in an onload handler.

There’s a snag, though. If the user is already at “http://your/url/#foo” and navigates to “http://your/url/#bar” (via another bookmark, for instance), the browser won’t tell you about the change. Other than fantasizing about an onhashchange event, there’s not much you can do about it. Well, you can use setInterval() to poll location.hash for changes, but you’re stuck between having a long gap between checks—and therefore slow update performance—or slowing things down with frequent checks.

So is there no good solution for web-app bookmarkability? Not that I’ve found.

Migrating to Tags

I’d like to put my web bookmarks into a tag-based system, instead of the folder-based system they’re in now. But what’s the best way to do that?

My first thought was to turn folder names into tag names, but that quickly breaks down. For instance, “Other” can be a reasonable folder name, but it makes no sense as a tag name. And what about nested folders? Should a path be concatenated into a single tag, so “/foo/bar/baz” becomes “foo-bar-baz”? If you do that, each item gets only one tag, and it’s no different than having them in folders. But the alternative has its own problems—some subfolder names make no sense in a global context.

There’s no getting around it: I think of different terms when I think “What should I name this folder?” versus “What tags should I put on this?”. But with five-hundred-odd bookmarks to migrate, tagging them all by hand isn’t exactly appealing.

One thing I could do is take advantage of the aggregate smarts of del.icio.us. Presumably a sizable majority of my bookmarks have already been tagged in del.icio.us—so why not write a little script to tag all of my bookmarks with the three most popular del.icio.us tags for each? It’s a fun idea, but I doubt I’ll do it. The whole point of having a personal tagbase is to use tags that have meaning for me; of course, that means that I probably will have to tag those bookmarks manually, sooner or later.

Encouragement for Tech Writers

I’m a newbie in the tech-writing field. Aside from an article (and program) that I sold to Compute! just before going to college, all my professional experience has been in programming. So I’m still trying to get my bearings in this new arena. I don’t like feeling lost, but I’m attracted to the challenge of doing something new.

In that context, a little encouragement goes a long way. Today I came across Kathy Sierra’s blog, Creating Passionate Users, and spent the better part of an hour reading great stuff like How to create a non-fiction bestseller and its sequel. Then I found her Computer Book Author’s Manifesto at O’Reilly.

All those posts are about books, and I’m definitely still in the article-writing stage. But they get me excited and ready to believe I might actually be able to do this after all.

Radial and Cartesian Thinking

Clay Shirky has found a new way to classify people into two groups, radial and Cartesian:

Radial people tend to think more about change than end state, and more about local maxima (are things getting better?) than about a global maximum (are things as good as they could be?). Cartesian people think more about end state than change, and more about global than local maxima.

It’s not that new, though; it’s more of a different way to look at Richard Gabriel’s dichotomy between Worse Is Better and The Right Thing. Only Richard isn’t into classifying people so much as development styles, while Clay blithely tosses people into categories, putting Richard into the radial/worse-is-better camp even though, as the above link demonstrates, Richard has flip-flopped several times.

I think Richard is closer to the mark: the point isn’t to classify people, it’s to recognize two different ways of thinking, so you can choose the best method for a given situation. Sometimes it’s better to tackle a problem by envisioning the smallest possible change that would solve it, while other times it’s better to rethink the whole picture. The trick is knowing when to do which.

The Shame of the Industry

Shelley Powers satirizes, psychoanalyzes, and pulverizes the male-dominated world of blogging (with some explicit language). It’s the best kind of satire: hilariously funny, with a very serious point.

There are women out there blogging, and excellently: Rachelle Mee-Chapman and Julie Leung are good examples. But Shelley’s point is well-taken: the blogosphere is, tragically, by and large a boys’ club.

And if you look solely at programming, the situation is even worse, not just in blogging, but in the industry as a whole. A sad-but-true story: in my freshman year of college, we had a guest lecturer one day for the introductory C++ class. He insisted that zero was a natural number, but since we’d been taught that the natural numbers started at one, dissent arose. His counter: “How many women are there in this room?”

Since then I’ve worked on several development teams with fifty or more programmers. None had more than five women. We should be ashamed of that. There’s no excuse for that kind of imbalance — it’s not just imbalance, it’s injustice.

Keeping in mind G.K. Chesterton’s reminder (”What’s wrong with the world? I am.”), I want to find some way to be a force for change. I want to help, not just stand idly by and wag my finger at some imagined class of prejudiced people. But how? I don’t know yet.

Open-Source JavaScript

A DHTML application’s source code is immediately visible to anyone who cares to look. You can keep it proprietary, but you can’t keep it secret. So why have there been so few open-source JavaScript libraries? Up till now, few apps have had a large enough chunk of code in JavaScript to justify splitting something out as a library. But as interest grows in rich JavaScript-based applications (a.k.a. Ajax, a name I’m not too fond of) and the average code size grows, we should see more libraries.

TrimPath is a relatively new umbrella project for just that. It currently houses three projects: a client-side templating library, a DSL for SQL-esque queries, and a spreadsheet engine. Steve Yen is the instigator and author of these projects; he has a blog on the TrimPath site.

Good stuff, and we need more of it. Which, in the open-source world, means that I should be doing more of it. Okay, I’m off to program.

Sherlock and XQuery

As a new Mac developer, I was intrigued to learn that Sherlock supports JavaScript and XQuery for developing new channels. Unfortunately Sherlock’s XQuery implementation is outdated and anemic, and the test environment of the XQuery Developer Channel leaves much to be desired.

For instance, the simple constant query <foo/> returns <NSCFType: 0×3b03b0> instead of <foo/> — the simpleminded channel implementation doesn’t bother serializing nodes back into a readable format. It’s possible to hack around this with the Apple-extension function source(), which takes a node and serializes it into a string. Other problems kept popping up, though, so I eventually gave up. The lack of coherent documentation about just what subset of XQuery is actually supported makes it all a trial and error enterprise, and it just isn’t worth it.

It sounds like XQuery will be baked in at a lower level in Tiger, to where it’s accessible to, say, Dashboard widgets. If it’s a sanely updated version of XQuery, that might actually be useful, and I’d look forward to it. As it is, though, I think I’ll be installing Berkeley DB XML or Qexo to satisfy my XQuery yearnings.

Nixing Comment Spam

I haven’t had much trouble with comment spam yet, but I’d rather take preventative measures than be drowned in a flood of spam later on. So, I’ve taken a few simple steps: disabling comments on older posts, altering the comment submission URL, and disabling trackback entirely.

I’ve also added an extra field to the comment form with a blindingly obvious question to answer. I first saw that on Jeremy Zawodny’s blog, and I like it better than captchas or hashcash because it’s fully accessible and doesn’t require JavaScript.

The upside to all this is that I’ve turned off comment moderation for the time being, so comments will appear immediately. Hopefully that will last awhile before the spammers catch on.

While I’m on the subject of blog administration, I should mention that I’m going through and categorizing my previous posts. I’m spending all this time talking about tags, so I should occasionally do some actual tagging, right?