False expectations take away joy, according to Sandra Bullock. Such was my feeling when I tried to write a full-fledged document using AsciiDoc. I thought I would be a pleasant journey. Could I be wrong?

Although not as popular as json4s, circe, or spray, jsoniter’s simplicity and impressive performance benchmarks caught my teams attention. How easy was is it to integrate into an existing codebase? And was it really going to deliver on its promises in real projects? It sounded almost too good to be true, so we decided to give it a go!

We all know mocking libraries like Mockito or Mockk to mock classes in our unit tests. They can be convenient to mock I/O with external systems by replacing the boundary classes (aka. DAO = Data Access Objects) with mock objects. That way we do not require a full-blown simulator of that external system. However, mocking using these libraries also has some drawbacks. One way to avoid these drawbacks is to write your own mocks.

Binnen softwareontwikkeling worden teams vaak geconfronteerd met een spanningsveld tussen keuzevrijheid en standaardisatie. Aan de ene kant zorgt keuzevrijheid ervoor dat teams tools en technologieën kunnen kiezen die het beste aansluiten bij hun specifieke behoeften en hun persoonlijke voorkeuren. Aan de andere kant kan standaardisatie juist helpen om uniformiteit en stabiliteit binnen een organisatie te waarborgen. De sleutel tot het vinden van een gezonde balans ligt in het ondersteunen van beide doelen, mogelijk door het introduceren van een Enablement team. Ik leg graag uit waarom.

Helidon SE provides a web server using Java virtual threads. When we configure the web server we can specify a specific port number the server will listen on for incoming request. If we want to use a random port number we must specify the value 0. Helidon will then start the web server on a random port number that is available on our machine.

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.