A Principled Approach to Architecture

A principle is a concept or value that is a guide for behaviour or evaluation. — Wikipedia This post presents a principled approach to architecture. These principles specify what I believe is important about architecture, without diving into any details about how an architect should work. No matter how an architect works day-to-day, by following principles, you can be sure you are providing value in the right areas. [Read More]

Range, Domain, and Codomain

Three common terms come up whenever we talk about functions: domain, range, and codomain. This post clarifies what each of those terms mean. Before we start talking about domain and range, lets quickly recap what a function is: A function relates each element of a set with exactly one element of another set (possibly the same set). Math is Fun That is, a function relates an input to an output. [Read More]

Functional Microservices

One proposed benefit of following a microservice architecture is that each service can be developed, released, and supported independently. In theory this allows development teams to work with less coordination and less overhead, leading to faster development times. In practice, this is difficult to achieve without some guidelines that make it work. The book The Tao of Microservices provides two such guidelines — transport independence, and pattern matching — that create an environment allowing you to compose services. [Read More]

A Functional Programming Learning Plan

I’m documenting my journey from functional neophyte to (hopefully) functional programmer by writing a series of blog posts on the topic. So far I’ve covered what functional programming is and why you would want to learn about it. In this post, I’m going to describe the resources I will be using to become functionally fluent. Although I have previously said I’m learning about functional programming, I should be more specific. [Read More]

Practical Differences Between Functional and Imperative Programming

I previously talked about what functional programming is by comparing it to other programming paradigms. This post expands on that post to talk specifically about practical differences between functional programming and the paradigm most of us are intimately familiar with — imperative. This post is punctuated with some quotes from the book An Introduction to Functional Programming Through Lambda Calculus. It’s worth noting that each of these practical differences are enabled because of the power of referential transparency. [Read More]

Why Functional Programming? The Benefits of Referential Transparency

Having covered what functional programming is, I wanted to spend a minute or two discussing why I want to learn functional programming in the first place. I’m sure we have all heard vague things about “side-effects”, “immutability”, and “composition”, but I wanted to dive a bit deeper on the topic to describe what — to me — is important about functional programming. Referential Transparency The key differentiating feature of (pure) functional programs is that they provide referential transparency. [Read More]

Overcoming Optimism with a Premortem

I’ve been reading the excellent book Thinking, Fast and Slow by Daniel Kahneman and came across a strategy for dealing with a common human behaviour problem that has direct impact on software development: overconfidence. According to Kahneman’s research, “overconfidence is a direct consequence of [how we think] that can be tamed — but not vanquished.” In other words, our brains are wired to make overconfident predictions and forecasts. [Read More]

What is Functional Programming?

I’m documenting my journey from functional neophyte to (hopefully) functional programmer by writing a series of blog posts on the topic. This is the first post describing what, exactly, the word functional programming means. Functional programming is a programming paradigm that lives alongside other programming paradigms. None of these paradigms have a precise, unanimous definition or standard, and there is not real agreement on which paradigm is better or worse for building particular types of software. [Read More]

Improving Test Coverage Using Exploratory Outcomes

In general, developers test features by focusing on the positive outcomes — the so-called “happy paths”. Unfortunately, this optimism can blind us to the less obvious or less probable outcomes that can cripple an application. I found one way to counteract this tendency is to try and “go beyond the happy path” by exploring the outcome of unhappy paths through a feature. I came across this idea in the excellent book Fifty Quick Ideas to Improve Your Tests by Gojko Adzic, David Evans, and Tom Roden, and expanded upon the book Writing Great Specifications by Kamil Nicieja. [Read More]

Bulk Generating Cloze Deletions for Learning a Language with Anki

tldr; Looking to learn a language using cloze deletions and Anki? Click here. One challenge in learning a second language is the sheer amount of vocabulary required for fluency. For example, one study has shown that the average eight year old knows 8000 words, while the average adult might know somewhere between 20,000 and 35,000 words. University graduates might know upwards of 50,000 words depending on their specialization. As an adult learning a second language, exposure to a lot of different words in their context is one of the best ways to learn vocabulary. [Read More]