Wil je een native app naast een web applicatie? Dan is dit nu duur en tijdrovend. Bij het bouwen van native apps gebruiken ontwikkelaars meestal andere talen, tools en frameworks. Dat betekent extra ontwikkelkosten en een langere time-to-market. Met Flutter bouw jij voortaan een app voor elk scherm vanuit een single codebase. Een win-winsituatie voor veel bedrijven en ontwikkelaars, want de ontwikkelkosten worden verlaagd en de time-to-market wordt versneld. Ik neem je mee waarom Flutter het platform is voor de toekomst.

Bekijk hieronder de presentatie van Jeroen Burgers op de CINQ.Conferentie 2023.

Tegenwoordig kies ik voor Flutter - Jeroen Burgers @ CINQ. Conferentie 2023

Bekijk de presentatie van Jeroen Burgers op de CINQ.Conferentie 2023: "Tegenwoordig kies ik voor Flutter"

Tegenwoordig kies ik voor Flutter

Op donderdag 5 oktober stond CINQ CTO Bouke Nijhuis op Devoxx Belgium met zijn talk "The Battle of the AI coding assistants". 

"So you are hearing more and more about AI coding assistants, but you do not know where to start? In this talk the biggest names in the AI coding space will go head to head. After a short introduction, I (or the AI?) will do several live coding sessions. All the assistants will get some time on stage. Furthermore, the pros and the cons of every tool will be discussed, but also the use of these tools in general. I will give my opinion on when to use which assistant. Finally, I will provide a glimpse into the future of AI coding assistants. After attending this session you should be able to improve your productivity by using the right coding companion."

Bekijk de opname van zijn presentatie hieronder:

The battle of the AI coding assistants By Bouke Nijhuis

The battle of the AI coding assistants

In my previous blog post -  Refactor that ugly code (Part 1) -  I talked about getting an ugly piece of code under test. Getting that code under test enables us to refactor it in a confident and safe manner. A safety net is in place. It is time to drive this thing home. In this post we are going to see if we actually can get rid of those pesky code smells.     

At the end of part 1 we ended up with this code: 

Now it is time to see if this code needs any refactoring. Let’s try to get a whiff of the code smells. Before we start, it is important to notice that the fact of code smells being present in your code base doesn’t necessarily mean that the code needs to be refactored. Code smells aren’t a bad thing, they are just signs that your code might give you headaches in the future. Afterall, why should we go on a refactor frenzy if the code never changes? If it never changes you might as well do it quick and dirty, commit, push and don’t look back.

Unfortunately (but fortunately for this blog, otherwise it would be a really short blog) in almost every case code changes. So we try to anticipate changes. We just don’t know exactly when they will come and what that change actually will be. At the risk of sounding a bit like captain obvious or come across as extremely boring, the easiest way to brace yourself for future changes is to keep your methods small. This doesn’t mean we dive into the code and start breaking it up and extract everything into its own class/method until we have a huge collection of one-liner methods. No, there has to be a reason or thought behind it. The number one reason to break things up in smaller pieces/modules is almost always: “each class should have its own responsibility or reason to exist”.   

We don’t want hollow middleman classes that just pass everything on to the next class. Neither do we want big “God” classes that do everything by themselves. “But what do we want?” you might ask yourself then. When looking at a class, the most important question I ask myself is: “What is the purpose of this class?”. Another great question to ask yourself would be: ”Is this class doing too much?”. If so, we might need to do something about all those responsibilities. 

To see if a class has too many responsibilities we need to determine what the purpose of this class is. Judging by the name of our class (AlarmService) it seems to be some kind of service class that coordinates the process of determining whether the alarm should be switched on or not. If I had to describe what a service class is/does, I would try to explain it with a real world analogy. A service kind of acts like a human traffic controller. The traffic controller blows his whistle, signals you to stop or shouts at you to drive your car in a certain direction when needed. What he certainly does not do is get in the car and drive it himself into the desired direction. Do you see the similarities? The service class shouldn’t be bothered with all that boring low-level stuff. A service should be delegating, that is what it is good at.

Looking at the service class in the code I see that the service has a state (the mutable field alarmStatus). This is a code smell and a red flag! You should never have state in a service class. There are several reasons for not having state in your service. For me, reusability and testability are the main reasons. Currently the alarm service is tightly coupled with the alarm state. The reusability is not as good as it could be. If we receive a new requirement which states that we want to be able to turn on the alarm manually for a reason not related to the pressure of a tire then we still have to use the entire AlarmService to achieve this. The method AlarmService.check() alters the state. AlarmService should not care how to turn on the alarm. It should delegate that to another class. Another thing that seems odd is the fact that the AlarmService itself is performing some sort of calculation to check if the pressure of a tire is within or outside a certain range. 

To sum it all up we can see the following responsibilities for this class:

The class coordinates the decision making logic for turning on an alarm. 

The class also does the decision making itself.

The class behaves like some sort of instrument to measure the pressure.

Ideally  a class should have one responsibility. Although the AlarmService in this example is very small, it already looks like a Swiss army knife! It knows and does too many things. Not ideal if your code is going to change in the future. If we don’t do something about it now, the cost of changing your code in the future can turn out to be really high.  

Another thing to look for in code is the readability of the code. Can we comprehend the code without reading the code over and over again? For example, if we look at the check method in the screenshot below we see that it isn’t a very long and complex method. But, besides the wrong naming of the threshold variables (variables that start with a capital letter?), that if-statement isn’t very reader-friendly so to speak. Every time I read it I am mentally reasoning what it actually is doing. This could be optimized. Let’s add this to the list of things to refactor.

Okay, enough complaining. Let's actually do something about that code. Based on the gathered responsibilities and weird things already spotted I came up with the following todo list:

break the hard dependency that the service has on the TireSensor

get rid of the state in the service and extract the alarm logic into its own class

delegate the actual assessment of the pressure into its own class

make sure the code is readable/understandable

First thing on the todo list: We want to break the hard dependency that the service has on the TireSensor class. We want that ugly “new TireSensor()” statement out of the code. 

We could accomplish this by injecting the sensor into the AlarmService. My first thought would be to do that via the constructor. And this is where my first design decision comes into play. Because, a service is typically instantiated as a Singleton and if I then inject the sensor via the constructor I would never be able to use/check multiple sensors without instantiating multiple alarm services (which is very hard to do when the service in question is a Singleton). If I always want to check the same sensor during the lifetime of the app, injecting it via the constructor would be fine. However, in this case, I think it would be wiser to inject it via the AlarmService.check() method. We now have some flexibility and anticipate being able to measure multiple sensors in the future. Sounds like a good reason that justifies the decision to inject it through the method.

By the way, I say "justifies" which kind of implies that taking another decision is wrong. But that’s not the case at all. I rather prefer the phrase “each design decision has a trade off” instead of talking about right or wrong.

After altering and adding unit tests and changing my code, it now looks like this. We are providing the dependency to the service through the method. Sweet! One down, several to go! 

Oh and by the way. You remember in my previous blog Refactor that ugly code (Part 1) we ended up with an inner TestableAlarmService class? We don't need that anymore! We can supply the mock through the check method. Cleaner tests! Win-win!

The next thing we want to improve is separating the actual alarm from the service. The AlarmService shouldn’t be responsible for keeping track of the state of an alarm. It’s time to create an alarm and release the service from that burden.

The way the alarm is working now is that you can turn it on once and you can never turn it off again. It sounds like that could use some improvement too. Let’s also change that while we are at it. STOP! This would be the point to stop typing, get away from the keyboard as far as you can and try to remember what the goal of this whole change was in the first place. The goal here is not to add any additional requirements and/or features. We are refactoring! Which means we want to improve the code (quality) without altering the behavior of the system. We can put this new idea on the backlog and carry on with our initial goal. After writing the tests upfront we can now start to implement the Alarm class.

And of course we want to use this alarm in our AlarmService. We inject it into our service. Via the constructor this time. This is also a design decision! I expect that we don’t need to use several different alarms when using the AlarmService. A constructor injection seems alright here. If this decision doesn’t turn out to be the right decision, it isn’t the end of the world! The main thing to keep in mind is that after refactoring you are always in a much better shape for maintaining your code than before we started this whole excercise. So, don’t be scared to make decisions. I would rather make a decision with certain trade offs which might be “wrong” but still improve your code quality. It is always better than doing nothing and having a crappy code quality.

We are progressing quite nicely. The alarm is extracted and injected, the sensor is injected… What else? Next up is moving the logic for the actual assessment of the pressure out of the class.

Now that we are on a roll we want to take away even more responsibilities from the service class. We could (and we should) put the logic/calculation, to determine if the measured pressure falls within or outside a certain range, into a separate class. 

One of the other things which is also very important is naming things. The naming should be logical (well, duh!). As logical as it sounds, it is also a hard thing to do. You don't want to end up with long class names like “TheTireSensorPressureRangeChecker”. On the other hand, you don’t want to be too vague either, like calling it “SensorManager” or something along those lines. What helps me name things is to try and think of a real world example that resembles what you want the class to do or to represent. 

“PressureGauge” seems to be a good name. And as always, we write the tests first! And we can do that fairly quickly because we already have the test cases in the AlarmServiceTest class from part 1. After that it is time to implement the gauge. In this implementation the gauge accepts a TireSensor, measures the pressure, assesses whether the pressure is too low, too high or optimal (based on the thresholds) and returns the result of the assessment (PressureState) to the calling client .  

A practical tip: it is good practice to “return” to the calling class as soon as you know the answer, instead of storing your result in a temporary variable and “returning” at the end of the method. Another great tip is that if for some reason you do need to store the value in a temporary variable, place it as close as you can to the place where you need the variable (pressure variable is right above the if-statement where it is first used). 

And just like we have seen with the alarm we also want to use this implementation and inject it in the AlarmService. And we're done! I already mentioned that naming things is important. I chose to rename the AlarmService into PressureMonitorService. This way the class name reflects the purpose of the service way better.

Note how we wrapped the delegation of the pressure assessment and alarm activation in a “pressureIsNotOptimal()” and an “activateAlarm()” method. The check method now almost reads like a normal sentence. The responsibilities are separated quite nicely and if another developer now looks at the code, he can immediately see what the intention of the class is and what the PressureMonitorService.check() method does. 

By the way, I also removed the method getAlarmStatus(). It feels a bit out of place. Since we now have a separate alarm, other classes that are depending on the alarm shouldn’t have to call that method via the AlarmService. Every other class in the system that needs to know the status of the alarm should be depending on the alarm and not this service class. Important thing to keep in mind is that other classes in the system could already call the getAlarmStatus() method. If we remove the method we also have to fix that. So before you delete a method you should always check where that method is used. If you have to change the whole application when you delete the method then you might want to postpone this action and do this in another user story. 

We refactored a lot but looking at the PressureMonitorService it was all worth it. We are ready for future changes! At the beginning we started with three classes/objects and no tests. Now that we are finished we ended up with twice as many classes/objects plus a fair amount of unit tests. The code has been split up in cohesive and logically bundled code blocks. The responsibilities are finally in the classes where they should be!

One last thing… When I show this code to other developers, there will always be a few that say: “But now I can’t see in one glance what the AlarmService is doing exactly”, “The calculation for assessing the pressure is in a separate class”, “The alarm and its logic is in another class”. "The code is scattered all over the place", “In the old code the only thing I had to do was open the AlarmService to know everything”.

My question to them would be: “Why do you want to know everything?”. You should not need to know everything in order to change something. If I had to choose between: 

putting all the logic in the AlarmService in order to literally know everything at a glance or

separating all the responsibilities into well designed/balanced classes that work together in a logical way and be better prepared for future changes…

… I would always go for the latter!  And if you do want to know everything in one glance, then you probably should have chosen a procedural language instead of Java to begin with.

As always, the code is available on my GitHub:

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

If you check out my code you might notice that the pressureGauge class looks entirely different than the one in this blog. That's because I was not done yet with my refactoring. I was experimenting and seeing if it is handy and/or useful to apply the Chain of Responsibility pattern to that class. But including that also in this blog is beyond the point I was trying to bring across. Zooming in on that though might be a nice sequel to this part. If you think this would be a great topic for another blog, let me know.

In this blog software engineer Victor Louisa shows you how to refactor existing code to get rid of the code smells.

Refactor that ugly code - Part 2

Refactor that ugly code (part 2)

Ik vind het schrijven van software een prachtig onderdeel van mijn baan, omdat bijna alles mogelijk is. Er wordt een idee bedacht om te bouwen, voor dat idee wordt een tech stack gekozen, en vervolgens wordt er vanuit niets iets gemaakt. Natuurlijk worden er tools, frameworks, en programmeertalen gebruikt, maar het echte begin is een lege editor zonder enige code. Deze vrijheid zorgt er alleen ook voor dat iedereen een eigen mening kan hebben over... nou ja, alles. Een style guide kan zorgen om een deel van de ontwikkeling binnen bepaalde grenzen te houden. Gelukkig kunnen die grenzen per groep afgesproken worden en is er geen gouden oplossing die voor iedereen werkt, dus we zijn niet alle vrijheid kwijt. Maar wat is een style guide precies? Waarom zou een style guide gebruikt moeten worden? Dat ga ik in deze blogpost toelichten.

Een style guide is een verzameling conventies die voorschrijven hoe code geschreven moet worden voor een specifiek project. Denk hierbij aan de formatting van de code zoals de indentatie; wordt deze met spaties of met tabs gedaan, en hoeveel precies. Of welke manier gebruikt moet worden voor het plaatsen van haakjes. Een limiet zetten voor het aantal karakters per regel is ook een veelgebruikte style guide regel. Wist je dat er vroeger zelfs een harde limiet van 80 karakters per regel was? Dit kwam door de tijd waar men nog met punch cards programmeerde - de punch cards van IBM hadden een maximum van 80 karakters per regel.

Er zijn veel onderdelen van programmeren die beschreven kunnen worden in een style guide. Grote tech bedrijven hebben hun style guides online staan, maar ook programmeertalen hebben soms een standaard style guide. Google en Airbnb hebben bijvoorbeeld style guides online staan die veel gebruikt en erg bekend zijn. Van de programmeertalen is een bekende style guide die van Python, bekend onder de naam PEP-8 (Python Enhancement Proposal 8). Nieuwe projecten gebruiken deze style guides vaak als basis, echter, omdat ze zo veelomvattend zijn, passen de projecten aan wat zij nodig vinden. Een uitgebreider overzicht van style guides vind je hier: https://github.com/Kristories/awesome-guidelines.

Om een beeld te krijgen van wat er beschreven kan worden in een style guide, heb ik hier een aantal voorbeelden uit de Google Java style guide.

“Source file basics”, hoe een bestand genoemd moet worden.

“Source file structure”, hoe imports geplaatst moeten worden in een bestand.

“Formatting”, hoe haakjes geplaatst moeten worden, hoe whitespace gebruikt wordt, en is er een karakterlimiet per regel beschreven.

“Naming”, hoe namen geschreven moeten worden (bijvoorbeeld camelCase of PascalCase).

“Programming Practices”, hoe bepaalde technische implementaties gebruikt moeten worden, zoals het afhandelen van exceptions.

“Javadoc”, hoe en wanneer Javadoc geschreven moet worden.

Waarom vind ik een style guide belangrijk?

Mijn voorstel om een style guide te gebruiken, krijgt regelmatig weerstand van collega's. Ik hoor vaak "als het maar te lezen is toch?", of "zolang het werkt maakt het niet uit hoe de code eruit ziet". Ik denk dat het volgen van een style guide belangrijk is, ongeacht de werking van de code.

Laat mij je meenemen in een kort verhaal. Het moment is aangebroken dat je als software engineer begint in een nieuwe codebase. Je bent er vol op gebrand om zo snel mogelijk te begrijpen wat er gebeurt in de code. Je download het project, begint met het lezen van de code, en… je hebt geen idee wat er gebeurt. Er is code die buiten het scherm valt, de indentatie varieert in lengte, soms zijn er witregels en soms totaal niet. Het gebruiken van haakjes gebeurt inconsistent, en bij elk stuk nieuwe code wat je tegenkomt, heb je geen idee wat je moet verwachten qua styling of logica. Na een paar uur is er meer tijd op gegaan aan begrijpen wat je hebt gelezen dan begrijpen wat de code doet. Zonde van de tijd, en frustrerend omdat je zo had gehoopt op een eenvoudige en snelle start.

Het bovenstaande verhaal is een perfect voorbeeld waarom ik een style guide belangrijk vind. Stel dat de code geschreven zou zijn volgens een style guide. In dat geval zou er consistentie zijn in de formatting van de code, de toegepaste logica, en eventueel ook in de opzet van de bestanden. Hierdoor wordt de codebase voorspelbaar waardoor hij makkelijk te navigeren is, en de code leest makkelijker omdat alles in dezelfde opzet is geschreven. Ook hoeft er geen discussie meer te zijn over welke stijl er toegepast wordt - dit is al besloten en ligt vastgelegd in de style guide. Daardoor kan er gefocust worden op het bouwen van nieuwe functionaliteit in plaats van discussies over de stijl te voeren.

Ik heb een minimum aan drie style guide regels die ik overal toegepast zou willen zien.

Als eerste, de indentatie. Wordt er met vier spaties gewerkt, of misschien met twee? Als tweede moet er een karakterlimiet per regel zijn, waarbij mijn voorkeur ligt op 120 karakters per regel. Als derde, welke methode voor haakjes (indentation style) wordt er gebruikt? Er zijn veel verschillende methoden hiervan, maar mijn favoriet is Kernighan & Ritchie stijl, ook wel bekend als K&R. Het openende haakje aan het einde van de eerste regel code, het sluitende haakje op een nieuwe regel:

De tegenhanger van K&R is vaak de stijl van Eric Allman, bekend onder de “Allman” stijl.
 Daarbij krijgt elk haakje zijn eigen regel:  

Style guides worden al heel lang gebruikt

Style guides worden al heel lang toegepast in andere industrieën. De wetenschap hanteert bijvoorbeeld style guides voor het noteren van referenties, zoals de Modern Language Association en de American Psychological Association guides. Voor marketing is een goede style guide zelfs bijna essentieel voor merkherkenning. Denk maar aan de witte oortjes van Apple; voordat Apple begon met witte oortjes waren ze allemaal zwart. Ook de wereld van boeken gebruikt style guides. Deze zijn zelfs zo bekend dat iedereen weet hoe een boek is opgebouwd: een bepaald aantal hoofdstukken die bestaan uit meerdere paragrafen, met op elke pagina een vast aantal karakters per regel. Stel je voor dat je een boek zou kopen waarbij elke regel ergens anders op de pagina begint en eindigt.

Persoonlijk vergelijk ik het schrijven van code met het schrijven van een boek. In beide gevallen wordt er tekst geschreven. In beide gevallen moet het format voorspelbaar zijn zodat het begrijpbaar is en het fijn leest. De consistentie van de styling en de voorspelbaarheid van wat er gaat komen, zorgen ervoor dat de focus ligt op content. Bij een boek is dat het verhaal, en bij een code is dat de logica die geïmplementeerd is.

Hopelijk is de belangrijkheid van een style guide ondertussen duidelijk, en is nu de vraag hoe deze toegepast kan worden. Globaal zijn er twee manieren:

De style guide documenteren, zoals het voorbeeld van de Google Java style guide hierboven

De style guide forceren via een tool genaamd een linter, zoals bijvoorbeeld Prettier.

Het documenteren van een style guide is de oude manier waarop een style guide werd gehandhaafd. Software engineers moeten hierbij elkaar controleren op het naleven van de style guide, en het document moet aangepast worden als er veranderingen zijn. Het nadeel van deze aanpak is dat een document vrij eenvoudig genegeerd kan worden. Ook kunnen engineers het niet eens zijn met de style guide en iets anders doen dan wat is voorgeschreven.

De aanpak van het forceren van een style guide is tegenwoordig een populaire. Linters zoals Prettier komen met een geopinieerde, vooraf bepaalde set regels die worden afgedwongen door middel van het scannen van de code. Als ergens de code niet voldoet aan de regels, kan dit direct aangegeven worden. Op deze manier kunnen software engineers de style guide altijd toepassen via een linter check. De linter kan geconfigureerd worden om een error of een warning te geven. Hierdoor kan een team zelf bepalen of ze de build compleet willen stoppen, of alleen een waarschuwing willen. Nog beter, de linter kan in elke stap van het development proces worden meegenomen:

Tijdens ontwikkeling, waarbij "format on save" toegepast kan worden. Hierbij wordt de code automatisch naar de style guide aangepast zodra een bestand wordt opgeslagen.

Tijdens het bouwen van de applicatie, waarbij de linter het build proces tegen kan houden als de code niet voldoet aan de regels.

Tijdens een CI/CD pipeline, waarbij de linter de pipeline kan stoppen bij het niet naleven van de regels.

Zelf ben ik een groot voorstander van style guides. Het zorgt voor consistentie, voorspelbaarheid, en leesbaarheid van de code. Waar je ook komt in de code, de stijl is herkenbaar waardoor de focus op logica kan blijven liggen. Daar komt bij dat je weet dat je collega's op dezelfde manier de code zullen schrijven. Via linters zijn style guides eenvoudig toe te passen zodat er geen tijd verloren gaat. Uiteindelijk zal iedereen baat hebben bij het toepassen van een style guide. En nee, een style guide hoeft niet heel uitgebreid en complex te zijn. Mij maak je allang blij met drie regels; welke methode voor haakjes gebruiken wij, wat is de karakterlimiet per regel, en hoeveel spaties indentatie gebruiken wij?

Bart van Dijk heeft een blog beschreven om je een beeld te geven van wat er kan worden beschreven in een style guide. Hiervoor heeft hij een aantal voorbeelden gebruikt uit de Google Java style guide.

Er worden zes onderdelen beschreven, namelijk Source file basics, Source file structure, Formatting, Naming, Programming Practices en Javadoc.

Style guides zijn een must-have

De laatste jaren is "Developer Experience", soms afgekort als DX, een steeds populairder onderwerp geworden. Developer experience omschrijft vooral hoe software developers het gebruik van hun tools ervaren, zoals een IDE of de API van een te implementeren stuk software. Hoe makkelijker een tool in gebruik is, hoe beter de developer experience. Echter, software development omvat meer dan alleen het schrijven van code. Van begin tot eind moet er worden gepland, ontworpen, geprogrammeerd, gedeployed, en uiteindelijk moet de software onderhouden worden. Al deze stappen zijn beter bekend als de Software Development Life Cycle (SDLC). In deze blogpost wil ik uitleggen waarom ik de SDLC belangrijker vind dan DX, en hoe de kwaliteit van een SDLC gemeten kan worden.

De developer experience zoals hij tegenwoordig bekend is, focust volledig op het schrijven van software, waarbij alles draait om de developer. Hoe blij is de developer met zijn IDE? Hoe snel kan een developer benodigde informatie vinden? Hoe snel is de feedback loop voor een developer? En hoewel dit hele goede vragen zijn om te stellen is het een kortzichtige manier van kijken naar de bouw van software.

De bouw van software gebeurt niet alleen door developers, maar door een compleet team. In mijn werk als software engineer heb ik altijd meerdere rollen om mij heen:

Informatieanalisten die zorgen dat de te bouwen functionele processen duidelijk beschreven zijn.

Data analisten zorgen ervoor dat de binnenkomende, tussentijdse, en uitgaande data correct is.

Operators werken aan stabiele infrastructuur en deployments.

Product Owners leiden het team in goede banen en zorgen dat de wensen van de klant geïmplementeerd worden.

Afhankelijk van bij welk bedrijf of in welk team gewerkt wordt, kunnen er meer of minder rollen aanwezig zijn. Mijn punt hierbij is dat ik, samen met mijn mede-software engineers, afhankelijk ben van mijn teamleden. Als in deze context gekeken wordt naar de DX kan het prima zo zijn dat de DX erg goed is, terwijl de werkervaring van mijn team nog steeds beter kan. Ik kan immers een fijne laptop hebben, een goede IDE, en een framework met goede tooling. Dit verzekert alleen niet dat mijn team net zo fijn kan werken, noch dat dit gemeten kan worden via een DX meting.

De SDLC kan meerwaarde leveren doordat het een heel team omvat, en niet alleen de developers. Er bestaat soms variatie in hoe de SDLC omschreven wordt, maar globaal gezien omschrijft de SDLC vijf fasen van software development:

Varianten van de SDLC zijn beter bekend als de waterval methode, iterative development, of Agile. Van deze varianten is Agile tegenwoordig de meest gebruikte. Voor een operator zal het zwaartepunt van de SDLC liggen bij Deployment en Maintenance. Een informatieanalist zal eerder focussen op de eerste twee fasen. Voor mij als software engineer zit het zwaartepunt van de SDLC in de Implementatie & Testen fase. In het geval dat er aandacht wordt besteed aan het verbeteren van de DX dan zou je alleen maar de Implementatie & Testen fase gaan verbeteren. Door te kijken naar de volledige SDLC en te verbeteren waar mogelijk kan de werkervaring voor het hele team worden verbeterd, met daarmee een toename in efficiëntie en productiviteit tot gevolg.

Het bepalen van de kwaliteit van een SDLC gaat het beste aan de hand van de vijf fasen, door naar de kern van elke fase te kijken. Welke rollen zijn essentieel? Wat hebben deze rollen nodig, en krijgen zij ook wat zij nodig hebben? Het lastige aan deze vragen (en in mijn ogen, ook het mooie) is dat er nooit een enkel, definitief, antwoord gevonden kan worden. Geen enkel team werkt op dezelfde wijze, en daarmee hebben geen twee teams hetzelfde antwoord. Echter, door kritisch te blijven, kunnen er in elk team verbeteringen gevonden worden.

Om theorie in praktijk te brengen wil ik een typisch scenario schetsen. Jeff Bezos heeft ooit voor Amazon bepaald dat een team niet groter mag zijn dan tien man, ondertussen bekend als een "2-pizza team". Dit zou de samenwerking verbeteren en het team efficient houden. Laten wij uitgaan van deze grootte en een team van tien personen nemen; 1 product owner, 4 developers, 2 testers, 2 informatieanalisten, en 1 data analist. Per fase zal ik aangeven wat ik denk dat de primaire rollen zijn voor die fase, eventuele secundaire rollen, en een toelichting waarom. Ook zal ik een aantal vragen formuleren als voorbeeld van waar de focus voor de fase op ligt.

De eerste fase is Planning. De primaire rol hierbij is de product owner. Secundair zijn de analisten en de developers. Tijdens de planning is het belangrijk om te kijken naar wat er gebouwd moet gaan worden voor de klant, en wanneer dit klaar moet zijn. De product owner is representatief voor de klant en heeft de beslissende stem in wat er gebouwd wordt en wat prioriteit heeft. Uiteraard zijn de analisten en developers van belang om in te schatten of zij de wensen van de product owner realiteit kunnen maken, maar het uiteindelijke besluit is aan de product owner om te nemen. Voor de analisten is het relevant om te kijken naar hoe een gevraagde functionaliteit moet werken en hoe de werkzaamheid na oplevering geverifieerd kan worden. De verificatie kan in een later stadium door de testers opgepakt worden. De developers moeten een inschatting maken over hoe zij de gevraagde functionaliteit kunnen bouwen. Vragen die belangrijk zijn bij deze fasen:

Wanneer is de oplevering van een functionaliteit?

Welke functionaliteit heeft de hoogste prioriteit?

De tweede fase is het Definiëren van Requirements. Hierbij zijn de analisten en de developers van primair belang. De testers kunnen ondersteunend zijn door mee te denken over hoe een functionaliteit getest kan worden. De gevraagde functionaliteit is duidelijk door de Planning fase, maar hoe de functionaliteit er uit gaat zien wordt in deze fase bepaald. De analisten zijn belangrijk voor het functionele deel, de developers voor het technische deel. Vragen die gesteld kunnen worden:

Hoe kunnen de acceptatiecriteria geverifieerd worden?

Kan iedereen meedenken en praten over de requirements, ongeacht senioriteit? Of wordt er vooral naar 1 persoon geluisterd?

Is er voldoende kennis om de requirements te bouwen?

Zijn er requirements die nog niet in de functionaliteit omschreven worden, maar wel nodig zijn zoals uptime of specifieke foutmeldingen?

De derde fase gaat om het Implementeren & Testen van de functionaliteit. Hierin zijn de developers en testers het belangrijkste. Secundair zijn de analisten om de developers en testers te ondersteunen wanneer informatie niet duidelijk is en meer toelichting nodig heeft. De developers moeten de functionaliteit bouwen naar de vastgestelde acceptatiecriteria. Testers kunnen toetsen of de acceptatiecriteria daadwerkelijk gehaald worden nadat de developers een eerste of opvolgende implementatie hebben gemaakt. Vragen die gesteld kunnen worden:

Is het testproces of de feedbackloop snel genoeg voor het team?

Zijn er nog bugs die opgelost moeten worden?

Zijn er voldoende automatische tests om regressie tegen te gaan?

De vierde fase is de Deployment van de applicatie. In deze fase komt de applicatie op de productieomgeving terecht met de nieuwe functionaliteit. Primair hierin zijn de developers om de deployment uit te voeren. Secundair zijn de analisten en eventueel ook de testers (hoewel testen op productie zwaar afgeraden wordt). De developers zorgen voor een goede deployment, via eventueel een geautomatiseerde pipeline. Daarna kunnen de analisten kijken of de functionaliteit aanwezig is en naar behoren werkt. Dit proces kan uiteraard eerst uitgevoerd worden op een acceptatieomgeving die gespiegeld is aan de productieomgeving om problemen met de productie applicatie te voorkomen. Vragen die gesteld kunnen worden:

Is de deployment goed gegaan? Draait de nieuwe versie van de applicatie naar behoren?

Hoeveel versies draaien er tegelijkertijd?

Als laatste is er de fase Maintenance. Hierin wordt de applicatie onderhouden en wordt er gezorgd dat de applicatie functioneel blijft. Functionaliteit kan worden verbetert, eventuele bugs worden opgelost, en processen kunnen worden gestroomlijnd. Uiteraard allemaal via een nieuwe development cyclus. Primair hierin zijn de developers, en secundair zijn de product owner en de analisten. De developers moeten voor het onderhoud zorgen, waar de product owner en de analisten bevindingen kunnen doen voor verbeteringen. Vragen die gesteld kunnen worden:

Is er genoeg informatie aanwezig om goed onderhoud te plegen?

Hebben de developers goede monitoring en alerting voor als er iets niet goed gaat met de applicatie?

Blijven de acceptatiecriteria behaald worden?

Kan de applicatie de druk van de hoeveelheid gebruikers nog aan?

Blijft de data consistent na lang gebruik van de applicatie?

Ik hoop dat via deze blogpost mijn blik op development duidelijker is geworden. Hoe belangrijk de developer experience ook wordt bevonden de laatste tijd, software ontwikkelen draait om meer dan alleen developers. Het vereist een toewijding van het hele team waarbij in elke fase van software development verbeteringen mogelijk zijn, weergegeven via de SDLC. Als elke fase gestroomlijnd is, zal het hele team tevredener en productiever zijn in hun werk. Dit bevordert uiteindelijk ook de experience voor developers. Ik zou daarmee ook willen pleiten om niet alleen naar "developer experience" te kijken maar om dit breder te nemen - noem het een "software development experience".

Waarom de hele software development life cycle (SDLC) belangrijker is dan alleen de developer experience (DX).

Verder kijken dan de populaire Developer Experience

In het verleden heb ik veel met het MQTT protocol gewerkt. Dit protocol bestaat al een tijd en wordt steeds vaker gebruikt, met name in smart home/IoT projecten. Doordat ik dit protocol steeds meer terug zie komen, leek het mij leuk om in deze blog uitleg te geven over wat dit protocol precies is, waar het voor gebruikt wordt en wat de voor- en nadelen zijn. Aansluitend heb ik een stuk code gemaakt dat gebruikt kan worden om het MQTT protocol uit te proberen. 

MQTT is een client/server protocol dat gebruikmaakt van een publish/subscribe principe. Het protocol wordt tegenwoordig voornamelijk gebruikt voor IoT (Internet of Things) doeleinden. Het protocol is in eerste instantie bedacht om met een lage bandbreedte, weinig energie en lage installatiekosten oliepijpleidingen te monitoren. Dit ging namelijk via satelliet verbindingen en was erg kostbaar. Tegenwoordig wordt MQTT in vele industrieën (zoals auto, logistiek, olie & gas) gebruikt. Daarnaast wordt dit protocol massaal gebruikt in smart-home oplossingen. 

MQTT bevindt zich in de applicatielaag van het OSI model en maakt gebruik van TCP/IP als transport. Hierdoor is het te gebruiken op een standaard netwerk en is er geen speciale hardware nodig om er mee te kunnen werken. Naast dat MQTT snel is en weinig bandbreedte vraagt, is het goed schaalbaar en zijn de berichten data agnostisch. Dit laatste houdt in dat het in principe niet uit maakt wat voor type data verstuurd wordt, hoewel berichten in JSON formaat het meest worden gebruikt. 

In deze blog zal ik de fundamentele basisprincipes van het MQTT protocol uitleggen. Meer informatie hierover is te vinden in de specificatie. 

Publish/subscribe is de methode die gebruikt wordt door het MQTT protocol en dient als een alternatief voor de request/response (polling) methode. Het voordeel van deze methode is dat alleen geïnteresseerde clients berichten ontvangen, wat efficiënt is voor het netwerkverkeer. 

De publish/subscribe methode werkt als volgt: als gebruiker kun je je "abonneren" (subscribe) op een topic waar je geïnteresseerd in bent. Wat een topic exact inhoudt wordt later uitgelegd. Gebruikers kunnen berichten sturen (publish) op topics. Zodra een bericht verstuurd is op een topic, zullen gebruikers die geabonneerd zijn op het topic het bericht ontvangen. Gebruikers die niet geabonneerd zijn op het topic zullen overgeslagen worden en zullen het bericht niet ontvangen. 

Een voorbeeld dat het wellicht duidelijker maakt is het abonneren op een YouTube kanaal. Zodra op dat kanaal nieuwe content verschijnt, krijgen abonnees hier bericht van, terwijl andere YouTube gebruikers dit bericht niet krijgen. 

De illustratie hierboven laat zien dat een temperatuursensor een nieuwe waarde verstuurd naar het topic "building1/room1/temperature". Naast de temperatuursensor is in de illustratie te zien dat er drie andere clients zijn. Van deze drie clients zijn er twee die geabonneerd zijn op het topic van de temperatuursensor. Deze twee clients krijgen dan ook het gepubliceerde bericht binnen, de andere client krijgt hier niks van te zien. 

De broker is het hart van het MQTT protocol. De broker is een centraal punt waar MQTT gebruikers (clients) zich op aanmelden. De broker houdt bij welke clients verbonden zijn en op welke topics zij zich hebben geabonneerd. Zodra de broker dus een bericht binnen krijgt van een bepaald topic, filtert de broker de clients die zijn geabonneerd op dat topic en stuurt vervolgens het bericht naar alleen deze clients. De illustratie hieronder laat hetzelfde principe zien als de illustratie gebruikt bij Publish en Subscribe. Echter deze keer met een broker als centraal punt. 

Figure 2. Publish/subscribe met broker voorbeeld 

De belangrijkste verantwoordelijkheden van de broker zijn: 

Het bijhouden van topics waar clients op zijn geabonneerd en welke clients dit zijn.

Het doorsturen van berichten naar gebruikers die zijn geabonneerd op het topic. 

Autorisatie van clients. 
Autorisatieregels kunnen opgesteld worden per client. Deze regels stellen welke topics beschikbaar zijn, welke operaties toegestaan zijn (publish en/of subscribe. 

Authenticatie van clients. 
Authenticatieregels kunnen opgesteld worden om te bepalen wat voor clients nodig is om met de broker te kunnen verbinden. Dit kan door het aanmaken en implementeren van een password file bij de broker configuratie. In dit bestand staat aangegeven welke gebruikersnamen acceptabel zijn met een versleuteld wachtwoord. Alleen de combinatie van de juiste gebruikersnaam en wachtwoord geven toegang tot de broker. Een andere vorm van authenticatie is het gebruik van een X.509 certificaat. 

De broker heeft ook de mogelijkheid om het berichtverkeer te versleutelen. Dit gebeurt door middel van TLS certificaten die toegevoegd kunnen worden aan de configuratie van de broker. Hier boven werd de X.509 certificaat genoemd als vorm van authenticatie, dit kan verwerkt worden in een TLS certificaat. De client biedt een client certificaat aan en bij de zogeheten TLS handshake zal dan de authenticatie uitgevoerd worden. Meer informatie over het TLS protocol is te vinden via deze link. 

Een topic is een punt dat de broker gebruikt om berichten te filteren voor de clients. Een topic kan uit meerdere niveaus bestaan, hierbij wordt een "/" gebruikt als scheidingsteken voor de niveaus. Doordat topics uit meerdere niveaus kunnen bestaan is het dus mogelijk om een hiërarchie te maken. Een goed voorbeeld hiervoor is "gebouwnaam/verdiepingsnaam/ruimtenaam/sensortype-/waarde". Naast topicniveaus heeft MQTT ook wildcards geïntroduceerd. Door een wildcard te gebruiken is het mogelijk om te abonneren of berichten te versturen op meerdere topics met een enkel statement. 

Topics hoeven niet eerst aangemaakt te worden. De broker accepteert elk topic zolang het maar minstens 1 karakter en geen spaties, speciale tekens of wildcard symbolen bevat. Let wel op dat topics hoofdlettergevoelig zijn. 

MQTT biedt veel voordelen, maar brengt ook nadelen met zich mee. Hieronder is een klein overzicht van belangrijke voor- en nadelen: 

Weinig resources 
MQTT verbruikt minimale resources, hierdoor is het protocol geschikt voor kleine microcontrollers. 


Lage bandbreedte 
MQTT gebruikt kleine headers voor de berichten, hierdoor wordt bespaard op bandbreedte


Eenvoudig te implementeren 
Open protocol dat geen additionele hardware vereist. 


IoT ready 
MQTT kan gebruikt worden voor IoT projecten. 


Goed schaalbaar 
MQTT netwerken kunnen wel uitbreiden tot miljoenen clients. 


Data agnostisch 
Berichten kunnen verstuurd worden in elk format. 


Security 
TLS encryptie en authenticatie mogelijkheden. 


Keuze in betrouwbaarheid bericht verkeer 
Quality of Service niveau is instelbaar 


Ondersteuning voor onbetrouwbare netwerken (Session awareness) 
Het is mogelijk om client sessies tijdelijk te laten onthouden door de broker, hierdoor zal opnieuw verbinden erg snel gaan. 

Single-point of failure 
Een actieve broker is nodig om een MQTT sessie actief te houden. 

Nu een uitleg is gegeven over het MQTT protocol, is natuurlijk nog de vraag hoe dit in de soft ware uitgevoerd kan worden. Het code voorbeeld is te vinden door te klikken op deze link. In dit voorbeeld is te zien hoe met een broker verbonden kan worden. Vervolgens zal er geabonneerd worden op een topic waarbij later een bericht verstuurd wordt. De printlines zullen bevestigen dat het bericht verstuurd en ook ontvangen is. Als laatste zal de sessie worden afgesloten door de verbinding met de broker te verbreken. Om deze code uit te kunnen voeren, is het van belang dat de juiste libraries worden geïmporteerd. In dit voorbeeld is gebruikgemaakt van de Paho library. Dit is een open source library van Eclipse die onder andere via Maven of Gradle is te importeren. Klik op deze link voor meer informatie. 

In het code voorbeeld is gebruikgemaakt van een online broker instantie die gratis te gebruiken is. Het is ook mogelijk om zelf lokaal een broker te configureren en starten. Een veel gebruikte broker is de Mosquitto broker. Ook deze software is een open source project van Eclipse. Klik op deze link voor meer informatie. De standaard configuratie zal al voldoende zijn om de code te kunnen gebruiken. Het is dan wel nodig om de BROKER String aan te passen naar het IP adres of domein adres waar de broker wordt gebruikt. Bij lokaal gebruik is hier het adres "tcp://localhost:1883" vol doende voor. 

Zoals te zien is in het broker adres, is dit meer dan alleen het IP of domein adres. Deze String bevat nog een prefix en een suffix. De prefix, in dit geval "tcp", staat voor wat voor soort verbinding opgezet moet worden. Hierbij is de keuze uit "tcp" voor onbeveiligd en "ssl" voor een beveiligde verbinding. De suffix bestaat uit een reeks cijfers, in dit geval "1883". Dit is het poortnummer waar de broker gebruik van maakt. Standaard staan MQTT brokers zo ingesteld dat "1883" gebruikt wordt voor een onveilige verbinding en "8883" voor een beveiligde verbinding. Uiteraard zijn andere poortnummers ook mogelijk. 

Als de libraries succesvol zijn geïmporteerd en de code wordt uitgevoerd zal het volgende resultaat moeten verschijnen: 

Connecting to broker: tcp://test.mosquitto.org:1883 
Connected 
Subscribing to topic: l2mqtt/exampleTopic 
Publish message to topic: l2mqtt/exampleTopic 
Published message! 
Received message from topic: l2mqtt/exampleTopic 
Message: Test message 
Disconnected 

In deze blog heb ik de theoretische basisprincipes van het MQTT protocol uitgelegd en door middel van een code voorbeeld geïllustreerd. Het protocol is echter het beste uit te leggen door middel van een toegepast voorbeeld. Daarom laat ik in mijn volgende blog een leuke toepassing zien van het MQTT protocol in een Minecraft-mod.

Wat is het MQTT protocol? In dit blog lees je waar dit protocol voor is, hoe het werkt en wat de voor en nadelen zijn.

Wat is het MQTT protocol?

Op donderdag 13 april 2023 stond Bouke op Devoxx France met zijn talk 'Improving your skills with the Debugger". Hij kreeg voor deze talk maar liefst een score van 4.47 uit 5! 

Deze presentatie gaat over het verbeteren van je debugging game. De meeste ontwikkelaars gebruiken alleen het spreekwoordelijke topje van de ijsberg bij het werken met de debugger. Er valt nog zoveel meer te leren, dus laten we eens kijken naar interessante mechanismen zoals:

frames laten vallen ("teruggaan in de tijd")

foutopsporing op afstand (waarom op uw lokale computer blijven?)

hot code swapping (sneller dan het opnieuw implementeren van de code)

stream debugging (voor die moeilijk te debuggen streams)

De hele presentatie zal in IntelliJ zijn. Sommige delen zijn specifiek voor IntelliJ, maar de meeste delen zijn van toepassing op alle IDE's.

Improving your skills with the debugger (Bouke NIJHUIS)

Bouke Nijhuis
Bouke Nijhuis is CTO bij CINQ ICT. Hij vindt het leuk om nieuwe dingen te leren en hij vindt het nog leuker om die aan andere mensen uit te leggen. Verder is hij een internationaal spreker en een committer van open source projecten. Je kunt hem bereiken op Twitter via @BoukeNijhuis.

Op donderdag 13 april 2023 stond Bouke op Devoxx France met zijn talk 'Improving your skills with the Debugger". Hij kreeg voor deze talk maar liefst een score van 4.47 uit 5! Bekijk zijn talk hier!

Improving your skills with the debugger

Improving your skills with the Debugger - Devoxx France 2023

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Alarm should be off when the service has been initialized.

Alarm should be off when the pressure is optimal

Alarm should be activated when pressure is too low

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

Onze laatste blogs over Development

Tegenwoordig kies ik voor Flutter

The battle of the AI coding assistants

Refactor that ugly code (part 2)

Style guides zijn een must-have

Verder kijken dan de populaire Developer Experience

Wat is het MQTT protocol?

Improving your skills with the Debugger - Devoxx France 2023

Refactor that ugly code (part 1)

How to write a simple IntelliJ plugin

Spring Batch to the rescue

Onze visie op Development in 2023