Matheus Marabesi website, sharing ideas about software development - Listing posts on page 4

In this blog post we are going to focus on four more of them, named The stranger, The operating system evangelist, Success against all odds and The free ride. Each one of them focuses on a specific aspect of code that makes testing harder, sometimes it comes from not doing TDD, sometimes it just comes from the lack of knowledge on designing code. Either way, this is an attempt to explore those flaws and avoid them in our own code base.

In this blog post we are going to focus on four more of them, named The greedy catcher, The sequencer, Hidden dependency and The enumerator. Each one of them focuses on a specific aspect of code that makes testing harder, sometimes it comes from not doing TDD, sometimes it just comes for the lack of knowledge on designing code.

Katas are the way that developers use for sharping their skills in a particular subject. For example, TDD, design patters, SOLID principles or any kind of design to develop software - out there, there are katas for software architecture. Katas, have their name and inspiration from the Japanese karate, that focus on a specific and only one thing at time and bet on repetition to improve little by little. As already mentioned by Felienne in her book The programmer’s brain repetition is not something that programmers rely on to improve their skills, in that sense, repetition seems to be something...

In this blog post we are going to focus on four more of them, named The nitpicker, The secret catcher, The dodger and The Loudmouth. Each one of them focus on a specific aspect of code that makes testing harder, the four presented in post are somehow connected to starters in TDD, most of them are patterns found in who has not experience writing applications guided by tests.

Hello there, this is the second episode of the dataviz-project where I am trying to record the steps I take to bring a legacy app into a better state. If you haven’t seen the intro, you can have a look at it here. For this episode I started to change a bit how the test strategy is approached in the code. In the previous episode one of the goals was related to the testing library - here we will start to do that.

Building software is hard, building software that users love and actually deliver value is even harder. For long, the software industry suffered (and still suffers) for lack of communication between technicians and business, leading to different approaches of how to get them on the same page and build. Even with the advent of the agile manifest it alone, can’t do the job. Tools and techniques are needed to fill in this gap. Impact mapping is a book that focus on the impact, regardless of the business, and by that, the author means impact, not features.

In this blog post we are going to focus on four more of them, named The mockery, The inspector, The generous leftovers and The local hero. Each one of them focus on a specific aspect of code that makes testing harder.

Reading is part of my routine, I try to read as much as the time allows me and in 2021 I could finally achieve the goodreads challenge, reading 14 books along the year. In 2020, I shared the books I read, but I couldn’t meet my goal of 12 books. As I enjoyed writing about the 2020 books, I am doing the same style in 2021, here is a short list of the books I read and the references I came along the way. Some of those have its own blog post just to go through the details and what...

2021 was a different year for me, taking the time to write more than I did last year, code more and learn a bunch of things that I didn’t know. In this blog post I will try to resume what the year was for me in numbers. You might be asking, which numbers? From where? Those numbers are essentially from blog posts I wrote, goodreads, from wakatime and google analytics. Wakatime is a tool that I use on the daily basis to track where I am spending my time, in which projects and in which programming languages. Goodreads is the...

Recently I read the book Growing Object Oriented Software Guided by Tests and had a few ideas on how to approach things in a different way, thinking on testing from end-to-end, from the start - I relate this approach to the London school of TDD, also known as outside-in TDD. Even though the style is well known in the industry, getting a proper setup is not something standardized - at least, I couldn’t find any. On one hand, it vary for different programming languages, for example, java uses junit and selenium whereas in PHP it could be PHPUnit and Behat,...