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)


But first we have to import some Maven dependencies.

  <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-batch</artifactId>
   </dependency>

   <dependency>
       <groupId>org.hsqldb</groupId>
       <artifactId>hsqldb</artifactId>
       <version>${h2.version}</version>
       <scope>runtime</scope>
   </dependency>

The most important dependencies are the spring-boot-starter-batch for our out of the box batch functionality and the hsqldb for storing all the job information and other non-interesting stuff that Spring needs to execute the job. 

For the full list of dependencies I suggest checking out the project from my GitHub. You can find the link to my project at the end of this blog.  

First up is the configuration. We create a configuration class and enable the batch mechanism by using the @EnableBatchProcessing annotation. This is an important little thing to do because if you don’t place the annotation on top of that class the whole thing will not work!

In this configuration class we define the input file (our csv) and output file (the XML). Also we have to inject the JobBuilderFactory and StepBuilderFactory. We are going to use these factories later on to configure our job. 

The next thing we need to do is create the Item Reader. The Reader will, as you might have guessed already, read the csv file and store the records for further processing. For storing we need to have a DTO (Data Transfer Object) so we will first create that one. Processing is on a per record basis, so we just need to model the record only (not the whole csv). 

Nothing fancy, nothing exciting… just a DTO.

Now it’s time to implement the reader. This will be a bean in the SpringBootBatchConfig class. It goes too far to put all the code in here so I suggest checking out the code from my GitHub and see what it exactly does and what it is made of but here is the snippet for my ItemReader.

Two things to note. This reader needs the input csv file so we have to set the Resource and it also needs a mapper for mapping the csv data to the Movie DTO.

Creating the mapper is as easy as implementing the Spring Batch FieldSetMapper interface and mapping the fields of the csv into the DTO.

We can simply read each field in the csv by using the readString method which accepts the index of the field you want. readString(0) for reading the first field of the record, readString(1) for the second field and so on.

Reader… Implemented! Next up is the Item processor. The processor will execute for each record in our csv. ItemProcessor is a Spring Batch interface. All the processor really does is accept an object from the ItemReader and pass it on to the ItemWriter. 

We only need to implement the processing logic which is basically mapping the Movie DTO (which was used during reading) to another DTO which represents the XML “record” (or XML node to be more precise). 

The XmlMovieDTO is annotated with @XmlRootElement to define the name of the movie node that will be used in the XML file. Because we annotate the fields with @XmlElement (and not the getters) we also have to annotate the class with @XmlAccessorType(XmlAccessType.FIELD). If you don’t do that then your application will complain that it has two properties of the same name and you are treated to several IllegalAnnotation exceptions! 

And that’s it for the processor. Movie in… XmlMovie out. 

Almost there. We just need to implement the writer and do some configuration and we are done. But first things first. Let’s implement the writer. The writer is also implemented as a bean in the SpringBootBatchConfig class.

Here we have to create a StaxEventWriter, which is an XML writer. It needs a marshaller for converting the XmlMovieDTO object into actual XML, a root tag name for the root element/node of the XML and the location (Resource) where the XML output file is going to be placed.   

To tie all of the components together and make it work we have to configure a job. A job can have several steps. In our case we just need one step in the job. 

When you look at the step method you see that this is the place where it all comes together. The reader, the processor and the writer. And that is all! Just run the application and your csv file will be turned into an XML file in no time. 

Did you notice that I didn’t even talk about the Job Repository and the Job Launcher that were shown in the overview picture? That’s because I don’t have to. Spring Batch takes care of all the low-level boring stuff and you can focus on the actual business logic.

The full working example can be found on my GitHub: 

https://github.com/vlouisa/spring-batch-demo/tree/master

As a bonus I added a version of the application that can transform the same input file into files with a different output format (JSON & XML). Switching between formats is handled in the application.properties file. Just set the correct profile and there you go!

The multiple output format version can be found over here:

https://github.com/vlouisa/spring-batch-demo/tree/multiple-output-format

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

Spring Batch CSV to XML

Spring Batch to the rescue

Verblijven in een kasteel, 3 dagen lang zon, sneeuw, prachtige pistes en hier en daar een kleine après-ski 🍻 - dit was de CINQ Wintersport 2023! 

🔸 CINQ WINTERSPORT 2023 | ZELL AM SEE 🔹

Lijkt dit jou ook wel wat? Bekijk onze vacatures en wie weet sta jij volgend jaar met ons op de piste!

Aftermovie CINQ Wintersport 2023 Zell Am See

In deze video vertellen Robin Jonkers en Bouke Nijhuis hoe wij ervoor zorgen dat jij gelukkig bent met je opdracht en hoe wij helpen bij jouw ontwikkeling.

Werken bij CINQ - Precies wat ik zoek!

Nieuw bij CINQ: De Speaker Academy. In een viertal avonden gaan collega Bouke Nijhuis en internationaal spreker Brian Vermeer acht collega’s opleiden tot potentiële sprekers. Bouke en Brian hebben beiden ervaring als spreker op conferenties in binnen- en buitenland zoals J-Fall, JavaZone en Devoxx. Tijdens de CINQ Speaker Academy delen zij hun ervaringen en bereiden zij de deelnemers voor op het spreken op conferenties.  

Bekijk de video waarin Bouke vertelt over zijn ervaring als spreker en hoe het idee voor de CINQ Speaker Academy is ontstaan. 

Werken bij CINQ - Speaker Academy

Het doel van de Speaker Academy is om de deelnemers klaar te stomen voor een presentatie op een conferentie. 

hoe schrijf je een goed voorstel (paper)?

hoe maximaliseer je je kansen om geselecteerd te worden?

Tijdens de avonden worden de deelnemers voorzien van de benodigde kennis, en gaan ze vooral ook veel oefenen met presenteren. Vervolgens zullen ze elkaar beoordelen en van feedback voorzien. Aan het einde van traject heeft iedereen een goed beeld van wat er nodig is om op een conferentie te kunnen spreken. Niet alleen het spreken zelf, maar daarnaast oefenen ze ook alle stappen die voorafgaan aan het spreken op een conferentie.

We sluiten het traject af met een interne CINQ conferentie waarbij de deelnemers hun nieuwe vaardigheden in een presentatie kunnen laten zien aan al hun collega’s. Hierna blijft Bouke beschikbaar als coach en zal hij ze begeleiden naar hun eerste “optreden” als spreker op een echte conferentie.

Wil je de voortgang van de Speaker Academy volgen? Houd dan onze LinkedIn pagina en Instagram in de gaten! 

Speaker Academy

"Daar heb je weer zo'n traject 🤔", was de eerste reactie van Bob Nieuwenhuis op de coaching die wij onze medewerkers aanbieden. Benieuwd wat hij er achteraf van vond? Bekijk dan de video! 

Bij CINQ vinden wij het belangrijk dat jij als medewerker je kunt blijven ontwikkelen. Daarbij ligt de focus niet alleen op de techniek en werk je ook aan je persoonlijke ontwikkeling onder begeleiding van een coach. 

In de video deelt Bob zijn ervaring met onze coach Joost Coolen van Helixers.

#coaching #werkenbijcinq #ontwikkeling

CINQ & Helixers

Werken bij CINQ - Persoonlijke ontwikkeling

Ik heb de afgelopen jaren veel met Kubernetes gewerkt bij onze klanten en ondertussen is het uitgegroeid tot mijn favoriete (container/cloud) platform. In onze DevOps unit bij CINQ hebben wij veel aandacht besteed aan Kubernetes met interne kennis-sessies, een reis naar KubeCon Europe '18 in Kopenhagen, ons eigen Kubernetes bootcamp-weekend in Friesland én een reis naar KubeCon in Detroit in 2022. 

Ik wilde graag mijn CKA (Certified Kubernetes Administrator) halen omdat ik in de breedste zin wilde weten hoe Kubernetes precies werkt, in plaats van alleen maar de nodige resources te gebruiken voor deployments. Denk hierbij aan de werking van de controlplane en het gebruiken van alle resources die Kubernetes tot je beschikking stelt. Dat zijn er namelijk nogal wat. Ook is het natuurlijk fijn om te weten dat je een bepaalde techniek beheerst.

Het CKA examen is een examen van 2 uur waar er van je verwacht wordt 15 tot 20 problemen/vraagstukken vanaf de commandline op te lossen in verschillende Kubernetes clusters. Een score van minimaal 66% is vereist om te slagen. 

Ik heb het examen pas ingepland toen ik er van overtuigd was dat ik de tijd zou hebben om een paar weken achter elkaar te kunnen studeren en te oefenen. Zeker ook omdat ik meerdere malen heb gehoord dat het een pittig examen is waar je goed gebruik moet maken van je tijd. 

Het examen kan je in je eigen huis/kantoor afnemen, waar je door een toezichthouder via de webcam en screensharing in de gaten wordt gehouden. Het online examen programma werkte prima. 

Hoe kun je jezelf nou zo goed mogelijk voorbereiden voor het examen? En welke punten hebben extra aandacht nodig? Hieronder geef ik 10 tips waardoor ik het examen met een score van 91% heb gehaald.

1. “Certified-kubernetes-administrator-with-practice-tests” 

Een alles omvattende cursus op Udemy door Mumshad Mannambeth. Zorg dat je de hele cursus hebt doorlopen en maak alle labs in Kodekloud. Alles wat in mijn examen werd gevraagd is behandeld in deze cursus.

Leer de kubectl commandline. Zorg dat je weet welk commando je waarvoor moet gebruiken, get, describe, logs, events, apply, etc.

Je mag de officiële Kubernetes documentatie erbij houden. Maak hier gebruik van door de cheatsheet erbij te pakken of snel te zoeken naar het onderwerp naar keuze.

Bouw een Kubernetes cluster handmatig vanaf de grond op. Alhoewel ik deze niet zo belangrijk vond als dat andere mensen die vonden, is het in ieder geval handig om het een keer te doen. Bovenstaande Udemy cursus heeft een guide om het op je eigen workstation met Vagrant en Virtualbox te doen. 

Bespaar jezelf wat tijd door de “imperative commands” te kunnen van simpele opdrachten. Denk aan: “kubectl run”, voor het deployen van simpele pods, of “kubectl expose” voor het aanmaken van een service die verwijst naar een bestaande pod. Dit zijn geen complexe opdrachten en zijn sneller uit te voeren op deze manier, in plaats van een YAML file te genereren of op zoek te gaan in de documentatie.

Zorg voor de complexere deployments dat je een YAML genereert, hergebruikt uit een eerdere opdracht of gebruikt vanuit de documentatie. Denk aan deployments met secrets of volumes. Gebruik hiervoor de voorbeelden in de documentatie en verander die naar wens.

Sla opdrachten over die je niet meteen weet, en maak deze later. Je hebt misschien de volle 2 uur nodig en elke punt is meegenomen. Vlag bepaalde vragen die je niet zeker weet om later op terug te komen.

Zorg dat je de Docker commando’s en concepten ook kent om te troubleshooten. Soms heb je geen kubectl tot je beschikking. Basic Linux kennis om te troubleshooten en opdrachten uit te voeren zoals: systemctl, nslookup, vi/vim, ps, ls, cp etc. 

Hetgeen waar CKA zich in onderscheid ten opzichte van CKAD is met name infrastructuur kennis. Zorg dat je gerelateerde opdrachten hieraan goed kunt maken. Denk aan ETCD backups, het gebruik van KubeADM, controlplane service configuratie en certificaten. Deze vragen zijn vaak veel punten waard en kosten meer tijd.

Controleer elke deployment of pods wanneer je deze hebt aangemaakt. Gebruik met de “get” of “describe” commands of jouw pods/deployments de juiste naam hebben, de juiste images gebruiken en überhaupt draaien en doen wat deze zouden moeten doen.

Met deze zorgvuldige voorbereiding en werkwijze tijdens het examen, heb ik het in één keer weten te halen. Heel veel succes met studeren en het examen. En als je vragen hebt, neem contact met ons op.

👩‍🏫In twee dagen Kubernetes Advanced training, worden onze DevOps engineers klaargestoomd voor het KCA examen.

Dag 1 zit er bijna op, tijd voor de vrijmibo! 🍻

@container_solutions #kubernetes #containersolutions #joure #cinqict #work #prep #workshop #devops #cinq

Met deze 10 tips ga je zeker slagen voor je Certified Kubernetes Administrator examen.

10 tips voor het halen van je Certified Kubernetes Administrator examen

10 tips voor het halen van je Certified Kubernetes Administrator examen (2023)

Jij bepaalt de richting, wij helpen je om je ambities waar te maken. In deze video vertelt Teun Roefs hoe we er samen voor hebben gezorgd dat hij helemaal op z’n plek zit, zowel bij CINQ als bij de klant. 😄

Werken bij CINQ - De ideale balans

Wil je een andere opdracht, een andere rol of misschien meer investeren in je eigen ontwikkeling? Bij CINQ denken we altijd met je mee.

Enthousiast geworden? We zoeken nog collega’s voor de Data unit. Neem gerust contact met ons op voor een kennismaking 😊

As a front-end developer, I work with a lot of tools to develop code. There are a few popular tools that I use and recommend for programming better front-end applications. Also, I would like to describe what I do to manage applications and how to simplify the process. It can be a really difficult process when you are building a bigger front-end application. I will explain the tooling that I use in this article.

Find and fix problems in your JavaScript code

The first recommended tool is ESLint. Most of the newest JavaScript applications are using Typescript. With the combination of ESLint and Typescript, the code quality will improve. When you are using this tool, it is possible to enforce standards for your team, but also for yourself. On the other hand, it helps you to think about your code and will help you when you forget something. For example, if you forget a type definition for one of your methods.

You can start with ESLint by installing it via npm. After installing ESlint you will find a configuration file in the root of your folder directory called eslintrc.json. The recommended way is to use a config like this:

"extends": [
  "eslint:recommended",
  "plugin:prettier/recommended",
  "plugin:@typescript-eslint/recommended"
],

I do not like to have a lot of custom configuration. This helps to prevent discussion within the team about specific rules. There are some rules that I do recommend. One of these is a simple rule to give an error for unused imports. To enable this rule, you will need a plugin.

In your rule configuration can you define what you should do in case of unused imports.

"@typescript-eslint/no-unused-vars": ["error"],
"unused-imports/no-unused-imports": "error",

In addition to these rules, I have a few other rules. I always want to give a type definition for a return function and do not allow the use of the any type. You can read the complete documentation of ESlint on the website.

An example eslint configuration can be found here.

One of the biggest frustrations, when I start at an existing project, is having no code standards. You want to talk about the function of the new code when somebody has opened a pull request and not about its formatting. That is why code standards are important. Of course, both are important, but formatting should be consistent across files. That is pretty hard when you do not have rules or principles. We cannot automate everything, but some tools can help us. One of these tools is Prettier.

Prettier is a tool that you can use in your codebase to format your code. It supports a lot of programming languages. You do not need to discuss style in your code review and this will save you time and energy. After you install it with npm, you also have a simple configuration file called prettierrc.json. I use a configuration like this:

In the above example, you can see a few options. I want to use a maximum of 140 characters per line, not use double quotes, and format with spaces instead of tabs. The complete list of the Prettier options can be found on their website.

An example Prettier configuration can be found here.

Automate your code standards before you commit

The next step would be automating the tools above. I prefer to do two different things. The first one for Prettier is to implement an auto-save functionality for your code editor. For example in Visual Studio Code, you can create a settings.json in a .vscode folder at the root of your codebase. You can set a default formatter and a format on save boolean for the whole project. The default formatter below can be installed as a plugin.

"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true,

The other step is to implement a pre-commit hook before you commit definitively to your repository. I use the tool Husky for that part. Husky is a tool to lint your commit messages, run tests, and in my case run the lint rules above. Also, it is possible to combine those. I often use it for linting code and running unit tests.

You can install Husky via an automatic command. It will give you everything you need for your first pre-commit hook, including an example to run your test. You can also install Husky manually. The steps to do this can be found here. After installing you will find a .husky folder in the root of your codebase. Inside this folder, you will find the commit hooks that are used. 

The latest step to prevent adding bad code in your codebase is to use the tool lint-staged. With this tool, it is possible to run linters over staged git files. By using this tool you can have control before you push code into the repository. To use lint-staged you need to install it via npm. After that part, you can configure which files are checked while using the lint-staged command. You can do this via a lint-staged part in your package.json or via .lintstagedrc.json file in the root of your directory. The recommended way is to use a config like this:

{
  "*.{ts,tsx,html}": "eslint --cache --fix",
  "*.{ts,tsx,html,scss}": "prettier --write"
}

The example above also includes a fix flag for eslint and a write flag for prettier. During the pre-commit phase, files are changed automatically when possible. To use lint-staged in your pre-commit hook, add a file like this:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
 
npx lint-staged
npm run lint

It does not always stop everything, but it does help. To get control over your application, I can recommend running linters and tests to your pipeline. In that case, you know for sure that your code has been checked.

An example Lint-Staged / Husky configuration can be found here.

It can be difficult to produce quality code when the business is waiting for new functionality. To improve code quality, I use SonarQube. This tool helps you to find bugs, code smells, vulnerabilities, and duplications. It is available in a lot of languages including JavaScript, TypeScript, HTML, and CSS. For brevity, I will not explain how you should install SonarQube in this article, but I hope you see the added value.

SonarQube does scan your static code. For me, the greatest benefit is the simplicity of the code, which helps to better understand other developers' code and make fewer mistakes in the code. After the scan, you see metrics of complexity, vulnerabilities, and duplications. This information increases your productivity, maintainability, and consistency. I believe that this can help you to increase the lifetime of the application. In addition, it will help to improve your developer skills.

Each front-end application consists of a lot of packages. These are included in the package.json with a specific version. It is important to update these packages regularly. If you do not, you get a big bang upgrade scenario which takes a lot of time, or more importantly, you could get security issues. Furthermore, your application can be outdated for specific devices. It can make future development hard when you postpone this.

Like using hooks you can use a bot to update these packages. Renovate is one of these bots which you can use for automated dependencies updates. It scans your dependency tree for old versions and updates them via a pull request. First, you should connect Renovate to your repository, so it has permission to read your codebase. Then you can create a renovate.json in the root of your directory. There are some configurations that I can recommend to use. One of these is to auto-merge for a minor or patch update.

“packageRules”: [
  {
      “matchUpdateTypes”: [
      “minor”,
      “patch”
    ],
    “automerge”: true
  },
]

By default, Renovate will create a PR for every package that can be updated. There is a rule to group packages so that we get fewer pull requests. You can create groups based on a pattern. With this can you bundle packages. In the example below I created a group for eslint. This combines updates for eslint and @next/eslint to a single pull request.

{
    “matchPackagePatterns”: [
    “^eslint”,
    “^@next/eslint”
  ],
  “groupName”: “eslint”
},

There are many more options to configure. For instance, when Renovate should run and how many pull requests are allowed to be open at the same time. Auto merge is useful if you have a good CI/CD pipeline with linters, tests, and finally deployment. The complete documentation can be found on the website.

An example Renovate configuration can be found here.

A great part of this article goes about consistency and automation. The code must be clear for other developers and yourself. The lifetime of your application will be longer when you have good maintainability. A few simple tools and configurations can make the code a lot better. Why not use it? It will not get any worse.

I am working hard for code consistency. In my experience, I want to discuss what the code should do and do not like to talk about personal preferences of coding standards. By automating and maintaining you avoid the discussion. Hopefully, this article is helpful for your challenges with developing front-end applications.

Which tools do I use for improving front-end applications?

Vakmensen, dat zijn we. En wat we doen op het gebied van informatie- en communicatietechnologie helpt organisaties slim verder. Effectief en meetbaar bovendien. Aangenaam, CINQ. Specialisten in Data, DevOps en Development. Wij geloven in specialisten, vandaar de driedeling Data, DevOps en Development binnen ons bedrijf. Zo zorgen we dat jij excelleert, want je werkt het best waar je je het meest thuis voelt. Logisch, toch?

cinq_logo.png

cinq_logo_square.png

CINQ ICT

We delen graag onze kennis over Data, DevOps en Development met je. Op ons blog lees je tips en tricks over bijvoorbeeld Splunk, Docker, Kubernetes en Java.

Onze laatste blogs