Recently I presented a webinar about CI/CD and GitLab. It contained a demo of the Auto DevOps feature of GitLab. Connected to a Kubernetes cluster, this Auto DevOps feature really impressed me. Setting this up appeared to be rather easy. Hence I would like to share how you can do this, so you can play around with this Auto DevOps feature of GitLab yourself.

Why should you experience the power of GitLab's Auto DevOps feature with Kubernetes yourself?

Because, when you push just a simple Java Spring Boot helloworld app to your GitLab repository. The Auto DevOps feature gives you out-of-the-box an impressive, full fledged, very powerful standard pipeline. This pipeline isn't only complete in terms of testing, scanning, security and performance. But it also deploys your code on your Kubernetes cluster and can expose it at a public domain with TLS enabled.

Before we start, there are a couple of prerequisites. You need two accounts and three CLI's:

Eksctl: simple CLI to create an EKS cluster

Optional: Registered domain in AWS. Adding a domain name to this setup really makes the Auto DevOps feature shine.

Remark: There are minor costs involved in AWS for this setup, e.g. EKS, Load Balancer, route53.

The tool eksctl provides a very nice and easy CLI to create an EKS cluster. We use it to create an EKS cluster with name eks-gitlab in AWS region eu-central-1.

# Create EKS
eksctl create cluster --name=eks-gitlab --region=eu-central-1
# Verify
kubectl get po -A

Note that eksctl has updated your kubeconf with the new Kubernetes cluster, hence you can directly connect with kubectl. You can also verify your Kubernetes cluster in the AWS console. 

Let's first create a new blank project in GitLab.

Go to: https://gitlab.com/dashboard/projects > New Project > Create blank project > Project name: gitlab-demo > Create project

Now we can connect our Kubernetes cluster to this new project by granting GitLab cluster-admin access.

Go to: Operations > Kubernetes > integrate with a cluster certificate > Connect existing cluster

We need to fill in some cluster values here, which we can retrieve as follows:

# Kubernetes cluster name: eks-gitlab

# API URL
kubectl cluster-info | grep 'Kubernetes' | awk '/http/ {print $NF}'

# CA Certificate
# First: Get secret name
SECRET_NAME_CA=$(kubectl get secret -o 'jsonpath={.items[*].metadata.name}')
# Then: Get CA cert
kubectl get secret $SECRET_NAME_CA -o jsonpath="{['data']['ca\.crt']}" | base64 --decode

# Service token
# First: Create service account
cat << EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: gitlab-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: gitlab
    namespace: kube-system
EOF
# Second: Get secret name
SECRET_NAME_CA=$(kubectl -n kube-system get secret | grep gitlab | awk '{print $1}') 
# Then: Get service token
kubectl -n kube-system get secret $SECRET_NAME_CA -o jsonpath="{['data']['token']}" | base64 --decode


Then push "Add Kubernetes cluster" to create the connection.

Now that GitLab has control over your cluster, it can install apps for you. These apps are installed with a single click.

Go to: Operations > Kubernetes > eks-gitlab > Applications

Cert Manager - automatically create TLS certificate for your web app

But feel free to discover other apps as well, like:

Prometheus - tool to monitor deployed applications

GitLab Runner - ensures the pipeline agents will run inside your Kubernetes cluster instead of running in the GitLab cloud environment.

GitLab can use a public domain to expose your web app.

If you do not have a registered domain in AWS, create one.

Note 1: AWS says it can take 3 days before the domain is ready. Mine took just 15 minutes.

Note 2: AWS will also create a hosted zone for your domain.

When you installed Ingress in the previous step. Kubernetes has created a load balancer in AWS. We will connect the domain to the load balancer by creating a CNAME DNS record.

Copy the DNS name of your AWS load balancer.

Go to: Route 53 > Hosted zones > [your domain] > Create record
undefinedundefinedundefinedundefined

Then push Create records to create the CNAME DNS record.

When the domain is connected to the load balancer, we need to configure the domain name in GitLab.

Go to: Operations > Kubernetes > eks-gitlab > Base domain: [your domain] (e.g. c3s.io)

Note: Do not add the wildcard * to the domain here.

Everything is ready to enable Auto DevOps.

Go to: Settings > CI/CD > Auto DevOps > Expand

Enable the checkbox "Default to Auto DevOps pipeline" and save your changes.

Now you can push your code to your new repo. Here is a simple Java Spring Boot helloworld example which you can use, but you can also choose a helloworld web app of any other popular language.

Note that this repo does not contain any Dockerfile, Helm chart or even a ci/cd config file. It is just a simple Java Spring Boot app with two tests defined and a standard pom file.

The moment you push your code a new pipeline is started:

This standard pipeline has an amazing set of features, like:

build based on buildpacks (builds code, builds Docker image and creates Helm chart)

Static application security testing (SAST)

It then creates a dast namespace in you Kubernetes cluster, to deploy your app and perform:

Dynamic Application Security Testing (DAST)

And then, when all of this is succeeded, it deploys your app into the production namespace in your cluster. And makes it available at

Or more general, at: https://<gitlab-group>-<gitlab-repo>.<your-domain>

You can also view your environments at: Operations > Environments

Now change some code and make a merge request to see that this triggers a similar pipeline, but now it is deployed to a branch related namespace. So you can compare it easily to your web app that is running in namespace production. When you are happy with your change, approve the merge request and your change will be deployed in production.

Note: All of the above pipeline steps consist of open source software and can be configured if needed.

Recall that the helloworld repo did not contain any ci/cd config files. GitLab Auto DevOps together with Kubernetes gives you a very mature and powerful standard pipeline. Of course, every project will need it's own tweaks and additions, but this standard pipeline gives DevOps teams just a very good and easy starting point for setting up their CI/CD.

Connect GitLab to existing Kubernetes cluster

How to use GitLab Auto DevOps with Kubernetes running on Amazon EKS.

The Power of GitLab Auto DevOps and Kubernetes

The power of GitLab Auto DevOps and Kubernetes

Why reinvent the wheel, when you can save yourself some time by using some vendor library, open source or even libraries that come bundled with the platform you are using? 

Using existing libraries is often easier and quicker. However, if you are not careful you can end up in a mess with code which is:  

Difficult to change. Leveraging third-party APIs leaves you with code which often looks like it is nothing but repeated calls to someone else’s library. Frequently resulting in your code being tightly knotted with the library’s.  

Difficult to test. Use of someone else’s code lulls you into a false sense of security. You end up thinking that you don’t need tests. After all, we aren’t doing anything significant, just calling some methods here and there. And before you know, the code has continued to grow and you are now left with something that isn’t simple anymore. It’s a patchwork of untestable code that no one wants to touch.

Help your future self and colleges and start wrapping third-party APIs.

“Wrapping third-party APIs is a best practice.” — Robert C. Martin

When you wrap a third-party API, you minimize your dependencies upon it. You are able to more easily move to a different library or mock out third-party calls when you are testing your own code.

You are not tied to a particular vendor’s API design choices. You can define an API that you feel comfortable with. 

Systems littered with library calls are harder to deal with than homegrown systems. First, it's hard to see how to improve the structure, because all you see are API calls. Most things that can give you a hint at a design is hidden in an external library. Secondly, you don’t own the API. You can’t rename anything to make them clearer. You can’t hide or add extra methods. 

Uncle Bob goes as far as advising you to wrap internal platform classes, like the Java Collection Map class. This may be a little much in most cases. 

So, you are refactoring code not implementing wrappers, how do you do this safely? Michael Feathers, in his book ‘Working Effectively with Legacy Code’, describes two methods:

Skin and Wrap. When refactoring existing code, this is the safest method to use.   

You start by making an interface which mirrors the existing API as closely as possible. Most IDEs come with build-in options for extracting interfaces from classes. 

You can now choose to preserve the signatures of the original API. First, you create wrappers for each one of the external library classes used in your code. These wrappers can delegate to the real API in production and point to mock objects when testing. (Code Snippet 1 & 2.) 

You may recognise this as the Decorator-pattern. If the third-party class contains too many methods, which you simply don’t need, you can skip creating the interface. Just wrap by passing the library class as a parameter to the constructor of your wrapper. (Code Snippet 3.)

After swapping out the third-party class for your own, you are left with code which is more loosely coupled and easier to test (using mock objects). 

 //   Example class to be wrapped 
class API{
    public void doSomething(){ /*implementation*/ }
  // … more methods 
}

//Wrapping using the Decorator Pattern
interface API {
  void   doSomething();

}

//Example wrapped class
class CustomAPI extends API{
    private API api;

    public CustomAPI(API api){
     this.api = api; 
    }  

    public void doSomething(){
    //add new functionality here
      this.api.doSomething();  
    //or here without breaking   previous code 
  }
  //other methods
} 

//Example wrapped class, but not so decorator-ish
class CustomAPI{
    private API api;

    public CustomAPI(API api){
     this.api = api; 
    }  
    public void doSomething(){
    //add new functionality here
      this.api.doSomething();  
    //or here without breaking   previous code 
  }
  //other methods
}

Responsibility-Based. However, when working with complex APIs with multiple classes containing dozens of methods it soon becomes unmanageable. 

Basically, you start designing your own API based on the functions you are using. And then wrap your new methods nicely in classes based on their responsibilities. Most likely, you will combine multiple third-party classes, or use the same third-party class in multiple custom classes. 

Of course, when you wrap a class, your new methods should only return standard Java classes or your own custom classes.

When moving code around, you want to separate the external libraries API from your custom logic. This is because you don’t want to test the third-party library. It has already been tried and tested. Also, you want your business logic to be library agnostic. Any major future changes to the third-party library, should at most only affect your custom API classes. 

By slowly extracting larger pieces of code into smaller methods, it makes the code easier to understand. When you locate custom logic, extract it to a new utility class. As soon as you feel like you have finished grouping functions together, you can more easily refactor and rename your utility classes to better reflect their functionality.

/*
*Example of custom designed Interfaces. They only accept standard or your own designed *parameters.

*/
public interface ContentEngine {
 CETask getTaskObject(String id);
 // etc.
} 

public interface CETask {
  //getters
  String getAttribute();
  //setters
  void setAttribute(String value);
  //more complex commands
  void doSomethingNeat();
  //etc
}

/*
*In this example Domain, ObjectStore, Factory and Connection belong to 
*a third-party library.
/* 
public class ContentEngineImp implements ContentEngine { 
    private ObjectStore objectstore;
     
    public ContentEngine(Connection connection, String defaultObjectStoreName) {
        Domain domain = Factory.Domain.getInstance(connection, null);
        this.objectstore = 
          Factory.ObjectStore.getInstance(domain, defaultObjectStoreName);
    }
    
    public CETask getTaskObject(String id){
      Task task = Factory.Query.findObject(this.objectStore, id);
      return new CETask(task);
    }

  // … more custom API methods
}

/*
*Task is a third-party Class.
*/
public class CETaskImp implements CETask {
  private String attribute;
 
  public CETaskImp(Task task){
    this.attribute = this.parse(task.getSomething());
  }
  
  protected String getAttributeImp(String attribute){
    return doSomethingWith(attribute);
   }    
  
  public String getAttribute(){
    return getAttributeImp(this.attribute); 
   }
  
  // … more custom API methods
}

Wrapping third-party libraries is definitely a good practice to follow. It may cost you some extra time, but in the long run you are left with a system which is easier and faster to change.

References
Robert Martin (2009). Clean Code. A Handbook of Agile Software Craftmanship.
David Thomas and Andrew Hunt (2020). The Pragmatic Programmer. 
Michael Feathers (2005). Working Effectively with Legacy Code. 

Working with third-party libraries and what to do when you find yourself in a mess

During the past few years, I have worked in several scrum teams on different projects. Thinking the time was right to validate my knowledge of the Scrum framework, I set about researching what certifications were available and how you need to prepare. 

The first certification I came across was the Professional Scrum Master I (PSM I) which is made available by the Scrum.org organization.  Scrum.org was founded by Ken Schwaber, no one less than a co-creator of Scrum. A good place to start. Scrum Alliance is another well-known organization which offers professionals a way of getting certified. Which one you choose is up to you, but I chose the Scrum.org certification route.

But isn’t this blog about passing the Professional Scrum Developer (PSD I) exam, not the PSM? Yes, you are correct. However, my first tip for passing the PSD is: first pass the PSM I. 

Before I took the PSD, I studied and passed the PSM I exam. When comparing the two exams nearly two-thirds of the questions asked during the PSD are copy-pasted from the PSM I.  So, if you have already comfortably passed the PSM I, you have already mastered the majority of the knowledge needed to pass. 

So how do you pass the Professional Scrum Master I Certification? 

When studying for the PSM I exam I used the following resources:

The Scrum Guide.  This document is the heart of Scrum. If you fully understand this document you will pass the exam, and more importantly you will understand Scrum. I recommend downloading this and reading it a few times. Then put it away for a week, and then read it again. 

The guide contains a few learn by heart definitions. Make sure you memorize these definitions, or at least know where you can find this information quickly when taking the test. The first 75% of your exam grade will be made up of relatively simple questions related to the different definitions defined in the guide. 

The final 25% of the questions will be related to the ‘spirit’ of Scrum.  You will be given several scenario questions and you will have to determine which answer best fits within the Scrum framework. These are the hard questions. But don’t worry there are ample resources out there to help you.

Open Assessments. There is an open assessment (practice exam) for every entry-level certification. These are free of charge practice exams; whose questions closely mirror the real exam. The great thing is, that you can take them an unlimited number of times. Every time you start an assessment you will get 30 randomly selected questions from a larger pool. 

After completing the assessment a few times, you will start recognizing questions.  From experience I can tell you that the real exam will have several questions directly taken from this pool, and some more which are really only slightly different. 

So, if you can consistently score 100% when taking the open assessments, you will be ready to take the exam.

Online courses. If you want, you can also follow an online course. Myself, I followed the ‘Scrum Certification Prep + Scrum Master + Agile Scrum Training' by Paul Ashun, course via Udemy.  Would I be able to pass the exam after solely following this course? No, I don’t think so. But it did help me when doing the Open Assessments. 

Third-party Practice Exams. The best way to practice for an exam is to practice with mock exams. After, you know all the Open Assessment question by heart, there is one more place where you can find plenty of mock exam questions: https://mlapshin.com/index.php/scrum-quizzes/.

Mikhail Lapshin is a developer who has been so kind enough to have created an online quiz tool and repository for practicing for a Scrum exam. This is a great place to practice and it helped me a lot.

How to prepare for the Professional Scrum Developer Exam?

So now you have studied for the PSM I and you have passed. Congratulations! Now you are ready for the next few steps. If you enjoyed studying for the PSM, then I will recommend quickly continuing with the preparations for the PSD. 

Firstly, if you are fresh out of college and you majored in Software Engineering, most likely you will be able to pass the PSD straight after completing the PSM I. At most, I would recommend you practicing with the PSD Open Assessment questions, and after you feel confident go for it.

However, if you have a more practical and less theoretical programming background, or you are curious what kind of theoretical works are at the heart of the Scrum framework, then I can highly recommend the following three books:

Clean Code. A Handbook of Agile Software Craftsmanship by Robert C. Martin.

The Pragmatic Programmer. your journey to mastery by David Thomas and Andrew Hunt.

Working Effectively with Legacy Code by Michael C. Feathers.

Finally, you should visit the Agile Alliance website. On their website you can find the Agile Glossary.  Here you will find the 75 must know terms and their definitions for Agile developers. This is a great resource for checking if you already have the theoretical background for the exam, or to use as a quick lookup, if you need to double-check certain terminology used during the exam.

After following these steps, you shouldn’t have any difficulty passing your Professional Scrum Developer Exam. Good luck!

In this blog by software engineer Ian van Nieuwkoop, you will read how to prepare yourself for the Professional Scrum Developer I certification exam.

Tips for passing your Professional Scrum Developer I (PSD I) Certification

A year after Splunk’s big release of version 8, the company now released Splunk 8.1 during their legendary (and virtual) Conf2020. As each release has many new features, in this article I would like to highlight some of these and discuss why they are interesting for users and admins based on my own practical experience. 

The new features that I would like to touch upon are:

Imagine you have the task of developing a new monitoring dashboard for your team and each of the panels have somewhat similar searches. In developing each panel, you probably perform multiple searches before getting to the ultimate search query. In previous versions of Splunk, each new search query was overwritten by the other in the search query bar. If you wanted to use a previous search query you specifically had to go to a search history panel to find your earlier search queries unless you had saved it on your clipboard. In other words, for your search history you had to look at different locations or perform multiple clicks, which felt like spending more time in finding previous searches and made searching sometimes less comfortable. This little issue is now solved in the new release of Splunk 8.1 

Splunk now added a new shortcut feature that allows you to quickly snip to previous search queries you performed. The shortcuts that can be used are Alt/Ctrl P (for previous) and Alt/ Ctrl N (for next) depending your operating system. Personally, I am very enthusiastic about this feature as it helps in actually spending time on performing searches instead of finding previous queries.

Another little feature that improves the experience of building searches and dashboards is the ability of adding comments in search queries. Similar to writing scripts, this way, you can make your search clear for others or leave a reminder for yourself when you continue the other day. This can be really helpful for Splunk users as well as admins. 

For instance, your comment could state what you are trying to do with this search or highlight the reason for a certain argument in your search query. In terms of troubleshooting, you can also specifically indicate with which argument you are struggling. 

From my admin experience, I once found this terrible search with 21 sub-searches of a certain user, which he had copied to multiple dashboards at his department. He probably was very proud of getting this big search to work. However, for me as a Splunk admin who wants to keep his platform running smooth and efficiently I wanted to help him out in improving his search. But looking at his query without the purpose or his ideas behind this big search makes it challenging to support. In this case, comments would definitely help in making a long search more readable as these could state why certain decisions or reasons for an argument were made. The possibility of adding comments can also help admins in supporting their Splunk users.

You can add a comment by adding three backticks ( ``` ) before and after your comments.

1.comments.png

For those Splunk users, who are unfamiliar with writing Splunk queries or who are new to Splunk, there is now a new feature called “Table views”. This feature allows you to easily create a table by clicking through the UI. This feature has been added to the datasets tab. As can be seen in the displayed figure, you can simply specify, which index, source, host you want to search and how you want your table exposed. In the background Splunk automatically writes the query for you, which you can easily export to a dashboard. Personally, I believe this is a great feature, especially for novices. I have seen in multiple companies that the adoption of Splunk is sometimes somewhat challenging for teams as they have to start writing queries, which is not common for each and every person. I believe this feature could remove some of the challenges when starting with Splunk.

Imagine that you as a Splunk admin, are going to implement a big change (like updating to Splunk 8.1) on your Splunk platform and you need to inform all your Splunk users, when this is going to happen and where they can find more information about this. Or imagine that you need to perform a restart of the search head during daytime, which impacts the users. How can we ensure that we reach all our Splunk users? A question that I have seen a couple of times in these kind of cases before. The new banner feature provides the possibility to communicate to all current Splunk users by displaying a bar on top of the Splunk page. This bar can be presented in multiple colors and may contain a message or link to a certain page. Personally, I am very enthusiastic about this feature. I have been in a position where I had to send an email to 1500+ Splunk users during a summer period regarding a change that we were going to perform and received 400+ out of office replies in my personal inbox. The intention is to reach every Splunk user that was using Splunk at that time. However, as we only had a list of registered Splunkers available, we had to contact everyone as we did not know who was actually using Splunk that week. This banner feature can now support us Splunk admins in reaching out to our Splunk users. Great work Splunk!

Workload management, the management of workloads on a Splunk platform has already been introduced before. However, in this release Splunk now also added admission rules. These rules support in the management of workloads depending on business needs. For instance, very often in practice, Splunk users, which have discovered the wildcard trick, define index=* coupled with some search terms in their query in order to find their data. 

It could be that they do not know the name of their index or some are simply to lazy to investigate what the index is and, therefore, decide to use “index=*”. As a consequence, this could have a very negative impact on the performance of the Splunk platform when running a query with this search term over a longer period of time. You could compare this to going to a library where you need to go through every single book out there as you do not know in which category the info you are looking for resides. You are simply telling Splunk to look through every single index over a certain time period, which takes processing power, and so impacts other users that want to perform search queries as well. With workload user management rules, you can now instruct Splunk to ignore wildcard search, which reduces the unexpected workloads on your platform. Besides wildcard searches, it is also possible to filter on “all time” time range searches or disallow searches in peak hours. So, this is a great feature to support admins in controlling their platform and reducing the chance of unexpected workloads.

These are five of the new features that the new release of Splunk 8.1 offers, which I believe, based on my own experiences, are great for Splunk users and admins. Further information regarding other features that common with this release, can be found at the following page: 

https://www.splunk.com/en_us/blog/conf-splunklive/what-s-new-with-splunk-enterprise-8-1.html

In this blog we talk about 5 new features in Splunk 8.1 and how they work.

5 new features in Splunk 8.1

Starters op de woningmarkt, een onderwerp dat regelmatig in het nieuws voorbij komt. Al een aantal jaar is de vraag naar woningen groter dan het aanbod, waardoor de prijzen flink zijn gestegen. Dit maakt dat het voor starters lastig is om zich in te kopen op de markt. Overbieden is tegenwoordig eerder de norm dan een uitzondering op de regel. Daarnaast zijn woning vaak al verkocht voordat je ze online hebt kunnen spotten, wat een aardige uitdaging is naast een 40urige werkweek. Kortom, voor een starter is het een hele uitdaging om de woningmarkt nauwlettend in de gaten te houden en er bovenop te zitten naast een fulltimebaan.

Als consultant op het gebied van datamonitoring en als nieuwkomer op de woningmarkt zag ik hier een kans voor een cool persoonlijk Splunk project. Mijn huizenjacht focuste zich op de woningmarkt in Rotterdam. Ondanks dat verschillende makelaars met ieder hun eigen aanbod en Funda al redelijk veel ondersteuning bieden, zat ik toch met verschillende vragen.

Wanneer komen nou de meeste huizen online? Welke huizen zijn vandaag online gekomen en in welke buurt? Ok, en voor deze buurt, wat is de gemiddelde vraagprijs? Is de vraagprijs voor deze woning aan de hoge kant? Wat is de m2 prijs?

Uiteindelijk heb ik mijn eigen monitoring dashboards gemaakt in Splunk, die mij net meer diepgang en inzicht kunnen geven in de Rotterdamse woningmarkt. Het is een ongoing project en graag presenteer ik in dit blog wat eerste resultaten. Daarna zal ik op bepaalde technische aspecten wat dieper ingaan. Qua data is alleen een geselecteerd aantal buurten en prijsklasse opgenomen die ik mogelijk interessant vond.

1.panel-kaart.png

Dit dashboard geeft net zoals Funda in één oogopslag welke huizen er waar te koop zijn in Rotterdam. De single values tonen respectievelijk het totale aantal koopwoning (in mijn index), het aantal nieuwe koopwoningen vandaag, het aantal nieuwe koopwoningen gisteren, deze week, vorige week, twee weken geleden, drie weken geleden en ouder dan een maand. Verder kan er linksboven ook op specifieke buurten in de stad gefilterd worden, voor wanneer er alleen interesse is voor een bepaalde buurt. Op het eerste gezicht een heel eenvoudig dashboard. Maar door wat drilldown magic toe te passen kun je hier veel meer informatie uit halen.

3.kaart-streetview.png

2.tabel.png

Wanneer je bijvoorbeeld op de single value “vandaag” klikt, verandert het aantal pijlen en zie je waar welke woningen vandaag online zijn gekomen. Daarnaast verschijnt er onderaan ook een tabel met meer gegevens over deze nieuwe koopwoningen. Zo zie je naast het adres, de vraagprijs, prijs per m2, buurt/wijk en de publicatiedatum & tijdstip. Wanneer je liever op de kaart speurt, kun je ook op een pijl klikken en die geeft ook meer details van de koopwoning. Zie je een interessante woning en ben je nieuwsgierig naar de buurt, dan kun je nog verder ‘drillen’ naar een panel die gelijk de woning op Google Streetview laat zien. Zo zie je gelijk of de straat of woning je aanspreekt.

5.statistieken1.png

6.statistieken2.png

Dashboard 2: Woningmarkt Rotterdam statistieken

Dit dashboard presenteert statistieken van de Rotterdamse woningmarkt. Ideaal voor een nieuwkomer die nog niet bekend is met de huidige woningmarkt in zijn/haar stad. Het dashboard is momenteel nog vrij basic en bestaat uit vijf panels. In de toekomst gaat deze nog verder uitgebreid worden en krijgt deze een visuele upgrade.

Het eerste panel geeft antwoord op de vraag wanneer de meeste woningen online komen en in dit specifieke geval op Funda. Voor Rotterdam komen de meeste woningen blijkbaar ’s nachts rond 0:00 online. 

Het tweede panel presenteert hoeveel woningen er per wijk te koop zijn (geweest). Zo kun je zien in welke wijk de meeste woningen te koop komen. Op langer termijn kan dit nog uitgezet worden tegen de tijd, wat je bijvoorbeeld een indicatie kan geven wanneer in welke wijk de meeste woningen online komen. Of een trendlijn die kan laten zien of het aantal toe/afneemt.

De gemiddelde vraagprijs voor een woning per buurt verschilt en dit wordt weergegeven in het derde panel. Deze wordt berekend door de vraagprijs gedeeld door het aantal woningen per buurt. Deze zal over tijd nauwkeuriger worden wanneer er meer woningen in de index zitten. Hetzelfde geldt voor het panel daarna, waarin je per buurt kunt zien wat de gemiddelde m2 prijs is. Zo weet je dus in welke buurt de woningen relatief gezien het duurste zijn.

In het laatste panel is te zien welke hoeveelheid m2 woning het meeste aangeboden is tot nu toe in de index in dit project. Zo weet een nieuwkomer vrij snel wat de grootte van de meeste woningen zijn die in de verkoop komen.

De data voor dit project komt uit verschillende bronnen. Allereerst voor de gegevens omtrent de woningen die in de verkoop komen, wordt er gebruik gemaakt van de RSS feed van Funda. De RSS feed bevat de volgende gegevens: straatnaam, huisnummer, vraagprijs, oppervlakte en het aantal kamers. De feed kan precies met een aantal filters getweakt worden, zodat je alleen de woningen krijgt die jij interessant vindt. In dit geval heb ik gefilterd op een aantal buurten, stad en een prijsklasse.

Voor zowel Google Streetview en coördinaten is er een connectie gemaakt met twee API’s van Google Cloud, namelijk Geocoding API en Maps API. Dit kost nog geen halve euro per maand. In het eerste jaar kun je hier overigens gratis gebruik van maken. Echter om de juiste coördinaten op te vragen is er een straat, huisnummer en postcode nodig. De straat en huisnummer kan uit de RSS feed van Funda gehaald worden. 

Voor de gegevens omtrent postcode, buurt en gemeente, is er gebruik gemaakt van een aantal CSV’s van het CBS. Destijds was alleen de dataset uit 2019 beschikbaar. Het CBS biedt datasets aan met informatie over gemeenten, buurten, wijken en postcode van heel Nederland. Voor dit project zijn er 4 CSV’s samengevoegd tot een lookup tabel en gefilterd op de gemeente Rotterdam. Gezien sommige datasheets meer dan een miljoen regels bevatten (wat excel niet aan kan) is dit een ideale klus voor Splunk. In de volgend afbeelding is te zien wat de verschillende CSV’s waren en hoe deze zijn samengevoegd. 

Om uiteindelijk de data te kunnen gebruiken in Splunk is er gebruik gemaakt van de volgende Splunk apps: “Google Geocode app” en “Maps+ for Splunk”. Deze apps zijn beiden beschikbaar in Splunkbase. 

De Google Geocode App helpt je in het vertalen van een adres (straatnaam, huisnummer en postcode) naar Latitude en Longitude coördinaten. Aan de achterkant wordt de Geocoding API aangesproken in Google Cloud. De opgehaalde coördinaten worden samen met het adres, de oppervlakte, het aantal kamers, de vraagprijs, buurt, wijk en gemeenten opgeslagen in een summary index. 

Deze summary index wordt vervolgens gebruikt in de Maps+ for Splunk app. Hoewel er ook andere apps/add-ons zijn voor Google is er voor deze app gekozen gezien deze op stad/straat niveau de kaart kan weergeven. Daarnaast biedt deze app ook de functionaliteit om een Google Streetview panel te maken. Wat zoals eerder beschreven op een dashboard is geïmplementeerd. Dit panel maakt op de achtergrond een verbinding met de Maps API in Google Cloud. Deze geeft op basis van de coördinaten vervolgens op streetview een visualisatie weer.

Het is een ongoing project waar nog veel meer uitgehaald kan worden. Ik zie steeds weer andere mogelijkheden en heb verschillende ideeën. Qua dashboard, ben ik bezig met de Splunk Dashboard Beta app om Rotterdam nog beter te kunnen visualiseren en het dashboard naar een hoger niveau te tillen. Verder gezien ik op langer termijn meer data heb wil ik trendlines gaan toevoegen en mogelijk biedt machine learning nog bepaalde voorspellende mogelijkheden. Verder ben ik aan het onderzoeken of ik ook de actuele verkoopprijzen kan verkrijgen zodat je kunt gaan zien hoeveel er gemiddeld overboden wordt. De vraag is echter of deze data vrij te verkrijgen is. Er zullen vast nog andere toffe ideeën zijn. Mocht jij er een hebben, let me know! 

Hoe ik tijdens mijn huizenjacht met behulp van Splunk de Rotterdamse woningmarkt in kaart heb gebracht.

De Rotterdamse woningmarkt in kaart met behulp van Splunk

In de wondere wereld van frontend technieken zijn er nog zoveel dingen om nader te onderzoeken. In afwachting van mijn screening voor de opdracht bij de Politie besloot ik om een nieuwe website te maken voor CINQ. En nu – medio oktober – staat deze eindelijk live. In dit blog deel ik graag mijn ervaring over – met name – Next.js. Dat is namelijk precies waar je nu naar kijkt.

Na het zien van de eerste proof of concept raakte collega Marc Jacobs geïnteresseerd in mijn positieve wil. Samen besloten wij te brainstormen om tot een plan van aanpak te komen om toe te werken naar wat voor ons een succesvolle website zou zijn. 

Woorden als specialisten in Data, DevOps en Development vormen de basis voor ons verhaal, gevolgd door sociale IT’ers. Tijdens het ontwerpen en ontwikkelen van de website stond verschillende kenmerken constant centraal: de unit’s, events, vacatures en blogs. Ons doel was duidelijk.

Voor ik deze vraag ga beantwoorden is het interessant om te weten wat Next.js is. Zij omschrijven zichzelf als een React Framework voor Productie waarmee je met simpele handelingen een applicatie van A tot Z kan ontwikkelen en in productie kan zetten. Je krijgt hierbij toffe mogelijkheden, wat je kan zien als builts-in functionaliteiten, om een hybride en server side rendered applicatie te bouwen met minimale configuratie.

Dat klinkt als een kind kan de was doen, maar dan? Er waren redenen om de oude CINQ-website te vervangen, bijvoorbeeld dat deze niet makkelijk door onszelf was aan te passen, het op de mobiel beter kon werken en dat wij graag ons verhaal nog beter zouden willen vertellen. Wij hebben voldoende specialisten in huis om - ook voor onszelf - mooie dingen te ontwikkelen. Hoe mooi zou het dan zijn als wij zelf onze eigen website zouden ontwikkelen en onderhouden? Met deze voorkennis, natuurlijk ook in afweging van vele andere aspecten als bijvoorbeeld Next.js of NuxtJS, besloot ik om te kiezen voor Next.js in combinatie met Prismic CMS.

Toen ik eenmaal begon met het ontwikkelen van de website in Next.js was natuurlijk alles nieuw voor mij. Waar begin je dan? Gelukkig heeft Next.js een duidelijke documentatie. Om een snelle start te maken heb ik ervoor gekozen om te beginnen met een ‘bootstrap’ van Next.js via commando: 

Door de afgelopen jaren heen ben ik gewend om al in componenten te denken, omdat je dit bij alle frameworks wel op een bepaalde manier gebruikt. Waar je normaal vanuit een router pagina of module iets doet, heb je dit bij Next.js onder een folder pages. Bij de bootstrap installatie krijg je de onderstaande folder structuur.

├── pages             # folder voor alle pagina's
│   ├── api           # folder voor alle serverless functies
│   _app.js           # overal document voor je applicatie
│   index.js          # index.js verwijst naar / van de applicatie
├── public            # folder voor alle assets
├── styles            # folder voor styles
│   global.css        # globale style (voor bv. body tag)
│   Home.module.css   # module style voor homepage

Bij het ontwikkelen van een Next.js applicatie zijn er twee belangrijke folders, dit zijn pages en pages/api. In de folder pages zet je alle pagina’s die de applicatie kent. Je kan dit zien als een soort van router structuur. In de folder pages/api zet je alle API endpoints die je als Node.js serverless functie kan gebruiken. In de praktijk voor de CINQ-website hebben wij daarom pagina’s als bijvoorbeeld: pages/index.js, pages/contact.js pages/[uid].js en pages/blog/[id].js Deze pagina’s verwijzen naar de homepage (/), de contact pagina (/contact), een willekeurige content pagina waar geen andere pagina voor is (/data) en een blog artikel (/blog/toffe-developer-ervaring). Voor wat betreft de serverless API endpoints moet je denken aan het ophalen van meer artikelen voor de blogpagina of het versturen van het contactformulier.

Als je eenmaal een pagina hebt aangemaakt in de pages directory, dan is de volgende stap om data op te halen en componenten te gaan ontwikkelen. Voor het ophalen van data en de manier van renderen heeft Next.js verschillende implementaties. Met getStaticProps() kan je ervoor zorgen dat een pagina bij het builden van de applicatie wordt gemaakt, dit heet dan static site generation. Deze wordt dan voor elk request gebruikt. Daarnaast heb je ook een server-side rendered variant, dit gebruik je door de methode getServerSideProps(). De laatstgenoemde is wel langzamer dan de static variant, want deze doet bij elk request het opnieuw opbouwen van de pagina. Voor ons geldt voor de meeste pagina’s het laatste.

Mijn collega Marc wilde graag de website zelf kunnen beheren. Prismic is een Headless CMS dat uitstekend te combineren is het met het gebruik van Next.js. Je kunt in Prismic een aantal content types definiëren, dit resulteerde bijvoorbeeld in types als een blogpagina, een content pagina, een medewerker, een review of een vacaturepagina. Deze types werden er zo op gericht dat je dacht vanuit het componenten niveau wat wij in de applicatie kennen.

Om je een voorbeeld te geven hebben wij in Prismic een content pagina type. Stel wij hebben de pagina over Development. Deze bestaat nu uit een intro header, een intro content, kernwaarden met logo’s, vacatures en blogs. In Prismic heb ik het zo ingericht dat je deze blokken kan invullen, wijzigen van volgorde of het juist aanvullen van informatie met een tag. Zo zie je bij de vacatures alleen de vacature voor development, evenals bij de blogs dat je alleen de blogs zie over development. Kijk je naar de homepage zie je weer alle vacatures en blogs.

Wellicht vraag jij af hoe ik vervolgens de koppeling heb gelegd tussen Next.js en Prismic. Vanuit de Next.js pagina heb ik in getServerSideProps() een functie geschreven die de data ophaalt vanuit Prismic. Dit doe ik aan de hand van het type pagina. Nadat ik deze informatie heb opgehaald, stuur ik deze properties als JSON terug naar de pagina. Vervolgens laat ik door een soort van beslisboom de juiste componenten in de juiste volgorde zien. Dit betekent ook dat ik dus herbruikbare componenten heb ontwikkeld. Zo zijn componenten als bijvoorbeeld de intro tekst - in de code noem ik dit hero content- gebruikt voor de content pagina’s, maar ook voor pagina’s zoals dit blog artikel.

Samenvattend kom je steeds terug bij de kernwaarden die wij onszelf eerder hebben gesteld. Zowel bij de pagina’s, als de componenten als de inrichting van het Prismic CMS zie je deze terug. Hierdoor hebben wij een dynamische website, voorzien van herbruikbare componenten en slim gebruik van het CMS. Bij lange na heb ik natuurlijk niet alle toepassingen en keuzes over Next.js, Prismic of zelfs het in productie nemen via Vercel in dit blog kunnen toelichten. Mocht je naar aanleiding van dit blog een deep dive willen, dan kan je daarover altijd contact met mij opnemen via jeroen.burgers@cinqict.nl of via mijn Linkedin-profiel. 

Hoe maak je een succesvolle website of applicatie met Next.js en Prismic? Lees onze ervaring.

De nieuwe CINQ website: Geslaagde combinatie van Next.js met Prismic CMS

What are the goals of CI/CD, how can they be reached? A great variety of tools are used and often managed by a central CI/CD team who integrate, standardise and maintain them. As a CI/CD consultant, I have created numerous pipelines, but none of them was so complete and mature as the Auto DevOps pipelines templates from GitLab.

Join this webinar to see what CI/CD can do and take the next step in your DevOps journey.

CI/CD – from code to running in production

Sign up for our free webinar: the Benefits of CI/CD

Ik heb de afgelopen 2 jaar redelijk wat 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 aardig wat aandacht besteed aan Kubernetes met interne kennis-sessies, een reis naar KubeCon Europe '18 in Kopenhagen en ons eigen Kubernetes “bootcamp” in Friesland. 

👩‍🏫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

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 3 uur waar er van je verwacht wordt 24 problemen/vraagstukken op te lossen in verschillende Kubernetes clusters. Een score van 74% is vereist om te slagen. 

- EDIT oktober '20: Sinds kort duurt het examen 2 uur, waarin je 15 tot 20 problemen / vraagstukken op moet lossen en je een score van 66% moet halen om te slagen. Alle andere informatie in deze post is nog steeds relevant. - 

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. 

Op 5 juli heb ik mijn eerste examen gedaan. Ik had het gevoel goed voorbereid te zijn. 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. 

Ik twijfelde of ik het had gehaald na afloop, omdat mijn KubeADM vraag in de soep liep door een error van de cloudprovider (AWS). Achteraf heeft dit geen verschil gemaakt en is het misschien zelfs nog goed gerekend. Het resultaat kwam pas na 36 uur aan in de mail. Uiteindelijk heb ik toch een score van 91% behaald op mijn eerste poging.

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 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 3 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. 

Het gene waar CKA zich in onderscheid ten opzichte van CKAD is 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 - laat het weten in de comments of neem contact met ons op.

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

Sommige opdrachten kun je gewoon niet weigeren. Wij zijn gevraagd door de Rijksoverheid om te helpen bij het monitoren van de infrastructuur van de CoronaMelder app. Een uitdaging die we graag aan zijn gegaan!

We hebben hiervoor direct onze control room ingericht en inmiddels monitoren we live de performance van de CoronaMelder app.

De app wordt momenteel in een aantal GGD regio's in de praktijk getest, voordat deze straks landelijk wordt ingezet. Het doel van de app is om mogelijke besmettingen eerder te lokaliseren, zodat er eerder getest kan worden en verdere verspreiding wordt voorkomen.

Mooi dat we hier met CINQ een bijdrage aan kunnen leveren!

Meer informatie over de app vindt je op https://coronamelder.nl/

Sommige opdrachten kun je gewoon niet weigeren. Wij zijn gevraagd door de Rijksoverheid om te helpen bij het monitoren van de infrastructuur van de CoronaMelder app.

Onze laatste blogs