There’s a pattern that I keep recommending to teams over and over again, because it helps separate concerns around I/O; sending and receiving things over a network, interacting with AWS, saving and loading things from data stores. It’s an old idea; you’ll find it filed under “Decorator” in your Gang of Four book.
For our purposes here, this is a compositional pattern that allows us to stack onion-rings of concern around an I/O boundary; strings on the wire, transfer protocols (eg HTTP) , formats (eg JSON), business concepts. There is no code in existence that should be concerned about more than one of these at once; they can be structured as stackable layers, and other modules can pick which level of detail they wish to talk to.
In this blog post, I share my recent experience in a UI project, as a developer with limited past experience in UI development. I published this internally on REA Group’s wiki a while back to foster interest in UI projects from a broader set of developers – highlighting that solid engineering is a big part of contemporary UI development.
This is not specific to REA, hence I was keen to share this journey externally on our blog. Continue reading
After making our journey from Flux to Redux, we were happy with how clean and simple our state management had become so we kept ticking along.
Author’s note: this isn’t an argument against Futures, there’s nothing wrong with them as such! This article is about good abstraction and proper separation of concerns when using them.
The aims of functional programming are much the same as any other discipline of software engineering: modularity, abstraction, low coupling, high cohesion, and so on. While the techniques and terminology are often new to developers, the goals and benefits are expressible in very familiar language — because it’s all software, and we’re trying to achieve the same thing! (Read SICP for more background on software engineering fundamentals expressed with functional ideas).
A few months ago, my colleague Chris Myers and I used some basic category theory concepts to guide us to a design that elegantly solved a problem in a Java codebase.
It isn’t the only way we could have arrived at the design; anyone could have done it, really! However, you might find it interesting to see what practical application of these ideas can look like. Importantly, category theory gives us a framework to shed light on what makes many good design concepts useful, and why. Continue reading