If you’ve ever used the Linux tee command, you can probably guess what this pattern is about. At a first glance, this might seem similar to the fan-out concurrency pattern and, in a way, it is. But there is one crucial difference. The fan-out concurrency pattern splits the input from one channel into several channels for concurrent processing, while the tee channel pattern creates two channels with the exact same data as the original one.
Yet another Go concurrency pattern! This particular pattern is extremely helpful in composing several transformations from data incoming from a stream, and is know as the pipeline concurrency pattern. In a pipeline, we define several stages, which are nothing more than objects that take data in, perform some operation on it, and then output the transformed data.
Link to the code https://github.com/ornlu-is/go_pipeline_pattern The Pipeline pattern in Go Pipeline pattern Translating the above definition to Go, the pipeline pattern is simply a function that takes a channel, performs some operation on the data from that channel, and outputs it to another channel.
I have written a blog post about the fan-in concurrency pattern and, unlike most texts on this matter, I left its counterpart, the fan-out concurrency pattern, to have its own post. While these two patterns are mostly used in tandem, I believe that it is fundamental to understand them separately, so as to not create any mental blockers that would coherce us to only use one pattern when the other is also required.
It is not uncommon to have a piece of software that is concurrently reading from multiple streams of data. However, for a multitude of possible reasons, we might want to aggregate these streams into a single one, for example, to send the data to another service. Fortunately, this is not a new problem, and the solution for it is well known as the Fan-In pattern.
Link to the code https://github.com/ornlu-is/go_fan_in_pattern The Fan-In pattern in Go Fan-In pattern As stated before, the idea behind this is incredibly simple: the fan-in pattern combines several data streams into one.
Makefiles are a popular way of making the development process easier, since they can be used to chain several commands that allow developers to build, test, run, etc. their code. Additionally, they can also be used to create a make-based build/test system. In this post, I’m going to cover something how to set up a Makefile rule to test Golang code and enforce test coverage, i.e., have the rule fail if a predefined test coverage threshold is not met.
I like the generator pattern. I hadn’t realized it, but I had already encountered this pattern before when I used to program in Python. I recently found myself requiring to loop over a large sequence of numbers. Naively, I created a slice with all the values I required and then I looped over them. However, I was not satisfied with this solution so I went digging and found the generator pattern.