Archive: October 2024

Wat wil je worden als je later groot bent?

Posted on by  
Juliëtte Veldhuis

Blogtober, een jaarlijks terugkerend initiatief waarin onze collega’s elke (werk)dag in oktober (veelal technische) blogs delen! Echt iets voor onze developers, mensen vanuit de inhoud, die hun kennis op deze manier met de wereld delen. Tot vorige week mijn collega Erik Pronk als ‘geintje met een seintje’ liet vallen dat hij nog wacht op een blog van mij. Mijn eerste gedachte: grappig, niks voor mij. Mijn tweede gedachte: challenge accepted!

Continue reading →

GKE with terraform and helm

Posted on by  
Dimitris Androutsos

In this tutorial we will deploy a Spring Boot applications to GKE. The application connects to a cloud Postgres database and exposes some REST endpoints. The required infrastructure is created with Terraform and the code is deployed to GKE with Helm. Helm is also deployed by Terraform.

  1. Java 17 installed

  2. Maven installed

  3. Docker installed

  4. gcloud installed

  5. A GC project setup with the billing configured

Continue reading →

Data Exfiltration via Git: A Forensic Investigation. Part 1, Exfiltration

Posted on by  
Menno van Veenendaal

In this two-part blog post, we’ll explore how data exfiltration to GitHub can be carried out from a Windows 10 workstation and how to investigate such incidents. Part 1 focuses on how data can be exfiltrated using Git and GitHub. In Part 2, we’ll dive into forensic techniques to retrieve evidence of data exfiltration and determine what was sent from the workstation.

Continue reading →

GitOps: DevOps 2.0

Posted on by  
Thomas de Groot

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.

Continue reading →

Shape Up your Event-Driven analysis with EventModeling

Posted on by  
Tom de Vroomen

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.

Continue reading →

Helidon SE Helpings: Default Configuration Sources

Posted on by  
Hubert Klein Ikkink

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:

  • Java system properties,

  • system environment variables,

  • a file on the classpath that has the name application.properties (based on default config parser that is part of the artifact helidon-config).

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:

  • application.yaml or application.yml,

  • application.conf,

  • application.json,

  • application.properties.

Continue reading →

Structurizr for Maintainable architecture

Posted on by  
Johan Kragt

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.

Continue reading →

shadow-left