|
|
|
snowballs where the tree will land
Wednesday, February 27 2008
Enough snow came with that last snowstorm (the one that saw me helping Gretchen get her car back up Dug Hill Road) to render the trails and landscape once more difficult for walking. If one were to take a cross section of the snow pack right now, one would probably find distinct layers from a dozen different storms, all with slightly different precipitation types.
This afternoon I took the chainsaw and trudged down the Stick Trail a couple hundred feet south of the Chamomile to where a dead tree had been blown down across it, and I cut the thing up into woodstove-length segments. This marked my most distant exclusively-human-powered firewood gathering foray. I had faith that my newly-customized firewood cart would allow me to haul this wood the 700 or so mostly-contour-level feet back to the house.
While I was there, I cut down a dead tree I found standing nearby. As usual when I'm cutting down a tree, one of the dogs (in this case Eleanor) decided to wait for me in precisely the place where the tree would be landing. I shouted at her to keep moving and she did so, but then came Sally, who decided to stop in that same suicidal spot. She's older and more distinguished and can't be cajoled into doing anything, so I had to hit her with a snowball to get her to move on.
Recent work developing a website has required me to pay close attention to a MySQL database as I try different things on the site, simulating a user. Since I prefer to monitor the database using my own web-based tools, but since I've configured the site's user authentication mechanism to be the same as that which authenticates access to the admin tools, it's not easy to be both a user and an admin at the same time. This forces me to use two different browsers simultaneously, since (as far as I know) there's no way for any one browser to keep track of two different parallel sessions on a single site from a single computer. At first I'd been using the beta Firefox 3.0 for my user login and the beta Safari-for-Windows browser for my admin login, but Safari started crashing randomly, so I've been forced to admin from Internet Explorer 7.0. It's been my first real exposure to this browser since I wouldn't otherwise have any reason to use it (other than to confirm that something is working in the kludgy environment it provides).
My database tools do not spit out particularly elaborate HTML. Much of what is displayed is presented in a single non-nested HTML table with no nested subsidiary tables. These rarely have more than 100 rows, although there are often references to styles in a cascading style sheet (CSS) and there is also some Javascript, some of which needs to scan through the data in the HTML tables in preparation for various client-side tricks that resemble (but are not) AJAX. As an indication of the sort of HTML we're talking about, a browser allowing a user to pick from among several tools for a listing of 198 tables comes to 115,351 bytes. That would have been excessive in 1996, but it's perfectly normal today.
What I find interesting about all of this is how different the behavior is when it comes to rendering these pages in Internet Explorer 7 versus Firefox 3. In IE 7 the page goes completely blank and then takes four seconds before anything appears. Firefox also takes about four seconds, but the page never blanks - it holds its old content until the new content is ready to be displayed and then starts displaying it immediately, making flowing changes on the fly as necessary. Firefox's behavior reminds me of the way IE used to be back in the early days of the web, when it was Netscape would infuriate me with its insistence on waiting for the final closing table tag before it would show anything.
I find the blanking of a page prior to displaying new content mentally problematic - it makes me wonder briefly if something has gone terribly wrong. It also breaks my focus, because while the screen is blank I'm left to rely on my short-term and mid-term memory to recall what the hell I'm doing. You see, the whole point of a graphical user interface is to offload cues about where you are in a procedure out of memory and into the visual system, freeing human memory to juggle the creative nuts and bolts of what is being done.
For linking purposes this article's URL is:
http://asecular.com/blog.php?080227 feedback
previous | next |
