Eagle Scout Tracking Sheet

There is a lot to do for a boy scout to go from the rank of Life to the rank of Eagle.  On Google docs I have created a spreadsheet that a boy scout troop can use to track the progress towards the rank of Eagle of Life scouts.  My intention is for this to be a tool for scouts themselves to use, rather than having their parents or troop adult leaders using this.  In addition to helping them see where they are in the process, I think seeing where their peers stand helps to motivate scouts!

Software Compared to Cities

(I have previously posted earlier versions of this write up elsewhere.)

Why should a system that is working well need to be replaced?

Successful software systems are like cities.  There are cities in Europe that have been continuously inhabited for thousands of years.  London or Rome today would be unrecognizable to Julius Caesar, yet the old cities were never abandoned and replaced - they were just continuously re-developed over the centuries.  Although we like to discuss replacing major software systems because their quirks annoy us, perhaps we should think of these as limitations that must be lived with, just as in these days of the automobile, we still deal with streets in Boston that were engineered for horses and wagons, and we have no intention of razing and rebuilding downtown.

Eventual State Consistency vs. Eventual Path Consistency

Overview

Brewer’s CAP Theorem says that a distributed application has to relax at least one of three properties - Consistency, Availability and Partition Tolerance.

It is often Consistency that is relaxed in favor of Availability and Partitioning.  For example, several popular database engines provide for geographically distributed instances, each of which commits its transactions locally, and then replicates to one or more remote instances.  In the event these updates collide with (or conflict with) updates made locally, corrective action can be initiated, either with a blanket rule such as “local always wins”, “remote always wins” or “ignore”; or with something more sophisticated, such as invoking application logic to take corrective action.

However, there are applications where detection of colliding updates does not suffice to ensure Consistency (where Consistency is defined as the database always being within the design parameters of the application logic – for example, the “in balance” guarantee that the sums of the assets and liabilities columns of a balance sheet are always equal).  There are applications where Consistency may require that the data read by application logic, not just the updates. must also be validated when checking for collisions.

I refer to collision detection by validating updates alone as Eventual State Consistency, and collision detection by also validating data read as Eventual Path Consistency.