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.
How to win. How to lose.
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 encourges us to conscript more correct approaches to understanding and constructing software systems.
Why is so much writing about code so unhelpful? Here’s one insightful investigation as to why.
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 boundaies 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.
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.
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.
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 gunfooting allowed by Enzyme. A great companion piece to Avoid the Test User.
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.