Infrequently Noted

back from Michigan. It was good to get a chance to see my family, and espically my grandmother who I haven't seen in years.

Finished Ross Anderson's excellent "Security Engineering" on the way back too. It's a book I bought when I still lived in Austin at the end of last summer and I've been stealing moments to read bits and peices of it ever since, and I want to say that this is a fantastic book. Even if you're not a paranoid like me, this book is both engrossing and clear. If you have even a marginal interest in security of any assortment, you owe it to yourself to read this book. And no, you can't borrow my copy, it's already claimed.

My life as told by Suck

Ok, I'm way too lazy to re-type this, so I'm pulling this from an email I sent to a good friend today. The following relates one of the odder things to happen in my life in the last couple of months.

So 2 nights ago I went out to get something to eat because at about midnight it struck me that I'd completely forgotten to eat that day. Anyway, I went to get some fast food (I know, I know "bad Alex!") and as I pull up to the window thing I discover that they are closed. But not before I roll down my window. And that's when my problems started.

Realizing that taco-hell was closed, I drove off to find the grocery store which I new was open, but halfway there it came to my attention that my window just didn't want to come back up. Fine, I thought, I'll just put some alcohol in the switch tomorrow and it'll clear right up like it always has.

Me and my youthful idealism.

So last night I took it over to a friends house. A couple of my friends live there and they are handy guys (a couple of EEs and a car wonk).
Figuring that it was the electrical system, we set out to fix it. After trying to clean out the switch to no avail, we tried to bypass it several different ways. Note that this is all happening out on the street at midnight and it's windy and cold. Anyway, after spending roughly an hour on that approach and finding that it didn't work, we were at our wits end. I just needed the window up because a storm front was moving in and if I could get the window up, everything else could wait. We decided to see if we could pull the window up by what small portion of glass was still exposed. Grabbing some vice grips, we attempted to lift the window, and for a second we thought we had some sucess, but both of the grips slipped off the window. Matt and Eric (my friends) decided to have another go at it. No sooner had their grips slipped again than an incredible crashing noise sounded down the street and echoed back through the hollow night, soon to be followed by a string of explatives. Mostly mine, I think.

There's something kind of surreal about the whole thing. I'm still not
quite sure what caused the window to shatter the way it did, and frankly I'm not sure I want to. I don't even want to think about what it's going to cost to get it fixed either, since it's money I probably don't have.

The handout for my Unix short course is up.

On innerHTML:

I don't know that there's anything that's more contentious in the DHTML community right now than the place (if there is one) for innerHTML.

It seems that every article or block of code that includes innerHTML these days must withstand withering public criticism or be followed by a years long thread on any number of public forums. Into that maw I assert the following:

innerHTML can be thought of as the DHTML equivelant of C's "goto". It's easily abused by those who do not understand it's dangers (or choose to ignore them), but it's benefits are undeniable. There are about 5 situations that I can think of offhand where using the goto directive in C can significantly simplify any number of problems. They are rare, but knowing that goto is available and being able to reckognize those nasty situations for what they are makes one a more valuable coder. I think the same is true of innerHTML.

The use of innerHTML by newbies is to be discouraged in the strongest of terms. It should be mantra that they be taught to ignore innerHTML as a solution to many of their "starter" problems. The should be taught the value of using textNodes, how modular programing can simplify most of those problems, and how building trees node by node can provide a more complete solution than many of the alternatives. But innerHTML should not receive an instinctive "no" from the web development community, but rather the guru-like raised eyebrow and a query for explination.

As front-end developers we rely on the browser to create a set of DOM nodes out of some text stream every time we request an HTML (or XHTML) document. Why should we not be able to count on that service after the browser loads also? Dissalowing access to that same functionality simply for the sake of avoiding newbie mistakes with such a powerful facility takes the wrong approach. We should be able to rely on browsers to expose most of their functionality to the scripter, otherwise we are wasting our time. innerHTML is not a security risk and there are places where if you need it, you need it bad.

Perhaps it shouldn't be standardized, I'm not sure about my opinion about that, but I do strongly beleive that the solution is not to rally against it, but rather to educate scripters about the right way of doing things, ignoring innerHTML as a solution until it's absolutely necessaray. innerHTML is a powerful tool for thorny problems, but it is not inherently evil.

Let's not promote ignorance over rational use of powerful tools. The right tools for the job...the right tools for the job...