I (used to) like rev=”canonical”

Update 4/14: So, I liked rev="canonical", but I like the notion of pages offering sets of alternative URLs better. There are enough cracks in the case for rev="canonical" to stop caring about it and instead focus on the notion behind it. However it’s expressed—is it rel="shortlink" now?—the final remaining things I’d like to see are:

  • 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…

Read More »

7 facts about me

So, it finally happened—I’ve been tagged by Stephen Donner. I’ve not been one to follow memes in this blog, but this one’s been going around the Mozillasphere for awhile now and has been kind of interesting. I’m half-tempted to bookmark and tag all the entries I’ve caught so far. Anyway, the rules:

  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:

Read More »

Tags do work (for me, at least)

For the “too long; didn’t read” crowd:

  • 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.

Read More »

Enter the LizardFeeder

The Mozilla Tree

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 Robot

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!

Resolutions

So, after all that, I suppose the thing to do for a new year is to figure out what’s next, maybe compose some disposable resolutions for the coming months. Well, here are some off the top of my head:

  • 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.

Three Years in Review

It’s been a busy 3 years or so.

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?

The Concise Guide to Dojo is a real book!

This year has been a doozy. A full account of it would fill a book, so it’s telling that I’ve neglected to raise much of a fuss about the fact that I actually have been working on a new book. Not only that, but part of that book has been spun off into yet another book of its own:

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.

An unnecessary Template Attribute Language

A funny thing happened on the way to building a delayed real-time feed display: I got temporarily obsessed with implementing a template language in JavaScript that, as it turned out later, I didn’t need. About the feed project itself, I hope to write more soon—but for now I want to get this extra template language thing out of my system and see if anyone else might have a use for it.

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.