In 2021 Java celebrates its 25th anniversary. As part of this anniversary Oracle offered to register for the Java SE 11 Developer exam for only 25 dollars (22 euros). This is an interesting offer, because normally this will set you back ten times as much. So I decided to go for it and to give it a shot. This offer was valid for two months, so there was a deadline to keep me focussed on my goal. In this blog I will give you some tips to pass this exam.

Before I get to this a little bit more background on myself. I did the Java 8 OCA exam in 2017 (so four years ago). Please note that this was the OCA version. The OCA version is a lot simpler than the OCP version. It will test you on far less topics. The Java SE 11 Developer is comparable to the former OCP versions.

Because of my previous experience I already knew about the kind of questions you can expect. The questions are, to put it mildly, misleading. The exam tries to trip you up with really obscure notations and almost correct options. To give an example, does the following line compile?

public static void main (String []args) {}

All Java developers recognise this as the main entrypoint of a Java program. Most developers will frown their brows on the part between the parentheses. Normally we see one of the following:

I had never seen String []args before, but apparently it is allowed, so it does compile. Most questions contain several of these “interesting” cases.

So to pass this (or any other Java exams) you have to become a human compiler. You need to know if code will compile or not. Half of the questions have an option that says the code will not compile. 

The first question is: Where should I start? 

Tip 1 - OCP Java SE 11 Developer Complete Study Guide

I used and recommend the Oracle Certified Professional Java SE 11 Developer Complete Study Guide from Jeanne Boyarsky and Scott Selikoff. This book has around 1300 (!) pages, but it has all the information that you need. It has the depth that you need to become the aforementioned human compiler. Furthermore it is also brimming with questions to test your knowledge and sharpen your skills. 

This book also comes with an online test environment in which you can customize the kind of exam you like to do. For instance you can specify that you only want questions about exceptions or security. You can also create an exam with only x questions or one that only contains questions that you incorrectly answered in the past. A great tool to prepare effectively. 

Tip 2 - Do not underestimate the difficulty of this exam.

The exam was much more difficult than I expected when I started this adventure. It took far more time and effort than I had planned to commit to this. In the intro of this blog I mentioned passing for the OCA 8 exam. I had to study quite a lot for this exam, but leading up to the exam I was pretty confident that I would pass. For this exam I studied thrice as hard and I could not predict the outcome. So in the end I put in about 120 hours to fail at my first attempt. 😞

Tip 3 - Practice a lot (and then even more)

After spending sixty hours on studying I took my first mock exam and I failed gloriously. I only answered 40 percent of the questions correctly. The exam asks really in depth stuff, so for me just studying was not enough. I had to practice and practice to familiarize myself with all the nooks and crannies of the Java language. So I spend another sixty hours doing as many practice questions and mock exams as humanly possible. I had to do the exam twice and I barely passed it the second time. 

Tip 4 - Look at the answers before reading the rest of question

All previous tips are about preparing for the exam. The last tip will be about the exam itself. It consists of 50 questions and you have to answer them in 90 minutes. That is 108 seconds per question. That is a scary little amount of time when you have to parse 15 lines of code. Normally you start with checking if the code compiles. So you start looking for compile errors. Once you have done that you try to understand what the code does. The code will not be straight forward. There will be strange constructs in there. There will be things that do not make sense in the real world. Finally you have to find the correct answer. This is a pretty tall order to complete in 108 seconds. Actually I was not able to do it consistently. So I had to change my approach. 

I started looking at the answers before I read the question and this really sped me up. Maybe there is no answer option that says that it does not compile. So you do not have to check for compile errors. Maybe there is an answer option that says it will give a compile error at a given line. Now you can check this line for obvious errors. These are only two examples, but you can get a lot of information from the possible answers. So use this information to your advantage to get the correct answer faster. 

Thank you for reading this blog and good luck passing the exam!

The Java SE 11 Developer exam is a tough cookie. Read our 4 essential tips to help you pass the exam.

4 Tips to pass the Java SE 11 Developer exam

We schrijven allemaal wel eens code die op een later moment een punt van frustratie wordt voor onszelf, of onze collega’s. Soms copy-paste je een stuk code (dupliceren) en komt het er niet van om dit op te schonen. Of je maakt een ontwerp beslissing die in eerste instantie goed lijkt, maar waarvan later blijkt dat het een tijdrovende fout is geweest. 

In deze blog zal ik twee grote frustratiepunten beschrijven, met de focus op Java, wanneer je code probeert te veranderen: dupliceren (copy-pasten) en het onnodig koppelen (coupling) ten gevolge van overerving (inheritance). 

Het kan erg frustrerend zijn wanneer je denkt klaar te zijn met het aanbrengen van een verandering, om er dan achter te komen dat je dezelfde verandering op een tiental andere plekken in je code moet herhalen, voordat het goed zal werken. 

Tijdens het ontwerpen van een systeem, zou je altijd het DRY principe moeten volgen: Elk stukje kennis moet een enkele, eenduidige, belangrijke vertegenwoordiging hebben binnen een systeem. Echter, betekent dit niet dat elke identieke regel tekst of code een duplicaat is. Het kan ook gewoon zo zijn dat de implementatie identiek is. 

DRY gaat over het dupliceren van kennis, die onder andere voorkomt in:

Vaak vergeet men dat documentatie ook geüpdatet moet worden, samen met de veranderingen die je maakt aan je codebase. Het enige wat erger is dan geen documentatie, is verkeerde of verouderde documentatie. Verouderde documentatie kan misleidend zijn en kan je een hoop extra werk kosten. 

Commentaar, of ‘comments’, is slechts een andere vorm van duplicatie. Functies en variabelen met duidelijke namen hebben geen comments nodig. Comments binnen methodes zijn een teken dat de methode te lang is. Deze zouden opgedeeld moeten worden in aparte methodes, met duidelijk beschrijvende namen.

Developers die niet weten wat hun teamgenoten aan het bouwen zijn, lopen het risico om vergelijkbare code te schrijven. Hierdoor dupliceren ze onbewust functionaliteit die al bestaat. Dit kan alleen worden verminderd door betere communicatie. Actieve en frequente communicatie tijdens de dagelijkse stand-ups, forums, etc. Het is dan ook verstandig om de source code en documentatie van anderen te lezen tijdens code reviews of informeel. 

En dan nu: duplicatie in code. Het is het beste om klein te beginnen met het verwijderen hiervan. Allereerst lokaliseer en verwijder je kleinere stukjes gedupliceerde code in aparte methodes. Hierdoor wordt het makkelijker om daarna de grotere stukken van gedupliceerde code te lokaliseren en verwijderen. Vergeet niet om test units te draaien na elke grote verandering, zodat je niet elke keer te veel werk moet terugdraaien. 

Verplaats gedupliceerde code van verschillende klassen, naar zijn eigen klasse.  Na het verwijderen, moet de nieuwe klasse gekoppeld worden aan de klasse die gebruikt wordt. In Java heb je twee opties:

• Optie 1:een 'has a'-relatie. De originele klassen kunnen een fractie van de nieuwe klasse krijgen als een private attribute. Dit wordt ook wel composition of delegation genoemd, omdat je functionaliteit delegeert aan componenten van een andere klasse.

• Optie 2: Een "is-a" -relatie. De originele klassen kunnen de nieuwe klasse uitbreiden.

Het belangrijkste om rekening mee te houden wanneer je een implementatieoptie kiest, is: Erfbelasting. Je moet nog een verandering maken en denkt dat je klaar bent. Maar helaas, je komt erachter dat je zojuist de code op een tiental andere plekken hebt gebroken, omdat meerdere klassen sterk met elkaar gekoppeld zijn.

Gelukkig zijn er een aantal goede methodes als het gaat om het verminderen van onnodige koppelingen. Eén daarvan is: Betaal geen erfbelasting. Inheritance/overerving is een vorm van koppeling en moet dus vermeden worden indien mogelijk. 

Waarschijnlijk is dit niet wat je geleerd hebt. Inheritance gebruiken voor gedragssamenstelling en polymorfisme is een gangbare praktijk die je in elk OOP-handboek aantreft. In de praktijk heeft het echter een aantal ernstige nadelen.

Allereerste: dit zul je je misschien niet realiseren, maar wanneer een klasse is overerft, ontstaat er koppeling tussen meerdere concrete classes. Een kind klasse is gekoppeld aan een ouder klasse, een "grootouder klasse" enzovoorts. Maar elk object dat dit kind klasse gebruikt, is ook gekoppeld aan al zijn voorouders. 

Ten tweede: in een beperkt domein is het logisch dat een auto een soort voertuig is. Maar zodra het domein waarin je werkt gecompliceerder en realistischer wordt, worden deze modellen complexer en bijna onmogelijk te vormen. Bijvoorbeeld: wat gebeurd er wanneer een auto ook een soort eigenvermogen, te verzekeren object, etc. is. In dit geval heeft de auto dus meerdere overervingen nodig. Dat is niet alleen onmogelijk in sommige talen, zoals Java, maar indien het wel mogelijk is, eindig je vaak met complexe modellen die je alleen maar hoofdpijn bezorgen. 

In plaats daarvan, kun je één van deze technieken gebruiken, zodat je nooit meer inheritance nodig hebt:

Interfaces: het implementeren van interfaces geeft je polymorfisme zonder inheritance. Deze objecten bevatten normaal gesproken geen implementatie en een klasse kan een oneindig aantal implementeren

Delegation: door het implementeren van ‘class instance’ als een attribute, kun je alle onnodige methodes van de klasse die je niet gebruikt verbergen. Hiermee verminder je grotendeels de complexiteit. Dit betekent echter wel dat je meer code zal moeten schrijven.

Mixins: het principe van een mixin is simpel. Je wil klassen en objecten kunnen uitbreiden met nieuwe functionaliteit, zonder inheritance te gebruiken. Stel dat je twee gerelateerde functies zou hebben, genaamd 'find(id)' en 'findAll()', en je wil dat meerdere klassen in staat zijn om deze functies te gebruiken. Je wil natuurlijk geen inheritance gebruiken, maar delegation voegt weer onnodige code toe. Als de taal waarin je programmeert over deze optie beschikt, zou het er ongeveer zo uitzien:

// in sudo code

mixin CommonFinders {
  def find(id){ … }
  def findAll(){ … }
}
class AccountRecord implements BasicRecord with   CommonFinders { … }

Dit is helaas niet beschikbaar in Java, maar sinds Java 8 kunnen we interfaces definiëren met (public) default methodes. Hierdoor kunnen we methodes toevoegen met implementaties aan interfaces. In Java 9 is de mogelijkheid toegevoegd om private methods in interfaces te gebruiken, wat het mogelijk maakt om schone default methods te hebben. In Java kunnen we een mixin die een interface gebruikt op de volgende manier nastreven:

// in Java 9+ code

public interface CommonFindersMixIn {
  default Record find(String id) { … }
    default Record findAll() { … }


// some private methods
// private void example () { … }
}

class AccountRecord implements   BasicRecord, CommonFindersMixin { .. }

Eén probleem blijft bestaan. Omdat private attributes nog steeds niet toegestaan zijn binnen interfaces, beperkt dit de opties die je hebt wanneer je complexe methodes schrijft. In dit geval zal je dus geen andere keuze hebben dan delegation te gebruiken en dus nog een beetje meer code te moeten schrijven. 

Duplicatie en inheritance zijn niets meer dan anti-patterns. Ze hebben voordelen op de korte termijn, maar bezorgen je uiteindelijk alleen maar problemen. Clean code is niet alleen beknopt en zonder duplicatie, maar het vergroot ook geen concrete classes tenzij dit absoluut noodzakelijk is. 

Referenties
David Thomas and Andrew Hunt (2020): The Pragmatic Programmer. 
Michael Feathers (2005): Working Effectively with Legacy Code.
Nicolo Pignatelli (2018): Inheritance Is Evil. Stop Using It. 

Dupliceer geen bestaande code en betaal geen erfbelasting

Het hebben van een native app die beschikbaar is in de Playstore (Android) en de App Store (iOS) was gevoelsmatig lange tijd een must. Ten tijde van mijn opdracht bij de Politie kwam het nieuws naar buiten dat zij stoppen met de Politie-app die je via de appstores kon downloaden.

Uit onderzoek van de Politie bleek dat de burgers en ondernemers de Politie-app te weinig gebruiken tegenover de hoeveelheid geld en energie wat het kost om de app te ontwikkelen en onderhouden. De Politie geeft aan verder te gaan op de responsive website en de andere omnichannel mogelijkheden zoals social media en chat.

Dat brengt mij bij het onderwerp of je als organisatie wel een native app moet willen en of je ook kan kijken naar alternatieven zoals een hybride of PWA (web) app. Ook als front-end consultant krijg ik regelmatig de vraag wat je nou het beste kan doen. Daarom probeer ik je in deze blog post mee te nemen in bepaalde gedachten, zodat het je op weg kan helpen om de juiste keuze te maken.

Stel je staat als organisatie op het punt om een bepaald product en/of dienst te ontwikkelen, dan kan jij jezelf een aantal vragen stellen die mogelijk relevant zijn:

Wat moeten gebruikers op hoofdlijnen kunnen doen?

Wat en met welke frequentie gaan de gebruikers ermee aan de slag?

Welke securityeisen stel ik aan mijn (native) app?

Welke performance ervaring wil ik de gebruikers geven?

Hoe (her)bruikbaar moet het zijn met andere (web)applicaties?

Wie moet het (kunnen) ontwikkelen en met welke snelheid?

Natuurlijk, dit zijn niet alle vragen die jij jezelf kunt stellen. Het geeft je echter wel handvaten om na te denken zodat je weet welke keuze je kan maken. Deze vragen kan je meten door te weten wat het verschil is tussen een native, hybride of PWA app. 

Het verschil tussen native, hybride en PWA (web) apps

Native App
Een native app ontwikkel je voor 1 specifiek platform zoals iOS of Android, welke je beschikbaar maakt voor de specifieke appstore. Je kunt gebruik maken van alle native functionaliteiten die het mobiele apparaat heeft, zoals bijvoorbeeld het op de achtergrond kunnen gebruiken van de locatiegegevens of het sturen van push notificaties. Je hebt de mogelijkheid om de beste performance te bereiken en kunt de beste design en flow experience toepassen. Daar tegenover staan de ontwikkelkosten versus het aanbod in de markt. 

Hybride app
Een hybride app is nog steeds een app die je uiteindelijk beschikbaar maakt voor de specifieke appstores. Doordat je ontwikkelt in een bepaald soort schil heb je de mogelijkheid om te bepalen of je dit doet voor iOS, Android of voor beiden. Deze schil, wat een framework is zoals bijvoorbeeld React Native, Native Script of Ionic, geeft je toegang tot een beperkt aantal mogelijkheden van het mobiele apparaat. Voorbeeld hiervan zijn de NFC-chip of het werken met offlinedata. Je bent in staat om direct voor verschillende platformen te ontwikkelen en minimale verschillen door te voeren. Uiteindelijk kan je minder bereiken dan een native app, maar wat betreft ontwikkelkosten en de techniek gebaseerde frameworks kan het voordeliger en efficiënter zijn. 

PWA (web) app
Een Progressive Web App is een applicatie die je volledig kan ontwikkelen met webtechnieken zoals HTML, CSS en Javascript. De PWA is vanuit de browser benaderbaar en te installeren. Je kunt met een PWA beperkt gebruik maken van functionaliteiten zoals de camera, offlinedata of push notificaties. Het geeft je de indruk dat je een native app aan gebruiken bent. Naast de beperkte functionaliteiten kan het ook nog eens verschillen hoe deze te gebruiken zijn per platform. Kort gezegd kan je met minimale effort een webapp ontwikkelen.

Welke techniek kies je voor je app en in welke case?

Terug naar waar ik deze blog mee begon. De Politie-app verdwijnt uit de appstores met de hierboven genoemde redenen. Naar mijn inzien klinkt dat logisch als je deze meet aan de eerdere relevante vragen en de verschillen tussen een native, hybride en web apps. Of je dan direct helemaal geen app meer hoeft te hebben, dat betwijfel ik. Zeker voor de Politie lijkt het mij dat je ook de mogelijkheid moet hebben tot het hebben van een hybride app of PWA (web) app. Met als reden dat je een groot maatschappelijk belang hebt, maar niet de volledige native ervaring nodig hebt voor de dienstverlening.

Ter afsluiting van dit blog richt ik mij op twee cases die ik wil koppelen aan een technische keuzes.

Case 1 - Tijdens een festival wil je de timetable kunnen inzien. Daarnaast wil je de bezoekers bij een bepaalde locatie een badge laten verdienen voor een gratis drankje. 

In dit voorbeeld weet ik wat gebruikers moeten kunnen doen. Hieruit maak ik op dat het beperkte doelgroep is, maar wel een brede doelgroep. Om iedereen de mogelijkheid te geven wil je voor beide platformen (iOS en Android) iets hebben staan. Je wilt wel een zo goed mogelijke performance bereiken. Daarnaast wil je gebruik maken van de locatiegegevens en offlinedata. In dit geval zou ik een hybride app als eerste willen onderzoeken.

Case 2 – Als kleine organisatie zie ik dat gebruikers regelmatig maken gebruik van een mijn omgeving en ik wil deze permanent en makkelijk beschikbaar maken.

In dit voorbeeld zie je duidelijk terugkomen dat het om een kleine organisatie gaat en dat er al een mijn omgeving is. Het zijn minimale requirements, namelijk het makkelijker en permanent beschikbaar maken. Daarom zou ik als eerste stap nemen om te kijken hoe je dit kan hergebruiken zodat je tot een webapplicatie kan komen. De simpelste manier in deze lijkt een PWA (web) app. 

Het bepalen van welke keuze je moet maken hangt af van je doelgroep, de frequentie, de requirements en de kosten. Wil je hierover een keer brainstormen, dan kan je daarover altijd contact met mij opnemen via jeroen.burgers@cinqict.nl of via mijn Linkedin-profiel.

Weet jij welke keuze je moet maken als het gaat om een native, hybride of PWA (web) app? Lees snel ons blog.

Wanneer kies je voor een native, hybride of PWA (web) app?

CINQ ICT is een expert op het gebied van Data, DevOps en Development. Een van de expertises binnen de Development unit is Java. Binnen de Development unit hebben wij gecertificeerde professionals die graag een uitdagend project aan gaan.

Een voorbeeld van een dergelijk project is de upgrade van Java 8 naar Java 11 bij Topicus Pension & Wealth. Het bedrijf is voornamelijk actief in de financiële sector. In 7 scrum teams werken zij met passie aan innovatieve en complexe systemen voor onder andere de fondsen- en aandelenhandel, vermogen en pensioenen. Ondanks dat men weet dat Java 8 voorlopig nog ondersteuning zal ontvangen van verschillende partijen, wil Topicus graag alvast de stap maken naar Java 11. Door nu alvast aan deze upgrade te beginnen, nemen zij het heft in eigen handen en zijn ze goed voorbereid op de toekomst. De upgrade komt dan ook de continuïteit van de software op lange termijn ten goede.

Het upgraden naar Java 11 gaat gemoeid met enkele interne Java wijzigingen, waardoor het upgrade-proces lastiger is dan slechts de sources compileren met een Java 11 compiler. Voor het upgraden is Topicus op zoek gegaan naar een partner die de kennis en kwaliteit heeft om deze upgrade tot een succes te brengen. Hieruit is de samenwerking ontstaan tussen Topicus en CINQ ICT. Op deze manier kan Topicus zich blijven focussen op het ontwikkelen van nieuwe features voor hun software oplossingen, en kan CINQ ICT zich volledig focussen op de upgrade naar Java 11. 

Met onze kennis van het Java platform, upgraden wij de libraries en API's, zodat deze weer compatibel zijn met Java 11. Het resultaat is dus niet enkel een upgrade naar Java 11, maar ook een solide basis om verdere upgrades op uit te kunnen voeren. Daarnaast stelt het Topicus in de gelegenheid om nog mooiere en betere software te bouwen met de nieuwste features van Java 11.

Kan jouw organisatie ook hulp gebruiken bij de upgrade naar Java 11? Of heb je een andere uitdaging op het gebied van software ontwikkeling? Neem dan contact met ons op.

Lees hier meer over de upgrade van Java 8 naar 11 die CINQ voor Topicus Pension & Wealth heeft uitgevoerd.

Java 11 upgrade voor Topicus Pension & Wealth

Upgrade van Java 8 naar 11 voor Topicus

De afgelopen jaren heb ik in meerdere scrum teams aan verschillende projecten gewerkt. Het leek me hoog tijd om mijn kennis van het Scrum framework te bevestigen, daarom ben ik een onderzoek begonnen naar welke certificeringen er allemaal bestaan en hoe je je het beste hiervoor kunt voorbereiden. 

De eerste certificering die ik tegen kwam, was de Professional Scrum Master I (PSM I), aangeboden door de Scrum.org organisatie. Scrum.org is opgericht door Ken Schwaber, niemand minder dan de co-creator van Scrum zelf. Een goede plek om te beginnen. Scrum Alliance is een andere bekende organisatie die professionals de mogelijkheid bied om zich te certificeren. Welke je kiest is natuurlijk aan jou, maar ik koos ervoor om dit avontuur aan te gaan via de Scrum.org certificering. 

Maar is dit niet een blog over hoe je je PSD I examen kunt halen, in plaats van de PSM I? Je hebt natuurlijk helemaal gelijk. Hier alvast mijn eerste tip voor het halen van je PSD: haal eerst je PSM I. 

Voordat ik de PSD haalde, heb ik eerst het PSM I examen gedaan. Als je de twee examens vergelijkt, zijn bijna tweederde van de vragen die worden gevraagd tijdens het PSD examen, zo overgenomen uit het PSM I examen. Dus, als je de PSM I hebt behaald, heb je het grootste gedeelte van de kennis al verkregen die je nodig hebt voor je PSD examen.

Hoe behaal je de Professional Scrum Master I certificering? 

Tijdens het studeren voor het PSM I examen gebruikte ik de volgende bronnen:

The Scrum Guide:  Dit document is het hart van Scrum. Als je dit document volledig begrijpt, zul je het examen halen - en nog belangrijker - zul je Scrum begrijpen. Ik adviseer dit document te downloaden en het een paar keer goed door te lezen. Dan laat je het een week met rust en lees je het opnieuw. 

Deze gids bevat een aantal uit je hoofd te leren definities. Zorg ervoor dat je deze definities goed onthoudt, of in ieder geval weet waar je deze informatie snel kan vinden wanneer je de test aan het maken bent. De eerste 75% van je examencijfer zal namelijk bestaan uit (relatief makkelijke) vragen m.b.t. de verschillende definities die beschreven worden in de gids.

De laatste 25% van de vragen zal te maken hebben met de gedachte achter Scrum. Je zal een aantal scenario vragen krijgen en je zal moeten bepalen welke van de antwoorden het beste past binnen het Scrum framework. Dit zijn de lastige vragen. Maar, geen zorgen. Er zijn goede bronnen te vinden die je hierbij kunnen helpen. 

Open Assesments: Er zijn oefenexamens (open assessments) beschikbaar voor elke entry-level certificering. Dit zijn gratis oefenexamens waarbij je vragen krijgt die lijken op de vragen uit het daadwerkelijke examen. Het fijne hiervan is dat je deze onbeperkt overnieuw kunt doen. Elke keer dat je een oefenexamen begint, krijg je 30 willekeurige vragen uit een grotere verzameling. Elke keer is het oefenexamen dus anders. 

Als je een bepaald oefenexamen meerdere malen hebt gedaan, zal je de vragen gaan herkennen. Mijn ervaring is dat het echte examen meerdere vragen zal bevatten die je ook al bent tegengekomen tijdens het oefenexamen. Sommige vragen zullen net iets anders zijn, maar er wel veel op lijken. 

Dus als je consequent 100% kunt scoren op je oefenexamen, weet je dat je klaar bent voor het échte examen.

Online cursus: Als je daar behoefte aan hebt, kun je ook een online cursus volgen. Ikzelf heb de cursus 'Scrum Certification Prep + Scrum Master + Agile Scrum Training' door Paul Ashun gevolgd via Udemy. Zou je het examen kunnen halen na alleen deze cursus te hebben gevolgd? Nee, dat denk ik niet. Maar het heeft mij in ieder geval wel geholpen bij het maken van de oefenexamens. 

Third-party oefenexamens: De beste manier om te oefenen voor een examen, is dus om te oefenen met een oefenexamen. Nadat je alle vragen van de open assessments uit je hoofd kent, is er nog een plek waar je je hart kunt ophalen met oefeningen.

Mikhail Lapshin is een developer die zo aardig is geweest om een online quiz tool met veel oefenvragen te maken, zodat je kunt oefenen voor het Scrum examen. Dit is een geweldige plek om te oefenen en ik heb er veel baat bij gehad. 

Hoe moet je je voorbereiden voor het Professional Scrum Developer examen?

Je hebt hard geleerd en hebt je PSM I examen behaald. Gefeliciteerd! Nu ben je klaar voor de volgende stap. Als je het leuk vond om te leren voor je PSM examen, raad ik je aan om zo snel mogelijk te starten met de voorbereidingen voor je PSD examen. 

Allereerst, wanneer je net bent afgestudeerd van een Informatica (of gerelateerde) opleiding, dan zal je je het PSD examen waarschijnlijk meteen kunnen halen na het voltooien van je PSM. Dan zou ik je in ieder geval adviseren om een paar keer te oefenen met de Open Assessments, zodat je je écht zeker voelt om je PSD te gaan halen. 

Als je echter een meer praktische en minder theoretische programmeer achtergrond hebt, of als je benieuwd bent welke theorieën een centrale rol gespeeld hebben bij het creëren van het Scrum framework, dan zou ik je zeker adviseren om de volgende drie boeken te lezen:

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

The Pragmatic Programmer. Your journey to mastery - door David Thomas & Andrew Hunt

Working Effectively with Legacy Code - door Michael C. Feathers

Als laatste zou je de Agile Alliance website eens moeten bezoeken. Hier kun je de Agile Glossary vinden, waarin 75 van de must know termen en definities worden beschreven voor Agile developers. Dit is een geweldige bron om na te gaan of je de theoretische achtergrond al hebt, die je nodig zult hebben voor het examen. Ook is deze tool handig om even snel iets op te zoeken, als je bepaalde termen wil dubbelchecken tijdens het examen.

In dit blog van software engineer Ian van Nieuwkoop, kun je lezen hoe je je het beste kunt voorbereiden op het Professional Scrum Developer I examen.

Tips om je Professional Scrum Developer I (PSD I) certificering te halen

Containers hebben de wereld van applicatieontwikkeling drastisch veranderd. Het is makkelijker dan ooit om je applicatie snel in productie te laten draaien - maar hoe zorg je er voor dat dit veilig, schaalbaar, en onder controle blijft? Wij helpen grote bedrijven met de adoptie van Kubernetes, op een bestaande omgeving óf we bouwen een compleet nieuw platform. 

Bij Kadaster in Apeldoorn helpen we met meerdere engineers van CINQ om het applicatielandschap verder te optimaliseren met behulp van Docker en Kubernetes. 

Het Kadaster liep al een tijdje met het idee om Docker te gaan gebruiken, maar maakte er nooit een topprioriteit van. Toen CINQ werd gevraagd om te helpen met een consultant om de adoptie van Docker te stroomlijnen, werd al snel duidelijk dat het hebben van een uitgebreide container orchestrator meerdere voordelen kon hebben.

Door gebruik te maken van verschillende producten, waarvan Kubernetes het middelpunt is, heeft CINQ het Kadaster geholpen om een meer robuuste en microservice-georiënteerde aanpak te hanteren. Hun applicatieomgeving gebruikt Docker nu voor meer dan 90% van hun workloads en het gebruik van Kubernetes voor de meeste applicaties groeit gestaag.

We hebben het voor verschillende teams mogelijk gemaakt om op te schalen in de cloud door gebruik te maken van Kubernetes' auto-scaling functie. Dit heeft gezorgd voor een zeer lage time-to-market delivery pipeline voor een groot data delivery team binnen Kadaster. Door gebruik te maken van automatische down-scaling, worden de kosten van deze pipeline zo laag mogelijk gehouden.

Wil je meer weten over de Kubernetes dienstverlening van CINQ? Neem dan contact op voor een vrijblijvende afspraak. 

De engineers van CINQ helpen bedrijven zoals Kadaster met de ontwikkeling van een schaalbaar applicatieplatform met Kubernetes als basis.

Kubernetes implementatie bij Kadaster

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-weekend in Friesland. 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 op te lossen in verschillende Kubernetes clusters. Een score van 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

We all write code which ends up frustrating us or our colleges sooner or later. Sometimes you copy-paste some code and don’t get around to tidying it up or you make a design decision which seems like a good idea at the time, but later turns out to be a time-consuming mistake. 

In this blog I’m going to describe two sources of frustration, with the focus on Java, when trying to change code: duplication and unnecessary coupling caused by inheritance. 

It can be very frustrating when you need to make a change and you think: “I am finished", only to find out that you need to make the same change in a dozen other places. 

When designing a system, you should always follow what is called the DRY (Don’t repeat yourself) principle: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. 

However, this doesn’t mean every identical line of text or code is duplication. It could just be the case that the implementation happens to be identical.   

DRY is about the duplication of knowledge; it is found in:

It’s easy to forget that documentation also needs to be updated, along with the changes you make to your codebase. The only thing worse than no documentation is wrong documentation. Out-of-date documentation is very misleading and can cost you a lot of unnecessary time. 

Comments are just another form of duplication. Functions and variables with clear names do not need comments.  Comments inside of methods are a sign the method is too large and should be split into private methods, with descriptive names. 

Developers who don’t know what their colleges are building are likely to write similar code. They end up duplicating functionality which already exists.

This can only be reduced by better communication. Active and frequent communication during the daily standup, forums etc. You should read other people’s source code and documentation, either informally or during code reviews.

Finally, duplication in code. It’s best to start small. First, by locating and extracting the smaller pieces into separate methods. Then you can more easily start locating and removing the larger pieces of duplicate code. Remembering, of course, to run unit tests after each significant change, to prevent having to roll back too many changes.

Move duplication across multiple classes, to its very own class. After extraction this new class needs to be coupled to the classes using it. In Java you basically have two options:

Option 1: A “has-a” relationship. The original classes can be given an instance of the new class as a private attribute. This is also called composition or delegation, because you delegate functionality to components of a class. 

Option 2: A “is-a" relationship. The original classes can extend the new class. 

When choosing the option to implement, the most important thing to take into consideration is: Inheritance Tax. 

You need to make another change, and again you think you’re done. However, you find out you just broke the code in a dozen other places. 

Fortunately, there are several best practices when it comes to reducing unnecessary coupling. One of which is:  Don’t pay Inheritance Tax. Inheritance is a form of coupling and therefore must be avoided if unnecessary and most the time, this is the case.

Paradoxically, this is not what you have probable been taught. Using inheritance for behavioral composition and polymorphism is a common practice you find in every OOP textbook. However, in practice it has some serious disadvantages.

Firstly, you might not directly realize this, but when a class is extended it creates coupling between multiple concrete classes. Not only is a child class coupled to a parent, the parent’s parent, and so on. But also, any object which uses this child is now not only coupled to this child, but also to all the ancestors.  

Secondly, in a limited domain, it makes sense that a Car is a kind of Vehicle. However, as soon as the domain you are working in becomes more complicated and closer to reality, these models become more complex and nearly impossible to model. For example, what happens when a Car is also a kind of Asset, InsuredItem, and so on. This needs multiple inheritance, not only isn’t that possible in some programming languages, like Java, but when available you end up with complex models that end up just causing you a headache.

Instead use one of these techniques, so that you never need to use inheritance again:

Interfaces. Implementing Interfaces give us polymorphism without inheritance. These declarations don’t normally create any code and a class can implement an unlimited number. 

Delegation. By implementing a class instance as an attribute, you can hide all the unnecessary methods of the class you aren’t using. Significantly reducing its complexity. However, this comes at the cost of writing more code.

Mixins. The basic idea of a mixin is simple: you want to be able to extend classes and objects with new functionality without using inheritance. Say you have two related functions called ‘find(id)' and ‘findAll()' and you want multiple classes to be able to use these functions. But you don’t want to use inheritance and delegation adds unnecessary code. If the language you are programming in has this feature built in, it would look something like this:

// in sudo code

mixin CommonFinders {

  def find(id){ … }

  def findAll(){ … }

}

 
class AccountRecord implements BasicRecord with   CommonFinders { … }

This isn’t available in Java. However, since Java 8 we can define Interfaces with (public) default methods. This allows us to add methods with implementations to interfaces. Java 9 added the ability to use private methods in interfaces, enabling us to have nice clean default methods. In Java we could emulate a mixin using an interface as followed:

// in Java 9+ code

public interface CommonFindersMixIn {

  default Record find(String id) { … }

    default Record findAll() { … }

 

// some private methods

// private void example () { … }

}

class AccountRecord implements   BasicRecord, CommonFindersMixin { .. }
 

One problem remains. Because private attributes are still not allowed in interfaces, this limits your options when writing complex methods. In this case you will have no choice but to use delegation and be forced to write a bit more code.

Duplication and inheritance are nothing more than anti-patterns. Practices which only have short-term advantages, but eventually end up causing more harm than good. Clean code is not only concise and void of duplication, but it also definitely doesn’t extend concrete classes unless absolutely necessary. 

References
David Thomas and Andrew Hunt (2020): The Pragmatic Programmer. 
Michael Feathers (2005): Working Effectively with Legacy Code.
Nicolo Pignatelli (2018): Inheritance Is Evil. Stop Using It. 

Don't Repeat Yourself and Don’t Pay Inheritance Tax

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

Connected to a Kubernetes cluster, the GitLab Auto DevOps feature really impressed me. Setting this up appeared to be rather easy. This post shows you how to do it.

Onze laatste blogs