Web Log of Ross Chapman

Hyperlinks

Rails Conf 2012 Keynote: Simplicity Matters by Rich Hickey

No Clojure experience actually required for this deep dive into what software “simplicity” really means and the hazardous semantic mistakes we constantly make with terms like “simple,” “easy,” “complex,” “hard,” when discussing our software preferences.

Surviving the Framework Hype Cycle - Brandon Hays

How to win. How to lose.

From complicated to complex

Being precise with our language when describing software is key to maintaining a steady notion of the world we are working in. “Complicated” and “complex” may first appear isomorphic, but the distinction jessitron offers contours a necessary taxonomic boundary for types of big software systems; and thereby encourages us to conscript more correct approaches to understanding and constructing software systems.

Instructive and Persuasive Examples

Why is so much writing about code so unhelpful? Here’s one insightful investigation as to why.

Michael Feathers - Edge-Free Programing

Explorations of program interruptions – logging, exceptions – that Feathers terms “edges” and Haskell-inspired strategies for mitigation. Mainly, how do we discover and handle invalid input at the farthest boundaries in our application in order that we can feel free to parse and process and data confidently deeper down. In other words, pushing edges to the edge. Beware production code examples in Java and Ruby. You may stumble across other developers coming across Feathers’ work and being profoundly touched. Here’s a strong endorsement from Peter Podgorski, which was also the article that led me to Alexis King’s deep think Parse, don’t validate:

One of the most intellectually challenging talks I’ve seen so far, at least when it comes to programming (we’ll get to other areas soon). What Michael Feathers talks about here is the kind of thinking outside the box that really flips your programming up side down. Or maybe “the right side up”, depending on how you think about it…

David Khourshid: Simplifying Complex UIs with Finite Automata & Statecharts: JSConf Iceland 2018

This was my initial intro into finite state automata in UI, thus marking a non-trivial evolution in my thinking for getting a handle on complex UI state for web clients.

Procedures, Functions, Data

Outside of Eric Normand’s [still in progress book] Grokking Simplicity this is, sadly and shockingly, the only other accessible example of utilizing functional programming concepts in real-world JavaScript code I’ve found. Mr. Smith leads you step-by-step from procedural (read: imperative) syntax to functional; thus achieving an example of what Hillel Wayne calls a “persuasive” (vs “instructive”): a more difficult, but helpful kind.

Execution in the Kingdom of Nouns

The classic OO/Java burn. OO vs functional is never the right debate, but I swear it can be instructional to consider the manner in which these two paradigms map (simplistically) to the grammatical opposition of Noun vs Verb. I don’t think software will ever escape linguistic and textual comparisons (ie software is writing). It’s a kind of writing, and I bet your (more functional-style) transaction sequences in JavaScript are very verb-y:

  arr.transform.select.flatten.doAnotherThing;

React Patterns

It’s like the Gang of Four but for React, and written with less an air of thought-leadery importance. I wrote React for almost two years without finding this site and I el great saudade for that time.

Testing Implementation Details

“The more your tests resemble the way your software is used, the more confidence they can give you.”

Developing this instinct really takes time. But this article from Kent is an erudite praxis to help you wrangle your test code to focus on the end user experience. It’s also effectively an advertisement for principles that drove the design of React Testing Library, and how it saves you from the kind of gun-footing allowed by Enzyme. A great companion piece to Avoid the Test User.

Types as axioms, or: playing god with static types

This is a good one for TypeScript developers who normally think about typing as a way of applying constraints. As King notes, TS influences this since the language intends for you to apply annotations alongside dynamically typed JS. But what if we thought about types another way: not as constraints, but as axiom schemas. King invites us to shift from a predictive to a constructive approach. Considering a similar post from Hillel Wayne, this post feels squarely located in the software scholarship domain that cheers the data modeling as a skill to be cultivated.

Parse, don’t validate

A companion piece for Michael Feathers’ Edge-Free Programing – (or is it the other way around) – that will introduce to the dangers of shotgun parsing and how to avoid them by shifting your mindset from validation to parse: an effort best pursued closest to the hard candy shell of your apps. Welcome to the world of Language-theoretic Security (LANGSEC)!