The video of my DSLs in JavaScript talk [slides - pdf] from QCon is now available on the InfoQ site; many thanks to all those who have written me or tweeted links, I appreciate it! I can’t say enough good things about QCon, it’s a great show with some amazing talks – if you have a chance to go, you really should. But, if getting to London or San Francisco (two of my absolutely favorite cities) isn’t on the radar screen, the next best thing is watching the fantastic videos you’ll find posted regularly on InfoQ. Enjoy!

Where would rather be this December, adjusting to winter or spending a few days in Orlando learning about what’s new and exciting in JavaScript, Ajax, CSS, HTML, design and a host of other topics? If the later appeals to you, book your seat today at The Rich Web Experience! In addition to some great talks by some of the best speakers in the industry, you’ll also have access to the JSF Summit. I think Neal Ford has been listening in on some of my Ajax talks – I call it a seasoning, he calls it a spice, but either way, the user experience is a key to making great applications. See you in Orlando!

Over on JavaWorld, you can see my latest article: Ajax: Tools of the trade. If it’s been a while since you looked at client side development and you still think alerts are the end all be all of web debugging, you might want to give it a read. Here’s the official summary:

Where JavaScript developers were once tool-deprived, today we’re often overwhelmed with the abundance of options. In this article, Foundations of Ajax author Nathaniel T. Schutta reviews development environments, debuggers, testing tools, and utilities that elevate JavaScript to first-class status in the Web development world. If you’re still programming JavaScript in a text editor, this survey of the modern tools landscape should open your eyes — and could make your life much easier.

If you like the article, you might also want to listen to the podcast of Andy Glover and I chatting about Ajax, JavaScript, testing and more. Enjoy!

At QCon, Glenn Vanderburg, Michael Feathers and I (there may have been others, as I recall some ESB was involved…) were talking about Mike’s 10 Papers Every Programmer Should Read post (if you haven’t read it, please do so now, I’ll wait. No really, go on.) A lot of programmers aren’t particularly well read, a fact that Mike laments, and we kicked around some theories as to why that is – here’s mine.

Why don’t we look at our past? I believe it has to do with the natural (10 year or so) cycle of language dominance. People who’ve never programmed in language n-1 look at the syntax in a book from, say the early 90s and scoff; they complain that they don’t know that language thus they can’t read the book. I’ve heard more than a few developers dismiss Design Patterns because the code wasn’t in Java, of course Java is starting to wane – a couple of days ago I was researching a book and noticed it had a bunch of negative reviews because the example code was Java!

Many developers are essentially Blub programmers and they can’t imagine life in any other language. Further, they firmly believe that anything that existed before Blub is the modern day equivalent of the Pony Express, antiquated and useless. To some, all the good ideas are new, and we have nothing to learn by studying our past, I suspect many of these people have never seen the mother of all demos (though maybe we have something new to rival that now.) A typical Blub programmer assumes that any book that doesn’t use Blub isn’t worth his time and thus misses out on a wealth of learning. They almost willfully ignore the past which explains some of the reactions to Mike’s post.

I’ve been doing my best to read my way through 10 papers and this afternoon I came to Kent Beck and Ward Cunningham’s A Laboratory For Teaching
Object-Oriented Thinking. Now, many people assume the whole agile software thing is just a few years old but here we see waaaaaaay back in 1989, a reference to YAGNI and a plug for teamwork:

We stress the importance of creating objects not to meet mythical future needs, but only under the demands of the moment. This ensures that a design contains only as much information as the designer has directly experienced, and avoids premature complexity. Working in teams helps here because a concerned designer can influence team members by suggesting scenarios aimed specifically at suspected weaknesses or omissions.

Great ideas then, a great ideas now. We’re a young industry, one that is further hamstrung by the belief that the language/technology/process du jour is all that plus a bag of chips. We’ve obviously made some huge strides, but in so many ways we’ve barely moved. But for the video quality, Engelbart’s demo could have just as easily been from 1988 or even 1998; sure, we’ve all got a mouse on our desk, but what about that 5 fingered keyboard? Not so much. Heck, every language is just trying to reinvent Lisp, and that’s more than 50 years old! Don’t be afraid of the past, those old guys knew a thing or two. We only hurt ourselves by ignoring the lessons they have to teach us.

As Neal Ford explains, the NFJS Anthology series has been reborn as a monthly magazine and in the current edition, you can read my take on test infecting legacy organizations. I’ve been a proponent of the testing meme for most of my career but I’ve also spent much of that time convincing reluctant coworkers (and managers) that testing was in their best interest – the article takes my talk of the same name and puts it to paper. All NFJS attendees get a complimentary copy of of NFJS, the Magazine, but anyone is free to subscribe. Each month you’ll get an eclectic mix of articles written by NFJS speakers on topics they are passionate about; if you’d like to see a sample article, check out Jared Richardson‘s A Case for Continuous Integration [PDF]. Enjoy!