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 REA, we have a list of highly sought after internal courses available on various topics including AWS, Docker and Elasticsearch. On 7th and 8th May 2018, we added Scala to the list, with over 20 people attending!
How did this all start?
Scala and functional programming have always had some mystique surrounding it. There is this idea that it is too hard or not pragmatic enough. Existing courses are very technical and many people including myself have struggled to complete them.
A Journey into Extensible Effects in Scala
This article is an introduction to using the Scala
Eff library, which is an implementation of Extensible Effects. This library is now under the Typelevel umbrella, which means it integrates well with popular functional programming libraries in Scala like Cats and Monix. I will not touch on the theoretical side of the concept in this post. Instead, I will be using code snippets to describe how you would introduce it to an existing Scala code base. This should hopefully improve extensibility and maintainability of the code. As part of this, I will demonstrate how to build a purely functional program in Scala using concepts such as
In this blog post, I'm going to provide a very simple explanation for Applicatives (aka "Applicative Functors") just the way I know them. I'm not going to cover the math behind it, or the laws which applicatives must obey.
I've taken a reverse approach compared to many other posts explaining Applicatives: rather than starting with what Applicatives are, I'm going to start with some examples to demonstrate the need for them, then I'll show how Applicatives can be used and at the end, I'll briefly cover how they can be implemented. Continue reading
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