The Wayback Machine - https://web.archive.org/web/20090101023947/http://decafbad.com:80/blog/

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 (3)

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)

The more things change…

September 2, 2008 – 12:46 am

So, in anticipation of hopefully carving out time to write more article-length entries like my last one on Ubiquity, I’ve revamped the design on this blog and updated the colophon. I’m also hoping to post more short entries as well, and get this place revived again in general. Let me know what you think about the new look!

By l.m.orchard | Posted in asides | Tagged , | Comments (3)

Writing a Delicious command for Ubiquity

September 1, 2008 – 12:37 am

In my last post, I got all fluffy about how cool Ubiquity is but didn’t share any code to prove the point. As it happens, I have come up with at least one useful command that I’m starting to use habitually in posting bookmarks to Delicious. You can subscribe to my command or check out the full source—this post will serve as a dissection of the thing. Since this will be fairly lengthy, follow along after the jump.

Oh, and it’s been awhile since I posted something this in-depth around here, so feel free to let me know how this first draft works. And, bug reports and patches are of course welcome.

Read More »

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

Ubiquity cracks open personal mashup tinkering

August 31, 2008 – 12:07 am

When I was a wee hacker, I lived my digital life though a Commodore 64. I played games on it, did homework, talked to people far away—you know, all the stuff they showed in the pictures on the box. I also took things apart—both the machine itself and software running on it. I grew up learning that my digital environment was ultimately understandable, susceptible to tinkering, and open to being bent to my own purposes.

From the Commodore 64, I graduated eventually to terminals and text editors, opening portals mostly onto computers elsewhere via powerful UNIX command shells. And, of course, over the past decade, this has largely given way to life in a browser.

Yet, for a little while, particularly in the first few years of browsers, freedom to tinker seemed cramped. JavaScript had yet to arrive, and was a little messy when it did. There was no relatively easy addon development. And, though the portals opened by a browser were richer than those provided by terminals, the paths of navigation defined by links controlled by site owners offered less freedom of movement than UNIX commands. I could create my own pages, but I couldn’t do much to others’ pages.

But then, javascript: URLs came around, dots were connected, and bookmarklets were born. Suddenly, it was possible to customize my browsing environment with arbitrary JavaScript code having access to the current page—no matter whose page it was. And, through the various tricks of the AJAX trade, bookmarklets have only gotten more capable throughout the years.

Smart keyword shortcuts came around a little later, allowing quick access to bookmarks via simple keywords typed into the location bar. The smart part, though, came in the form of bookmarked URLs with placeholders and keywords given arguments to fill the placeholders—allowing not only quick access to bookmarked pages but also search engine forms bookmarked with late-bound fields.

Bookmarklets inherited the benefits of smart keyword shortcuts. The same placeholder in http: URLs can be inserted into the code of a javascript: URL, thus parameterizing the JavaScript code and incidentally turning the location bar into a kind of primitive command line. For example, one of my most heavily used “addresslets” is based on John Resig’s original “Super-Fast Delicious Bookmarklet”.

Another leap in prying open the browser tinkering space came in the form of Greasemonkey—an addon-powered environment created explicitly for the purpose of end-user scripting applied to others’ pages. Greasemonkey user scripts can do more than bookmarklets, and with a much better development environment to boot. And, though a user script can’t do quite as much as a proper browser addon, they’re much easier to hack on and distribute.

Now, consider one of Mozilla Labs‘ newest projects, named Ubiquity. This rough and experimental addon for Firefox combines and improves upon everything I’ve described so far:

  • Ubiquity is a hackable command line environment, better than bookmarklets and smart keyword shortcuts;
  • Ubiquity enables persistent customization of others’ pages, not unlike Greasemonkey;
  • Ubiquity facilitates live in-browser creation and web-based subscription to user commands and scripts;
  • Ubiquity gives access to browser chrome resources without a need for frequent restarts;

So far, most of the commands I see popping up since the 0.1 release have not accomplished much more than smart keyword shortcuts in the location bar could. But, it’s early yet, and Ubiquity is far from limited to these commands.

Once the basics have been well-explored, I expect to see more people taking a crack at the broader capabilities offered by Ubiquity. Bookmarklets and Greasemonkey can’t access browser chrome—but Ubiquity can. Ubiquity also offers a user interface that’s so much more promising than keyword shortcuts, including command previews and typed parameters with suggestions.

Ubiquity promises web-wide mashups directed by a conversational command interface. All in all, the potential of this makes me feel like my digital environment—browser and web as a whole—is getting even more intimately, personally hackable.

It’ll be very interesting to see where this project goes.

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