After my visit to this year’s BusConf at the beginning of August 2018 and some discussion with a colleague who asked me about my opinion Value Objects and FP, I decided to start learning about Applicative Functors. I was surprised how easy it is to implement a more functional style validation using them and I knew that I have to prepare a talk about it to share my passion. There’s also an excellent blog post from Codurance about this topic in two parts that I highly recommend (Part1, Part2).

I did not expect to have enough insights/time to hold a session at SoCraTes at the end of August about it, but I began preparing one anyways in hope to have it ready for SoCraTes Franken Day in September.

While preparing it finally occurred to me, that by trying to explain the topic to others, I finally got a deeper understanding of it myself. I was so surprised how well it went so I decided to hold a small evening session about it in SoCraTes. While it still lacked some polishing, I think that I could give the attendees a gist of Validation in FP which was very fulfilling for me.

I think that learning by teaching works for me and I will continue to hold sessions about topics where I do not consider myself being an expert.

In order to try out new stuff and learn about new languages, tools and libraries, I created a little GitHub project. Right now I’ve uploaded some Coding Katas in different languages. Next week, I will try out python and upload some more stuff. Perhaps I should stop doing GameOfLife and FizzBuzz, it gets boring after the third or fourth language 😉

From my experience, when introducing mocks to your testing, it is easy to get messy, hard to maintain code. The 4 heuristics I’d like to present come from my experience with Outside-In designed artifacts that might not be right. Keep in mind that these are not meant to be a path of virtue that I must slavishly follow. I often violate them and still feel that the code is good (enough). Continue reading “My Heuristics for working with Mocks”

I want to accuse someone for writing bad code. This person has written lots of crap for about 7-8 years. Little time went into refactoring and even less into automated tests. When I look at his code my first thought is “what the hell was this guy thinking?”. In many cases his approach to software design has proven to be harmful for me. For example, when forced to fix a bug that was introduced by my bugfix because I did not understand the code well enough. Continue reading “A little self-accusation”

After using TDD at work for about 2.5 years, I finally feel that while I still need more practice I am no longer a novice. I am confident enough to post some advices that come from common pitfalls I’ve encountered when still at beginner level. While they might be obvious to TDD experts I often notice similar mistakes other beginners make. So I thought that I might write as well them down. Continue reading “Quick tips about practicing TDD”