In de afgelopen jaren heb ik bij verschillende opdrachtgevers in diverse branches mogen werken, zo ook bijvoorbeeld voor de overheid. Vanuit een van deze opdrachtgevers was de wens om een nieuw platform te bouwen en beschikbaar te stellen aan meerdere doelgroepen en moest deze diverse functionaliteiten ondersteunen. De keuze stond vooraf al vast dat deze applicaties en API’s via een microservices architectuur ontwikkeld zouden gaan worden. 

Kort gezegd bestaat een landschap van microservices uit applicaties die ontwikkeld zijn als een verzameling van applicaties (dus functionaliteiten). Elke applicatie kan je zelfstandig ontwikkelen, implementeren en onderhouden zonder afhankelijkheden van andere applicaties.

Om een idee te geven hoe het platform is ontwikkeld doe ik in deze net alsof wij een pizzeria genaamd “De CINQeria” zijn met soortgelijke vraagstukken, namelijk:

De consument wil een lijst van pizza’s zien, samenstellen en bestellen via de website en een app;

De pizzeria wil de bestellingen ontvangen, bereiden en bezorgen via een webapplicatie en app. 

Op basis van deze wensen kom je tot een landschap van vier applicaties (de blauwe blokken) met overeenkomende functionaliteiten (de grijze blokken), zie de afbeelding:

Naast de applicaties zullen er ook vier backend services nodig zijn, zie de afbeelding:

Pizza Service, heeft als doel om bestelbare pizza’s terug te geven;

Topping Service, heeft als doel om de toppings voor een specifieke pizza terug te geven;

Payment Service, heeft als doel om de afhandeling van de betaling te regelen;

Order Service, heeft als doel om bestellingen binnen te krijgen en te verwerken.

Sommige functionaliteiten maken gebruik van meerdere services, maar er is vanuit de functionaliteit gezien altijd maar één ingang/startpunt. Voor de functionaliteit “overzicht” zal enkel de “pizza service” benaderd worden, eveneens voor de functionaliteit “samenstellen” welke de “topping service” gebruikt. Bij de functionaliteit “bestellen” wordt het al een stuk interessanter. Om de pizza’s te kunnen bestellen zal dit via de “order service” verlopen. Omdat je natuurlijk eerst moet betalen, zal er vanuit de “order service” een beroep gedaan worden op de “payment service” zodat de betaling gedaan en geverifieerd kan worden. De functionaliteit “bestelstatus” zal via de “order service” verlopen.

Voor de consumenten zijn de ingangen naar de services voornamelijk via de “pizza service” en “topping service” om vervolgens te bestellen via de “order service”. Vanuit de CINQeria is de ingang voornamelijk de “order service”. Deze laat ons namelijk weten welke orders er zijn geweest. In een order staat onder andere informatie welke pizza’s er zijn samengesteld en of de betaling succesvol is gedaan. Om de functionaliteit “orders” en “bereiden” te kunnen doen zal de “order service” als startpunt worden genomen. Deze haalt vervolgens weer informatie op uit de andere services. Voor de consument als de CINQeria ziet het er dan ongeveer zo uit:

De communicatie van en naar services kan je op allerlei manieren optuigen. De belangrijkste regel die je moet onthouden is dat elke service zijn eigen doel heeft. De “order service” heeft (data)-afhankelijkheden van alle andere services, maar het doel is nog steeds het geven van informatie over de order. Je kunt het zien dat elke service een contract heeft voor input en output. Dat wil zeggen dat de inhoudelijke informatie van de order wordt opgehaald uit de andere services. In de “order service” staat informatie over welke pizza ID’s en bijhorende topping ID’s. Idem van de betalingstatus. Door middel van contractbeheer (schema’s definiëren, contracttesting, etc) hou je grip op wat erin en uitgaat. De data kan je bijvoorbeeld laten lopen via message queuing en het ophalen van data via GraphQL. Ook wil ik gelijk benadrukken dat alleen dit al een vak apart is tussen services.

Naast de services weten wij ook dat De CINQeria meerdere applicaties gaat gebruiken. Zo heeft elke applicatie zijn eigen gebruikers, zijn eigen doel en eigen platform. Door hier zo slim mogelijk over na te denken kom je tot een wens om een aantal dingen vast te leggen, dit zijn een Design System en Styleguide, gedeelde componenten en gedeelde functionaliteiten. Omdat allemaal te bereiken maak ik een keuze die wel toekomst vast is, maar waarin je nog wel de mogelijkheid om keuzes te maken.

Voor de CINQeria wil ik zo min mogelijk ontwikkelen en een zo groot mogelijk bereik hebben via verschillende platforms. Daarom kies ik voor een Design System uit Webcomponents (gemaakt via StencilJS) en een gedeelde library waarin ik dezelfde (deel)-functionaliteiten heb. Dan kan je ongeveer op zoiets uit:

De gedeelde library wil ik ontwikkelen met Angular, zodat de meeste applicaties hier slim gebruik van kunnen maken. De mobiele applicaties wil ik bijvoorbeeld ontwikkelen met Ionic in combinatie met Angular. Op deze manier heb ik samenwerking tussen het Design System, de gedeelde library en de applicatie zelf.

De blauwe blokken zijn nog steeds de applicaties en de oranje blokken beschrijven op welke manier. Binnen deze applicaties wordt gebruik gemaakt van de donkergrijze blokken, wat dus gedeelde functionaliteiten zijn die op hun beurt weer gebruik maken van het Design System. De lichtgrijze blokken zijn ook functionaliteiten, maar binnen de applicatie zelf. Ook deze componenten maken weer gebruik van het Design System. 

Door middel van dit artikel hoop ik jullie een klein beetje meegenomen te hebben in de wereld van microservices in combinatie met Micro Frontends. Zogezegd, zo gedaan. Ten tijde van dit artikel wist ik natuurlijk op voorhand al ongeveer wat ik wilde gaan schrijven. Toch heb ik hier en daar wat moeten aanpassen in de blokjes van functionaliteiten en services om het verhaal beter over te brengen. De belangrijkste conclusie die ik kan meegeven is keep it simple en hou vast aan het doel van de service of applicatie. Hoort dat echt bij die service of wordt het op nog meer plekken gebruikt? Is het daarom reden voor een eigen service? Maar let op; blijf bij de les. Het landschap aan services groeit snel, dus zorg altijd dat je het onder controle hebt met contractbeheer en testing. Een gewaarschuwd mens telt voor twee.

Een landschap van microservices uit applicaties (van frontends) die ontwikkeld zijn als een verzameling van applicaties (dus functionaliteiten).

De CINQeria; een wereld van microservices en frontends

In een eerder blogartikel benadrukte ik dat een native app ontwikkelen lange tijd gezien werd als een must. Ik legde de nadruk op de keuzes die je kan maken om de juiste beslissing te kunnen maken. Daarin had ik mij voorgenomen om niet specifiek te richten op de mogelijkheden van native apps. Voorheen werd specifiek ontwikkelen voor Apple of Android als ‘lastig’, ‘duur’ en ‘veel tijd’ ervaren, omdat je dit moest doen in verschillende talen; namelijk Swift en Java/Kotlin. Om dit probleem op te lossen heeft Google een cross-platform gelanceerd genaamd Flutter. Is Flutter daarmee de toekomst van cross-platform native apps?

UI-toolkit voor native compiled applicaties voor mobile, web en desktop

Flutter zet zichzelf in de markt als een UI-toolkit om native compiled applicaties te ontwikkelen voor mobile, web en desktop. Dit doe je door middel van een single codebase, wat wil zeggen dat je één stuk code hebt wat zich laat compileren naar de specifieke platformen die jij wenst. Om een Flutter app te ontwikkelen zal je de (vrij) nieuwe programmeertaal Dart je eigen moeten maken. Flutter leent zich ervoor om snel te ontwikkelen door Stateful Hot Reload en ben je de baas over elke pixel van de applicatie. 

Dart lijkt enigszins op een combinatie tussen Java/C# en Javascript. Het verdeelt zichzelf over drie verschillende eigenschappen. Een geoptimaliseerde UI, productieve development ervaring en snelle performance op alle platformen. Dart is – volgens wat zij zelf schrijven – makkelijk om te leren. Je kunt gemakkelijk code (on)afhankelijk van elkaar maken. Door middel van je eigen editor kan jij dingen als debugging snel voor elkaar krijgen. Ook passen zij AOT-compile toe om zo de juiste performance ervaring te bereiken. 

Voor meerdere platformen (snel) ontwikkelen vanuit een single codebase

Ook mogelijkheid tot het compileren van een native desktopapplicatie

Voorzien van een herkenbare/vergelijkbare architectuur

Beschikbare widgets zijn getest en makkelijk te gebruiken

Dart-code het meest dicht bij het native platform

Regelmatig breaking changes, onderhoud kan een uitdaging zijn

Geen mogelijkheid tot specifieke UI voor verschillende platformen

Programmeren in Dart vereist een leer curve, maar makkelijk te leren

Niet volledige mogelijkheden kunnen benutten van de telefoon

Niet de eerste keuze voor kleine apps (compileert veel)

Als je kijkt naar de voor- en nadelen, dan zie je gelijkenissen met andere hybride frameworks. De juiste keuze hangt af van ervaring, doelen en vereisten. Flutter zou ik overwegen wanneer de focus echt ligt op performance. Het is hoe dan ook sneller dan oplossingen die door middel van een webview wordt geladen. Door de vele breaking changes zou ik eerder neigen bij grotere apps voor een andere oplossing (bijvoorbeeld React Native) te kiezen. Het heeft – net als vele anderen frameworks – zeker potentie. Nogmaals verwijzend naar mijn eerdere blogartikel, voeg daarbij Flutter zeker toe als optie.

Lost Flutter het probleem op om niet meer per platform te hoeven ontwikkelen? De mogelijkheden zijn er, maar is Flutter de toekomst?

Flutter, de toekomst van cross-platform native apps?

Is Flutter de toekomst van cross-platform native apps?

Soms vraag ik mijzelf wel eens af of ik energie moet blijven steken in de verschillende frameworks, in het bijzonder Angular. De wereld gedraagt zich zoals deze gevormd wordt door ons als ontwikkelaars. Er is altijd wel weer wat nieuws, maar hoe zorg je dat je op de hoogte blijft van alles? Als ervaren front-end developer probeer ik bij te blijven in deze ontwikkelingen, maar pin ik mij niet vast aan een bepaald framework. Simpel gezegd leer ik de concepten van het ecosysteem van de frameworks en focus ik mijzelf altijd op de native kant van Javascript.

Terug naar het onderwerp; Angular. Om met de deur in het huis te vallen is het (nog steeds) een keuze die je als organisatie kan maken. Het framework is niet uitgestorven in tegenstelling wat je sommige soms hoort zeggen. Kijk je puur ter vergelijking van de downloads via NPM dan heeft Angular niet gewonnen en niet verloren. Op basis van de sterren kan je bepalen of iets populair is, daarin blijft Angular achter ten opzichte van een React of zelfs Vue. Het aantal issues is bij Angular vele maler groter dan bij de andere frameworks. Het biedt meer, dus er zijn meer bugs of feature requests.

Een aantal jaar geleden heeft het team van Angular besloten om elk halfjaar met een nieuwe versie (major) te komen. Sinds de eerste stabiele release medio 2016 zitten wij anno 2021 op versie 12. Hoewel het als major-release wordt uitgerold bevatten deze nauwelijks breaking changes. Door middel van de update guide kan je gemakkelijk van versie 6 naar 8 of van 8 naar 12 updaten. 

De ontwikkeling van Angular staat allesbehalve stil. Dat zie je vervolgens ook terug in de verbeterpunten en functionaliteiten die zijn toegevoegd. In versie 6 was de belangrijkste changes om de meest gebruikte third party packages eveneens mee te laten bewegen in de update cycles van Angular. Vanaf versie 8 stond performance en bundle sizing centraal, waar je in versie 9 het alom bekende ‘Ivy compiler and runtime’ als standaard werden gesteld. Last but not least in versie 12 hebben zij onder andere gewerkt aan het (beter) beschikbaar maken van libraries zodat functionaliteiten herbruikbaar kunnen zijn.

Als laatste punt waar ik stil bij wil staan is dat Angular een duidelijke roadmap beschikbaar heeft gemaakt. Momenteel zijn zij bezig met het versnellen van de unit test tijden. Kijk je verder naar waar zij nu mee bezig zijn, dan zie je daar een aantal interessante dingen op staan als bijvoorbeeld het verbeteren van toegankelijkheid van de components of het bijwerken van de end to end test strategie.

Mijn conclusie is dat Angular heel veel in zich heeft waarbij je ook voor de komende jaren prima mee vooruit kan. Dat wil niet zeggen dat het altijd de keuze is die het meest aansluit. Er zijn genoeg redenen (tijd/budget/kennis/doel/organisatie) om te kiezen voor een ander framework, dat zijn voor mij ook de belangrijkste redenen om mij te blijven verdiepen. Zoals ik eerder al schreef. Er is voor mij geen bepaald framework wat voor mij het belangrijkste is, zolang ik maar de context en concepten van de andere frameworks maar niet vergeet. Bijvoorbeeld dat de CINQ-website is ontwikkeld met Next.js en Prismic. Stay informed, je bent nooit te oud om te blijven leren!

Wat is de toekomst van Angular? En waarom gebruik ik het nog? Het blijft (nog steeds) een optie.

Waarom ik nog steeds Angular gebruik, maar ook andere frameworks niet vergeet

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?

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

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

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.

Onze laatste blogs over Development