SIGAVDI #92: Breakfast Smoothie Edition

What’s good

• Richard Schneeman on setting up CI for a Ruby library project on CircleCI. This is a great walkthrough, and I can vouch for CircleCI being a superior product. The ability to SSH into a troublesome pipeline to experiment with solutions is killer.
• GeePaw Hill on the winding path to learning to use test-driven development skillfully.
• I believe that the transition from object to process metaphysics is one of the most important paradigm shifts for working with complex systems. Here’s Carlos Perez on how the the debate between nature vs. nurture is the debate between understanding the world in terms of nouns vs. verbs. One quibble: he says “mysticism” derogatively at one point. But I’m increasingly convinced that the human mystical sense is their systems-thinking sense.
• DAMP vs DRY (and why your tests should be DAMP)

What’s New

• New on RubyTapas: continuing our series on containers for development, we create our first Dockerfile and then learn about layers!

What’s in my head

Recently I saw reference to an AI paper that asserted that algorithms don’t make poor decisions due to fatigue. As opposed to those sketchy, unreliable humans. This amused me.

A long time ago I worked on hard realtime ATC radar software for multi-runway airports. A lot of the work that went into that system involved graceful degradation as the system became overwhelmed. What do you do when there are more “targets” (aircraft with transponders) than the system was specced to handle? Do you fail in a surprising way? Do you handle it in a way that just silently loses radar tracks? Or do you fail predictably?

The thing is, computers make poor decisions, full stop. They make poorer decisions at the limits of their capacity. In the best case someone manages to predict and plan for likely types of exhaustion (memory, thread count, I/O, etc etc), and structure the degradation. In the worst case their response to overwhelm is nondeterministic.

And computers absolutely become fatigued too. Anyone who has ever rebooted their PC because it was getting slow and acting weird knows this. Fatigue is an artifact of complex systems, not some uniquely biological thing.

Fatigue can happen on very small timescales (garbage collection) or larger (oops, we leaked file a few file descriptors a day until we ran out). The more complex a system, the more unavoidable fatigue is. Evolution has had four billion years to work on this problem and its latest and most successful model spends eight hours out of every twenty-four rebooting. Apparently the flexibility has more utility than the availability.

The field of hard realtime programming is, in one sense, an attempt to minimize the possibility of that kind of fatigue by locking down sources of complexity. If your program never allocates it can never become GC-bound. But that also limits the flexibility of such systems.

In fact it limits them to making “decisions” in only the most trivial sense of the word. The more human-like the judgment required in terms of richness of input and context, the more complexity required, and the more potential for systems operating at their limits to screw up.

---