web

I’ve been working on a web project that has gone through multiple iterations, and many hands, before landing on my desk. Over that time (and while it’s been in my care, as well as before), the stylesheets have acquired quite a few geological layers. The primary CSS file has had over 2,000 lines, with more than 600 selectors spread over almost a dozen stylesheets. Since the site has gone through multiple revisions and adjustments–at least five major versions in the month or so I’ve been working on it–a lot of these selectors aren’t being used anymore.

This is a classic case of the Lava Flow anti-pattern:

When code just kind of spews forth and becomes permanent, it becomes an architectural feature of the archeological variety. Things are built atop the structure without question and without hope of changing what is beneath them. The existing code is seen as an historical curiosity.

The best thing to do with lava is to blast it away, leaving just the useful bedrock. But removing unused CSS selectors is a tedious and error-prone undertaking; my Java IDE can tell me which methods and variables are no longer in use, and profile an application for redundancies and deprecated components, but I didn’t have a comparable development tool for styles. Luckily, my core development philosophy–somebody smarter than me has already solved this problem, and has probably put the information out on the Internet–panned out, and I discovered the Dust-Me Selectors Firefox add-on.

Dust-Me Selectors can look at an individual page, or at an entire site, and tell you which selectors are actually in use. It generates a nice report, broken down by stylesheet file and including line numbers, that will direct your blasting caps and jackhammers at the problem areas. After running it through my pages, I was able to reduce that main CSS file to just over 1,000 lines (it’s a complex site), with less than 200 selectors defined.

The tool can be run against individual pages or against a sitemap; for a large site, a sitemap is by far the best approach. If you don’t have a sitemap.xml file yet, it’s relatively easy to generate one, either with your development tools or CMS, by hand for a short list of pages, or with a simple script. I found that it was less reliable in single-page mode: your coverage won’t be as good, and things like Ajax windows are going to get in the way of accurate results. A comprehensive sitemap ensures coverage.

It’s also a good idea to use caution when pruning the styles; I went through the list of flagged selectors and disabled them with comments, visually testing the site as I went along. There were a handful of cases where Dust-Me flagged styles that were actually in use, primarily within jQuery code that was manipulating element classes on the fly. After I verified that my leaner, meaner CSS files were working, I moved all of the commented code out into a new file just in case some of those selectors need to be resurrected in the future.

There are a few reasons to tidy up your CSS files. Download performance, though not as much of an issue in the broadband world, is a factor: my old core file was about 41KB, and my new one is 17KB. Browser performance, too, is a factor: parsing unneeded CSS code may be a very tiny drag on performance for faster machines and browsers, but every millisecond you save on unnecessary parsing is time you can put the browser to work doing something more interesting and useful.

The best argument for cleaning up the lava flow, though, is maintainability. Scrolling through those 2,000 lines of code in search of an errant style, or trying to debug a rendering issue when looking across a dozen files for a class or ID, is a drag on productivity. In the heat of battle, it’s far too easy just to add another selector to the bottom of the file, which only contributes to the chaos. Pruning the excess weight early in the development process makes it much easier to maintain clean code as the project moves along.

Last weekend, I installed Jolicloud, a Linux distribution (built on Ubuntu) that extols the virtues of a minimalist, cloud-based operating system. In a week of using it, I’ve found it to be very similar to Ubuntu in usability and performance, and not a bad fit for how I use the netbook.

Jolicloud markets itself as a dual-boot OS, intended to be installed side by side with an existing Windows installation. They are targeting netbook users with Windows XP or Windows 7, who are looking for a lighter alternative but aren’t quite ready to abandon the Windows platform. It’s also available as a stand-alone OS, though, installed into the primary partition of the netbook, which is the option I chose.

Ease of installation

The download and installation was pretty familiar. The Jolicloud ISO is made available over BitTorrent, which was a bit of a hassle for me: I had to download and install a BitTorrent client, and the ISO download was a little slow. I can understand the decision to use the BitTorrent model–it offloads the downloading costs from the Jolicloud infrastructure–but it did pose an additional hurdle for the casual downloader. After downloading the ISO, I had to download and run the Jolicloud USB creator to make a bootable USB drive.

The actual installation was identical to Ubuntu’s: basic configuration (user name, password, location, language, keyboard, etc.), snappy bootup, and then application installation. Jolicloud recognized my hardware, found my network, and within less than 30 minutes of running the install I had a fully-functional netbook.

Application Support

The Jolicloud application directory is a pleasing graphical environment, with applications organized into categories and represented by an icon and description. The expected tools are here: Dropbox, Wine, OpenOffice, and Gimp are all listed, and installation is quite simple.

Most of the applications in the directory, though, aren’t really stand-alone applications: they’re Mozilla Prism renderings of popular web sites, like Facebook, Twitter, and HootSuite. I installed a few to try them out, but found that they were more disruptive than useful in this format. On the netbook, my primary tool is Firefox, and I find it much easier to manage a collection of Firefox tabs than a collection of application windows. With bookmarks and plug-ins in Firefox, I can treat sites like parts of an interconnected application, which is a very different model than the iPhone-like site-as-application model. This may work for people who are used to the single-threaded iPhone environment, but I found it far less than useful.

Another innovation in the Jolicloud OS is a social network of its very own. When you set up your local account, you also have the option to establish a Jolicloud social account. Within the Jolicloud dashboard, you can find and “follow” other Jolicloud users, even seeing which applications they’ve installed. To be honest, this isn’t a selling point for me; Twitter, Facebook, and LinkedIn seem more than sufficient for my “social” computing needs, and I’m not sure that anyone should know or care that I’ve just applied the latest patches to Gimp. I can imagine that there are people who would find this to be a selling point, though (probably the same people who would like the Facebook and Twitter “apps” from the Jolicloud directory).

Stability

Jolicloud is comparable to Ubuntu Netbook Remix in the stability department. When in use, it tends to stay up and connected; when waking from hibernation, though, it frequently becomes groggy and needs a hard reboot to recover. My WiFi connection goes through phases–it is usually established soon after rebooting, but occasionally becomes unstable. Recovering the connection is usually automatic, though has required manual intervention and even a reboot in some cases.

Performance

Again, nothing special here; overall good performance, with occasional bouts of sluggishness when in heavy use. The OS boots quickly, usually in under 30 seconds, and Firefox starts up snappily. Some of the Prism applications can be sluggish, but after their novelty wore off (after about half an hour) I never went back to them.

Appearance

Ubuntu users will be right at home: the Jolicloud desktop is basically the Ubuntu desktop, with a few system icons reworked. Application categories are listed on the left, system resources (networks, disks) are listed on the right, and application icons are presented in the middle. There are tools built in for tweaking the desktop, and I suppose one could install a different desktop manager if one felt compelled, but it’s a functional and attractive look out of the box.

Overall Assessment

Jolicloud is a solid netbook operating system. It installs with relative ease, and does the basics that a netbook needs to do.

The “social” aspects don’t appeal to me, though; I don’t need to be “connected” whenever I use my netbook, and don’t need another social profile to maintain. And the Prism applications are largely superfluous; they don’t add anything to the experience that isn’t available in a more seamless, integrated way through a regular browser.

If I had to choose between Ubuntu and Jolicloud, I would probably stick with Ubuntu. If I wanted a Linux OS to run alongisde Windows, I would probably still stick with Ubuntu for its more advanced package manager. But Jolicloud is a good netbook choice, and a little slimmer than Ubuntu.

Fortunately, I don’t have to choose between Ubuntu and Jolicloud; the beauty of the netbook is that my choices are dizzyingly complex. And so now it’s time to wipe the flash drive clean and try something new.

I’ve made a couple of small adjustments to the BookLinker plugin I announced yesterday.

1. The popup will now be placed according to the available window width. I found that if the link appears close to the right margin of the browser screen, the popup could drift off-screen. Now, the popup’s left position will be based on the position of the link and the window width; ideally, the popup will be positioned directly above the link, but it will shift left accordingly.
2. LibraryThing has many book cover images available, but it doesn’t have them all. If a book cover is not available, an appropriately-size “No image available” image will be loaded instead. (I actually like the way I got this to work, by registering an onLoad event on the image; because there’s some latency in the request from LibraryThing, who will send an invisible 1×1 image when no cover is available, I don’t really know until the image loads if I got anything good. Registering an onError didn’t work, since something will always load, but in the onLoad I check the image width and then swap as appropriate.)

I would really like to add an AJAX call, probably to LibraryThing, to retrieve more information about the book and display the author and title. Not as elaborate as the LibraryThing widget (you can build your own here or see mine in the left sidebar here), but a little more than blank space. This is a little beyond my PHP skills this morning, though maybe I’ll have a solution by tonight.

For the last month, I’ve been deep in the bowels of a JavaScript project, which I’ve found to be equal parts fascinating and frustrating. Coming from a mostly Java background, I find the loosey-goosey aspects of JavaScript–weak typing, late binding, extremely forgiving syntax–particularly galling. In my LotusScript days, I was a big advocate of “option explicit” to keep me honest and avoid mistyping variable or function names; no such luck with JavaScript. There’s a lot to be said for the dynamism of JavaScript, of course, but it can come at the expense of the developer’s sanity.

Enter “lint” (or, at least, “lint-like”) tools for JavaScript. Though maybe not as nice as having Eclipse warn me about bad habits while writing Java, or Lotus Designer grumble when I save bad LotusScript, these tools apply a gimlet eye to my source code and goad me into cleaning up my act. A couple of them can be integrated into various JavaScript development tools, but since I’ve been working on this project in Notepad++ (which probably can be integrated with one or more, but I haven’t bothered to figure out how yet), I chose to use the on-line versions. Though there’s a lot of overlap, each tool–JSLint, JavaScript lint, and JSure–has its own strengths and quirks, so it’s not a bad idea to run your code through them all.

JSLint

WARNING: JSLint may hurt your feelings. Or at least it will if you feel that your JavaScript code is a reflection of your personal worth. If, instead, you see your code as a measure of your ability to wrestle with the beast that is JavaScript, then JSLint is a useful point of leverage in that struggle.

Of the three online JavaScript “lint” tools I’ve tried, JSLint is the strictest. As Douglas Crawford, author of JSLint (and the O’Reilly guide JavaScript: The Good Parts) states on the tool’s documentation page:

JavaScript is a sloppy language, but inside it there is an elegant, better language. JSLint helps you to program in that better language and to avoid most of the slop.

JSLint compares the code you paste into it against a set of coding standards, and lets you know where your code is lacking. It identifies unused and undeclared variables, provides a mechanism for identifying misspelled variable/attribute names, warns about comparison operators with type-casting side effects, and grumbles about misuse of “eval”-type statements that pass functions around as strings.

The interface is workmanlike: a no-frills page takes your input into a big text area, and lets you set a few switches (“Tolerate eval”; “Disallow bitwise operators”). The output appears between the input box and the switches, with each problem noted along with the line number and statement. I found that it worked best to fix a few of the issues, clear the JSLint input box, and repeat with the fixed code (especially since JSLint will only go so far before it gives up on you . . .)

All in all, highly recommended for finding the nits hiding in your tangled JavaScript locks.

JavaScript Lint

JavaScript Lint has both online and downloadable flavors; the online version is similar to JSLint: you paste in your code, and you get a report that shows potential flaws. Unlike JSLint, the report shows you the errors in the context of the entire code block, with the errors flagged in red:

This is both good and bad: it’s nice to see things in context, but it’s difficult to navigate a large code block and scan for errors. A list of error links would make the output easier to use. JavaScript Lint also lacks the various switches and options that JSLint provides, though it also appears that its list of problems to check is less stringent than JSLint’s. There are a few switches available, like an “option explicit” implementation, but they can only be used by embedding comments directly into the source code. My prejudice is toward non-intrusive tools that don’t require me to change source code to use them, and that’s a mark against heavy usage of JavaScript Lint.

JavaScript Lint is built on the Firefox JavaScript engine. I would expect this to give it an edge on verifying that JavaScript code is standards-compliant, but may not make it so useful for checking code for non-compliant implementations (IE, I’m lookin’ at you . . .). All in all, though, JavaScript Lint is a useful and usable tool for flagging JavaScript errors.

JSure

A more recent entry into the JavaScript “lint” tools, JSure offers a few more input options than JSLint or JavaScript Lint: besides pasting the code into the online form, you can also pass a URL or upload a source file. And, like JSLint, it provides unobtrusive options for how code is reviewed.

JSure’s output format is somewhere between JSLint and JavaScript Lint: you see the errors and warnings in context, but only the functions with errors and warnings are displayed. This makes for a report that is both smaller than JavaScript Lint’s and more readable than JSLint’s. But, like JavaScript Lint, it’s not as comprehensive as the defensive developer might like; it lets a lot of loose practices slide that would cause JSLint to look askance at your code.

No doubt there are other “lint”-like tools for JavaScript available, perhaps even some that are easily incorporated into an IDE. My little visit to the world of JavaScript has taught me nothing if not that this territory is in flux: desperately in need of frameworks and tools now that JavaScript has become much more than an “optional” technology, the JavaScript community is providing world-class solutions that compare well to those that have been available for some time in the Java world. There’s still a bit of a “build it yourself” ethos that makes leveraging the advancements of others easy, but even that seems to be changing as JavaScript matures.

The purple lint guy is from Cheryl Capezzuti’s lint-sculpture project; send her the fluffy stuff from your dryer!