So, this is some serious Web 2.0 action: Instructables user zachninme (and ex-intern) wanted to have a rating system for comments on the site (so far, we only allow users to rate the instructables themselves.) He built a Greasemonkey script that any Firefox user can install; this injects a rating interface into all the comments whenever that user visits Instructables. Then, he wrote a backend using the new Google App Engine that collects all of the ratings, aggregates them, and pushes the show/hide logic back to the user’s Firefox client.

Voila: instant community/social feature, completely disintermediated from our site. The web being what it is, nowadays, he doesn’t have to run a server or get permission from us. Innovation accelerates…

Here’s a link to his announcement.

Having not read the session description ahead of time, I was expecting this to be all about browser hacking in the narrow sense: specific tricks, workarounds, and hacks. Instead, it was a much more interesting talk about why this approach to feature development is vital to the web itself.

We are in the midst of an incredible acceleration in the variety of technologies vying to serve as our interface to the cloud. Dillard did a great job characterizing the forces at play (standard vs proprietary, open vs. closed.) He then explained the complicated role that technical hacks play in this ecosystem, since they can both allow developers to adopt standards before browsers support them, and at the same time push the standards themselves (treading dangerously in the territory of proprietary feature sets.)

His advice to developers boiled down to this: Don’t wait for standards, but hack as dangerously close as you can to the bleeding edge of where you think the open web is headed. The most valuable hacks are the ones that bring future standards to today’s (and yesterday’s) browsers.

Do Try This at Home: Ajax Bookmarking, Cross-site Scripting, and Other Web 2.0 Browser Hacks
Development, room 2003, Friday 3:50 PM
Brian Dillard (Pathfinder Associates)

My rough notes are after the jump.

Read the rest of this entry »

This was the one-year follow-up after Steve Souders did his first presentation (at last year’s Web 2.0) on optimizing the performance of frontends. He’s done some amazing work collecting best practices, including a whole decision tree on the best methods to inject script into a page, based on browsers, the need to access scripts cross-domain, etc.

As far as immediate applicability to my work at Instructables, this was by far the most interesting talk of the conference for me. Rough notes after the jump.

Even Faster Web Sites
Focus on Web Operations, room 2002, Friday 1:30 PM
Steve Souders (Google)

Here’s a link to the slides. As a preview, below is the money shot: a full decision tree for how and when to use any one of six different methods for dynamic script inclusion:

In addition, I had a very interesting conversation with badass engineer/analyst Artur Bergman who has suggested some ninja moves to get us past the the external script loading problems that we’re having at Instructables. I’d previously been stumped, so this may be something of a coup.

Read the rest of this entry »

This was a great talk by Gregg Pollack, who’s a big Ruby on Rails evangelist. Here, he makes his case for TDD (Test-Driven Development) in general, and a new form of it called BDD (Behavior-Driven Development) which he hearts. The live-coding was fun (it always seems fun, with Rails) but it made for some very bad note-taking. Fortunately, I found a video online with similar content, so you can watch for yourself.

This doesn’t have immediate application at Instructables, though I’ll be looking into BDD and TDD systems that have been developed for frontend code. Rough notes and links after the jump.

The Art of Testing Web Applications
Thurs 2:40 PM, Development 2003
Gregg Pollack (Rails Envy)

Read the rest of this entry »

This was a session by Matt Jones (Dopplr) and Tom Coates (Yahoo! Brickhouse / fire eagle) on the past, present, and future of “data portability” and other ways in which users experience and give access to their personal data. They discussed a lot of interesting design patterns that are fundamental to our current phase of innovation. These are interactions and metaphors that don’t always come to mind when people think of the superficial aspects of Web 2.0. Rough notes after the jump.

Polite, Pertinent, and… Pretty: Designing for the New-wave of Personal Informatics
Design and User Experience 2006 Wed 9:40 AM
Matt Jones (Dopplr), Tom Coates (Yahoo! Brickhouse / fire eagle)

Read the rest of this entry »

This was a session by Alex Payne (Twitter) and Michal Migurski (Stamen Design, who did the Digg Labs apps) on their experiences designing, implementing, and scaling APIs. My rough notes are after the jump.

Design Your API: Learnings from Twitter and Stamen
Development, room 2003, Wed 2:40 PM
Alex Payne (Twitter), Michal Migurski (Stamen Design)

Read the rest of this entry »

I’m hanging out at the web2.0 conference, this week, checking out occasional sessions and schmoozing. Instructables is doing free laser etching on the conference floor for your laptop/phone/genitalia.

I’m also doing a web2Open (the un-conference running parallel to the main one) session tomorrow afternoon at 12:50PM called “Coding Lazy.” It will be all about how Instructables uses tags to model Javascript dependencies in the client, and how that allows us to code at full speed while procrastinating on proper factoring and optimization for as long as possible. Stop by if you’re interested!

Here’s the Web2Open schedule. And here’s how to get a free pass.

Dust-Me Selectors looks like the killer app for clearing out CSS that your site doesn’t need. We’re using it to quickly cut down the CSS mess on Instructables.

Dust-Me Selectors is a Firefox extension (for v1.5 or later) that finds unused CSS selectors.

It extracts all the selectors from all the stylesheets on the page you’re viewing, then analyzes that page to see which of those selectors are not used. The data is then stored so that when testing subsequent pages, selectors can be crossed off the list as they’re encountered.

You can test pages individually, or spider an entire site, and you’ll end up with a profile of which selectors are not used anywhere.

Larry Wall offers some sage words on the nature of scripting languages, including what they are, the history of various languages, and how they’re likely to evolve in the future. Here’s a nugget:

The Present

When I look at the present situation, what I see is the various scripting communities behaving a lot like neighboring tribes in the jungle, sometimes trading, sometimes warring, but by and large just keeping out of each other’s way in complacent isolation.

I tend to take an anthropological view of these things. Many of you here are Perl programmers, but some of you come from other programming tribes. And depending on your tribal history, you might think of a string as a pointer to a byte array if you’re a C programmer, or as a list if you’re a functional programmer, or as an object if you’re a Java programmer. I view a string as a Text, with a capital T.

Text

I read that word from a postmodern perspective. Of course, the term Postmodern is itself context-sensitive. Some folks think Postmodernism means little more than the Empowerment of the Vulgar. Some folks think the same about Perl.

But I take Postmodernism to mean that a Text, whether spoken or written, is an act of communication requiring intelligence on both ends, and sometimes in the middle too. I don’t want to talk to a stupid computer language. I want my computer language to understand the strings I type.

Perl is a postmodern language, and a lot of conservative folks feel like Postmodernism is a rather liberal notion. So it’s rather ironic that my views on Postmodernism were primarily informed by studying linguistics and translation as taught by missionaries, specifically, the Wycliffe Bible Translators. One of the things they hammered home is that there’s really no such thing as a primitive human language. By which they mean essentially that all human languages are Turing complete.

When you go out to so-called primitive tribes and analyze their languages, you find that structurally they’re just about as complex as any other human language. Basically, you can say pretty much anything in any human language, if you work at it long enough. Human languages are Turing complete, as it were.

Human languages therefore differ not so much in what you can say but in what you must say. In English, you are forced to differentiate singular from plural. In Japanese, you don’t have to distinguish singular from plural, but you do have to pick a specific level of politeness, taking into account not only your degree of respect for the person you’re talking to, but also your degree of respect for the person or thing you’re talking about.

So languages differ in what you’re forced to say. Obviously, if your language forces you to say something, you can’t be concise in that particular dimension using your language. Which brings us back to scripting.

How many ways are there for different scripting languages to be concise?

How many recipes for borscht are there in Russia?

Wall goes on to describe a dozen or so “dimensions” in which scripting languages can vary in their expressiveness/conciseness. I found this to be the most interesting part.

I came across this piece on the Daring Fireball blog.

I almost forgot about this, which is strange because I wrote it all the way back in August, 2007 and use it on a daily basis. JSLoad is a clever bit of plumbing that powers all of the user interface over at Instructables. We’ve released it under an open-souce license (LGPL.) A lot of non-coder friends read my blog, so the coolness of it may not be apparent. Suffice it to say that I’m proud of it, despite its rough edges. I’m also hoping that it will be useful to others.

For the geeks, JSLoad is a script loader and dependency manager:

The real usefulness of JSLoad comes with its ability to group dependencies using tags. Tags are arbitrary labels that you can apply to (i.e. make dependent on) any group of files or other tags. Tags can be applied to single files or multiple files. Multiple tags can be applied to a single file. You can even think of your tags as depending upon a portion of a file (say, class within a file containing several classes.)

As a result, you can mimic most other dependency structures: Chains, trees, or more complicated graphs. You can tag things that often appear together, that share a certain aspect; whatever your usage calls for. At Instructables, for example, we generally have a base set of widgets and features whose dependencies are primarily tree-like. Those little bits are then collected into larger groupings like “editable” or “commentable”; abstract labels that approximate the kinds of interfaces that are common on our site.

Tags are also very useful while refactoring code. Often, because of the flexibility of Javascript, you won’t be sure of the best way to split your code across files. Which portions will be used together most often, and should thus be grouped together to reduce HTTP requests? With JSLoad, you can tag the variant groupings, then organize your code as you wish. Your web pages will just call JSLoad the tags as they need them. Over time, you may find that one tag is used much more often than the others. Using JSLoad, you can refactor your code into a more efficient file structure, without changing any of the script calls in the pages that use the code.

Click through to the official page to read more or to download the code for yourself. You can also preview it on the test page to see it in action.