 |
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.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2005-12-22Patterns: Starting in the Meta-MiddleIt did not take long, during my investigations for TROST: Templates for Raising Open-Systems Trustworthiness, to determine that I had to figure out how to apply pattern languages. This seemed perfect for characterizing activities that invest trustworthiness in software and related artifacts. But digging into software-design pattern resources was unsatisfying. Something was missing and I needed to seek out original sources tied to the work of Christopher Alexander in order to find a point of comprehension. From there I could appraise recent work in software patterns, principles, and practices. That approach worked. Satisfied that I knew enough to begin applying pattern-language principles, I felt ready to set down some patterns of software development and deployment that reflect trustworthiness. I began noticing patterns everywhere, and I made note of them. I didn’t do much to articulate them. My first barrier was settling on a format for pattern descriptions that is not locked too tightly to a software methodology. The format must also be consistent with a stand for trustworthiness and how I symbolize it. Finally, I was worried about refactoring pattern descriptions if I were to alter the format down the road and I wanted to be satisfied that I could tolerate any change that was called for. I have a format that I am now confident in being able to sustain with only minor adjustments as I record actual patterns. The format features pattlets as summaries and as covers on expanded descriptions of patterns. It lets patterns be developed progressively over time. This TROST Pattern-Template Approach is based on a ten-topic structure that can be elaborated as needed. Although I have changed the usual nomenclature, the topics were synthesized from an analysis of several published formats. It is not necessary to employ all ten features, though some are quite essential:
Now all I need are some worked examples that make sense of this nomenclature and how the format can be applied. I’ve been shirking that. I’ve avoided writing down patterns themselves using the format I have. I distinguish patterns, I make notes about them, and I avoid documenting them. I think I’m afraid of my usual tendency to explode a can of worms and end up diverted from some critical work that I have on my docket. The only way to dispel that is to get started and not be bashful about leaving dangling connections for filling in later on. Having the format is my starting point for arranging the actual content. My next steps are to document those patterns that are applicable in work I am now doing, working my way toward building a pattern catalog and factoring out a pattern language. It is interesting that I turn stupid in rolling up my sleeves for that. I have no idea what formative childhood experience is being driven up with this, but I am confident there is one. The summary of my approach was created as an appendix in my draft dissertation on TROST. The appendix provided a brief summary and guide, with links to where the expanded description is found on the Internet. I often write that way, making web pages and then writing a synopsis that then shows me a crisper way to present the material. The synopsis may go on a blog or, in this case, into the back matter of a thesis. I then back-factor the cleaner narrative to the web pages. In this case, I’ve been sitting on that final step since late September. Grady Booch has been blogging about the incorporation of patterns in his evolving Handbook of Software Architecture. His December 10 post on the topic struck a chord with me and I sent him a link to my September 25th material. Then on December 13–16 he posted some great information about sources and approaches, helping me to realize that I missed some key sources in my late summer researches. On Tuesday December 18 he linked to my material and, gratified as I am for that, I’m suddenly embarrassed that company’s coming and I haven’t cleaned house. OK, I dusted and swept and back-factored and refactored the pages and I’m now ready for the preservation-society tour. Just don’t ask to see the kitchen. [Oh, and bringing groceries in from the car just now, I got what it is about putting up actual patterns: fear. I’m terrified.] 2005-12-20Without Context, Every Open-Format Standard Is the BestBest-Possible: a Technical Term? My long-time colleague Bill Anderson makes an interesting comment on my questioning whether and how the OpenDocument Format was really, seriously, and willfully contrived to be the best possible product-agnostic format standard for documents:
Best-Possible as the Mugging of Fitness-for-PurposeThe more I mull on this, the more peculiar the “best-possible” hyperbolic excess seems to me. It’s like describing the guillotine as the best-possible headache cure, or capital punishment as the best-possible homicide deterrent, or sacrificing innocent but foreign civilians as the best-possible prevention of terrorism on United States territory. It seems to me that even “better,” with its suggestion of some sort of situation-agnostic stack ranking, is also context-free until we say exactly with respect to what and for whom. Product-agnosticity is hardly a worthy thing in itself. I am left marvelling at how easily we decontextualize and make religious these prognostications over incomparables. Maybe its an indication of how desperate we can be to escape choice in the face of uncertainty. Although this topic arose in my response to the strange mariage de convenance that seeks to frame its crusade as an OpenDocument vs. Microsoft Office death match, I think there is a lesson here for the way we jump on fads in information technology. We want there to be one answer and we want it to be simple. And then we make ourselves crazy when our over-extended and under-justified pontifications collide with each other. I wonder if that is starting to drive civil life way too much too. No Format for All of the Documents All of the TimeI have already expressed my scepticism that there’s a universal document format, let alone OpenDocument being it. And I strongly doubt that Open Office XML Format is it either. I am aligned with the recent Microsoft statement that “the formats are significantly different, with different design points and strengths.” Fortunately, there is starting to be enough technical material that we can satisfy ourselves on the matter and also understand the gaps that separate the two approaches. I first learned about the quoted Microsoft statement from some discussion-list posts that saw the statement as making serious misrepresentations of the development history of the OpenDocument specification. I can’t speak to the timing of the OpenDocument release, and your review of the OASIS TC records may find somewhat more than “almost no material changes to the OpenOffice specification from the time it was submitted.” Although OpenDocument advocates were offended by this appraisal, OpenDocument co-editor and contributor David Faure acknowledges that although the claim of almost no material changes “is certainly exaggerated,” OpenDocument is mostly based on OpenOffice.org 1.1. So we have “almost no material changes” as another incomparable to stand against “best-possible.” That’s unfortunate, and we are each left to ponder where we’d place the judgment call on “material changes.” OO.o Already Near-Perfect?Further down in his post, Faure makes another interesting statement. He asserts that the OpenOffice [he says OD] “format was designed from the start to be as much independent as possible from the implementation of the office suite applications, and that's why it was a great basis for a standard.” In my words: little change was required from the format of the OO.o base document because it was already so great. I am unclear on the measurement of “great basis,” yet-another technical term, and I wonder how much of that conclusion was written into the premise (in this case, the TC charter’s first revision and the rationale for it), rather than demonstrated. I concede that the task of ECMA TC45, focused as it is on a defined legacy, verifiable behavior, and rigorously-defined document-interchange condition, is more-precisely demonstrable and, in that respect, easier. Abandon the Legacy, Save the Future!I’ve lost count of the number of times that I’ve been accused of designing for the ages and told to stop it. I think of systems architecture as, in many respects, finding an organization of function that keeps the adopter’s options open as well as we know how at the time. Turning my back completely on the future is not an option for me, if only to prepare for uncertainty as well as I can. At the same time, I respect the effort to preserve the Microsoft Office document legacy. I’m a practical beneficiary of that effort (since Office 97) and I applaud the commitment to continue it with an open format standard. When it comes to avoiding anything to destabilize a code base that is in widespread use, I am also exceedingly conservative. You can imagine my surprise when Dan Bricklin used some time with Microsoft’s Alan Yates to lobby for cutting loose from the legacy in order to look toward the future. I think the concern is captured in Dan’s saying “I think this is the time before it's too late.” Now, Dan isn’t saying that there should be a complete break, but that Microsoft should be willing to consider some sort of more-or-less safe legacy-breaking changes that secure a better future. I am unclear about the speculated future that will be threatened by an Office Open XML that preserves today’s legacy of Microsoft Office documents. Perhaps it is like the establishment of QWERTY keyboards making it too late for the “better” Dvorak arrangement. Bricklin has other misgivings and I look forward to his further articulation of the exact concerns and how they are to be grounded in the concrete. I don’t fathom his interjection of browser views (an ephemeral phenomenon) as a concern over persistent document formats for interchange, for example. Somehow, we need more grounding and context. I had better start with my own work. I don’t want to immerse any deeper into any determination of when and where the OpenDocument format is superior to Microsoft’s Office Open XML file formats. It’s too soon and the question is too abstract, like seeking a linear trustworthiness metric. Here are recent details on the march toward eventual ground-truth on the matter:
|
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |