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

We all know that a page that loads in three seconds will provide a negative user experience. But does having every page load in less than one second make a meaningful difference? How can you tell? When is enough … enough? Non-functional requirements such as performance are often not precise enough to be specified as discrete numbers. Rather, they work on a sliding scale of acceptability. Would slightly better performance be significantly more valuable from a market perspective? Would significantly better performance be just slightly more expensive to implement? When dealing with performance, usability, reliability and so forth, we often end up in a difficult trade-off analysis. ...

Bertrand Meyer first introduces the principle of Command Query Separation in his book Object-Oriented Software Construction. The principle states that a well designed object should have methods that are either commands or queries. A command changes the state of an object, but does not return any data, while a query returns data and does not change any state. By dividing methods into these two categories, you will have a better understanding of what does, and what does not, change the state of your system. ...

At first glance, Amazon’s First-In-First-Out (FIFO) message queues provide an excellent feature set for business-critical scenarios. With FIFO, the order in which messages are sent and received is strictly preserved. With exactly-once processing, message duplicates are not introduced into the queue, and consumers control when a message is made available for redelivery. Reading past the marketing hype, how well do FIFO queues work in the real world? This article takes a deep dive into SQS FIFO queues to test the claims of message ordering and exactly-once processing, paying particular care to the conditions under which these claims hold. I show how exactly-once processing can be achieved, and how that message ordering is preserved through failure conditions. I conclude with an examination of the relationship between in-order and exactly-once processing and atomic broadcast and consensus. ...