Posts

This is the second post in the series “Have Clojure UIs Taken the Wrong Path?”. The first post is here. How do we choose between building an application using a hypermedia approach versus the client-side SPA? This post won’t answer that question. But it will say how not to make that choice. A common heuristic is the spectrum that stretches between old fashioned “Multi Page Apps” (MPAs) for basic use cases, to Single Page Applications for rich client interactivity. ...

The Clojure community has focused on React-based solutions for complex front-end clients such as Reagent, Rum, Om, Re-frame, and Fulcro. For all their differences, they follow a very similar architecture, making heavy use of client-side state and using RPC for client-server communication. We will call this the “React+” approach. But is this the right choice? I will suggest the answer may be negative. My suspicion is that as web UI libraries advance, the problems they solve are not essential. Rather, the problems are accidental; they are generated by the React+ architecture. ...

In the Pragmatic Programmer, Andy Hunt and Dave Thomas tell us: “it’s critical that you write code that is readable and easy to reason about.” This seems uncontroversial; it is the rare point on which software engineers typically agree. Or do they? In fact, developers disagree about what “readability” means. “Readability” can be given two contrary meanings that we will call imperative readability (or readability-i) and declarative-readability (or readability-d). Imperative Readability This form of readability focuses on how the code operates. It emphasizes a clear presentation of the implementation details, such as which libraries are used, how data sources are accessed, and how functions perform their tasks. ...

The “Library Locker” is a common anti-pattern for incorporating third party libraries into an application. The application wraps the library with its own function, which mixes concerns and makes the library more difficult to use. In this article, we will first consider the original problem the library locker is introduced to solve, then an example of the library locker, and then suggest better alternatives. The Problem Suppose we have system of microservices that support astronomical applications. We locate our calls to our other microservices in a service directory. ...

This is the first in a multi-part series, “Brittle Clojure”. In this series, we will consider common patterns in Clojure which yield brittle systems, as well as methods to ensure robustness. None of the basic principles for building robust software are unique. Most literature, however, is focused on object-oriented systems. Our point of view will sometimes zoom in to Clojure “in the small”, and sometimes zoom out to distributed systems built with Clojure. ...

Among DORA’s more controversial findings is that trunk based development is superior to feature branching. Teams achieve higher levels of software delivery and operational performance (delivery speed, stability, and availability) if they follow these practices: Have three or fewer active branches in the application’s code repository. Merge branches to trunk at least once a day. Don’t have code freezes and don’t have integration phases. Since we know not to be Cremoninis, we won’t be distracted by whether trunk-based development meets the HN trendiness standard, and we’ll be skeptical of anectdotal appeals to experience ...

Differences of opinion about how we ought to write software have an air of the philosophical about them. Some prefer TDD and microservices, others may prefer monoliths and think that most testing is a waste of time. Or engineers may prefer to use continuous development methodologies, while businesses prefer a waterfall approach with decorative scrum ceremonies. Are we stuck with opinions? Must we be subjected to the obligatory “well, in my experience …”? Are we simply expressing our personal feelings, or is there some truth to be had? ...