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 Duration to configure properties that express a duration. When we set the value of the property we can use:

The Java Development Kit (JDK) includes a tool called jshell that can be used to interactively test Java code. Normally we run jshell and type Java code to be executed from an interactive shell. But we can also use jshell as a tool on the command line to accept standard input containing Java code to be executed. The output of the code can be used as input for another tool on the command line. We run jshell - to run jshell and accept standard input. The simplest way to pass Java code to jshell is to use echo to print the Java code to standard output and pipe it to jshell.

In our day to day work we are always striving to innovate and deliver high-quality software. One technique that could help you be more successful in achieving these goals is inner source. Inner source refers to applying open source principles within an organization. It is about adopting the collaborative, transparent, and decentralized approach commonly seen in open source projects and applying it to the organization’s internal software development.

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!