Blunder Dome Sighting  
privacy 
 
 
 

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.



Click for Blog Feed
Blog Feed

Recent Items
 
Just Ducky, Simply Ducky. And You?
 
All Clear: End of Test #1
 
Why Learn Assembly Language
 
Linking the Atom Feeds
 
Button, Button, Where's the Update?
 
Do We Have a Firewall or a Development Web?
 
Attack of the Naughty Bees
 
What Do You Do When Security Software Cocks-It-Up?...
 
All Right, Now What?

This page is powered by Blogger. Isn't yours?
  

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
 
Millennia Antica: The Kiln Sitter's Diary
 
nfoWorks: Pursuing Harmony
 
Numbering Peano
 
Orcmid's Lair
 
Orcmid's Live Hideout
 
Prof. von Clueless in the Blunder Dome
 
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
 
DMA: The Document Management Alliance
 
DMware: Document Management Interoperability Exchange
 
Millennia Antica Pottery
 
The Miser Project
 
nfoCentrale: the Anchor Site
 
nfoWare: Information Processing Technology
 
nfoWorks: Tools for Document Interoperability
 
NuovoDoc: Design for Document System Interoperability
 
ODMA Interoperability Exchange
 
Orcmid's Lair
 
TROST: Open-System Trustworthiness

2004-08-31

 

Your%20Message%20Here

Your%20Link%20Here.  There was a slip-streamed change to the BlogThis! functions such that URLs and titles became character-set guarded via URL-encoding.  Even spaces in titles show up as '%20' codes.  The strange part is that having this material outside of URL encodings is just plain wrong.  These are not markup-recognized.  It was surprising how long it stayed that way. I see from the Blogger Status page that this problem was noticed and the earlier BlogThis! was restored.  I also welcome the expanded provision of status and a history of events, changes, and fixes. There's a lesson here about the slip-streaming of releases or, as the Blogger folk like to say, pushing features.  I don't let Microsoft do that, and they only push out invitations to pull for the most part.  (For the odd case of XPSP2, I managed to do the full download and burn a CD-ROM.  I will do a full rebuild with XPSP2 and not struggle with dropping it in as an update.  And I won't be doing automatic updates, thank you very much.) Recent Blogger updates have all come as surprises, sometimes annoyingly destabilizing surprises.  That provides a great lesson for both the appeal of the Web as a distribution mechanism and the importance of stability in the change-management of service interfaces published on the web. The situation with web interfaces is particularly daunting.  The way we normally see what works on the web is to turn it on and see what happens.  It is the ultimate extension of the code-and-fix mentality.  The resulting cost of randomizing users is way too high, especially if there is something much more involved than delivery of static content. The active web requires a different approach to change-introduction and controls.  I was already thinking about how to stamp out surprises as I was increasing my own ability to activate incident-response procedures in the face of some misadventure with my web sites.  I have already resolved to never willingly breaking a link to a page that I have ever published, so I religiously leave tombstones for anything that I finally have to move.  I'm now looking at what it takes to make other changes in ways that minimize disruptions to users, even though I may never know if there was anyone who might be impacted. The Blogger feature-pushing practice, and its propensity to surprise some portion of a large population is an useful lesson.  It has me be far more attentive to how easily I can make careless alterations that disrupt my blog sites.  Out of those experiences I am raising the level of transparency and accountability for operation of the site.  It might not matter that much here, with a small population of visitors.  Even so, I expect the practices I learn to be of immeasurable value. What I find the most daunting is the realization that others may have unacceptable experiences visiting my sites, and I won't be aware of it.  Unless someone happens to mention it, or show it to me, I might never know.  I don't run every browser, with every combination of plug-ins and security settings, combined with firewalls, intranet proxies, and whatever else there is that can alter the end-user experience.  And I didn't mention accessibility yet.  As much as I resist it, I suspect that dealing with accessibility and failure modes that preserve accessibility is going to be what matters.  Now there's a worthy challenge. I see two lessons of my youth that apply to the deployment of software.  Although I was hardly keen to wrestle or play football in high-school, I always remembered that before try-outs we were first taught how to fall and to avoid injury.  When I started skiing, I remember that the first lessons were about how to get up after falling and then how to fall safely, even as a way to avoid danger.  My physical-education teachers and ski instructors might be surprised to see where I now apply those lessons.  They certainly do apply:  When our software creations break, and they will, how do we minimize the impact and how will we be prepared to make repairs and amends.

 
Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $