Heb je interesse in het werken met containers en container orkestratie met Kubernetes? Dan is onze meetup 'Docker & Kubernetes voor beginners' op donderdag 8 juni iets voor jou!

Tijdens de workshop krijg je uitleg over containers (Docker & andere container runtimes) en wordt de basis van Kubernetes uitgelegd. Daarna ga je zelf aan de slag met een aantal opdrachten waarin je leert werken met Docker en Kubernetes. Ervaring met Linux en werken op de commandline is daarvoor wel vereist.

Programma
17:00 - 18:00 Inloop met eten
18:00 - 20:00 Workshop Docker & Kubernetes voor beginners
20:00 - 21:00 Borrel

Spreker
De workshop wordt geleid door Peter van Ekeren, DevOps engineer bij CINQ. 

"Na de start van mijn IT carriere als .NET developer en sysadmin, ben ik in aanraking gekomen met DevOps en de CI/CD methoden en technieken. Vervolgens heb ik mij verder gespecialiseerd in de richting van cloud oplossingen met Azure en AWS, CI/CD, Infra as Code en containerisation & orchestration met Docker, Rancher en Kubernetes. In mijn laatste opdrachten heb ik nieuwe omgevingen met Kubernetes clusters ontworpen en ontwikkeld met behulp van infrastructure as code. Daarbij heb ik collega's begeleid en als vraagbaak en mentor gefungeerd op het gebied van deze oplossingen."

Locatie
CINQ ICT, Burgemeester Stramanweg 101, 1101 AA Amsterdam

Wil je erbij zijn? Meld je aan via Meetup.

Meetup: Docker & Kubernetes workshop

Op onze eigen booth op KubeCon + CloudNativeCon Europe 2023 kun je elke dag een toffe LEGO set winnen door KubeDoom te spelen. Dat LEGO populair is dat wisten we al... Maar dat je het bij bijna 30 booths kunt winnen, hadden wij ook niet gedacht! Er is zelfs een heuse LEGO lounge waar je kan spelen en op woensdag waren de winnaars van LEGO Masters aanwezig tijdens de KubeCrawl / CloudNativeFest voor een workshop. Een ding is duidelijk, deze community is gek op LEGO! 

En terecht, vinden wij!  Ook vandaag werd weer volop KubeDoom gespeeld bij onze booth. De opdracht was vandaag iets anders, zodat iedereen weer een nieuwe poging kon doen om te winnen. Ook hebben we veel leuke gesprekken gehad met potentiële klanten, partners en kandidaten. Aan het eind van de middag kwam Sander, de winnaar van dag 1, zijn Batman Tumbler ophalen. Met een score van 12 punten had hij de hoogste score behaald! Veel plezier met bouwen, Sander!

Vandaag was er één echte uitblinker in KubeDoom. Damon Wright zette in de loop van de ochtend een dikke score neer van 23 punten, en daar kwam vervolgens niemand meer bij in de buurt. Hij had de deployment zo snel gerepareerd, dat hij vervolgens veel tijd had in het spel om de monsters (pods) te pakken te krijgen. De monsters spawnen in verschillende ruimtes in de map en Damon had ook nog eens de mazzel dat er veel monsters tegelijk in dezelfde ruimte terecht kwamen. 

Behalve heel veel LEGO zijn er ook een hoop andere dingen te winnen. We zagen Playstations, veel Nintendo Switch's, iPhones en koptelefoons voorbij komen. Onze collega's hebben weer succes gehad bij verschillende booths, want Christian ging met een Star Wars Republic Gunship naar huis en Harmen won een DJI Mini 2 drone! 

Vrijdag is de derde en laatste dag van de conferentie. De sponsor showcase gaat weer na de keynotes open en is dan van 10.30u tot 15.30u. De prijs voor de hoogste KubeDoom score op vrijdag is de Ghostbusters ECTO-1 en we zijn benieuwd naar de scores. De opdracht is uiteraard weer een beetje aangepast, zodat iedereen weer evenveel kans maakt. We sluiten de dag af met een gezellige borrel bij onze booth, dus kom vanaf 14.30 vooral even buurten bij de CINQ booth op plek S76 in de Daffodil zone. We gaan er een feestje van maken ;-) 

Lees het verslag van CINQ op KubeCon + CloudNativeCon Europe 2023 dag 2

KubeCon + CloudNativeCon dag 2: LEGOfest

Vandaag was dag één van KubeCon + CloudNativeCon Europe 2023 in de RAI in Amsterdam. Het is de grootste open-source conferentie van Europa en als Kubernetes specialisten kunnen wij natuurlijk niet ontbreken! In deze blogpost lees je een korte recap van onze eerste dag op de conferentie met een aantal foto's en reacties van onze collega's. 

In het ochtendzonnetje die lekker de RAI in scheen, begonnen we de dag met het opzetten van onze sponsor booth en vooral: het klaarzetten van de game die we voor de conferentie hebben gemaakt. Met deze GitHub repo als vertrekpunt hebben we een eigen versie van KubeDoom gemaakt. Ahh Doom, iedereen die in de jaren 90 een computer had kent het wel, het was namelijk een van de eerste 3d shooters en in die tijd (en nog steeds;)) een grote hit. Deze versie van Doom draait op Kubernetes en in de opdracht die wij eromheen hebben bedacht ga je aan de slag om de kapotte deployment te repareren. Wanneer je dit goed doet en je ervoor zorgt dat de pods draaien, komen deze pods als monsters in Doom tevoorschijn. Daarna kun je in de game de monsters/pods afschieten en daarmee scoor je punten. 

De hoogste score van de dag was 12 en 'stimmerman' won daarmee de LEGO Batman Tumbler! Er waren drie mensen met dezelfde score, maar omdat hij deze als eerste had gehaald is 'ie de winnaar! De prijs ligt voor 'm klaar bij de CINQ booth!

Wat vond jij het leukst/inspirerend vandaag?

Deze vraag stelden we aan onze collega's die als bezoeker op de conferentie waren. Zij konden kiezen uit een enorm schema van presentaties. Daarnaast is er de Solutions Showcase waar alle sponsoren proberen om met de leukste swag en meest creatieve spelletjes contact te leggen met de bezoekers. 

"Ik vond het leuk dat je op een andere manier in aanraking komt met alle verschillende tooling en oplossingen voor bijv Kubernetes. Ik kende een hoop nog niet en vaak als je op internet gaat zoeken kom je die ook niet altijd tegen."

"De gezelligheid en enthousiasme van iedereen op KubeCon. Maar met name de talk over Efficient Access To GPU Resources van twee K8s engineers werkzaam bij CERN. De mensen hadden veel plezier en veel kennis en de Use Case is heel uniek en heel interessant."

"Ik vond het inspirerend om te zien hoe veel mensen bezig zijn met mijn vakgebied."

"Een tutorial talk over networking voor containers. Het was soms iets te basics, maar het raakte een aantal interessante punten voor een blog die al een tijdje in m'n hoofd zit. Heb meteen zin om er mee aan de slag te gaan!" Talk: Tutorial: Measure Twice, Cut Once: Dive Into Network Foundations the Right Way! - Marino Wijay & Jason Skrzypek, Solo.io

CINQ is niet de enige die mooie sets weggeeft, sterker nog: er wordt héél veel LEGO aangeboden bij de verschillende booths. Peter won de raffle bij de IBM booth en ging naar huis met de LEGO Star Wars Republic Gunship.

Donderdag is de tweede dag van de conferentie en is er weer een boordevol schema aan presentaties, lightning talks en spelletjes. Voor de fanatiekelingen is er om 06.30u al een hardloop 'fun run' en om 09.00u begint de dag met de openings-keynotes. Onze stand is vanaf 10.30u geopend en ook op dag twee maak je kans op een vette LEGO set -  als je de high-score haalt in KubeDoom. Je vindt de CINQ booth in de Daffodil Zone op plek S76. Zien we je morgen?

KubeCon + CloudNativeCon Europe 2023 dag 1 zit erop en in deze post lees je een kort verslag van onze eerste dag op de conferentie.

CINQ op KubeCon + CloudNativeCon

KubeCon + CloudNativeCon dag 1

Als DevOps Engineer bij een klant gebruiken we Terraform voor het beheer van de infrastructuur via code (IaS). Dit biedt ons vele voordelen, zoals de mogelijkheid om efficiënter te werken en menselijke fouten te minimaliseren. In deze blog zal ik mijn ervaringen met Terraform delen, en zal ik voorbeelden geven van hoe we Terraform gebruiken voor het beheer van alerts op Google Cloud Platform.

Terraform is een open-source tool van HashiCorp die wordt gebruikt voor het beheer van de infrastructuur via code. Met Terraform kunnen we de infrastructuur definiëren en beheren door middel van code, in plaats van handmatig te werken via een webconsole of terminal. Terraform maakt gebruik van een declarative syntax, wat betekent dat we ons niet bezig hoeven te houden met de onderliggende details van de configuratie.

Terraform biedt vele voordelen ten opzichte van traditioneel handmatig beheer van de infrastructuur, waaronder:

Efficiëntie: Door het gebruik van code kunnen we sneller en efficiënter infrastructuur configuraties beheren. We kunnen ook snel wijzigingen aanbrengen in de code, in plaats van handmatig wijzigingen aan te brengen via een webconsole of terminal.

Versiebeheer: Door de infrastructuur configuratie te beheren via code, kunnen we gebruikmaken van versiebeheer en samenwerken met andere teamleden. We kunnen wijzigingen in de infrastructuur configuratie bijhouden en terugdraaien indien nodig.

Herbruikbaarheid: Terraform stelt ons in staat om code te hergebruiken, wat het beheer van complexe infrastructuur configuraties vereenvoudigt.

Minimalisering van risico's: Terraform minimaliseert het risico op menselijke fouten, aangezien we werken met code in plaats van handmatig werken via een webconsole of terminal.

Hoewel Terraform vele voordelen biedt, zijn er ook enkele uitdagingen bij het werken met Terraform. Enkele van deze uitdagingen zijn:

Complexiteit: Het beheren van complexe infrastructuur configuraties kan uitdagend zijn met Terraform. Het is belangrijk om de code zo goed mogelijk te structureren en te documenteren om de complexiteit te minimaliseren.

Tools en integraties: Terraform vereist vaak de integratie met andere tools en services, wat extra werk en configuratie vereist.

Foutopsporing: Foutmeldingen kunnen soms complex/ingewikkeld zijn, vooral als je niet bekend bent met het Terraform-ecosysteem. Maar door ervaring op te doen en kennis te vergaren, kunnen deze uitdagingen worden overwonnen.

Bij de klant gebruiken we Terraform voor het beheer van verschillende aspecten van de infrastructuur op Google Cloud Platform, waaronder alerts.

Om een voorbeeld te geven van hoe we Terraform gebruiken, zal ik hieronder een vereenvoudigd voorbeeld laten zien van hoe we alerts beheren via Terraform. Dit voorbeeld maakt gebruik van Stackdriver als monitoringtool.

resource "google_monitoring_notification_channel" "email" {
  display_name = "My email channel"
  type         = "email"
  labels = {
    email_address = "my-email@example.com"
  }
}

resource "google_monitoring_alert_policy" "alert_policy" {
  display_name  = "High CPU usage - Alert Policy"
  combiner      = "OR"

  conditions {
    display_name = "High CPU usage"
    condition_threshold {
      filter      = "metric.type=\"compute.googleapis.com/instance/cpu/utilization\" AND resource.type=\"gce_instance\""
      duration    = "60s"
      comparison  = "COMPARISON_GT"
      threshold_value = "0.8"
      trigger {
        count = 1
      }
    }
  }

  notification_channels = [google_monitoring_notification_channel.channel.name]
}

In dit voorbeeld gebruiken we Terraform om een email notificatie channel te maken en een alert policy te definiëren op basis van hoge CPU-gebruik voor alle VM's die draaien binnen GCP. Wanneer het CPU-gebruik wordt overschreden (in dit geval 80%) voor een duur van 1 minuut, wordt er automatisch een email verzonden naar de opgegeven channel.

Hopelijk heeft dit voorbeeld je een idee gegeven van hoe krachtig Terraform kan zijn voor infrastructuurbeheer via code.

Wat is Terraform? Waar gebruik je het voor? Wat zijn de voor- en nadelen? In dit blog deelt DevOps engineer Sefa Yavuz zijn ervaringen met Terraform aan de hand van een concreet voorbeeld.

Infrastructuur als code met Terraform

CINQ ICT lanceert deze maand een nieuwe dienst: de KubeScan. Dat doet de Kubernetes Certified Service Provider op KubeCon in de RAI Amsterdam. De KubeScan is specifiek ontwikkeld voor bedrijven die de eerste stap willen zetten naar containerisatie met Kubernetes.

Veel organisaties moderniseren hun IT-landschap door naar de cloud te migreren en door hun softwareproducten in containers te verpakken. De vervolgstap is container-orkestratie door Kubernetes. Dit complexe proces vereist specifieke expertise. Voor bedrijven die op zoek zijn naar schaalbaarheid en flexibiliteit voor hun digitale producten, is de KubeScan van CINQ ICT de oplossing.

“Sommige bedrijven hebben al ideeën over hoe ze met Kubernetes willen werken en vragen om een second opinion, terwijl anderen nog moeten starten met een plan”, vertelt Stefan Koppelaar, commercieel directeur bij CINQ ICT. “De KubeScan biedt in beide gevallen een uitgebreid advies en plan van aanpak. Eventueel gevolgd door de implementatie van de oplossing en training in Kubernetes. Zo beginnen bedrijven met een betrouwbaar en kostenefficiënt fundament aan hun migratie naar de cloud.”

CINQ ICT heeft de KubeScan al bij diverse bedrijven mogen uitvoeren. Zo ontdekten een uitgeverij, een bedrijf dat payroll software maakt, en een softwarebedrijf voor banken en verzekeraars, al het potentieel van Kubernetes voor hun organisatie. 

“Bedrijven die software ontwikkelen, zijn voortdurend op zoek naar manieren om de werking hiervan te verbeteren”, vervolgt Koppelaar. “Ook omdat ze te maken hebben met verschillende IT-omgevingen bij hun klanten. Kubernetes is een populaire oplossing om op een gestandaardiseerde manier software sneller naar een werkende productieomgeving te brengen.”

CINQ ICT is van 19 tot en met 21 april te vinden op KubeCon + CloudNativeCon Europe 2023 bij stand S76.  

CINQ ICT lanceert deze maand zijn KubeScan tijdens KubeCon in de RAI Amsterdam. De KubeScan is specifiek ontwikkeld voor bedrijven die de eerste stap willen zetten naar containerisatie met Kubernetes. Lees hier meer.

CINQ ICT lanceert KubeScan op KubeCon Amsterdam

After a few years as a Splunk Administrator it was finally time for me to get my Splunk Enterprise Architect certification. In this blog I will share my journey through the different courses and what I did to prepare myself for the practical and theoretical exams.

Before starting your Splunk architect courses you should have the following certifications:

Make sure these certifications are still valid since they expire  3 years after obtaining them. You can still follow the courses for Splunk Enterprise Architect if they have expired, but you will not be able to take the last exam at Pearson VUE until you renew them both.

These are the three courses you have to follow:

Architecting Splunk Enterprise Deployments 

During two of the three required courses you will have access to lab environments, use the time you have left after completing the assignment to look at the assignments and make notes on the commands you used.

Make sure you make notes during the courses about best practices and things like search factor/replication factor and site settings, these notes will help you out when you take the practical lab.

Since you are required to do a practical lab to obtain the Enterprise Architect certification I highly recommend building your own Splunk environment lab. If you have a pc or laptop with 16 GB you could use a couple of VM’s with minimal cpu/memory (1/1GB) to build your own Splunk clusters.  For a cluster you could build something like the following set up:

A virtual machine for the license manager, manager node and deployment server role.

2 virtual machines for an indexer cluster

A single search or if you really have some resources left you could make 3 virtual machines as a search head cluster and use the license/manager node as a deployer.

For a license you could request a developer license at:

https://dev.splunk.com/enterprise/dev_license/

That way you really get some experience with setting up a Splunk environment.

For the practical lab you have a Webex call the first 4 hours with one of the Splunk trainers.

Use these 4 hours to make sure that you understand what you should be building. Don’t start at the beginning without looking at all the steps that you should be going through.

Once you have all the information you need to build a Splunk environment you can start but make sure you take notes during the configuration.

You will get 24 hours to complete the environment and sent a mail to the trainer, if you have built Splunk environments in the past then you could finish in 4 to 6 hours. If you have never build a Splunk environment then it will likely take about 10 hours so make sure you have enough time allocated in your calendar to focus on the practical lab.

Once you have passed the practical lab you will get access to the exam at Pearson VUE if you have the power and admin certification, this one is just like any other Splunk exam. Make sure you read through all the provided documents and your notes from the courses  and you should be able to pass this exam and become an official Splunk Enterprise Architect.

https://www.splunk.com/en_us/pdfs/training/splunk-enterprise-certified-architect-track.pdf

Prepare yourself for your Splunk Enterprise Certified Architect exam with tips and tricks from our Splunk consultant.

How to prepare for the Splunk Enterprise Certified Architect exam

Today I am going to talk about refactoring legacy code. When I say “legacy code” I mean code that has been created by another developer, who isn’t around to explain how the code works. You certainly have seen that kind of code at some point in your career. Code that someone else made, undocumented, messy, hard to read, hard to understand and definitely hard to maintain. 

This is the first in a series of posts that will cover the subject of refactoring. In this part I am going to give you some pointers on how to start cleaning up that mess. In the next post I will show you how I would make the code better maintainable and do the actual refactoring. 

I have used the racing-car-kata of Emily Bache (Independent Technical Coach and  author of "The Coding Dojo Handbook") as a starting point and inspiration to write this post. And as always I will share the GitHub link of my take on this kata at the end of this post. 

Imagine this: You have just been hired by the “Red Bull Racing” team as the hotshot developer. They have put you in charge of the Telemetry Monitoring System. You are responsible for monitoring the condition of Max's racing car. They have already developed a service that continuously measures several aspects of the engine, wheels, brakes, etcetera and it gives you instant feedback on the condition of the various components. 

Excited as you are, you decide to do a quick git clone of the repository, crank up your favorite IDE and open that project just to take a peek at that awesome piece of code. Then in a matter of just a few minutes your joy and excitement disappears like snow in the sun. No tests. No documentation. Crappy code. Good luck!

For demonstration purposes the code that I am about to show you is simple, but just imagine that this code is part of a huge code base. The idea is like this. We have two classes:

The TireSensor is just a fake sensor because in this exercise the refactoring focus is solely on the AlarmService. Just for the sake of argument pretend that this is an actual implementation of a sensor that communicates over TCP/IP. The sensor measures the pressure of a tire. To simulate a real sensor, every time the measureTirePressure method is called, it returns a random number between 22.5 and 30.5 which represents the actual pressure of the tire.

When you take a look at the AlarmService you’ll see that the service measures the pressure of a tire. When the pressure is either too low or too high the alarm is switched on. AlarmStatus is a simple enum which has two values that represent the actual status of the alarm. It can either be ON or OFF.

Although the code in this service class is small and the working of the code is fairly straightforward, it contains quite a few code smells and moreover it doesn’t have any unit tests! Time to do something about it.

The first thing you have to do when you start working on the code is resist the urge to start hacking away. No. Seriously. Don't do it! As mentioned earlier the code doesn’t have any unit tests. That is the very first thing you should be focussing on before you even start to think about refactoring! Because as a real boy scout you should not want to change any production code when the code isn’t covered by unit tests. Let’s write the tests and get going!

Quickly you start writing the first test but soon you discover that testing this code is harder than it looks. The main reason that makes it so hard to write the test is because of the call to the measureTirePressure method in the TireSensor class. When writing unit tests most of the time you want to assert some expected output. In this case you want to assert that the alarm is correctly switched on when the pressure is not within a given range. 

Given the fact that the method measureTirePressure returns arbitrary/randomized values we can’t assert anything. The result would be a flaky test at best. In order to bring the code under test we have to modify the production code a bit. But, as mentioned earlier, we don’t want to alter any production code if there are no covering tests in place! We’ve got a catch-22 on our hands. This is one of the reasons why some developers don't even bother to start writing unit tests. "Too much hassle". "We'll do it live!". Famous last words!

This time we won't do it live! To circumvent the chicken-or-the-egg problem I tend to bend the rules a little bit. Not breaking, just bending. I still do not change production code. Unless it is to bring the code under test AND the modification can be executed as an automated simple refactoring by the IDE. 

In general when writing a unit test you want to have absolute control of its collaborators. Control over the collaborators enables you to test your business logic in total isolation. This makes your unit tests fast, repeatable and reliable. You can achieve this by creating a mock of a collaborator, inject it in your class and use the mock instead of the real object. In our case we want to have a mock of the sensor that we can use in our tests, preferably by using a framework like Mockito. In that way you control the behavior of the sensor and make those arbitrary values that the real sensor produces be a thing of the past.

There is only one problem. The sensor is instantiated inside the AlarmService. In other words, there is a hard/direct dependency between the two objects. The AlarmService depends on the concrete implementation of the TireSensor.

Because of the hard dependency we can't mock it directly with Mockito. Well… That's not entirely true. With Mockito (or by using reflection and doing it yourself) we could use field injection in our test which is very easy to use and looks clean. 

Very tempting but field injection would not be my preferred choice of injecting because field injection (in comparison to constructor based injection) hides the dependencies that the class needs. You need to dive into the internals of the class itself to see all the dependencies the class needs. Also, a developer could (because it is so easy and clean looking) inject too many dependencies which could lead to the class doing too many things and breaking the single responsibility principle.

To avoid all that and break the hard dependency we can use the "extract and override" technique instead. It would enable us to inject the mock directly into the service and test it that way. How does it work? I will explain this in the next section.

The goal of the extract and override technique is to separate the business logic that belongs to the class from the calls that are made to the collaborators. 

Since the call to the measureTirePressure method is the call that we want to have control over in our tests we are going to make a seam. A seam in software development is a place where two classes interact with each other. An often used analogy is a seam in clothing, being the line where two pieces of fabric are stitched together. 

For years the IDE of my choice has been IntelliJ. With IntelliJ we can easily extract a method in an automated fashion. It's just a matter of selecting the method, pressing Ctrl + Alt + M, making sure that the method is protected and there you go! We have created our seam.

You might think: what does extracting that code into a separate method bring us? Good question! Absolute control over the sensor.

In our test code (AlarmServiceTest) we can now create an inner class (TestableAlarmService) that extends the AlarmService and overrides the logic in the seam. We are now able to make the sensor return any value that we want, when we want! Finally! We can start doing some real unit testing now.

I want to keep the TestableAlarmService  as lean and mean as possible. The reason for keeping it simple is that the need for the "extract and override" technique is a sure sign of a very big code smell in your production code. The TestableAlarmService is just a temporary solution. At the end of this whole refactor exercise I want this TestableAlarmService madness expelled from my code base and peace will then be restored in my project. But for now, we go with this solution to break the hard dependency that the service has on the sensor. 

In my TestableAlarmService I am overriding all the seams of the actual AlarmService that contain the code that I want to mock. Only thing left to do is injecting the mock in the subclass. And by doing this the mock has been separated from the actual business logic that I want to test.

TestableAlarmService is ready. Now it's time to start covering all the business logic in the AlarmService and add those tests. Analyzing the AlarmService I come up with 5 different scenarios, they are:

Alarm should be off when the service has been initialized.

Alarm should be off when the pressure is optimal

Alarm should be activated when pressure is too low

Alarm should be activated when pressure is too high

Once the alarm is activated it should stay activated regardless of the pressure values measured after that

In the first scenario there is no interaction with the sensor, so therefore we can instantiate the AlarmService and assert that the alarm is off. In the other scenarios there is interaction between the service and the collaborator. This is where our TestableAlarmService comes into play. We can instantiate and use the TestableAlarmService and assert the alarm status as you would normally do.

You probably noticed that I am using @ParameterizedTest in my test class. Parameterized tests enable me to run a certain scenario (test case) multiple times and provide different values for the pressure I want the sensor to return. Handy for testing obvious values and edge cases without having to write the same test twice. 

The @ParameterizedTest annotation is available in JUnit 5. I hope not, but if you are still using JUnit 4 you'll have to use a third-party library to enable parameterized tests. JUnitParams is a good example of such a library. 

Tests are done. Life is good. Time to check if my AlarmService is fully covered by the tests. I run the tests with code coverage statistics on and, as you can see in the next screenshot, all the business logic is covered. Everything except for the seam, but that is expected. Keep in mind that the seam will be a temporary thing. The main point that I want to bring across is that all the business logic which we are interested in has been covered by tests.

Alright! Not bad at all. We are done for the day. Halfway there. A lot of work has been done already:

We discovered that it isn't always easy to bring existing code under test because of hard dependencies.

We resisted the temptation of using field injection in our tests.

We have seen that hard dependencies can be broken with the extract and override technique.

We noticed that once these dependencies are broken it is really easy to test our business logic.

Looking at the code it is far from what we ultimately want but it is much better than what it was when we began. We are in pretty good shape to finally start refactoring. 

In my next post I will cover the actual refactoring of the service and we will finally be freed from those horrible code smells. 

The code is available on my GitHub. The starting position can be found here:

https://github.com/vlouisa/tire-pressure-kata/tree/tpms-service

The result of bringing the code under test can be found here:

https://github.com/vlouisa/tire-pressure-kata/tree/tmps-service-under-test

Software engineer Victor Louisa shows us how to refactor existing code in a series of blogposts. In the first post of the series he explains how to clean up code from someone else before you can actually start refactoring.

Refactor that ugly code

Refactor that ugly code (part 1)

When you are visiting Amsterdam for KubeCon + CloudNativeCon Europe 2023 in April, I hope you will also have some time to stroll around our beautiful city. And if you do, check out these places that are amongst my personal favourites! This list features a lot of craft beer, arcade games, hidden food gems and a few special museums. Hit me up on Twitter when you are in town!

If you are looking for a place to unwind from the conference with a drink and some snacks, there are multiple great options within walking distance from the RAI convention center.

Tap Zuid, which is less than 10 minutes away from the RAI by foot, has 25 different beers on tap and they serve beers from almost all of the 30+ Amsterdam craft beer breweries. They also have a nice dinner menu with burgers, flammkuchen & other options.

You are lucky, because in April StrandZuid opens their terrace again. This restaurant / bar has an amazing floating terrace and especially on Friday afternoons there is a great vibe with all the locals who are celebrating the start of their weekend. Obviously, they serve a wide range of snacks, including bitterballen! And the best part? It’s actually connected to the RAI so if your legs are tired from roaming around the conference all day, this is the place for you.

Located in the middle of the famous Vondelpark, you will find Proeflokaal het Blauwe Theehuis from Brouwerij ‘t IJ - one of Amsterdam’s finest craft beer breweries. On their large terrace they serve a selection of their beers from the tap, sandwiches, pizzas and other snacks. A perfect place to hang out after you’ve strolled through the park. You can also play table tennis or “jeu de boules” there.

They also have a taproom underneath Amsterdam’s largest windmill, where their first brewery is also located. When the weather is nice, they have large tables outside where people can mingle and enjoy their beers in the sun. 

Looking for a typical Amsterdam “brown cafe”? There are many, but one of my absolute favorites is Cafe de Poort. It has been located on this spot on the Haarlemmerdijk since 1899, and this street has been named the best shopping street in Amsterdam! It is just 10 minutes from the Amsterdam Centraal train station. 

Another institution when it comes to brown cafes is Cafe Hoppe. This all-day cafe serves breakfast, sandwiches and is located in the heart of the city center. The Dam square with the Royal Palace and Amsterdam’s biggest shopping street Kalverstraat are just a few minutes away. Cafe Hoppe attracts a very diverse crowd and is bustling just about every day! 

Amsterdam has a lot of different kitchens to choose from, because of all the varying cultures living in the city. For the very best lahmacun (also known as Turkish pizza) in town: you have to go to Effendy on the Rozengracht. This long-time family owned business serves a perfect lahmacun with crispy dough and they have multiple options for the filling. The original with kebab is great, but also give the vegetarian one with spinach and feta cheese a try! 

Located in the “Old-West” part of Amsterdam, indoor food valhalla Foodhallen has a big bar in the middle surrounded by more than 20 different stands that serve food. From sushi to Dutch meatballs, pizza to Vietnamese streetfood and many many more. The Foodhallen is located in a building called “de Hallen” - which used to be where trams were serviced, there is also a movie theater and art studio. 

Located in the beautiful Westerpark, make sure to pay a visit to TonTon Club to get your fix of arcade & board games. Their arcade section has Mario Kart, 4-player Pacman, Game of Thrones, Dance Dance and multiple (not so standard) air hockey tables. Add in their big selection of board games, a lot of different beers and a very nice selection of Japanese snacks and you will have the time of your life. 

While you’re in Westerpark, do NOT, I repeat do NOT, just walk past Dumplings without ordering at least one of their plates of freshly made Dim Sum or Jianbing (“Peking crêpes”) . It is just a small kiosk but don’t let the looks of the place fool you: their food is a-ma-zing!

Amsterdam has a world-famous museum district, home to three of the most iconic museums in the country: Rijksmuseum, Stedelijk Museum and Van Gogh Museum. However… you may want to check out these other modern hotspots as well. 

Our House This modern museum celebrates our rich history in the world of electronic music.  Located in the heart of the city center, near the Rembrandtplein with a lot of bars and cafes in the area. Our House is a modern museum about electronic music culture. Discover the evolution of electronic dance music through this high-tech, audio-visual exhibition, told in numerous interactive installations. "Our House" takes you on a 75-minute digital journey through the music genre by means of a range of interactive exhibitions, shows, and performances, telling the story of how it evolved from a rebellious underground community to a global cultural phenomenon. If you are a lover of electronic music, this is the place to be! 
https://www.our-house.com/  

Looking for a thrill? AMAZE is a 1 hour audiovisual immersive walk-through experience. In 7 separate stages, they take you on a journey that stimulates all senses and takes you to a deeper layer of consciousness. You’re in for quite a ride!
Info & tickets: https://amaze-amsterdam.nl/ 

On the other side of the IJ river, on the NDSM Wharf there is STRAAT - a museum dedicated to street art and graffiti. Located in an old shipyard, they currently show an exhibition focused on women in street art. You can take the free ferry to NDSM from behind Amsterdam Central Station, which is a nice 15 minute ride with great views of the city and the A’dam Tower and EYE Filmmuseum. For more info and tickets go to https://straatmuseum.com/en/equalopportunities.  

Visiting Amsterdam for KubeCon + CloudNativeCon Europe 2023? This is were you need to go foor drinks, food and arcade games!

Must visit places in Amsterdam during KubeCon + CloudNativeCon Europe 2023

Must visit places in Amsterdam during KubeCon + CloudNativeCon Europe

In this blog we will state some of the changes and challenges you might face when you upgrade from Splunk 8.2x to Splunk 9.0.4. After reading this blog and checking the latest release notes you should have a better understanding of the upcoming changes when you upgrade to Splunk 9.

Starting with Splunk 9 the classic dashboards should now use a version number, if you do not have a version number the user will see the warning below:

All dashboards that contain the <dashboard> tag will automatically receive the version when upgrading to version 9.0.4. If you upgrade to a lower version you have to add the version=”1.1” yourself. Any dashboards that contain dropdowns will contain the <form> tag instead of the <dashboard> tag. These will not get the version=”1.1” and you have to manually add the version to no longer show the warning.

We recommend to use 9.0.4.1 since 9.0.4 contains a known issue for dashboards that contain <set tokens (found this information on the Splunk Slack):

And this means that the token will no longer work and the dashboard functionality that depends on that token breaks.

To find out if you have any dashboards that might be affected you should run this search that was shared by Becky Burwell on the Splunk Slack:

| rest /servicesNS/-/-/data/ui/views splunk_server=local 
| rename eai:data as DASHBOARD 
| fields id author Type title eai:acl.app DASHBOARD 
| rename author as Owner, title as Name 
| fillnull value=NONE Owner Type AppName Name, DASHBOARD, 
| search  Owner!=nobody  
| xpath field=DASHBOARD outfield=token_name "//condition//set[not(text())]/@token" 
| where mvcount(token_name) > 0 
| mvexpand token_name 
| eventstats dc(Name) as num_dashboards
| table num_dashboards, Owner Name, token_name, DASHBOARD

The workaround is to manually change these dashboards before upgrading to Splunk 9.0.4 by adding version=”1.1” into the <dashboard or <form tag. 

It was stated that this is fixed in version 9.0.4.1 that was released on the 17th of March.

Please note that any dashboards in etc/apps and etc/users will be changed by upgrading, any dashboards that are pushed by deployers in etc/shcluster/apps will not be changed. So pushing apps with dashboards in the default folder without version=”1.1” might undo the changes done on the search heads and show the warning again for users.

With Splunk 9 Dashboard studio now supports the usage of tokens, this is one of the most requested feature for Dashboard studio dashboards. You can now set default tokens or pass tokens when linking to other dashboards , this opens the linked dashboard with the token values so you can see the right information without having to select the options again.

To read all about these changes please see the links at the bottom.

There is a new option to help admin troubleshoot, there is a new index called _configtracker. This index will contain changes to .conf files and their key value pairs. This makes seeing what was changed and when it was changed so much easier without using 3rd party tools.

If you receive ip information in you Splunk environment you can enrich that ip information with the iplocation command. This adds the following fields by default to the results:

City, Country, Region, _time, lat, and lon

Splunk ships its software with a Maxmind database containing this information. It normally gets updated when you upgrade to a new Splunk version. For some use-cases the data needs to be refreshed weekly to prevent the use of inaccurate data and false positive hits when checking for certain countries. To make it easier to update this information you can now update this using the GUI or by placing the file on your search heads and specifying the path in the limits.conf file. For exact instructions please visit the link at the bottom of the page.

Splunk has changed some of the names used in folders and configuration files. An important change is when you have an indexer cluster and you are pushing your apps from the master-apps folder.
 With Splunk 9 you should start using manager-apps instead of master-apps since that will be removed in a feature release. In order to use manager-apps you should copy over all files and folders from the master-apps and remove them in that location. When you start copying you also have to check your conf files for hardcoded paths, the indexer path will change from slave-apps to peer-apps, any hardcoded references to slave-apps will break. Usually paths are used for SSL configuration and you do not want that to break after your upgrade.

There are more changes in Splunk 9.0.x, please read the release notes and check out the Splunk slack channel Splunk_9_upgrade_issues to see what other users are encountering or ask for help.

Splunk Enterprise Release notes: https://docs.splunk.com/Documentation/Splunk/latest/ReleaseNotes

Splunk slack: https://splunk-usergroups.slack.com

Dashboard studio changes: https://docs.splunk.com/Documentation/Splunk/latest/DashStudio/WhatNew

Configuration change tracker: https://docs.splunk.com/Documentation/Splunk/9.0.4/Troubleshooting/WhatSplunklogsaboutitself#Configuration_Change_Tracker

iplocation command: https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Iplocation

Manager-apps: https://docs.splunk.com/Documentation/Splunk/9.0.4/Indexer/Updatepeerconfigurations#Which_directory_to_use:_manager-apps_or_master-apps.3F

Upgrade to Splunk 9 and you will find some new and improved features. Check them out here.

What's new in Splunk 9

In my humble opinion, IntelliJ is the best Java IDE out there. But even the best IDE can be improved. In this blog I will tell you why I decided to create a plugin and how this went down.

Let’s backtrack a few steps to understand why I decided to write a plugin. I was preparing to give a talk at Devoxx France. It is a live coding session that shows off features of the debugger. Every time when I prepare to give a talk, I try to update the talk. This time I decided to use the new UI of IntelliJ. No sooner said than done I applied the change and started practicing. During the first test run I noticed that there was a bug in the new UI. In the old UI I could shift click in the gutter to get a logging breakpoint. This did not work in the new UI. Furthermore I was looking for a solution to get a logging breakpoint without the use of the mouse. I was not able to find a solution for this problem. Therefore I decided to kill two birds with one stone. I decided to create a plugin that solves both problems.

So my first thought was to just create a plugin, because how difficult can that be? Those were famous last words, because it turned out to be much harder than I expected. My initial idea was to create a “proper” plugin. That is a plugin that can easily be installed by others by downloading it from the Jetbrains Marketplace. Within an hour it was clear that creating a proper plugin is hard and takes a lot of time. Luckily IntelliJ offers a simpler solution in the form of a live plugin. You can directly test your plugin in the IDE without complicated steps. This plugin does not end up in the marketplace, but is far simpler to develop. Far simpler does not mean it is simple. It still took several evenings to get it to work properly.

So the goal is to create a live plugin that will create a logging breakpoint without using the mouse. The latter part is easily solved by binding the action of the plugin to a keyboard shortcut. Creating a logging breakpoint in code is a bit harder, but before we dive into that let’s explain what a logging breakpoint is and how you create one manually. A logging breakpoint is a breakpoint that only logs something and does not suspend. Both these breakpoint options (logging and non-suspending) are relatively unknown. But you can easily create a logging breakpoint by first creating a simple line breakpoint and then changing its properties. You have to make the breakpoint non-suspending (so it should not pause the execution of your program) and it should have a logging expression. The screenshot below shows how this would look like in IntelliJ.

Picture 1 - A logging breakpoint in IntelliJ

So doing it manually is pretty straightforward and now it is time to do this with a live plugin. The first step is to install the live-plugin plugin from the marketplace. This enables the live plugin functionality. The second step is to write the live plugin itself. You can choose between Groovy or Kotlin when creating one. I decided to go with the latter, because I am more familiar with that language. 

After looking at some example plugins I decided it was time to start writing my own. I broke the problem down in the following sub-problems:

show a notification when pressing a keyboard shortcut

set a simple breakpoint when pressing the shortcut

modify the breakpoint so it becomes a logging breakpoint

use the current selection to determine what to log

Let’s start with the first, showing a notification when pressing a keyboard shortcut. I copied an existing plugin from a tutorial that did exactly this and started modifying it. The only modification that it needed was changing the keyboard shortcut. This was relatively easy and within fifteen minutes I had this sub-problem solved. On to the next one!

The goal here is to set a simple breakpoint when pressing the right key combination. My plugin already reacted to the correct key combination, so I only have to create a breakpoint. This is where it became pretty complicated. I had no clue which API to use. So I spend several hours browsing through the IntelliJ API documentation to get a vague direction. Then I browsed a lot of classes in the com.intellij.xdebugger package to find the first glimmers of hope. I found the class XDebuggerUtilImpl and it had a method called toggleAndReturnLineBreakpoint. This seems like the right place to start! Unfortunately the method took six parameters. I will not bore you with all the details, but let’s focus on one. The method needs a list of breakpoint types. This sounds logical, because it needs to know the possible types of breakpoints it can set. But the type of parameter looks like this: List<XLineBreakpointType<P extends XBreakpointProperties> extends XBreakpointType<XLineBreakpoint<P>, P>>. Okay, this is not for the faint of heart. Several hours later I got the hang of it and I was able to create a simple breakpoint by pressing the right keyboard shortcut. Hooray!

The next step is to modify this breakpoint so it will not suspend the execution of the program and it will log something. This part was pretty straightforward. The methods mentioned above returned a promise with a breakpoint in there. After using two simple setters the simple breakpoint became a logging breakpoint. The sweet smell of victory is almost mine!

Next up is using the current selection to determine what will be logged. The idea is that the user selects a variable and the breakpoint will log the name and the value of the variable. It should also work when selecting an expression. In that case it will print the expression and its outcome. It is pretty simple to get the selected text and to use this to create the desired logline. Only one subproblem remaining!

The last one is putting the breakpoint on the next line. This needs a little bit of explaining, because initially I thought that putting the breakpoint on the same line would be fine. It turns out that this does not work well when creating a variable. When you set a breakpoint it will pause the execution at the beginning of the line, so before it creates the variable. If the variable does not exist yet, it is impossible to read and log its value. Therefore I decided to put the breakpoint on the next line. This turned out to be too simplistic, because the next line could be a whiteline and those do not support breakpoints. The final solution is to put the breakpoint on the next line that supports breakpoints. I learned a lot about caret models, cursor offsets and source positions, but several hours later I had a working prototype!

So with this plugin I do not need to use the mouse when creating a logging breakpoint. Furthermore I can quickly create logging breakpoints while using the new UI. Just selecting a variable and pressing the right keys on the board is enough.

The final result can be found on Github: https://github.com/BoukeNijhuis/devoxxfr2023/blob/main/.live-plugins/plugin.kts. The file plugin.kts is in the .live-plugins folder so the live-plugin plugin will automatically load the plugin whenever the project is opened in IntelliJ.

So after some evenings of writing a live plugin it is time to create a “proper” plugin which can be easily installed from the JetBrains marketplace. But this is a story for another time. Once this time arrives I will write another blog about it.

How to write an IntelliJ plugin that creates a logging breakpoint without a single click.

How to write a simple IntelliJ plugin

Recently I had to do something that wasn’t exactly in my wheelhouse. It also was kind of a one-off thing. I had to provide an initial load. In this case it meant that I would receive a huge csv file and somehow had to turn it into one big XML file. And if that wasn’t bad enough… They needed the XML file yesterday!  After a quick Google search there it was… Spring Batch! Initially I thought this is overkill for a one-off type of thing. But nevertheless I decided to give it a shot. And guess what? Within a few hours I had cooked up a pretty good solution. So not bad at all!  In this blog I am going to show you how easy it is to build a Spring Batch component (backed up by Spring Boot) that will transform a csv file into an XML file.

The objective sounds simple. I have a csv file which could look something like this:

711 Ocean Drive;Joseph M. Newman;Crime drama;Columbia
Abbott and Costello in the Foreign Legion;Charles Lamont;Comedy;Universal

and somehow I have to turn this csv file into this:

<?xml version="1.0" encoding="UTF-8"?>
<Movies>
   <Movie>
       <Title>711 Ocean Drive</Title>
       <Director>Joseph M. Newman</Director>
       <Genre>Crime drama</Genre>
       <Remark>Columbia</Remark>
   </Movie>
   <Movie>
       <Title>Abbott and Costello in the Foreign Legion</Title>
       <Director>Charles Lamont</Director>
       <Genre>Comedy</Genre>
       <Remark>Universal</Remark>
   </Movie>
</Movies> 

Spring Batch to the rescue! To make this work the Spring Batch application needs these things:

some configuration to glue it all together (Job Launcher, Job Repository, Job & Step)


How to use Spring Batch to process a .csv file to XML.

Onze laatste blogs