The Journal Of E. A. Kolb

By now you should probably be aware that Google dropped a new browser on the market a couple weeks ago: Chrome. It's currently a beta product (version 0.2 and change) for Windows only, but it already seeing at least the active market share of Apple's Safari in the wild. Google Chrome is worth talking about not just for what features it does and doesn't bring to the browser market or its standards adherence. It's something worth talking about because it's not just Yet Another Web Browser from a code perspective.

I say this and mean it both as a good thing and as something that makes our jobs as web developers harder. And I say 'harder' in the sense that it will force us to not be lazy. Google Chrome changes how back-end browser processing works. For instance, each tab in the browser is its own system process, which optimizes memory recovery over a prolonged period of web use. More importantly, however, is that it changes how Javascript is processed.

For the last fifteen years (or however long Javascript’s been implemented on the browser level), Javascript has been a lock-step affair. Your document is read by the browser vertically. When a <script> block is encountered, its contents are executed, preventing the browser from taking any other action. That is not the case with Google Chrome. I’ve not got it entirely worked out yet, but it is definitely doing more things in parallel, including loading and processing of Javascript.

I'm not speaking for the rest of you, but one habit I've got with my web development is that I will pepper inline <script> tags throught my code. Usually, this is so relevant bits of Javascript remain in the same vascinity as the markup it drives. It might not be entirely proper, but it gets the job done and doesn't make a follow-up developer hunt for unmarried segments of ColdFusion/PHP and Javascript.

This fast-and-loose style of javascript programming has proven to be problematic in Chrome thus far. For instance, in the project I'm currently working on, I'm using Adobe's Spry as an effects and AJAX library in conjunction with ColdFusion's javascript libraries. The Spry includes create the global Spry object and I've had inline <script> blocks that would instantiate Spry effects or data sets. The issue that I was seeing in Chrome is that the inline blocks were sometimes being executed prior to the completion of the Spry includes, resulting in errors from invoking undefined properties of the global Spry.

Thus far, my solution to it has been to revisit the loose bits of inline javascript that I'm so used to peppering throughout our code. If you find yourself in a situation where Google Chrome is making your Javascript go busto, try this at a very early stage of processing.

Then, you can do this with your inline stuff:

This is going to give you control over all the little bits of JS you want to pepper into your document at will and will make sure it's all executed at onLoad (by which point all referenced Javascript files have been executed) in the order you want them executed. It also has the added bonus of meaning you never ever have to write an onload function that has to substitute some other onload.

Hope this helps.

Here's the key to the cross-browser issue I just tackled: the actual height of the document in an IFrame.


I know, I know. First question you probably had is, "Why are you using an iframe?" It's a cheap and easy way of loading an entire document into what you've currently got going. In this case, it helped untangle an upload new / manage existing items interface easier to implement. I've got an interface where I'm dynamically loading a page into an iframe and then resizing it to fit the height of the loaded document. MSIE keeps the document in a different spot in the DOM so I had to hunt it out.

1.) Microsoft Internet Explorer 7
One of the components I've written for eGov's clerk suite is a miscellaneous receipt processor. Receipts in general consist of the subtotal from the items found thereupon plus the taxes and fees and assorted whatnot heaped on top of that. In this instance, receipt items are based on service codes. For a clerk's office, these codes are tied to how the money collected for an item should break down into their general ledger distributions. In other words, when you pay $X to your county clerk for Some License, $W is kept by the clerk's office, $Y goes to the state, and $Z goes back to the county in general (where $W + $Y + $Z = $X).

Not all receipt codes are created equal. Fixed values are trivial, but some of these codes are percentages of a given amount. For instance, if they're charging you for 5% sales tax on your car then the amount you pay rather depends on the amount you paid for your car. So, to proceed with the calculations at that point, my code uses JS' prompt() function to obtain that foreign value immediately rather than muck about running absurd calculations.

Enter MSIE7. Some genius at MS decided that JS' prompt() is an untrusted function call. This means that prompt() does nothing unless one of two things happens:
    1.) The user right-clicks the pop-down sheet each time and chooses to temporarily allow the call to work.
    2.) The site is manually added to MSIE's list of trusted sites.

This came to my attention when I went to train the first end users with this particular component yesterday and it just wasn't working, despite a thorough double-check of functionality. Problem is, I've got MSIE6 on my work computer, which didn't present this asinine problem.

Regarding #1: no one sees those pop-down sheets to begin with ever, let alone the fact that it's a totally unacceptable non-solution to the problem. I cannot count to you the number of PEBKACs I've dealt with that would have been thirty second calls if anyone actually mentioned these sheets to me. Regarding #2: that's something that hasn't been part of our setup process and with counties on the other end of the state it's not a trivial matter to have that arranged.

Ultimately, I'm going to have to write an AJAX-y circumvention that does the same fucking thing as Javascript's prompt() because Microsoft had to go screw with their implementation of JS.

And before you fucking say it, we can't dump MSIE. It's not even an option at TNII counties (it will be uninstalled), let alone the fact that we're using a third-party ActiveX control for dialogless printing.

2.) Apple iPod

Prognosis on my older 20GB model comes and goes. Last night, the thing was a brick. Right now it's "fine". At least, for definitions of fine that are permissive of potential bad clusters on the disk, unexplained and only periodically reproducable startup failures, and so forth.

The way I figure, it's had a run of a few years and it's pretty much enjoying its last days. Time to start looking for a new one, right?

Guess not.

I haven't followed the market for these things avidly or anything. I'm not the kind of guy who gets a boner over the gadget market. Don't get me wrong, gadgets are great and all; I just don't pay much attention until I'm actually in the market.

Apparently, Apple's decided that they really just hate their customers these days. The least expensive iPod model is $250. Sure, the iPod Nanos are cheaper, but I don't want a fucking iPod Nano. Those things have something like 2-8GB of space. I'm using about 15G of my 20GB right now, so that's not even a viable option for me.

Thing is, I can't get an iPod that doesn't have all these new features that I don't want. The whole video kick is nice, but I fly maybe once a year and when I do I've got a book handy. Aside from that, when is a video screen on my iPod going to do me any good. Hell, I don't even need a color screen on mine.

I want what I've got - a 20ish GB MP3 player that integrates directly with iTunes. The product I describe no longer exists on the market. I would gladly give Apple money for the product I want. I will not give Apple money for features I don't want and will not use. This is an impasse, so they're losing me as a customer.

And you'd better believe that this fuck up makes me rethink ever putting money into their desktop or laptop computers, something I've been contemplating for a while.

The Optimist:
"I think I've adequately demonstrated that a comprehensive build process including external schema files should be a top priority for this project right now."

The Pessimist:
"Oh [OMITTED] [OMITTED] [OMITTED]ing [OMITTED]er on a [OMITTED] [OMITTED] orphan [OMITTED]! I just dropped the dev suite database by accident."

Apparently, unserialize is really picky about anyone messing with the serial string. Just spent an hour debugging why unserialize wasn't working on a serial string stored in a database where, per client requirement, all inserted data is strtoupper'd. Can't just strtolower on a serial string, though -- if there are null values in there (signified as N;), they must be upper case.

The following call may be a bit convoluted, but it works.

unserialize(preg_replace('/;n;/', ';N;', strtolower($serial)))

Of course, if you have string data within that array, that'll get clobbered by the strtolower. In my case, I was dealing with integer values (aside from the key names). But this might save someone else out there a little trouble.

I have a couple web dev projects being worked on in my lab right now, and I'm at the point where I need to start thinking seriously about preventing XSS (cross-site scripting) and other input-based vulnerabilities. I've been doing research on data scrubbing for a  little while now and I haven't come across any kind of worthwhile out-of-the-box kind of solution. The issue seems to be a largely unresolved one, so I'll need to brew up my own solution.

In my research, I did come across a blog entry advocating the use of input validation over filtering. I initially dismissed this as over-sensitive to ergonomics - web development for people without deadlines. However, discovering an utter lack of any kind of graceful filtering solutions, I began to reconsider. I'm going to need to put a fair amount of work into evading XSS and input vulnerability issues anyway, so I can't exactly dismiss the ergonomic argument on the grounds of development time now, can I?

I'm thinking now that I'm going to work on developing a generic input validation platform to integrate into my current and future projects. The goal is to identify input crises to parameterized sensitivity and bail out to a verification form in the event of a conflict. On the whole this shouldn't be exceedingly difficult, but the raw truth of the matter is that I've really never put any energy into personally exploring input-based vulnerabilities of web applications, so my own ability to identify the conditions of a crisis are limited. In other words, this is something I'll need to look further into*. Since this is something I'm splitting into its own project, I'm planning to press on with other items on the agenda. If you have any input or remarks on the matter that might help direct my line of thinking on the matter, I'd be most appreciative to hear it.

* _{I loathe having to write that I need to look into or to research something; it's perhaps the single most futile thing I could write at any given time, like opening a term paper with an equivalent of, "In this paper, I'm going to tell you about..."}