Writing a good test is hard, but, what does good actually mean in testing? Striving for an encompassing answer is not the goal of this post, but to focus on a single topic called state management. However, why should we bother, when many state-related topics do not become apparent in specifications, because of their isolated and predominant single-threaded nature?
A few months ago I worked on a Golang project, which was developed and built on a Linux environment only. Fortunately, it could be compiled on a Windows machine and just lacked some of the standard Linux build tools not given by a regular Git installation. However, it could be solved with a full Git SDK installation and with the help of pacman. I wasn't familiar with the SDK before and was curious if I could get some other tools running, which I use on Linux servers like tmux as a terminal multiplexer.
Writing good software is hard if we run a business behind it. I guess that nearly everyone experienced the consequences of taking the short path or not having the time to revert bad design or architectural decisions. The time for feature development decreases and firefighting begins and people start digging for the cause, taking a step back, looking at their system. If this has been experienced in the past years when the concepts of microservices appeared,
then the chances are high that the root cause has something to do with the giant, named Monolith, but is this justified? I remember a quote I read some years ago, which says:
We like to use services that allow us to connect with many people and share our ideas and data with them. Technologies with a broad network are more appealing to use, as they enable us to speak to people that we would never have addressed otherwise.
However, most services run on a freemium base and we pay for this by watching advertisements, tolerating the fact, that our information is analyzed to make those more 'tailored' on the one hand and also made available to algorithms that search for a pattern on the other.
It was in January when I blogged about Redux on Android and, around the same time, I've started implementing a solution in Kotlin.
My purpose was not to do the n+1 implementation of Redux, but more to provide a solution that can be used in conjunction with some of Kotlin's new language features like coroutines, to handle asynchronicity for instance.
Search
Latest News
Modern jest-ing with a Chance of Whaleball
29 May 2019
How to use your favourite Linux tools on Windows
18 February 2019
Quo vadis Monolith
05 September 2018
Take your data home
26 May 2018
Bonjour Conflate - A short overview
05 June 2017
A report on Kotlin, Redux and Android
29 January 2017