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. Service composition is the holy grail of microservices, allowing you to build progressively more complex functionality safely and efficiently. This post discusses how transport independence and pattern matching allow you to compose services, what service composition means in terms of functions, and how you can use this composition to build complex services additively. ...

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. I do already have some middling experience with Clojure and Lisp, but I have too many battle scars from running dynamic languages in production to go down that path again. At this point in my career, my experience dictates that any new code I write will be statically typed. Because of this bias, I’m going to approach learning functional programming through the lens of statically typed functional languages. My learning plan will reflect that and help narrow the scope of this project. ...

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. ...

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. An expression is said to be referentially transparent if it can be replaced with its corresponding value without changing the program’s behaviour. ...

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. In software development, this overconfidence usually presents itself in estimates of the importance of projects to the business, the success rate of new projects, and in development timelines. We all seem to have an intuition that these biases exist, but what can we do to counteract them? One idea presented by Kahneman’s colleague Gary Klein is the premortem. ...

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. ...

This page provides a collection of premade Anki decks filled with cloze deletion tests for learning a second language. Use the table below to find the dataset for the language you speak (the native language), and the language you wish to learn (the target language). Native Language Target Language Anki Package Audio CSV English French eng_fra.apkg eng_fra.zip eng_fra.csv English German eng_deu.apkg eng_deu.zip eng_deu.csv English Spanish eng_spa.apkg eng_spa.zip eng_spa.csv English Italian eng_ita.apkg eng_ita.zip eng_ita.csv Frequently Asked Questions How to Import these Decks into Anki You can import the cloze deletions into Anki using the CSV file provided for each language. To import a file, click the File menu and then select Import. ...

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. ...

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. A common test for learning words in context is called a cloze test. ...

In most organizations, software development is split between two groups — product management and engineering. Product management is focused on building the right system. This requires product managers to meet with users, try and understand their needs, and develop solutions that meet those needs. To actually develop the solution, product managers must involve engineers who are focused on building the system right — writing the code, making it stable, and supporting it in production. Unfortunately, there exists an uncomfortable gap between product managers and engineers that forces the product manager to explain features in terms that an engineer can implement, and that forces the engineers to explain technological constraints to product managers in terms that a product manager can understand. To bridge this gap requires careful and considerate communication. It requires empathy from both product managers and engineers. ...