Misclicked and stumbled on this blog? I can relate, every time using the UI of a cloud provider I’m always nervous I make errors in configuring my resources. In answer to this DevOps is embracing GitOps, DevOps taking development best practices and applying them to infrastructure automation.

If you run multiple batch updates in postgres, you may run into deadlocks.

We’ll look into why this happens and how we can prevent it.

There are many ways to analyse and write down business needs and hand them over to developers for implementation.

In many cases knowledge and information gets lost in translation and/or developers don’t understand exactly what to build and come up with their own solutions and the scope gets bigger and bigger, also called scope creep.

So, how can we get to a shared understanding of the business needs and prevent scope creep?

This is where the combination of EventModeling and ShapeUp comes in play.

There are 2 broad extremes when doing Scrum. To make scrum-items based on tasks or on functionality.

When we use Helidon SE we can use the Config class to pass configuration properties to our application. The static method create() creates a default configuration. The Config class is then configured to support different input sources. This configuration reads configuration properties from the following sources in order:

The last input source behaves differently based on which classes that can parse a configuration file are on the classpath of our application. If we use the helidon-config artifact on the classpath then the configuration file read is application.properties. To read a JSON formatted configuration file we must add the helidon-config-hocon artifact to the classpath. The file that is read is application.json. With the same artifact we can read a HOCON formatted configuration file that is named application.conf. Finally if we add the helidon-config-yaml artifact to the classpath we can read a YAML formatted configuration file that is named application.yaml or application.yml. Helidon SE will only read one configuration file from the classpath with the following order of preference:

Simon Brown’s C4 Model for architecting your software solutions provides a clean and structured way of modeling software. Structurizr is not a new tool, but with some new "Solution Architecture" responsibilities flowing my way I was looking for a way to create maintainable models. I found Structurizr extremely useful for creating easy to maintain models to use and change(!) during discussions with architects and developers alike.

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.