This place is a long-neglected ghost town that sees a begrudged entry every few months, when I happen to remember it still exists and I feel guilty for not feeding it with content. What I’ve yet to figure out is if the cause is a matter of motivation, publishing tools, audience, or writing topics.

Behold as I ramble on for many tens of words pondering the cobwebs here at 0xDECAFBAD.

Motivation

Other outlets have absorbed nearly all of my motivations that once prompted casual blogging. And those other outlets, in most cases, provide better rewards:

• For quick top-of-the-head thoughts and quips, Twitter works best for the brain-spew and gets me feedback from interesting people faster than my spam-embattled comments here ever did.
• For sharing things I find on the web, Delicious took that job over years ago and Google Reader has been angling for the job as well.
• For sharing code and projects, I’ve started doing more and more over at my GitHub account.

Quite awhile ago, I even went so far as to redirect the front page of my decafbad.com domain straight to a page that’s nothing more than a shell for a FriendFeed widget that aggregates my output from elsewhere. It’s kind of a cop-out, but if you want to see what I’m really up to, that’s a much better page than my stagnant blog index anyway. I’ve got a local archive of my activity, and have been meaning to make a self-hosted lifestream more front-and-center, but I’ve been too busy to bother.

Publishing tools

In fact, I’ve been thinking about killing my WordPress installation here altogether, and switching the blog over to a static fossil snapshot. Since I rarely post, there’s rarely a comment inbound here these days that’s not trying to slip through an ad for pills or fake handbags. Thus, most of the CPU cycles on my web host are spent on busy work processing requests that will never amount to anything real. So, why bother having an actual PHP application running here?

The one thing that I haven’t done a lot of lately—and would like to carve out time to get back to—is some real long-form writing. You would think that that’s where this WordPress thing would come in handy, but oddly it seems not to. I hate writing in textareas in browsers, haven’t found a desktop blog client that I liked in years.

So, because of the little things that annoy me, I stop writing before I start because the anticipated process to publish seems like a chore. I’d much rather be writing in MacVim and checking text files into a git repository. Then, I could throw Jekyll or something yak-shavingly homebrewed on top of post-receive hooks to do indexing magic and such in static HTML. You know, the stuff that took forever in MovableType back in the day, but decoupled from my actual writing process.

Huh, now that I describe it, the above sounds like a chore too—but it would be a shiny new toy! At that point, I wouldn’t be blogging so much as publishing an archive of essays on the web. But, at least I’d know the format would be future-proof, the platform exploit-resistant, and the overall maintenance less worrisome. If I had comments, I could even outsource them to another service and run periodic backups to be safe.

Audience

But, beyond the mechanisms, there’s who I imagine might be reading this stuff. I hold off on writing a lot of things that could be posted here because they’re maybe not tech-nerdy enough. If it doesn’t have at least one code example, I hesitate to share it here—and if I don’t share it here, I probably don’t share it anywhere.

And then there’s the thought that whatever I write here, no one will read it if it’s too long. This entry is mostly written to myself, and I expect a single-digit comment count—most likely zero. I get the most feedback on the shortest things, which has ultimately lead to Twitter and its 140 character limit yielding some of my most rewarding interactions on the web in years. I post an essay here, and it’s all crickets.

The exceptions are where I post something really useful, like that article about HTML 5 Drag & Drop or a Delicious command for Ubiquity. That is, of course, a clue if comments and feedback are what I’m after.

Writing topics

So, what could I be writing about these days? Let’s see, I could write about:

• what I’ve been up to at Mozilla since I started;
• brewing beer and roasting coffee at home;
• retro computing on my C64 and Amiga;
• developing for Palm webOS;
• random thoughts on life;

Huh. That all sounds like a blog, and one I would read myself—though that last one sounds like my LiveJournal, long neglected since I started dating my wife and got much less emo in general. We probably don’t need to go there so much, but I could probably bore with more even-tempered philosophical expositions.

What’s the problem?

I wonder what my real problem is, then? Is it really just a matter of butt in the seat that I’m missing? I write every day—in a paper journal, in wiki pages, in emails, to myself—I just don’t write much here. Maybe all the above is just a collection of excuses.

Lately, I’ve had this notion that I should try writing and publishing for an earlier version of myself. That is: all these things I end up searching for and researching on the web, I should write them up in a way that I wish had been the first search result in Google. Whatever the topic, if a younger version of me wanted to find it, I should put it out there to be found. Never mind who else I think might read it or (not) comment on it.

Write for myself, write what I’d want to read—sounds pretty obvious when I put it out there like that. So, is that the deal? Who knows; we’ll see if a change in perspective results in more happenings here.

This one’s been a long time coming, but it’s finally sitting in my grubby little hands:

My contribution to this book includes all of the material from The Concise Guide to Dojo, plus a second concise guide worth of material on the MooTools JS framework. In addition to my work, you can find the work of Ara Pehlivanian on YUI, Scott Koon on Prototype, and Harley Jones on ExtJS.

• An more generalized scope for alternate URL choices asserted by publishers, not just URL shortening. Other criteria beyond character length include ease of entry on mobile devices (eg. short, but also simple, maybe mostly numeric), ease of verbal mention (eg. billboards, postcards, etc).

• HTTP headers are great where available—hooray for HEAD—but it still needs to be in the page for publishers who can’t set custom headers.

• Microformats are great, but I’d rather not parse a whole page to the footer to lift out the desired URLs.

• Don’t panic. Have fun.

And with that, I’m going to try coming up with other things to write about so this blog doesn’t stay dormant. The rest of this entry remains unedited below…

So, like it says up there: I like rev=”canonical”.

Basically, it’s a way of saying—instead of using that 3rd-party service you like for munging my URLs, use one of these pre-munged URLs I’ve provided. Ideally, the URLs I provide will be shorter for your needs, but my URLs won’t be subject to potentially distasteful things I object to with respect to a service you might pick.

I like keeping control of URL spaces in the hands of their publishers. This also opens the field for more individual choice in URL shortening services, allowing more people to try their hand at building a better mouse trap—or allowing publishers to opt out of the mess altogether.

And, apropos of that, I tend to like rev="canonical" as the means of expressing this choice.

There’s a lot more background on this whole shebang, but I’ll just stick to my $0.02 on the discussion so far.

It’s too alpha geeky to get adopted—also: NERDS!

Alpha geeks write plugins for web publishing systems used by less-alpha geeks, who eventually install web publishing systems for those even further down the geek scale. It’s not unheard of for something incredibly nerdy to become relatively common, if it proves useful.

Feed auto-discovery is in blogging software and browsers now—it was once considered a somewhat arcane usage of the rel attribute on <link> tags in HTML <head>.

Everyone needs to implement their own URL shortener.

No, but everyone gets to pick a shortener for their own URLs—which could coincidentally be self-hosted or third-party. Isn’t the web great?

The rev attribute is too hard to understand, people will get it wrong.

I hadn’t paid much attention to the rev attribute until a week or so ago. I read the HTML spec on links again. Within 10 minutes of reading the spec, my understanding became this:

• rel="{X}" — “this link means {X} in relation to the current page”.
• rev="{X}" — “this current page means {X} in relation to this link”.

I may have misunderstood it—if so, explain to me how and I’ll admit it’s harder to understand than I think. There are harder concepts in the HTML 4 spec.

The rev attribute is removed in HTML5

That’s too bad for HTML5.

The rationale given for the removal seems sensible enough. But, I’d say the rationale for removal is weakened if someone finds a use for the attribute and uses it correctly.

rel="shorter" / rel="short" is better and more explicit.

I like this idea in general, and I don’t really care strongly enough about rev="canonical" vs rel="short" to make much noise beyond this blog post.

But, I prefer the semantics of rev="canonical", I don’t think rel="short(er)" is better, and actually I think the less explicit assertion is a feature. I’ve not yet been convinced otherwise—but realistically, if either catches on, I’ll probably use the most popular.

rev="canonical" doesn’t mean “shorter URL”

That’s okay—what if I don’t want you to have shortened versions of my URLs? Doesn’t fit in your tweet? Screw you. I didn’t want you to link to me that badly anyway. Bah.

That, of course, is self-defeating. Conventional use of the attribute will probably yield shorter URLs out of self-interest. Furthermore, I could even offer a half-dozen URL variations, and you could use the string length function in the language of your choice to pick one on the basis of shortness. There’s a lot of choice to go around here.

Also, feed auto-discovery links don’t always lead to truly alternate versions of the current page—but instead to a useful set of items, many of which may currently appear somewhere on the page. So, even the “clear” semantics have some play in them as used in the wild.

A rev="canonical" HTTP header is better.

Hmm, maybe. It would certainly allow for possibly lighter-weight HEAD requests in determining the alternative URL for a given URL. But, I would expect it to fall apart in collections of static HTML pages baked by an offline script where web server configuration might not make setting custom headers easy.

Not everyone has the luxury / inclination to have a dynamic language capable of setting headers running in their web server.

rev="canonical" should appear on hyperlinks in the body of the page

I like microformats, in general. But, I don’t really want to potentially parse a whole page to find the shorter URL that might be in the footer. With rev="canonical" in the <head>, I only have to parse so far before I find it or give up.

There’s a lot of prior art on this with relation to feed autodiscovery—we used to mainly look for RSS feed URLs inside the page, too. It sucked.

Claiming to be canonical for another URL is trouble.

Okay, how about requiring a reciprocal rel="canonical" on the same page with rev="canonical".

Trust but verify—and only accept rev="canonical" where rel="canonical" matches the current URL and rev="canonical" yields a 301 redirect to the rel="canonical".

I can’t see this verification process being necessarily more burdensome than using a 3rd-party shortener API—and that’s if you’re paranoid and building an index that needs some measure of resistance to gaming.

A single character slip from rev="canonical" to rel="canonical" could wreck your Googlejuice!

So, don’t do that.

Maybe Googlejuice should be more resilient. Maybe it actually is—has anyone actually soured their juice yet with a mistake like this and lived to tell the tale?

Either way, characters mean things in computer languages, so make sure you use the right ones in the right order.

You guys are moving on this stuff too fast!

Welcome to 2002, when lots of us had more spare time than employment and we deployed new crap like this on our blogs and sites daily.

Back in those olden days, we manipulated raw HTML with our bare hands and deployed radioactive code using our teeth—all without benefit of protective change control. We probably all have cancer of the access logs now, but it was all in the name of Web Science!

Too long; didn’t read

So, yeah. I like the idea behind rev="canonical" and I prefer its expression as rev="canonical" best—but the idea is the important thing. Let’s get over the expression part fast and spend more time exploring the nuts and bolts and implications of the concept itself.

1. Link to your original tagger(s) and list these rules in your post.
2. Share seven facts about yourself in the post.
3. Tag seven people at the end of your post by leaving their names and the links to their blogs.
4. Let them know they’ve been tagged.

Now, for your random facts, after the jump:

1. My wife is a nerd, who tracked me down via a user name shown in the webcam picture I used for my Yahoo! Personals ad, in order to avoid paying to reply. Dial-up BBSes and DOOR games played a part in our courtship.
2. We have two ocicats, littermates named Puck and Inanna. They’re both very cute and are more awesome than anyone else’s cats.
3. I have sleep apnea, and use a CPAP machine every night. If you snore, go get tested. Heart disease, of which my snoring father died, is one of many possible consequences of untreated sleep apnea.
4. Although I have been a computer nerd since the age of 7, I had the wild notion in starting college that I wanted to be a journalist or a psychologist. Luckily, the web took off during my freshman year, which let me be a little of all the above. I’m not sure why I ever thought I’d be anything other than a computer nerd.
5. I’m a complete introvert and though I work hard at being sociable, I need a day or two alone for every half-day or so spent being social. My main coping mechanism since even before my teenage years was to make friends from behind a keyboard and screen, and the internet has made that even more scalable as I’ve grown up. And now, I get to work that way too—HUGE SUCCESS!
6. In my senior year of High School, I won 2nd place in the Ayn Rand Institute’s The Fountainhead essay contest. This was the culmination of having read every scrap of Ayn Rand’s writing I could get my hands on throughout High School. I used the money to take a summer trip to visit a friend who’d moved to Texas and to buy my well used, now dead palmtop PC.
7. I like extremely hot spicy food, insanely hop-saturated beer, Irish whiskey, and fresh locally roasted coffee.

Per Ben Hearsum, I think I’ll make this a leaf node in the meme spanning the Mozillasphere. In a quick 5 minute search, it looks like most blogging Mozillans have already been tagged, and I’m not going to spread the contagion outside the organization. :)

• I’ve been using a lot of tags on Delicious over a relatively long time, so they seem very useful to me.
• Delicious encourages the use of tags through UI convention and tool usage patterns, whereas Flickr presents no particular bias toward collecting tags from users.
• Since title and description attract more contribution effort from users on Flickr than on Delicious, it’s natural that search over those fields will be more productive than for tags.
• Search on Delicious doesn’t have access to the complete text of the bookmarked resource, and often tags will contain information missing from the supplied title or description.
• All told, tags on Delicious are more essential than tags on Flickr.
• In conclusion, I think Do Tags Work? misses the value of tags, as I know them, by focusing on Flickr.

Of course, I don’t really care what this means for folksonomy and the rest of Web 2.0—tags work for me on Delicious. So, I suspect this means I’m not entirely opposed to the sentiment in Do Tags Work?, because I don’t think tags work everywhere their use is attempted.

The rest of this entry elaborates on the above.

From Cathy Marshall’s Do Tags Work?:

Have I convinced you that tags aren’t all they’ve cracked up to be? I hope I have, but nonetheless there’s a lingering fascination. Surely there’s something to be done about tags: we don’t want to just turn up our noses at Mr. Weinberger’s argument.

From Mark Bernstein’s In TEKKA: Tags:

The study could be repeated on more images, and in additional contexts. It might be bad luck. But if it’s a repeatable result — and I think we all know it is — then we’re going to have to rethink a lot of our Web 2.0 rhetoric. Folksonomy is an illusion.

From my bookmark on Delicious:

If you can get past the rambling paragraphs of awkward fun-poking at tags interspersed with library science / web 2.0 / cultural references—as well as a discovery of what, you know, Flickr is all about—there’s a well-embellished and obsessively-assembled statistical analysis of tags vs title vs notes in finding photos featuring tourist heel-spinning on the testicles of a bull mosaic in Milan. My impression is that she’s missed the point of tags, but I’m having trouble reducing the impression to a critique.

It might be that I’m intimidated by the writing in Do Tags Work? or by the fact that a lot of work was done to produce numbers I can’t dispute. Either way, I have neither the time to produce a counter-study nor the wherewithal to extract and refute points in that article with precision. So, I’m just going to throw my impressions out there and hope they coalesce.

• Tags are extremely useful to me.
  • I’ve been using tags on Delicious since shortly after the site was created.
  • To date, I’ve saved 11825 bookmarks and spawned 6069 tags. (More on that ratio later.)
  • Tags have worked very well for me, both in later finding my own saved resources and in finding aggregates of others’.
• Flickr is not the poster child of tagging—Delicious is.
  
  • On Flickr, I’ve found tags occasionally interesting, but not incredibly so. More a curiosity than a killer feature, really. (More on that in a bit, too.)
  • To be honest, I’ve not found a great deal of use for tags around Web 2.0 properties beyond Delicious, folksonomy hype notwithstanding.
  • Fun fact: When I worked on Delicious, we disliked the term “folksonomy” and tried never to use it in serious discussion.
• The places where I’ve found tags useful are text-heavy, where the full text is either not indexed or not displayed in results when using search.
  • Consider magazine articles or blog posts bookmarked on Delicious.
  • Those bookmarks are subject to the character limits of title or description fields.
  • Far more often than on Flickr, there is information in tags not present in a bookmark’s title or description.
• On Delicious, the use of bookmarklets and extensions is the primary source of new bookmarks.
  
  • These tools tend to produce a title based on the original bookmarked page and, when present, a description summarized from the page contents by way of highlighted text.
  • With this in mind, consider that tags often make up the sole intentional contribution made to the bookmark by the person saving it.
    
    • Beyond the choice to save the bookmark in the first place, that is.
  • Whereas on Flickr, the effort is spent on title and, sometimes, the description. Beyond that point, tags are an afterthought, at best.
• The user interface of tagging is near effortless versus, say, formal taxonomies or nested folders.
  
  • Even the much-debated choice of the big, fat space bar as a delimiter supports minimal effort.
  • Minimal effort lowers mental cost, which promotes more noise, but also encourages more input (or any input) and thus more signal overall.
  • People have limited attention span budgets from which useful metadata can be solicited. Tagging lowers the budget requirement.
• The reason why I have generated a ratio of 1 new tag for every 2 bookmarks is that I use tags in a way akin to free association, made possible by the low cost of tagging.
  
  • This is a feature, not a bug.
  • I have many, many tags used only once and never again—some of them are, in fact, jokes.
  • But, I have generated some tags that I’ve come to adopt more heavily, most of which proved surprisingly useful over months or years of recurrence.
  • As for those tags I’ve never used again: They cost nothing, can be hidden below visibility thresholds, and can be merged later into more appropriate tags if I care to do so.

And, there’s where I run out of steam. For the conclusion, go back to the beginning of this entry. Biased though I might be, I think Delicious is the place to study tagging, and there they’re of great use. This is where I think Do Tags Work? misses the value, despite the volume of writing and data.

The Mozilla Tree

Behind Firefox is Mozilla, and behind Mozilla is a community. And the Mozilla community acts a lot like an ecosystem, which can be visualized as a kind of living tree—not to confused with the mozilla-central tree. Oh yeah, and Mozilla is the name of both a Foundation and a Corporation.

Confused yet? If not, then we should talk so you can explain it to me, because it all looks pretty tangly and intertwingled to me. Nonetheless, it seems to work, and produces a good chunk of my favorite software and technologies.

There are many efforts to track what’s going on—including planets and newsletters and bugzillas and wikis and repositories and tinderboxen. Some of these resources report on, or are driven by, the activity occurring in the others. Some are automated, and others are carefully stitched together by hand. None offer a full picture of what’s going on in the Mozilla galaxy in a way that’s casually comprehensible by a sane human being.

Of course, that’s not a slight against any of these sites or the people maintaining them—extracting an overview from such an organic phenomenon is neither easy nor straightforward. But, it might be fun to try.

As an infovore and avid practitioner of continuous partial attention, my first impulse is to reach for a firehose and stick my head into the stream. Relax, defocus, and try to let my pattern recognizers do their thing—sometimes those pattern recognizers are in my head, and sometimes they’re written in Python.

Firefox Victory!

But, for Mozilla, I couldn’t find a stream of sufficient volume or completeness to satisfy me or my robots. Happily, though, my feeding urge found itself aligned with a project to discover the patterns of contribution in the Mozilla community and to find a way to thank the contributors responsible.

So, while we’re still working on the thank-you angle, allow me to introduce you to the Lizardfeeder. The LizardFeeder is a feed aggregator, whose source code is built atop Sam Ruby’s Planet Venus. The LizardFeeder pulls together and archives activity streams from a wide variety of Mozilla community sources. Beyond the usual human-readable pages produced by a blog-gathering Planet, the LizardFeeder accumulates statistical and historical data meant for consumption and analysis by robots.

At present, the only robot navigating the LizardFeeder archives is an AJAX-ified user interface that animates the firehose as a near real-time or time-lapsed stream of events scrolling by.

This is just meant as a conversation starter, though. I’m hoping to gather feedback and find more sources, as well as to entice creative community members to come up with more sophisticated visualizations of this data.

So, take a look, check it out, and let me know what you think!

• Spend time with my lovely wife.
• Eat less, move more.
• Write more.
• Be a valuable contributor at Mozilla.
• Make a few new friends.
• Spend time with friends.
• Paint the front porch.
• Treat the back deck.
• Reseed the lawn.
• Maybe grow a garden.
• Maybe learn Haskell.

Note that most of what’s happened in my life over the past 3 years is missing from that list.

Yes, this promises to be one of those posts I seem to keep writing. It’s not quite LiveJournal material, but it’ll be completely devoid of code or any notable geekery—so feel free to move along.

In late 2005 to early 2006, after a busy and stressful Autoshow season working at Organic, I finished a book on del.icio.us. Meanwhile, the girl and I prepared for a wedding and a honeymoon in San Francisco. Unexpectedly, I got offered a job at Yahoo! a month or so before getting married. We got married on June 9, 2006. We had a honeymoon in San Francisco. Then, less than a month after that, we moved to Santa Clara and I started at Yahoo! working on del.icio.us.

Three months after moving to Santa Clara, I got injured and lived in a Vicodin-fueled haze on the couch for a month or two. I limped around through to Spring 2007, back to work and occasionally trying to make it to geek events like SuperHappyDevHouse. At Yahoo!, we started complete ground-up rewrite work on Delicious 2 with a much expanded team. I went to Hack Day London, but couldn’t say much about Delicious. We continued working on Delicious 2 throughout the Summer of 2007.

My Dad passed away in August of 2007, and we flew back to Michigan to take care of things. From remote, at my Mom’s house in Michigan, I worked a little on Delicious 2. It seemed so close to launch, and I wanted distractions. Then, after a month or so back in CA, I started work on a new JavaScript book. Work on Delicious 2 trudged on. I took on more work for the JavaScript book. We didn’t go out much at all, and weren’t all that happy. The holidays were particularly hard.

Around that point, my wife and I got fed up with our state of affairs in the Bay Area and decided it was time for things to change. Having gotten injured and couch-bound right at the beginning probably didn’t help, but we never quite felt at home in California. I still have a lot of starry-eyed regard for the birthplace of Silicon Valley and all, but for us it’s maybe a better place to visit than to live.

In early 2008, my wife found us a wonderful house in Michigan. Work on Delicious 2 hadn’t yet completed, but I left Yahoo! anyway. I changed jobs twice in one month, finally landing at Mozilla. After 6 weeks or so of working from Mountain View, we left California and moved into our new house back in our home state. Relatives and old friends were suddenly thousands of miles closer, and we got out of the house more in the first 2 weeks than we had in the previous 2 years. Telecommuting for Mozilla presented me with a steep learning curve, but an undeniably great working arrangement.

Finally, more than half a year later, I’m still at Mozilla and they seem to like me there so far. Also, part of my work on the JavaScript book has made it to the shelves in the form of the Concise Guide to Dojo. This past summer, Delicious 2 finally launched—and though I’m sad not to have been there when the finish line was crossed, I still think leaving was the best decision for me and mine. We’ve settled into the new house, and I’ve been gradually trying to leave the hermitage to get into the happenings in the Ann Arbor / Detroit area, of which there seem to be an interestingly growing number.

And, that’s pretty much the past 3 years’ exhausting adventure so far… what’s next?

So what is this new book of mine? Well, besides being a showcase for my lovely author photo (thanks Wrox!), it’s the result of having spent several months’ worth of very early mornings pouring line-by-line over the source code of the Dojo JavaScript framework and making the rounds by assorted community resources—all in an effort to cook up a distilled guide of a little over 250 pages.

I’ve tinkered with various releases of Dojo over the years—so I didn’t just drop into this cold. However, this book project represents an intensive push to really wrap my head around the latest releases and share the process on paper. As such, this isn’t a book of case studies or in-depth projects. Instead, you should be able to flip to any section and drop straight into succinct explanations and demonstrations of the various utilities and facilities offered by the Dojo framework. You’ll find all of the usual bits and bobs offered by modern JavaScript frameworks, but I’m hoping I’ve been able to surface a few of the more unique advantages offered by Dojo.

Essentially, this book is a better written, professionally edited version of the sort of reference notebook I assemble for myself whenever my serial enthusiasm strikes and I go headlong into a new technology. Usually these end up in a private laptop wiki or text file, occasionally as a blog post, but this one got turned into a book. I’m prone to embarrassment about the condition of the former, but hopefully you’ll find that the extra effort put into the latter by myself and my editors make it worth the “Programmer to Programmer” sentiment behind the Wrox imprint.

At any rate, go order a copy for yourself. Hell, order another few for (belated) stocking-stuffers. Then, stop by the book forum hosted by Wrox and let me know what you think.

See, I had a notion it would be keen if I had access to the same template language on the client as on the server. I needed to render a number of list items statically on the server with feed entries, then update that list with new entries on the client as they became available through JSON feed polling. It’d be a pain in the butt to maintain two separate list item templates for client and server, so I reached for a shared template language.

Never mind that I’d just gotten done writing a small book on Dojo, and was already aware of the existence of the DojoX Django Template Language. This might’ve worked, since the server end of things was written in Python (though not with Django). That the JavaScript side already used jQuery wasn’t too tall a hurdle. Also, I’m sure there are a handful of other JavaScript/Python template language match-ups to be found.

But, let’s be honest here: I’ve always been a fan of Zope’s Template Attribute Language for their Page Templates, and have long wondered how hard it would be to implement. The concept seems so much cleaner to me than most string-formatting template languages, and the workflow from mockup-to-template and back again has always been appealing to me when it works. So, when my first few experimental steps in trying my hand at it actually started working, I couldn’t stop coding.

And now, the thing is mostly done. It has no tests, has features left undone, and probably yields plenty of bugs—but I finished it enough to use it practically, and that was long enough to convince me it wasn’t the right tool for the job.

Still, though, I can’t help thinking it might be the right tool for some job. That could be because I spent a lot of time on it, or that I’m unreasonably fond of TAL, but it still feels like a decent little plugin to have on hand. Maybe someone reading this will have a similar conclusion.

Oh and by the way, plain jQuery turned out to be a better tool for the job in question. This seems to nicely balance the duplicate effort between server and client, demanding only that I stick with semantically significant CSS class names in the server template—something I should be doing anyway:

        // Clone and populate a new entry.
        var new_item = $('#feed-items .entry:last')
            .clone()
            .attr('class', entry_classes.join(' ')) 
            .find('.group span')
                .text(tags['group'])
            .end()
            .find('.title')
                .find('.favicon')
                    .attr('src', favicon)
                .end()
                .find('.link')
                    .attr('href', entry.link)
                    .text(entry.title)
                .end()
            .end()
            .find('.updated')
                .find('.timeago')
                    .attr('title', entry.updated)
                    .text(entry_updated.strftime('%+'))
                    .timeago()
                .end()
                .find('.time')
                    .text(entry_updated.strftime('%I:%M %p'))
                .end()
            .end()
            .find('.author')
                .text(entry.author || 'n/a')
            .end()
            .prependTo('#feed-items')
            .hide();

Of course, plain is a relative term here.

When chemists consult a volume about professional chemical technique, or when surgeons reach for the latest update on neuroanatomy, they can usually find a book that isn’t couched in terms of silly examples and jokes. So can poets, mathematicians, and geologists. For some reason, though, it has become the accepted practice that language manuals should spend lots of time with silly, self-deprecating jokes, and that their example applications should be breakfast loggers and fantasy football leagues (or, conversely, payroll programs).

As an tech author with just a few books under my belt, Mark’s take on Practical Prototype and script.aculo.us struck a bit of a sour note for me, because I’d like to work on making my tech writing more entertaining than not. I think that’s a good thing, but I’m willing to be convinced otherwise.

I think the issue is that there are different meanings for “professional” when it comes to the web. There are web scientists and there are web masons. Web scientists pursue fundamentals and disambiguations, while web masons are busy building the next micro-site for the new product release from the almighty client. Many web scientists are also computer scientists and many web masons are also web scientists—but most web masons I’ve known come from creative liberal or fine arts backgrounds.

Though, for what it’s worth, even amongst computer scientists there’s still a tradition of leaving room for jelly stains and other oddities. This seems to be the sort of thing Mark acknowledges with dismay. (“It’s not fair to blame Mr. DuPont for the general vice.”)

Is playfulness in literature just a computer science thing? I’m not a chemist; maybe chemists just don’t like being funny in writing, or maybe their jokes are more subtle.

In any case, I think the “practical” genre of tech books is aimed at people who want to get something done, aren’t interested in or have little time for context or background, yet wouldn’t mind being entertained during the course of weekend tinkering and self-education.

So, a good book. But take out the jokes, trim back the sample code (or dispatch it to the Web site where it makes more sense), and give us to professional perspective, and everyone is going to be much happier.

The guidelines with which I’m familiar for tech books in the “practical” or similar genres include advice such as “show, don’t tell”. They also suggest that, although sample code should be made available online, the author should compose the book assuming that it’s a standalone product. Web sites and CDROMs with code often vanish, but a bound book remains stable—which is especially useful on a cross-country flight without net access. Professional perspective is of course a desirable thing to work into the prose, but job #1 is to illustrate the right way to do things through running code.

How does Prototype+Javascript relate to other languages — C++/STL, say, or SELF? What, precisely, are the semantics of the key methods? I don’t need the inevitable chapter 1 pitch for the wonderfulness of Javascript and the badness of MSIE, but it might be a good place for a quick summary for the pros. Call by reference • no pointers • primitives are objects • everything has a prototype slot • parens() do this, braces {} do that, brackets [] do something else • single and double quotes are different. Kernighan & Ritchie did this so well in C, and it’s not like we’re not familiar with their example.

I’d posit that most in the audience for “practical” tech books are entirely unfamiliar with Kernigan & Ritchie and haven’t touched a line of C source code. Most of these readers have probably tumbled down the slope from HTML to CSS and finally to JavaScript in order to get something interesting to happen in a browser—and usually while under an unreasonable deadline.

I’d really be surprised if many readers have heard of Self or C++/STL or have much of a grounding at all in computer science or programming language fundamentals. Having these fundamentals would of course help web masons get a deeper understanding of the technologies that make the job possible, but the pragmatic rewards tend not to make up for the effort involved.

So, to sum up, the purpose for this entry isn’t to beat up on Mark Bernstein. He’s written a great deal of prose and code that I respect, so his opinion is interesting to me. Rather, I’ve tried to express my own understanding of this writing market, and hoping I’ve aimed at the right goals.

…the core idea that should be upheld by companies like Apple should be about making things better and less often. Making things that will be able to evolve, be upgraded, be adaptable, hackable and more fun to use for longer so that as a customer I don’t think that I’m buying version 3.4 of something that will only be as good as it’s last press release. I want to buy “the” quintessential Apple product and cherish it for years, like people would cherish a vintage car.

From De-Scribed: The upgrade treadmill is wearing us out:

Replace “quintessential Apple product” with pretty much “any product” (use your imagination) and you start to get at a shift in both attitude and culture that would solve a lot of problems. Get off the upgrade treadmill. There are already too many others.

When’s the last time you upgraded your watch to one with a more reliable chronometer? Bought a new pen with a better ink formulation or superior delivery mechanism? You may, of course, be an exception—but there are a lot of other personal artifacts that have reached similar plateaus for most, where the classic vintage version is every bit as useful as the modern iteration.

I keep wondering when personal computers will hit a flat spot in Moore’s Law. Or, failing that, when the capabilities and usability of such a machine meet and surpass any reasonable owner’s practical demands to the point where fashion and style become the selling features. I think we’re almost there—actually, we’re probably there now for most people who aren’t me.

Beyond the constantly growing demands of gaming, it seems like most personal computers now can do most of what anyone wants them to do. Even for me, this last-gen MacBook Pro feels like the best computer I’ve owned to date, and strangely enough I’m hesitant to think about upgrades for awhile this time. I like the product design, performance is very good, and I’ve got the memory maxed out to the point where I can run several copies of Windows in Parallels—which, itself, I think is a very weird requirement, yet still satisfied by this machine.

Storage media can hold amazing amounts of personal photos and video, and will reach near-incomprehensible levels pretty soon. Screen resolution is just about at a point where most people don’t care if it gets better, and the same goes for sound. Barring any sort of Moore’s Law for finding new uses for personal computers that require significantly more power, demands for functionality will likely be completely met by even the lowest end laptop soon.

So, how long until the first new personal computer arrives that turns out to be the old beater I still use 15 years from now, or sell to a kid down the block who just got his web learner’s permit?

I’ve updated my UbiquityCommands page and checked in my latest revision of the Delicious command.

The main new feature is a status bar item reporting bookmarks for the current page:

As you can see above, the command now comes with a status bar panel powered by the Delicious URL info JSON feed, providing bookmarking info on every page visited. It shows a bookmark count, a tooltip with further information, and sends the user to the URL info page on Delicious when clicked. It mostly works, but it could use some looking at. This is my first time really cracking open the hood on Firefox and XUL, and so I’m feeling around in the dark.

Specifically, I’m using Ubiquity’s page load hook—but I’m also trying to augment that by tracking tab selection events, in order to keep the status bar info updated for the active tab. But then, that leads me to trying to track new windows, to attach the tab selection event handler for every newly opened window. Or I could just be barking up the wrong tree entirely. At any rate, the code is probably brain-dead dumb, so I hope someone can clue me into a better way.