Sunday, January 31, 2010

Lack of isomorphism in RIA Web Markup

I'm continually bothered by a nagging sense of discomfort with the way Web standards and popular technologies have developed over the past seven years. Emerson is often misquoted thus
Consistency is the hobgoblin of a small mind
but the actual quote is
A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.
The foolish consistency of which Emerson writes is, I believe, not the kind of uniformity which, if not present, lends that ineffable sense of elegance to mathematical theories, but is just that kind of embedded legacy of practice we see every day on the Web. One remark is that a lack of symmetry and non-uniformity is inversely related to the perpetuation of foolish consistencies.

I'll just draw attention to the axiomatic approach to mathematics, in which theorems are logically derived from definitions, and higher order systems are constructed. Algebraic systems for instance are logical systems of relations which consist of a set and one or more operations on that set, which together satisfy some given algebraic axioms (closure, associativity, identity, invertibility, etc.) The uniformity of such algebras is what allows us to construct logical statements and make formal deductions with great confidence that the results make sense.

Many programming platforms are lacking in that kind of uniformity. This is especially true of Web platforms, where historical accidents and what-the-browser-developers-could-get-working define the basic assumptions of the system. The foolish consistencies of linearized element layout for example continue to be perpetuated even as the industry shifts to CSS 3, because the CSS layout model inherits its assumptions from HTML. Consider also that in so many programming environments, it is rare to have the same operation applicable uniformly across all of the elements of a set. Neither is the DOM API the gleaming example it could have been, when one considers the effort that had gone into the node set APIs that preceded it (Groves for example). And now the industry continues to build upon the Swiss Cheese architecture with microformats, a half-hearted retake on architectural forms with more holes.

Wednesday, January 27, 2010

Comments about Drupal

Drupal has some very interesting engineering under the hood. The flip side of the no-salable-features coin is that there is a LOT of room for a system integrator to prepare prepackaged solutions and packing facilities, much in the way that Red Hat, Novel, and Canonical have done with various spins of *NIX OS's. And compare those to Apple's OS/X, which is also now *NIX based, and you can see how a user experience can be improved while retaining the interesting engineering in the core. What we need is not another CMS with its guts hanging out all over the place like Drupal, nor one with no user-serviceable parts, but one that wraps CMS primitives (like those of Drupal) in a tight cocoon of seamless silky smoothness.

That could mean hosted Drupal or an application layer tier made to completely isolate and automate changes to the Drupal core. Very recently, we've seen service providers pushing in that direction. Two notable mentions are DrupalGardens.com and OpenAtrium.com. In particular, in a blog at imagexmedia.com, Phillip Lamb discusses what they've done to address the salable feature problem of Drupal using the Features module. I'm not sure Features encapsulates and hides enough of Drupal's dross, but it is a huge step in the right direction. Someone finally gets it.

Tuesday, January 26, 2010

Putting the lie to Internet Explorer 8

As an INTJ, I look at the world a bit judgmentally through my Objectivist eyes. One way to judge the suitability of a conversation for effectively communicating a valid message, is to ask yourself, "How many deceptions or lies are being conveyed, and to what extent does either party have to analyze or decode what is being said in order to get to a true representation?" A conversation full of lies is not well-suited to communicating truth.

Similarly, we can judge the suitability of any tool to a given task, by asking how much one must modify ones' own goals and outcomes in order to use the tool. Do you quickly get what you want, or do you lose time with a lot of waste and results that are fragile and likely to break?

One overriding goal I have as a coder is to express a solution directly, without gratuitous vendor-specific code. By that measure, Internet Explorer 8 continues to be as unsuitable for Web development as previous versions, because it requires me to insert tags for parsing HTML5. These tags serve Microsoft's goals of making my pages appear to be endorsing Internet Explorer as a brand, which is at odds with my professional goal of writing to standards.

That's why I DO NOT advocate using shims or shivs or libraries to make up specifically for IE's defects. By doing so, we only reward a company for bad practices, and put more lies in our own Web conversations.

Monday, January 25, 2010

Lenovo: World Class Craptops.

After about a year, I've learned to HATE my Lenovo laptop. The Chinese company took a well-established brand with a solid reputation for quality, and sent it to the crapper. The next time you're considering purchasing a laptop, don't think twice about Lenovo. Think at least five or six times, then buy a Mac instead.

Do yourself a favor: look at the Lenovo support forums. What you will find is a company that has been riding on fumes, unable to make system hardware or software that works properly. Screwed up video chip soldering traces, dying batteries, problems re-awakening from sleep mode, wireless software drivers that continue to crash systems ... the list of common customer complaints to which Lenovo offers no substantive response is endless.

Then there is the generally low quality of the hardware itself. The cases on the newest models flex more than a child's toys. Think that buying an extended warranty from Lenovo will help? Not for the battery, which will go dead predictably just after a 12 months when used with the braindead Lenovo power management software. Lenovo only has a 12 month warranty on the battery. And the other parts wear out quickly too. Like the touchpad buttons. Mine is already half broken and wobbling in place.

Never again. I thought HP screwed up when it placed the heat sink fins inside the casing preventing them from being cleaned (and ensuring overheating), or having power supply soldering traces that would de-laminate. But Lenovo has well outpaced HP in producing world class Thinkpad Craptops. I'll never waste another minute of my time on a Lenovo computer again.

Thursday, January 21, 2010

Questioned about Drupal

A friend asked me if I could train them on Drupal. As I wrote them a response (sure, but I'm no expert) I realized it was too good to leave just for a personal conversation. The rest of the reply follows.




I have set up a few Drupal sites for myself, and found that it was not at all suitable for a one person operation. Two key reasons are that:

1) Deploying a salable feature on Drupal often requires coordination between the steps of creating typed content ("nodes") and identifying and installing multiple add-on modules. Contrast this to Joomla or Wordpress, where a salable feature is most often implemented as one installable package.

For instance, when I set up a portfolio, it required an image gallery module, then an image import module, then an image module, then a taxonomy module, and I think a couple of other modules, then configuring the content nodes in the right order and with the right taxonomy type... and modules had to be installed in the "correct" order else something might not work... it is a development task that can become intractably tangled rather than a straightforward configuration process.

People have been known to destroy Drupal sites by installing modules. But developers like the complexity because they can compose solutions by tying together nodes via the behavior of the add-ons; the complexity also offers them a modicum of job security because no customer in their right mind would want to monkey around with the content nodes.

2) Security updates to the Drupal core are supposed to be installed in the following way: the site add-ons are uninstalled, the patch applied, then add-ons reinstalled and reconfigured again. Drupal reminds me it has a security update needed once every month or so. This is hideously infeasible without a fully automated configuration process to recreate the salable features and content I've deployed, which is not in the core.

Getting to a scripted, repeatable process requires more add-ons and procedures, and I have not yet found the time or motivation to put that together. I know others claim to have no problems, but I often find people are punting, not counting their true costs, or are doing risky things that aught not to be done. I want things to be predictable and reproducible, and safe for the client (me). Lacking that I felt Drupal presented too much overhead for me to maintain for my own site.

I also thought that Drupal's templating system lent itself toward uglier sites.

That isn't to say I think Drupal is horrible. It has an elegant internal structure compared to Joomla. I just don't think the developers care about making pre-packaged installable solutions, in the way that Joomla developers obviously do. That's why there is an aftermarket for Joomla add-ons and not for Drupal. It isn't because, as they say "there is a strong 'give back to the project'" mentality ... lots of Joomla developers release free stuff too... but few people want to buy two axles, an engine, a windshield, etc etc ad nauseum, when they are in the market for a car.

Tuesday, January 5, 2010

Lost time

I wonder why after so many years, popular Linux systems like Debian and Ubuntu are still such absolute crap to work with?

I learned to program on a AT&T 3b2 multiuser UNIX System V box. No special graphics, not even a good X desktop for it, just character based terminals. Yet it worked. Doing things like installing software... um... it worked. I just spent the past two hours pissing away the time trying to get Debian to install a package with apt-get, only to get roadblocked with errors about GPG key validations and packages which couldn't be found.

If I had another forty to sixty hours of my life to piss away finding the right update sites and obtaining the right GPG keys, and the right how-to to install them, maybe I could actually follow through on the Python Fuse tutorial I was going to do. But I don't. And here is the crux of the problem with Linux: it offers the false economy of free software in exchange for a huge tax upon your time spent learning about and working around gratuitously meaningless problems. It isn't that things don't just work -- so often they do not -- but the distro makers are engineered the environment to break spontaneously by introducing dependencies that have to be updated manually.

Now, I used to support clients with UNIX machines in mission critical applications. Learning how to fix things is what I did. But at some point, you have to be able to rely that the components you're putting together aren't themselves carrying latent faults by design. Debian's update capabilities are nice, but the system has no capacity to pick up that GPG keys have changed. Also, there's no obvious authority for saying what the update site list should contain. Apparently sites change, and the keys do too; that drift over time effectively breaks a system in place. The user's system cannot be updated without a repair, yet the breakage had nothing at all to do with changes to the system itself.

My goal was simple: to run a python program. I didn't want to fuss with updating the system, but I needed the Fuse package and the Google python bindings. Unfortunately, the GPG keys can't be validated. Why is this even an issue? Didn't someone know that the keys would change over time? Are you really going to expect users to jerk around with GPG when that is about as far removed from their daily problems as you can get? To an Ubuntu user who isn't a Debian monkey fixing such problems is a recurring cost-prohibitive proposition. Proposing that a system as fragile as this be used as a production Desktop solution is not just silly, it violates engineering ethics.

Update: I eventually did get the keys updated, by way of some merciful hints by a few friends. Following up, I found two other unrelated issues that followed a similar anti-pattern, arising because Ubuntu keeps making things easier by removing or moving configuration files. Such is the slipping sideways of progress.