Imagine a module Calculator defining some methods which then you call like Calculator.sum(1, 2). While this usage of a module is valid in some cases, this time I think we are seeing an antipattern in place. Let's see in my opinion when using a module directly to call methods on it makes sense and when it is an antipattern.
Recently we had to integrate our system with a label API that provided OR
as its unique operator in queries. For us as consumers of the API it meant that the number of labels we needed per object increased at orders of growth
of quadratic of the labels of an object. As a consequence the complexity of our code also increased at quadratic orders of growth
In a recent pull request of mine at work a colleague called my attention into an antipattern I had in the code, namely Using exceptions for flow control
, and he was right. So we just had to change it.
Have you ever wanted to fire the office alarm, play a Star Trek epic track and start a red blinking light every time your build of the master branch broke in your Continuous Integration server? This is how we did it: we wired our Jenkins
to make calls to a Sinatra
webserver running on a Raspberry Pi
which then commands an Arduino
over an USB to have the fun going at the office.