waffle

Klein Rants: “One thing I want to do is keep the ‘Labels’ of the new Blogger Beta a bit simple, but tag the heck out of my posts with Technorati tags. Technorati tags are inserted into the blog post itself with an HTML snippet. It is a pain to re-write this snippet every time I post, even with a post template of some pre-made sample tags.

Enter ThisService! I wrote a short Perl script that takes a list of comma-separated tags, and returns the proper HTML snippet to make that list into Technorati tags. I used ThisService to hook it into the services menu, and Voila!, painless Technorati tagging in my blog posts.”

Always fun to hear about ThisService scripts. Oh, and Teece? “Next up, a Perl script that does “smart quotes” and removes multiple spaces, but that is also smart enough to ignore quotes inside HTML tags” sounds very much like SmartyPants, drop-in compatible as a ThisService script, and written in Perl.

Have you made a useful ThisService script? Do tell in the comments.

Remember the hard drive I ordered in September? It shipped yesterday. Yeah, I know.

Another thing you might remember is the awfully complicated (but, I tell myself, completely necessary) plan I came up with to migrate the files. Thanks to some suspicious behavior and subsequent Help file reading, it turns out Disk Utility’s Restore functionality is much smarter than I thought - it copies all files and metadata off of a drive or disk image, which is what I want. It does not do a bit-for-bit copy of the whole partition inside, as I originally thought. This effectively reduces my outline to this:

1. Shut down computer.
2. Attach new hard drive to IDE to USB/SATA-adapter, and the adapter to the computer. (Yes, USB is plug-and-play, but I do not want to risk having to pull the hard drive out unannounced, and earlier testing shows that just dismounting the volume will not shut down the hard drive, nor will putting the computer to sleep.)
3. Boot up with a Mac OS X disc.
4. Using Disk Utility, partition and format the new disk.
5. Using Disk Utility, “Restore” the main partition with the contents of the old disk.
6. Shut down computer.
7. Boot up with the new disk once to verify that it works.
8. Celebrate/rejoice, depending on phase of moon. Alternatively, make necessary adjustments to bodge new disk into booting properly.
9. Shut down computer.
10. Unhook USB adapter and perform actual swap of old and new hard drive.
11. There is no step 11.

JavaScript, oh JavaScript. You mistreated, capable language, forever doomed to nail annoying flying clocks to people’s cursors. That was the story, say, four years ago, anyway. JavaScript is in the middle of a renaissance now. It’s being used for useful things, like autocompletion on text fields, instead of the perpetual avian watchfaces of yesteryear, and while effects are still aplenty, this time many of them are actually quite useful. Still…

The big problem with JavaScript is that it’s a simple language at a low level, attached to HTML - probably the only non-Excel technology that’s even remotely “programming” that the man on the street would be able to tell you things about. Non-programmers write JavaScript, in droves, and the outcome is just not pretty.

Why am I being such an elitist about this? Am I not all about wanting technology to enable people to do cool things? Of course. The strongest trend on the Web has been one that’s been persistent ever since its conception, and one where a lot of momentum is going - letting everyone have a web site with relative ease. Aside from pages with cat pictures and animated horizontal rulers with Calvin and Hobbes, this also spawns a lot of writing with a lot of great ideas and unique perspectives. I am very impressed by this, and I am in no way opposed to this. But this isn’t about content, it is about code.

Non-programmers was a word picked very carefully. Probably the vast majority of the smartest people in the world are not programmers. This is not about being smart. Programmers are able to visualize how to break down a problem, how to solve it in the least steps in code, how to reduce repetition, how to thoroughly test edge cases, how to ensure compatibility, how to make the code robust. With very few exceptions, you either have this skill or you don’t, and so when people that are not actually programmers write code, chances are the outcome is functionally ugly and not well thought-out.

JavaScript’s position as a language so closely joined with HTML in today’s web browsers magnify this effect. When you search on Google for JavaScript, there is a very big chance you’ll be getting code snippets. It is hard to actually learn the language itself without, figurative scythe in hand, fighting through the jungle of snippets. This all piles up.

And yet, the ‘real’ programmers amongst us still overuse JavaScript from time to time. Beyond just getting the code right, using JavaScript properly - and I define “properly” as “in a way that actually enhances the site it is on substantially” - requires extreme vigilance and restraint. Using every component in the whole HTML-based hodgepodge correctly and to their maximum potential is nothing less than a form of art.

Let me share an example.

Starting a few months back, the online Apple Store started a new profiling effort. Many product pages now look and work substantially different. Put simply, they were able to fit more content into less screen real-estate. How did they do this? Small tabs everywhere, and JavaScript powering them. There are sub-sections of product info that (if you have JavaScript enabled) load without refreshing the page (by sending JSON), which is important on a store product page, because you don’t want to drag the customer away from the Buy button and you don’t want to waste more bandwidth than you have to. You can flip between one ‘tab’ of product info to another on the greater scale, and the philosophy trickles down to showing tech comparison tables in abbreviated or full form, all the way down to being able to view Mac and PC system requirements in tabs (this in particular is not remotely stored), saving space and cleaning up the entire page.

Why I’m bringing up this example is not because I’m impressed by the ingenuity of it (but rest assured that I am), no - I’m bringing it up because of another reason. You see, I’m currently reimplementing all of my partially outdated software site. I am using a lot of JavaScript to add small useful touches, like a product popup menu hidden away in a corner to facilitate easily getting to other products. Yesterday, I implemented a very close analogue to the Apple Store’s tab loading. It took five hours and I ended up throwing it away. Why did I throw it away?

My solution required loading the entire page in a hidden iframe in order to cherry-pick the correct elements to bring over. Even if it had turned out not to be buggy or unreliable in some cases, I realized that I was not saving bandwidth, and that I had no actual reason to not reload the whole page. I decided to just let links be links and I saved some valuable space in my script library, which in the long haul also means less to maintain, since every line of code is going to be a liability.

Sometimes, the really good solution isn’t really good for you. It’s all about being able to recognize what you gain from having that particular solution.

As long as I’m talking about this, I want to highlight another ground rule that I have in rebuilding the site: unless something lives and dies by JavaScript - and some legitimate applications do, like Google Maps - make it unobtrusive.

Being unobtrusive is an idea championed by many and under an array of other names (like Progressive enhancement and, vice-versa, graceful degradation), but it’s powerful nonetheless. The gist is that if someone with JavaScript disabled goes to your site, the content should just work, and if someone with JavaScript enabled goes to your site, the extra functionality should spring to life, and ideally, the HTML sent over the wire shouldn’t be much different.

Unobtrusiveness appeals in many ways. Less to maintain, better code separation and of course, being indistinguishable from magic. Getting the thinking nailed down can be hard if you’re used to getting at your HTML somewhat more directly, but it is definitely worth it. I have a “flippable” (expandable/collapsible) container element implemented by simply specifying three fields of extra metadata in the HTML (two ids and one class), and the screenshot gallery is almost completely set up by unobtrusive parts, being, simply, a list of links to the full screenshots in the source.

If you’re still writing “monolithic” sites - sites where the HTML basically requires being transformed into something else to be useful, or sites where the JavaScript generates other essential parts - I think you should check out Unobtrusive JavaScript. Hopefully, you’ll be thanking me.

I have a vision. It’s of a hard drive storage solution. I call it The Storage.

The Storage would be a six-pack sized appliance. It would sport USB, FireWire and Gigabit Ethernet ports. It would be hollow, with four slots, and carry connectors inside those slots. It’d also have some sort of chip inside it supporting a stripped-down Linux (or *BSD) distribution and reasonable (256 or 512MB) flash storage (for its inner workings and stuff you want to run from it in addition to the disk and shares management).

To each of the four slots, you could hook a drive module. The drive module would consist of a 3.5″ hard drive and an interface plate, hosting USB and FireWire connectors, and a special connector. The idea is that the interface plate would hook into the connectors inside The Storage, connecting the hard drive to it. The interface plate would snap onto any 3.5″ hard drive, and there would be one model for SATA drives, one for IDE/Parallel ATA and maybe even one for SAS. (The special connector mentioned earlier would be a passthrough for the current interface - whichever it is - when connecting to The Storage, and power would go through the FireWire plug.)

The whole idea behind The Storage beyond those technical specifications is based on these observations:

1. There are very capacious hard drives now.
2. Many people need reasonably capable portable hard drives for moving files or working out of the office.
3. Many people need very capable external hard drives at home or in the office for backup.
4. More often than not, you need to buy completely separate products for 2 and 3.

The Storage would pool all your stuff together. It’d work with pretty much any 3.5″ hard drive you could throw at it, from the cheapest to the most expensive. It would allow you to tear off just this one hard drive and use it as a regular portable hard drive, leaving the rest of your drives available for automated backup jobs, indexing, rendering or whatever else you could cook up.

The Storage would be reasonably priced - say $100 to $200 including the appliance and one or two drive plates - and you could periodically grow your storage with off-the-shelf hard drives for reasonable amounts of money.

The Storage is technically possible today, but no one is doing it.