With @ConfigurationProperties in Spring Boot we can bind configuration properties to Java classes. The class annotated with @ConfigurationProperties can be injected into other classes and used in our code. We can use the type DataSize to configure properties that express a size in bytes. When we set the value of the property we can use a long value. The size is then in bytes as that is the default unit. We can also add a unit to the value. Valid units are B for bytes, KB for kilobytes, MB for megabytes, GB for gigabytes and TB for terabytes.

We can also use the @DataSizeUnit annotation to specify the unit of the property in our class annotated with @ConfigurationProperties. In that case a the value without a unit assigned to the property is already in the specified unit.

Today is the 4th of October which is World Animal Welfare Day.
As a tribute, I would like to dedicate this blog to the man’s developer’s best friend: K9S.

All jokes aside, I would like to address the struggle I see with DevOps teams. It is expected of every team member to possess the skills to manage your code but also the operations side like the CI/CD pipeline, and infrastructure like Kubernetes and Cloud providers. Reality has learned that not every developer has extended knowledge of all those things like for example Kubernetes. In this blog, I want to advocate for awareness of the difference in expertise and how I think you could help your team to learn and improve. For example, the CLI and Kubernetes aren’t everyone’s besties, but with the CLI UI tool K9S, you can make Kubernetes a little more accessible for everyone.

Config derivation with ZIO config and Magnolia.

As software engineers, we are constantly looking for ways to build faster, more scalable, and more efficient systems. But we often overlook one critical aspect: sustainability. Just as in sports, where long-term success comes from balancing peak performance with endurance, sustainable software engineering is about creating systems that not only perform well today but also remain viable and efficient in the future.

AssertJ already provides many useful assertions for all kind of types. But sometimes we want to define our own assertions for our own types. We can define new assertions by extending the AbstractAssert class In this class we add methods that will check the values of our type. The names of the methods can reflect the domain model of our type. This can make our tests more readable and understandable.

To compare nested objects we can use the usingRecursiveComparison() method in AssertJ. We can set up the nested objects with values we expect, invoke a method that would return the actual nested objects, and then use the usingRecursiveComparison() method to compare the actual nested objects with the expected nested objects. This is a very clean way to compare nested objects. Also when we would add a new property to the nested objects our test would fail as we didn’t use that new property yet for our expected nested objects.

In our Tech Radar we put CloudEvents in the trial phase of the platforms quadrant. We’d like to take you on a journey and show you what CloudEvents are and how they can be used. In our Second blog about CloudEvents we showed you how they can be applied. In this third blog we will be looking at CloudEvent extensions, a means to extend the specification with propriatary properties!

In our Tech Radar we put CloudEvents in the trial phase. We’d like to take you on a journey and show you what CloudEvents are and how they can be used. In our First blog about CloudEvents we introduced you to the specification. In this second blog we will be looking at how CloudEvents can be used in practice!

In our Tech Radar we put CloudEvents in the trial phase. We’d like to take you on a journey and show you what CloudEvents are and how they can be used. In this first blog we will be looking at the CloudEvent specification and the serialized end result!

Join me for my first look into GitHub Codespaces. I’ll walk you through setting up some basic configuration, and some things to keep in mind.

The is macro in the clojure.test namespace can be used to write assertions about the code we want to test. Usually we provide a predicate function as argument to the is macro. The prediction function will call our code under test and return a boolean value. If the value is true the assertion passes, if it is false the assertion fails. But we can also provide a custom assertion function to the is macro. In the clojure.test package there are already some customer assertions like thrown? and instance?. The assertions are implemented by defining a method for the assert-expr multimethod that is used by the is macro. The assert-expr multimethod is defined in the clojure.test namespace. In our own code base we can define new methods for the assert-expr multimethod and provide our own custom assertions. This can be useful to make tests more readable and we can use a language in our tests that is close to the domain or naming we use in our code.

The clojure.test namespace has the are macro that allows us to combine multiple test cases for the code we want to test, without having to write multiple assertions. We can provide multiple values for a function we want to test together with the expected values. Then then macro will expand this to multiple expressions with the is macro where the real assertion happens. Besides providing the data we must also provide the predicate where we assert our code under test. There is a downside of the are macro and that is that in case of assertion failures the line numbers in the error message could be off.