Enter the LizardFeeder

January 5, 2009 – 7:01 pm

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!

By l.m.orchard | Posted in entries | Tagged , , , , , , | Comments (5)

Resolutions

January 5, 2009 – 2:10 pm

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.

By l.m.orchard | Posted in entries | Comments (2)

Three Years in Review

January 5, 2009 – 2:09 pm

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?

By l.m.orchard | Posted in entries | Comments (3)

The Concise Guide to Dojo is a real book!

December 19, 2008 – 10:35 pm

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.

By l.m.orchard | Posted in entries | Comments (4)

An unnecessary Template Attribute Language

November 1, 2008 – 3:23 pm

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.

By l.m.orchard | Posted in entries | Tagged , , , , , , , | Comments (2)

Jelly Stains and Web Masons

October 29, 2008 – 10:42 am

From Mark Bernstein’s entry on Practical Prototype and script.aculo.us:

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.

By l.m.orchard | Posted in entries | Tagged , , , , , , | Comments (7)

Upgrades versus Antiques

October 19, 2008 – 12:07 pm

From Greenmonk: The Blog - Cherish The AIR? Just because you can doesn’t mean you should:

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

By l.m.orchard | Posted in entries | Tagged , , , , , | Comments (6)

Improving my Delicious command for Ubiquity

September 7, 2008 – 1:20 am

After writing up my first stab at a Delicious command for Ubiquity, I planned to continue revising it based on feedback and to work on exploring more of what Ubiquity enables. I started looking into writing my own nouns for tag suggestions, as well as playing with page load and browser startup hooks. And, I also started poking at a little bit of deeper extension development, which took up most of my time today.

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.

By l.m.orchard | Posted in entries | Tagged , , , , | Comments (13)