John Resig and what we can learn about Useful Blogging

John Resig is an inspiration. His blog is ultra-useful. It's clear, informative, and often cutting edge in the JavaScript/jQuery/browser space. His posts are often accompanied by helpful graphs and, more often than not, usable code and workarounds. I have been a fan of jQuery since I started using it this summer, and have continued to be impressed with it's creator's output. Even when he posts an opinion piece, it is on topic and respectful. The important question arises: what makes his blog so useful and how can we emulate it?

Consider a recent post about the accuracy of JavaScript timing. Now, an ordinary blogger would have posted something like "I ran across some odd results in my Dromaeo testing. Anybody know wassup?" But John went deeper, did a lot of testing, graphed the results, and posted what he found. Heck, he even included a graphic explaining normal distributions. (Basically, JavaScript timing in Windows/IE is very coarse - results are rounded to the nearest 15ms.)

By comparison my own blog is a bit of a ramble. It's true that I'm not so single-mindedly interested in browser programming. My programming interests run the gamut from scalable software architectures, front-end architectures, programmer productivity, prototyping, web design, and data design. And of course there's a sizable amount of personal items in this blog stream. But even so I daresay the overall quality of the blog has much room to improve.

I would like to create a new blog that is more like John's - focusing purely on my core technical interests, designed to be useful and educational, rather than just an invitation to discuss. It needs a new, simpler URL - like javajosh.com/blog. Since I only have about 30 (valued) readers a month I don't think the transition would be too bad. And I can always continue to post personal and "off topic" things to this blog. (An important question is what to do with on topic posts to the old blog, but I can tackle that one later.)

A demo of jMaki: yet another unnecessary abstraction

Doris Chen posted an screencast of jMaki in use (with Netbeans and Glassfish). It's unnecessary because a) jMaki isn't a good idea, b) the tooling looks cumbersome, and c) the end result looked really bad.

jMaki isn't a good idea because it's a taglib that tries to normalize the use of many javascript libraries by abstracting over them. In principle it reminds me of Apache's commons logging api, which is designed to abstract away the differences between Sun's logging API and log4j. This pattern of bad idea pervades the Java platform, unfortunately. Successful projects use succesful implementations, not just APIs. It's important to know Tomcat, not just the servlet APIs, and it's important to know log4j, not the commons API. And it's important to know jQuery and it's UI plugins, not jMaki. To do real work you're going to have to know the underlying JavaScript library anyway, so why bother with an abstraction that will just get in the way?

The Netbeans tooling looks rather cumbersome. I've been (re)reading Donald Norman's "The Design of Everyday Things" and was struck with how unruly Netbeans looked in the screancast. It's all the little things Doris has to do - find an obscure menu item to check that a plugin is installed, center the dialog box on her screen, search through a list of completely unrelated plugins to enable the one she wants, etc. Or when she drags a widget into the JSP and has to right-click and "format" the badly formatted text every time. Since when does dragging stuff create text? And why can't it format itself?

The final blow was that the end result looked (and sounded) like crap. The fish eye widget was layed out wrong, and the google map was too large and also layed out wrong. Putting sound in the page was just a bad idea - that's like adding blinking text. (Just because you can doesn't mean you should!)

Apologists would say (at least) that I'm nitpicking. At least the tools worked; and none of those things I mention are show stoppers, and any programmer who can't deal with a few tool quirks doesn't deserve his salary. And as for the end result looking bad, this was a programmer's demo, not a designer demo - it can all be fixed with some CSS edits later, done by a web designer.

My response is this: the tools work, but encourage errors. They encourage small errors of setup and use. But they encourage a much larger error: the tooling's "map" of the system is not that of the programmer's (or at least not this programmers). I fail to see what a JavaScript abstraction has to do with SVN, and yet these things are presented together in a dialog. I fail to see how a collection of text is a "widget" or why dragging would create text. And yes, I fail to see why I need a JavaScript abstraction in the first place that appears to do little more than substantially increase the complexity of my system.

I feel that IDE's are little more than glorified text-editors, and begin to fail when they themselves introduce abstractions. In a subtle way, the tooling begins to dictate the programmer's mental model of the design- and runtime of his system. In this case, it's nice that Netbeans can easily add a taglib to your web project. But it's not nice that this capability is expressed as a "plugin". It should be expressed as a macro or script: a macro that adds a jar or two there, a line of code to web.xml there, and adds some new JSP specific snippets (particularly taglib declaration and taglib instances). It may even remind you that you'll have to redeploy to get the effect. One concrete difference between a plugin and a script abstraction is that the Netbeans plugin method requires that you select the "plugin" on project creation.

The end result should look good because this kind of programming is all about the front-end. Widget positioning and sizing is not a trivial problem to be swept under the rug! Either jMaki or Netbeans needs to take better care to provide better defaults. And too, programmers are (hopefully) wary of these "slap it together" demos - everyone knows (or should know) that slapping stuff together is the easiest part of programming. It's fitting it all together professionally and solidly which takes time, effort and skill.

Illustrator Ninja

Here is 40 hours of illustration condensed into 7 minutes by the remarkable Chad Pugh:

iPhone Invisible Shield Review

I scratched the screen of my iPhone a bit on my keys, and resolved to get a screen protector. I purchased the Invisible Shield from amazon.com for about $12. I followed the directions closely, and almost immediately noticed a reddish discoloration, and some subtle mottling - not bubbles but subtle irregularities in texture. I also noticed that the touch sensitivity of the screen was reduced. On two occasions keys that I did not intend to press were pressed and held - and it was the backspace key (which resulted in the loss of two fairly long text messages). Last night I removed the Invisible Shield. The difference was remarkable - my iPhone screen was brighter than it had been in 3 months, and the touch screen deliciously responsive. It was like getting a new iPhone.

I estimate that the cost to produce what is essentially a sticker has got to be very small - less than $1, which makes the asking price of $12 very high. (products of this nature are generally marked up by a factor of 5 or 6 - 12 is very high).

Given all of this, I cannot recommend the Invisible Shield. Given the pace of technological progress, it is better to endure the occasional scratch and eventually replace the device, especially if the usability of the device is reduced by that protection. I think that my iPhone's screen can last 4-5 years if I can manage to avoid putting my keys in the same pocket as the phone!

This is a photo of the removed Invisible Shield, clearly showing the reddish discoloration. Frankly, against the white napkin it looks much more dramatic than on an iPhone.