When bytes
meet Mike

Everybody knows that programmers are spoiled. When not enjoying free fruits in their fancy offices, they probably work from the end of the world that looks like a paradise. Even during challenging economic conditions, the market still tries to exceed their expectations… A comfortable life and great earnings - who wouldn’t want that? In fact, there’s much more to appreciate. Most developers experience levels of organizational maturity that other industries have never dreamed of.

Equals ignoring fields is a pretty common operation. While often used within the test code to exclude selected fields from equality assertions, it can also be handy in our domain code. With Kotlin data classes, we can implement equals ignoring fields without using reflection or extra libraries. This solution feels almost too simple to describe, but it’s interesting to compare it with the available alternatives. Status quo Let’s take a simple blog post representation as an example:

Not all Java releases receive the same attention from the community. The ones marked as “LTS” have a much higher chance of broad adoption (even if many of us don’t fully understand what the “LTS” means). This alone makes the recently released Java 21 a serious contender. I believe it’s the most influential Java release since Java 8. Just not all of its groundbreaking aspects are already evident to everybody…

Imagine we’re building yet another e-commerce platform. One of its crucial business processes is, of course, processing an order. After a successful payment, the Orders module (domain) has to call Warehouse asynchronously to prepare purchased goods. Yet, they may not be there. Usually, it’s not a big deal, since we can get them from our suppliers. But what if any of the items are not available anymore? The order has been already placed!

I launched my own brand “Mike my bytes” in November 2020 as an experiment. Rebooting my existing blog (dated back to 2015!) along with becoming active on Twitter really paid off. Apart from joy, it also brought thousands of people interacting with my content every month. Today, it’s high time to make some adjustments. Refreshed mikemybytes.com design is just the beginning. Content is king The Twitter I discovered in 2020 is no longer there.

The calendar doesn’t lie. A decade of my professional career in software development has just passed. 10 years of experience always felt like a magical and very distant boundary. Am I a better engineer now? Am I a different person? Absolutely! Yet, it didn’t happen overnight. Reviewing these changes is a fascinating exercise. Sometimes I struggle to remember what I had for lunch the day before… But 10 years?! That’s really a lot of time!

Quite some time ago, JUnit’s @CsvAnnotation caught my attention. It turned out so interesting, that I dedicated it a separate blog post and a significant part of a conference talk. It also inspired me to create a new way of writing parameterized tests with JUnit 5. The JUnit 5 FormattedSource library allows defining test case arguments in a human-readable way, following a user-defined format. As a result, it can be used to improve tests readability.

Keeping our domain (business) logic together is usually a really good idea. It not only makes it easier to reason about the most important part of our code but also increases its cohesion. Yet, decoupling the domain code from all the rest (orchestration, persistence, etc.) can be tricky. In this post, I’d like to share a simple pattern that helps me with that. The amazing Unit Testing Principles, Practices, and Patterns book calls it the CanExecute/Execute pattern.

Database migrations are a standard way of dealing with database schema changes, especially in the relational world. No matter which solution we choose (e.g. Flyway or Liquibase in the Java ecosystem), the number of migrations usually grows together with the project itself. An unfortunate side effect is that the test execution time grows as well. An effective way of speeding up our test execution in such cases is to squash (compact) all the existing migrations into a single file.

The very last days of the old year are probably a good time to think about the next one. Although we already learned how inaccurate any predictions can be, it still feels like an interesting exercise to me. Let’s try to predict the tech future just a little bit… 🔮 I have to warn you, that everything you’ll read here is just a reflection of my own gut feeling. It’s a bunch of guesses based on news, observations, and discussions with my colleagues (👋).