About a year ago I wrote a blog with the title ‘How to write a simple IntelliJ plugin’. In the previous blog I explained why I wrote the plugin and which steps I had to take. Furthermore you will also read that I set out to create a proper plugin. That is a plugin that can easily be installed by downloading it from the Jetbrains Marketplace. This turned out to be much harder than I expected, so that is why I settled for a live plugin last year. The blog ends with the suggestion that I will write a proper plugin in the future and will blog about it. Well the future is now, as this blog will be about creating this proper plugin. 

The main reason to pick up this pet project again is the fact that I will be giving my talk ‘Improving your skills with the debugger’ at JavaLand. The old plugin is part of this talk, but I always try to update my talk with the latest and greatest. So I decided it was time to finally create a proper plugin. 

The difference between the previous and the current title is exactly two words. The word ‘write’ became ‘create’ and ‘simple’ became ‘proper’. I talked enough about the second difference, so let’s explain the first. The meat of the previous blog was how to write (or code) a plugin. This blog will focus more on how to get this plugin in the JetBrains marketplace. So it also covers the process after writing the plugin. 

In the previous blog I wrote that I tried to create a proper plugin, so my first step was to open this old project and to make sure that everything still functioned. The previous project was around a year old and to my surprise I could not get it working again. Software decay/rot is real! I spent a few hours before I decided to throw the towel. I solved this issue by starting with a clean slate. Jetbrains provides a template plugin repository (link) that you can fork. So I did this and added my code from the previous project. The code compiled again, so the problem was solved!

The first thing I noticed when using the provided template was the feature that one can start a completely new instance of IntelliJ with your plugin pre-installed (see Image 1). This was something I did not notice the previous time I tried to create a plugin. A very useful feature which lets you properly manually test your plugin before you upload it to the marketplace. 

Image 1 - Run Plugin starts a new instance of the IDE with your plugin pre-installed.

The observant reader noticed the word ‘manually’ in the previous sentence. This is a fine start, but in the end we need automated tests as well. It turns out that it is pretty hard. The documentation gives a few examples, but I still spent hours and hours before I got a green unit test. In those hours I had to figure out why a part of my test context was not initialized properly. I spent a lot of time in the source code of IntelliJ to find clues. In the end it turned out to be a dependency problem. I had to specify that my plugin was dependent on the Java features of IntelliJ. For people with the same problem Image 2 shows where to add dependencies. After addressing this omission, things went pretty smooth and I had a lovely green unit test in the end.

Image 2 - This is where one adds dependencies.

With this test in place, I could finally do some refactorings and remove some unnecessary boilerplate from the template plugin project. Furthermore I found a bug while manually testing the plugin. So I updated the test (and fixed the bug) to prevent this ever happening again. As far as I was concerned the plugin was ready to share with the world.

The first step in publishing the plugin is signing it with a private key. The Jetbrains marketplace will use the public key to see if everything is in order. You only have to create a private-public key pair and the template takes care of the heavy lifting after you add a few environment variables. This is a pretty standard procedure for app (or plugin) stores. 

The next step is uploading the plugin to the marketplace. Again a straightforward process. You can choose between a manual upload or an upload via the Gradle scripts in the template. In the former case you can upload your .jar file in your browser. In the latter case you first need to generate a token in your Jetbrains account. The next step is to add this token as an environment variable. You can run the Gradle scripts locally or you can use the included GitHub Actions pipeline. 

The last step is the most difficult one. You have to wait till the people of the Jetbrains Marketplace approve your plugin. This process takes up to two business days. Luckily I had something to do in the meantime, because the dependabot found a lot of dependencies to upgrade. In case you do not know what dependabot is: it is a GitHub bot that creates pull requests in your project whenever it finds a newer version of a dependency.

I am really excited to have my first plugin published on the Jetbrains Marketplace! I learned a lot in the process of creating, testing and publishing the plugin. Normally I use Maven as my go-to buildtool. So it was a nice change to be forced to use Gradle. Secondly, I have never used GitHub Actions before and it is nice to see it in action (pun intended). Thirdly, I had a reason to browse the IntelliJ codebase, which was interesting. Finally, it gave me an excuse to write a new blogpost. 

The plugin can be found here:
https://plugins.jetbrains.com/plugin/23796-log-selection-with-breakpoint

Please visit it, as I've put in extra effort to create an animated gif to demonstrate what the plugin does.
The source code can be found here:
https://github.com/BoukeNijhuis/breakpoint-log-selection

So, there is only one question left to answer: how will I continue this blog series? Good question! My intention is to add a feature to the plugin that enables you to change the hard-coded log expression. However, to do so, I need a UI where you can edit the current expression. So, that sounds like a lot of work. Till next year!

Image 3 The plugin can be found on the IntelliJ marketplace

In this blog Bouke Nijhuis explains how he created a proper plugin for IntelliJ and how he published it on the IntelliJ Marketplace.

How to create a proper IntelliJ plugin

De CTO's van onze drie units - Data, DevOps en Development - vormen samen met de CTO van CINQ een denktank: de CINQTank. Zij houden zich bezig met het “voorspellen” van de toekomst. Samen met de mensen uit de units kijken zij in de verschillende vakgebieden naar de ontwikkeling van technieken en tools. Hiermee wordt een technische visie gecreëerd. Deze wordt onder andere gebruikt om richting te geven aan de opleiding van medewerkers. Tevens wordt het gebruikt als input voor de jaarplannen van elke afdeling. Tot slot is het natuurlijk ook gewoon leuk om na te denken hoe de toekomst eruit zou kunnen zien. Hieronder lees je onze verwachtingen op het gebied van Development in 2024.

Als we terugblikken op de verwachtingen van het afgelopen jaar, voorspelden we een toenemende vraag vanuit de markt naar gespecialiseerde ontwikkelaars die bereid zijn buiten hun gebruikelijke rol te treden. Deze ontwikkeling heeft zich gedurende het afgelopen jaar voortgezet.

Kort gezegd zijn onze klanten op zoek naar ontwikkelaars die goed zijn in het ontwikkelen binnen hun specialisme (bijvoorbeeld backend Java), maar niet terughoudend zijn om andere ontwikkelwerkzaamheden (bijvoorbeeld frontend Javascript) op te pakken. Er wordt van ze verwacht dat ze buiten hun eigen vakgebied kunnen acteren en ook verantwoordelijk zijn voor het ontwerpen, testen, beveiligen en beheren van hun software samen met de specialisten op deze onderwerpen.

Als we de cloud providers analyseren die actief zijn in ons marktsegment, valt op dat Microsoft Azure veruit het grootste marktaandeel heeft. Dit is een opvallende trend, aangezien er een wereldwijde voorkeur voor AWS is. Bij het trachten te verklaren van deze trend in Nederland, kom je uit op een historisch sterke vertegenwoordiging van Microsoft Nederland en de aanwezigheid van ervaren Nederlands personeel met betrekking tot Microsoft Azure.

Bovendien markeerde het afgelopen jaar als het 'Jaar van Artificial Intelligence', met als primaire katalysator de vrijgave van ChatGPT aan het grote publiek. Hierdoor kwam iedereen ermee in aanraking, wat resulteerde in een situatie waarin eenieder er gelijktijdig gebruik van kon maken. Deze dynamiek verschilt aanzienlijk van de gebruikelijke manier waarop baanbrekende technologie de markt betreedt. Normaliter is het aanvankelijk te kostbaar voor de gemiddelde persoon en komt het eerst ten goede aan grote ondernemingen die er royaal voor betalen, alvorens het zich verspreidt naar de open source-gemeenschap.

Door deze nieuwe manier van technologie op de markt brengen, constateren we dat veel bedrijven nog niet volledig zijn voorbereid op de implementatie van AI. We zien dat technologiebedrijven intensief bezig zijn met het verdedigen of vergroten van hun marktpositie door AI toe te voegen aan hun portfolio.

Tegelijkertijd merkten we op dat bedrijven die software ontwikkelen nog niet volledig gereed waren om AI in de praktijk te ondersteunen voor hun medewerkers. Veel grote ondernemingen waren hierdoor zelfs genoodzaakt AI in de ban te doen,  uit vrees voor datalekken, ongeoorloofd gebruik en andere risico's.

Ten slotte, als engineer, was het mooi om te zien dat gedurende het hele jaar wekelijks nieuwe ideeën en toepassingen op het gebied van generatieve AI opdoken. Zelfs aan het einde van het jaar lijkt deze trend niet af te nemen. Dit maakte het jaar buitengewoon interessant.

De opkomst van open toegankelijke Large Language Models heeft ertoe geleid dat we een herdefinitie hebben gekregen van AI. Waar we vorig jaar nog intensief debatteerden over de kwestie "het is machine learning, geen AI", lijkt iedereen zich er nu langzaam bij te hebben neergelegd dat AI de overkoepelende term is geworden waaronder we alles scharen.

Ook het komende jaar zal in het teken staan van AI. Terwijl de technologiereuzen Microsoft, Google en Amazon zich blijven concentreren op het aanbieden van Large Language Models, heeft de rest van de AI-markt een aanzienlijke toename van aandacht en innovatie ervaren. Ook het komende jaar belooft daarom een voortdurende stroom van nieuwe tools en ideeën met betrekking tot het gebruik van AI.

Ook op andere technologie segmenten zijn bedrijven druk bezig hun producten aan te passen aan de komst van AI. Het meest sprekende voorbeeld voor ontwikkelaars zijn de code assistenten die voor veel ontwikkelaars een tool zullen worden / blijven voor dagelijks gebruik ter ondersteuning van hun werk.

Steeds meer bedrijven hebben al AI-richtlijnen vastgesteld of zijn bezig met het formaliseren van het gebruik van AI. We zien hierbij een duidelijke trend waarbij veelal wordt gekozen voor het hosten van Large Language Models binnen de eigen private cloud. Hierdoor zullen veel ontwikkelaars het komende jaar de mogelijkheid krijgen om ook code assistenten te gebruiken in het kader van hun opdrachten.

Wat betreft de backend constateren we dat de JVM-talen nog steeds de dominante meerderheid vertegenwoordigen in ons marktsegment, waarbij Java nog steeds de grootste speler is. Echter, steeds meer klanten maken ook gebruik van Kotlin. De verwachting is dat beide talen in de komende jaren steeds meer gezamenlijk zullen worden ingezet, waarbij Kotlin een steeds prominentere rol zal gaan vervullen.

Als we naar backend frameworks kijken, blijft Spring (Boot) nog steeds de grootste speler in ons marktsegment. Desalniettemin groeit de interesse voor alternatieven zoals Quarkus en Micronaut. Op dit moment wordt echter vaak nog niet heel concreet gevraagd naar werkervaring met deze laatste twee frameworks en is ervaring met Java/Spring voldoende. Mocht de populariteit van Quarkus en Micronaut echter snel toenemen, dan zal bij het werven van ontwikkelaars ook een grotere voorkeur ontstaan voor specifieke ervaring met deze frameworks.

Het javascript ecosysteem blijft één van de meest veranderlijke omgevingen in de IT met constante ontwikkelingen op gebied van runtimes, libraries, build tools en zeer actieve ontwikkelingen van Typescript met de komst van versie 5 in het afgelopen jaar. Deze trend zal doorzetten en onze frontend ontwikkelaars zijn hier aan gewend en dusdanig intrinsiek gemotiveerd dat ze makkelijk met deze ontwikkelingen mee gaan.

Echter is er ook een stabiele factor op het gebied van frontend. Wat betreft frameworks blijven React en Angular dominant. In ons marktsegment constateren we een groeiende vraag naar React ten opzichte van Angular.

Over het algemeen blijft het voor onze ontwikkelaars raadzaam om technische kennis in tweevoud te verwerven en te experimenteren met nieuwe technieken. Denk hierbij aan bijvoorbeeld twee verschillende frontend frameworks, twee verschillende programmeertalen of twee verschillende cloud omgevingen. Dit is raadzaam omdat het beheersen van kennis in tweevoud, een bredere kennis ondersteunt en meer inzichten met zich meebrengt. Bovendien maakt de eerder verkregen kennis het leren van een derde onderwerp in dezelfde categorie sneller en gemakkelijker. 

Als we specifiek kijken naar development, is er op dit moment geen onderwerp of technologie die duidelijk zal verdwijnen in het komende jaar. Het lijkt erop dat de focus voornamelijk zal liggen op het verfijnen en optimaliseren van bestaande toepassingen. Kosten en duurzaamheid zijn hier voornamelijk de drijfveer.

De meeste bedrijven hebben hun cloudtransities voltooid of zijn hierin vergevorderd, waarbij veel applicaties nu cloud native zijn. Desondanks overwegen enkele bedrijven in specifieke gevallen delen van hun IT-infrastructuur terug te halen uit de cloud of te migreren naar hybride situaties. Vaak wordt deze overweging ingegeven door minder positieve ervaringen met cloud providers of wordt het gedreven door kostenoverwegingen. 

De verwachting is dat deze discussie de komende jaren steeds prominenter zal worden en dat de strategie van "alles in de cloud" verschuift naar "in de cloud, tenzij."

Als we de backend-architectuur onder de loep nemen, is de verwachting dat er een spanningsveld zal ontstaan tussen micro-architecturen en monolieten. Gedurende vele jaren werden monolieten als ongunstig beschouwd. Ze moesten worden vernieuwd en werden als ongeschikt gezien voor de cloudtransformatie.

Echter, dankzij katalysatoren zoals Java-modules, Spring Modulith, en soms negatieve ervaringen met de complexiteit van een microservices-architectuur, wordt verwacht dat de vertrouwde monoliet in sommige bedrijven en situaties een nieuw leven zal krijgen.

Microservices-architecturen zullen gedurende vele jaren een prominente rol blijven spelen en zijn uitermate geschikt om schaalbare, cloud-native, gedecentraliseerde, en herbruikbare architecturen op te zetten. De complexiteit van deze systemen ligt in de onderlinge interactie.

De verwachting is dat er een niche zal ontstaan waar bedrijven met kleine softwareteams ervoor kiezen om de complexiteit van onderlinge systemen weer in de applicatie zelf te integreren. Dit doen ze door applicaties op te splitsen met behulp van modules in plaats van microservices, waardoor dezelfde ontkoppeling en herbruikbaarheid gefaciliteerd kan worden.

In de wereld van Artificial Intelligence bevinden we ons in een periode waar alle tech giganten op meerdere fronten strijden om de overhand op de markt. Op het gebied van zoekmachines, AI assistenten en cloudproviders concurreren voornamelijk dezelfde bedrijven om marktaandeel, met name Microsoft, Amazon en Google.

Businesspartners voor het hosten van Large Language Models (LLM) en andere generatieve AI-toepassingen.

Direct in het ecosysteem van ontwikkelaars door middel van code-assistenten.

In het consumentensegment door de potentiële verschuiving van zoekmachines naar AI assistenten, met als onderliggende reden advertentie-inkomsten.

Wat opvalt, is dat Microsoft op al deze fronten zeer prominent aanwezig is:

Door investeringen in OpenAI heeft Microsoft toegang tot de grootste en beste LLM's ter wereld.

Hierdoor kon Microsoft LLM snel implementeren als assistent voor hun Bing-zoekmachine.

In het enterprise-segment is Microsoft, vanwege zijn positie op de Azure-markt, een aangewezen partner om LLM en andere generatieve AI-toepassingen in private clouds aan te bieden.

Met GitHub Copilot positioneert Microsoft zich ook in het IDE-segment met betrekking tot AI.

Microsoft lijkt daarmee op meerdere fronten direct marktaandeel te willen veroveren, zowel op het gebied van zoekmachines ten opzichte van Google als in directe concurrentie met AWS door middel van AI cloudservices en code assistenten. Of dit zal resulteren in een situatie waar mensen eindelijk Bing gaan gebruiken, valt nog te bezien. 

AI heeft de potentie om de markt volledig te ontwrichten en op dit moment zijn de meningen over de mate hiervan nog sterk verdeeld. Binnen CINQ zien we veel dynamiek rondom dit onderwerp en een actieve discussie over de toekomstige rol van AI binnen onze markt. 

Het lijkt onvermijdelijk dat er verschuivingen zullen plaatsvinden, hoewel de mate van deze verschuivingen nog moeilijk te voorspellen is. Het is nog niet duidelijk of de AI samen met ons of in plaats van ons gaat programmeren. In het meest extreme geval zal de ontwikkelaar van vandaag een sturende en controlerende rol krijgen.

Als we specifiek kijken naar wat er zal verdwijnen, zullen AI tools delen van ons werk overnemen. De mate hiervan is echter nog moeilijk te voorspellen, omdat het afhangt van te veel factoren.

Hier bepalen we de potentie van technieken ten opzichte van de inspanning die het kost om ze eigen te maken.

Inspanning: Bij inspanning gaat het om de inspanning voor onze developers om kennis en kunde op te doen van een onderwerp. Hierbij telt mee dat als onze developers bij een klant al veel met soortgelijke technieken in contact komen, dat de inspanning over het algemeen lager zal liggen. Bijvoorbeeld de inspanning voor CINQ om nieuwe Cloud technieken op te pakken is laag, omdat de meeste developers al veel basis kennis hebben opgedaan bij verschillende klanten.

Potentieel: Bij potentieel gaat het niet alleen om het potentieel van de techniek in de hele markt, maar ook om impact op CINQ en zijn klanten. Voorbeeld: Quantum Computing heeft het potentieel de hele IT markt te veranderen. Echter voor de diensten die wij leveren is het aannemelijk dat Quantum Programming voorlopig nog niet aan de orde is. Hierdoor is de potentie laag. 

Voor CINQ is het goed als de units elkaar beter kunnen vinden en hierdoor elkaar makkelijker kunnen ondersteunen.

Dit willen we bereiken door meer kruisbestuiving te bewerkstelligen tussen de units. Dit doen we door expertise met elkaar te delen en door gezamenlijk projecten te gaan doen. 

Vanuit zowel de DevOps als de Data unit is er behoefte aan meer programmeer expertise. Hierbij kan de Development unit goed ondersteunen. 

Omdat er steeds meer verantwoordelijkheid komt te liggen bij ontwikkelaars, is de kennis die de Data unit heeft van monitoring en observability zeer waardevol voor onze ontwikkelaars. Daarnaast kunnen we van deze expertise gebruikmaken om productieproblemen beter te analyseren en meer controle te hebben over ons productielandschap.

In dit artikel lees je wat onze verwachtingen zijn op het gebied van Development in 2024. We beschrijven trends in de markt en ontwikkelingen binnen de CINQ Development unit.

Onze visie op Development in 2024

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. 

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.

Onze laatste blogs over Development

How to create a proper IntelliJ plugin

Onze visie op Development in 2024

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