Service-Oriented Programming is my primary programming paradigm. It divides the software into self-contained “services” or groups of functionality. Services also apply in functional programming, rather, service-like behavior is enforced all the way to the foundational functional concepts.
The Pragmatic Programmer tells the now legendary tale of talking with a rubber duck to overcome programming problems. This sounds a bit silly, but programming is a design activity all the way down to the source code implementations. Problems and possibilities often won’t reveal themselves until we try to communicate them. Every programmer needs a duck. So what is yours?
Language is strongly related to the kinds of thoughts we have. Language shapes to favor what it’s users most want to describe. This post introduces a series about how I internalized the value of different programming languages. Specifically, my transition to functional-style thinking. I’ll be diving into concrete design problems and how FP trivialized my long-standing struggle with them.
I posted about Synthesizing Project Organization Methods a few months ago. Well… I’ve been busy putting it to practice in my own code, and the results have been been beyond my expectations!
I’ve been unhappy with the async/background work model in my system for a while. The async logic always seems excessively complex, either entangled with business logic or creating opaque coupling between flows. However, my recent breakthrough on code structure suggested a clear path to adding background work in an aspect-oriented style. Let’s examine a refactor that helped me prove decorator-style async communication.
The Language of the System by Rick Hickey is an illuminating talk about why systems differ from programs. It provides a clear framework for understanding and addressing the differences. I believe these same ideas underpin some of the recent movements in software design philosophy. Let’s explore.
This is a throw back to one of my earlier wrestlings with the Open-Closed principle and writing extensible frameworks. The goal is to shed some light on an important realization that let me to understanding the Open-Closed Principle.
A friend of mine, Paul Spoon, wrote a delightful article about using the Anti-Corruption Layer pattern as a tool for more stable tests. I tried the pattern with skepticism, and will now never go back. Let’s take a brief look at the pattern then dive into the benefits I’ve experienced.
A general design for integrating notifications (email, text, push, etc) has long eluded me. However, a recent refactor using the concepts of Synthesizing Project Organization Methods has settled my search. Here I’ll explore my refactoring experience and why the conceptual shift is generically more stable.
C# (and Java) offer a type call enum (aka enumeration). It represents a fixed list of possible values and is a powerful tool for communicating intentions through the type system. However, a recent legacy project forced me to face the shortcomings of enums and realize an even more powerful pattern, struct named constants.