The EDFH is defeated once again

In the first post in this series, we came up with some properties that could be used to test a run-length encoding implementation: The output must contain all the characters from the input, in the same order Two adjacent characters in the output cannot be the same The sum of the run lengths in the output must equal the total length of the input If the input is reversed, the output must also be reversed In the previous post, we tested various RLE implementations created by the Enterprise Developer From Hell and were happy that they all failed.
Read full post

Generating interesting inputs for property-based testing

In the previous post we attempted to define some properties for a run-length encoding (RLE) implementation, but got stuck because the random values being generated by FsCheck were not very useful. In this post we’ll look at a couple of ways of generating “interesting” inputs, and how to observe them so that we can be sure that they are indeed interesting. Observing the generated data The first thing we should do is add some kind of monitoring to see how many of the inputs are interesting.
Read full post

The Return of the Enterprise Developer From Hell

In a previous series of posts, I introduced you to the burned-out and lazy programmer known as the Enterprise Developer From Hell, or the EDFH for short. As we saw, the EDFH loves to practice malicious compliance. Recently, the EDFH’s influence was apparent with this viral answer to an interview problem. Write a function that converts the input to the output. Input: “aaaabbbcca” Output: [(‘a’,4), (‘b’,3), (‘c’,2), (‘a’,1)] Of course the EDFH answer is simple:
Read full post

Revisiting the six approaches

In this series, we looked at six different approaches to dependency injection. In the first post, we looked at “dependency retention” (inlining the dependencies) and “dependency rejection”, or keeping I/O at the edges of your implementation. In the second post, we looked at injecting dependencies using standard function parameters. In the third post, we looked at dependency handling using classic OO-style dependency injection and the FP equivalent: the Reader monad.
Read full post

Dependency Interpretation

In this series, we are looking at six different approaches to dependency injection. In the first post, we looked at “dependency retention” (inlining the dependencies) and “dependency rejection” (keeping I/O at the edges of your implementation). In the second post, we looked at injecting dependencies using standard function parameters. In the third post, we looked at dependency handling using classic OO-style dependency injection and the FP equivalent: the Reader monad.
Read full post

Dependency injection using the Reader monad

In this series, we are looking at six different approaches to dependency injection. In the first post, we looked at “dependency retention” (inlining the dependencies) and “dependency rejection” (keeping I/O at the edges of your implementation). In the second post, we looked at injecting dependencies as standard function parameters. In this post, we’ll look at dependency handling using classic OO-style dependency injection and the FP equivalent: the Reader monad Revisiting the logging problem In the previous post, I briefly discussed the logging problem.
Read full post

Dependency injection using parameters

In this series, we are looking at six different approaches to dependency injection. In the first post, we looked at “dependency retention” (inlining the dependencies) and “dependency rejection” (keeping I/O at the edges of your implementation). In this post, we’ll look at “dependency parameterization” as a way of managing dependencies. Dependency parameterization Given that you have made the effort to separate pure from impure code, you may still need to manage other dependencies.
Read full post

Six approaches to dependency injection

This post is part of the 2020 F# Advent Calendar. Check out all the other great posts there! And special thanks to Sergey Tihon for organizing this. In this series of posts, we’ll look at six different approaches to doing “dependency injection”. This post was inspired by Mark Seemann’s similar series of posts, and covers the same ideas in a slightly different way. There are other good posts on this topic by Bartosz Sypytkowski and Carsten K├Ânig.
Read full post

Against Railway-Oriented Programming

This post is part of the 2019 F# Advent Calendar. Check out all the other great posts there! And special thanks to Sergey Tihon for organizing this. Six and half years ago, I wrote a post and did a talk on what I called “Railway Oriented Programming”. It was a way for me to explain to myself and others how to use Result/Either to for chaining together error-generating functions.
Read full post

Why F# is the best enterprise language

This post is part of the 2018 F# Advent Calendar. Check out all the other great posts there! And special thanks to Sergey Tihon for organizing this. “Why F# is the best enterprise language” is not meant to be a clickbait title – it is my sincere opinion, and in this post I will attempt to justify it. If you stick around to the end, I hope that you will agree, or at least be a little bit persuaded.
Read full post