Leroy Campbell

My Backbone One arrived in the mail this weekend. I’m impressed with the build quality. The grips fit well in the palm. The joysticks have a nice amount of travel. Though not a seamless bind, the controller wraps the iPhone tightly enough for heavy button-mashing.

Tip of the day: Inflate half-and-half with air before adding it to coffee. You can thank me later.

Dr. Eugenia Cheng has a way of making difficult concepts less puzzling by teaching how to think like a mathematician.

It’s interesting to stoop down and see the world from the eye level of my kids periodically.

Rich Hickey’s Simple Made Easy is one of my favorite software talks. He explains how easy (to lie near) is not the same as simple (to be untwined).

…hoping The Mandalorian will astonish me on Friday…

I set Dark Noise to Rain on Tent for 25 minutes when I want to concentrate.

I’ve been in California since June, and still surprised that the weather is rarely dreary.

Situated Software

Dr. W. Edwards Deming’s teachings give me a new lens for approaching software development.

Lately, I’ve been noodling on a concept I call situated software, where I think about the software I build as integrated with its environment (i.e., the customer and her use case) instead of isolated from the environment. This stems from an appreciation for a system. When I think of software—particularly software for business users—as part of a larger system, it leads me to a different design and different engineering tradeoffs.

iA Writer 5.5 added Micropub support for publishing. This is great.

Learning to Discern – Quality & Quantity – The W. Edwards Deming Institute Blog

Variation appears in how well the parts are eventually integrated into a system and, how well the system performs, day after day.   Once again, quality is about use.  

For an introduction to the legacy of W. Edwards Deming, check out Kelly Allan’s Deming 101 presentation.

The Deming Institute is a treasure trove of wisdom. I’ve only started to dive in. I’m sure I’ll have more to share in the coming weeks.

Dr. Russell Ackoff, unpacking systems thinking in twelve minutes:

The system is not the sum of the behavior of its parts; it’s the product of their interactions.

SQLite is one of my favorite pieces of software.

Domenic Denicola, after categorizing async APIs:

Push and pull have distinct, not-very-overlapping areas where they each work well, and saying that we should pick one of the four APIs you mentioned and stick with it, as some people do, is shortsighted and leads to awkward code.

Shriram Krishnamurthi, highlighting what makes Scheme macros efficient in Automata via Macros:

What is the goto-like construct that corresponds to a dereference in a data structure? The answer was given by Guy Steele (Steele, 1977): the tail call.

Sandi Metz and Katrina Owen, explaining the importance of names in 99 Bottles of OOP:

Although the struggle for good names is painful, it is worth the effort if you wish your work to survive to be read. Code clarity is built upon names.

Understanding Event Loops by Implementing One

Matt Might once said:

My teaching assumes that to understand is to implement.

So to better understand how JavaScript’s event loop works, I implemented a simplified version (in Go). I only focused on timers; I may add asynchronous I/O later. My implementation combines a priority queue and counter to schedule tasks on the event loop. Calling setTimeout or setInterval adds a task, using its delay to calculate the task’s priority. When the task completes, the loop increments its counter to advance time.

Check out the full implementation on GitHub.

Mike Amundsen’s walkthrough of client-side hypermedia is a good demonstration of the Web’s greatest strength: links between things.

Katrina Owen, concluding her dotGo 2016 talk:

Applying the flocking rules systematically, over and over again, allows you to transform code with a series of seemingly insignificant increments.

This is refactoring in practice…small structural cleanups without changing behavior.

Nice reminder from Personal Kanban:

Capacity is an ineffective measure of throughput, and a horrible way to gauge what we can do. It doesn’t measure how we actually work, or at what rate we actually work. Capacity is merely a brute force measure of what will fit.

In Solving the Problem of Fit, Todd Rose and Bob Moesta discuss how no one is average and that individual distinctions matter.

Kevlin Henney does a good job of explanation how to approach testing. It is less about the tool and more about how you use it.

William Byrd, getting nerd chills as he explains The Most Beautiful Program Ever Written. I posted a version of it in Racket here.