The Edges of the Box

 Discussing Inspiration versus Perspiration, at the weekend Mysterium 2020 con, Rand Miller talks about "the box" and working within it in a creative activity.  This is not about coloring in the lines, it is about accomplishing something with the resources available and the unpredictability and surprises that show up in the development.

Doing the small thing really well can be the ramp to learning/discovery and a way of bootstrapping to anything more ambitious.

Hearing that, I was reminded of my tribulations with The Miser Project and what I should do to delineate the oMiser development inside all of the thinking-out-loud Issues.

The initial box is having a sufficient proof-of-concept.  That means the SML/NJ mockup will provide a working oFrugal that allows exercise of the oMiser computational model.  The mockup is practical for demonstration of how the theoretical limits of computation are achieved.  The particular model also brings focus to how the stored-program concept affords representing numerous theoretical entities related to practical reality.  

This does not mean that oFrugal is particularly expressive.  It is essentially a calculator for deriving oMiser obs.  oFrugal and oMiser lack support for expressing representations at higher levels.  oFrugal/oMiser make that limitation almost self-evident.

But that's the box.  Having captured a variety of ideas that don't have to be addressed, I will retreat to working inside (but pushing) the edges.

Soft Landing for Clear Voice

Before the world shifted under our feet this year, I blogged about restoration of my voices across what I refer to as nfoCentrale, an amalgamation of web sites and blogs.

Lately I have turned, instead, to down-sizing and consolidation, focusing on a small number of projects that are central to my computer-science vocation.  This is a realistic move in light of my age and limited energy and enthusiasm, recognizing I have cast a net with too many unwoven holes in it.

Consolidation will be on GitHub, since it provides version control, Markdown authoring, hosting, wikis, and preservation of projects.  I expect that GitHub will endure as long as I require it, and having Git as a laboratory and preservation mechanism is ideal.

I will continue the nfoCentrale site, although more add-on domains will be surrendered; the content will remain as subdirectories of nfoCentrale.com and the catalog will reflect the altered amalgamation reality.

I also have to consider migration to a blog or two hosted on GitHub rather than Blogger.  This will provide relief from the disconnects between the current Blogger and LiveWriter; LiveWriter files are also not ideal for preservation purposes, though better than none.  I am saddened by the loss of continuity.  I will work through that in small steps. 

Steven Sinofsky on Crisis Leadership

I read the original Twitter thread and felt the need to be able to reread it, probably more than once.  Thankfully, an annotated version is now available on Sinofsky’s Medium blog.

It is worth reading.  It is worth understanding that any crisis arises and must be addressed under chaotic conditions.

There’s also the matter of preparation.  There can be strategies and plans for the foreseeable.  And, as is frequently reported, when the crisis erupts, the plans go out the window.  Yet we are better prepared for having done the planning, actually made the preparatory arrangements, and gained some level of training even if not the same as having been tested in response to a previous crisis.

Mel Conway on Humane Tool Design

Mel Conway has come up with a 85-tweet narrative on his view on having a universal-level arrangement for computational operations that is learned the way we all learned to listen, speak, move, walk, and explore as infants.  The idea is that we will ultimately grown up in this, whatever its forms, and it will have become a natural capacity.  Conway has an approach in mind.

The threads are all on Twitter.

Prelude (1 tweet)

0. Introduction (2 tweet thread)
A cloud-based Application Development Platform for the Rest of Us

1. Thesis (2 tweets)
-   If non-programmers are going to build real-world solutions, a simpler programming langauge isn’t enough
-    posits a collaborative situation in which everyone can participate with the skills they already have

2. Democratization of culture-critical information technologies (Historical Perspective: 16 tweet thread)

3. Universal Human Skills Model of Progress (16 tweet thread)

4. Humane Tool Design: 12 Principles (14 tweet thread)

5. On Platforms (20 tweet thread)

6. Where the Work Stands Now (17 tweet thread)

The proposed goal is a Humane, Asynchronous, Asymmetric Construction Platform for Stateful Business Applications

There is background material in Conway’s Humanizing Application Building presentation (PDF download).

I can appreciate the thesis, and I think Excel is a perfect illustration of the kind of collaborative participation that could be involved.  I would like to know more about what is essential versus incidental in the proposed cloud-based arrangement.

Above all, Conway’s thesis and narrative merits much thoughtful consideration.

Situating Performance Architecture

"Without the cognitive work that people engage in with each other, all software systems eventually fail" ACM Queue January 2020

It should be no surprise that our devices and computer software train us to learn how to operate with them.  We are the adaptable participants.  At the same time, we are not aided in formulation of conceptual models and practices that afford successful interactions.  

Perhaps the way to articulate my concern about this is by reflecting on a situation that was successful.  This was years ago; it is the handiest illustration that I have personal experience of.

Performance Patterns

The diagram below is a depiction that I refer to as a Performance Architecture.  It is a diagrammatic pattern that involves scanned images being captured and organized in digital form.  I term this an RSVP pattern: Read/render, Store, View, Print/present.

Used before Design Patterns became a thing in software development, the template for components of this pattern are very simple.

Based on the notion of dataflow diagrams, the indications of flow can be taken simply as transfer of data across a definite interface from one process to another process or storage.

By itself the RSVP pattern is abstracted at a high level above a detailed implementation case.  The pattern depicts an intermediate performance-architecture level.  Going deeper exposes more internal arrangements.  The surface at which users and operators approach and interact with the (sub)systems is also suggested.  At this informal conceptual level, fidelity of operation takes two forms.  There is specified technical fidelity to specified variations that an implementation supports.  At the same time, there is subjective (light-bulb) fidelity with respect to a particular usage situation and how that is satisfied by experimentation and confirmation of operation.

Customized Application

In an actual custom application, depicted above, the RSVP pattern was divided between two operations, 4.2 and 4.3, factoring the conceptual arrangement further.  Choreography with the additional activities involves considerable manual arrangements involving physical artifacts and a worksheet that is maintained throughout the progression of operations.
  

The purpose of creating digital images was preservation of scarce physical books that were deteriorating as the result of 19th century printing using papers produced via acid-based pulp-paper processing.  The phenomenon is evident in old paperback books and also old newspapers.  The book pages become brittle, discolored, and fragile.  In order to preserve the books digitally, the book is destroyed by removing (guillotining) the binding, separating the individual pages.  It is the individual pages that are scanned without any mechanical feeding, checked for successful capture of the pages, and then added to a digital collection with additional material for organization of the images as pages of a digital book. A printed and bound replacement book is produced and checked against the original pages.

Overall Situation

Rescue of deteriorating 19th century books was part of a prototype effort conducted to determine a successful preservation approach.  The effort was tied into an overall college-campus research library system.  Although the RSVP pattern occurs informally within activity 4.0, Make Digital Preservation, integration into operation of the research library and honoring of the sensibilities of the research librarians and curators was paramount.

People are not explicitly reflected in the diagrams.  There are human activities everywhere the physical and the digital are in conjunction.  Also, fine-grained iterations are to be understood.  There were provisions for rework and also correction from errors –- blemished scanning, pages out of sequence.  There also was a need for training of operators and supervision of operation.  Computer Center operations were relied upon for IT support. 

Although highly-tacit, the diagrams of this kind often serve as touch-stones for the participants to orient themselves with regard to their contributions and the overall enterprise.  It also reflects the constraints on subordinate procedures and what their architecture must serve in the higher level depiction.

This situating provided global context for agreement among the technical team providing the digital RSVP portions and the personnel of the library.  The entire undertaking was through a successful prototype codevelopment.  The digitally-preserved books are now part of an extensive set of digital collections made available on the World Wide Web.

There was important technology dependence.  Adequate preservation required high-quality flatbed scanning of book pages that was protective of the fragile pages.  High resolution xerographic printing of indelibly-fixed toners on archival papers was accomplished using an original Xerox DocuTech Network Publisher fed from a Unix server.

The configuration information is rather barren in the absence of the architectural patterns and the situating external architecture.  We get a view of what the system configuration is, but not what it is for.  And this is the most-replaceable component in the overall performance architecture.

At the intermediate and upward into the external architecture, there is a diagrammatic means for shared understanding and evolution of variations, improvements and extensions.  There is significant acknowledgment of tacit understanding, and a place for confirmation of consistency among those understandings between producers and those who adopt and employ the resulting system.

This case study is meant to be suggestive about preservation of end-to-end and user-situated understanding by sketches of this sort.  Whatever the form employed, distinguishing the levels and capturing the context in which built components must fit is important for understanding of the developers and those the development serves.  

Bruce Schneier on Policy vs Technology

Bruce Schneier posted this IEEE Security & Privacy essay on his blog today.

Read the posturing in the comments and wonder about the ones that resonate with you.

Compare with the thrust of the article and the purpose and nature of law and politics.

Discuss among yourselves.

Complexifying Elections: Technological Wishful Thinking over Accountability and Demonstration

Via ACM TechNews, Computerworld’s Lucas Mearian reports MIT researchers say mobile voting app piloted in U.S. is rife with vulnerabilities. 

There is a fundamental tension between having secrecy of ballots and a desire for auditability and detection/prevention of fraudulent manipulation of the voting system.

The TL;DR: The most important question concerning electronic/internet technical mediation of a voting system is this: When the system is determined to fail or corrupted on election day, what fall-back is in place for swift and certain recovery?

The next question is, what provisions are there for detecting such an incident is occurring or has occurred?

The Quandary

Insistence by researchers that paper ballots be the best choice has to do more with avoiding additional vulnerabilities and exploits that can be invisible, massive, difficult to audit, and not subject to the usual verification of chains of custody and handling between the means of submission (polling places and mail/drop systems) and current means of authenticating the registered voter and/or the unopened ballot.  Paper-ballot systems  limit the varieties of attack and their potential absence of detection.  Integrity of the system is grounded on human activity and the transparency of election administration. 

The paper ballot provides the best case of privacy, with the only connection being the handover of a ballot to a registered voter or the receipt of a sealed ballot before removal and introduction into processing.  The secrecy of the voter’s balloting is established at that point.

It is also the case that widespread fraud against voting systems has never been demonstrated, as much as it is feared by those who are contemptuous of voters not like themselves.  The small numbers of cases tend to be more pathetic than any serious rigging, such as the greater impact of voter suppression and distortion of choice through gerrymandering.

In some sense, those current manual-system provisions and safeguards do not go away.  Adding technological solutions is more complex and requires much more understanding, preparation, and dependence on specialized skills and appropriate conceptual models not possessed by polling place workers, those in election headquarters, and the management/administration, however well-intentioned. 

Advocates of technological fixes are on a death-spiral starting with the abandonment of paper ballots and continual fix and repair, adding complexification without addressing the importance of standard security requirements and especially risk management that applies to the delivery of invisible technology. 

A particular problem with citizen-facing voting technology is that it is not possible to have the normal cycles of learning and improvement.  It has to work the first time and every other time.  Furthermore, adversaries are not obligated to reveal their ability to penetrate and manipulate a system until it is too late. 

There is nothing new here in the difficulty of creating and deploying technical systems in which there are critical privacy and security requirements.  What is new is the impact on an area that is much more fragile in the face of disruption and breakdowns and the lost of trust inevitable breakdowns invite.  If the producers of technical components resist transparency for whatever reason, one must presume defects, not believe perfection with no evidence, only wishful thinking.