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

In this blog we will state some of the changes and challenges you might face when you upgrade to Splunk 9.1. After reading this blog and checking the latest release notes you should have a better understanding of the upcoming changes when you upgrade to Splunk 9.1.

Preserve search history across search heads

A well know complaint of any Splunk user is that if the Splunk Search heads are in a cluster, they lose their search history. This is because the history of the users is stored locally per Search Head. Starting from Splunk 9.1 the search history is replicated to the other cluster nodes by using a kvstore. This was one highly upvoted Splunk Ideas item and its great to see that Splunk listened to the feedback and implemented it.

For critical Splunk environments the ability to renew the TLS certificate for outputs/server or web without having to restart splunkd is a very welcome change. This helps administrators to minimize downtime of their Splunk environment. 

Starting with Splunk 9.1 it is possible to fill the Dashboards Trusted Domains List with domains/urls that provide content for their dashboards. This will prevent warnings for your user that external content is loaded when they open the dashboard. A other helpful feature is that if you link to external website like your ticket management system you no longer have to click allow if the url is added to the Dashboards Trusted Domains List.

There are a number of improvements to the dashboard studio dashboards in Splunk. 

Export the data results of any visualization to a CSV

If a search does not provide any results you can now hide the panel when you are using a absolute layout dashboard. This is not the exact same functionality as the depends option in simple xml dashboard but this does help. 

You can now export each result to a csv, instead of opening each search and having to export the data there.

Instead of having the inputs in the top left corner it is now possible to place them closer to the panel they affect. This makes it easier for user to “get” how the dashboard is impacted by changes inputs.

After reading the description we tried to find more documentation and ask on slack what the impact of this change will have on searches. The answer from Splunk is as follows:

stats v2 is an "under-the-covers" change that we're telling customers about just as an fyi; it's not anything for you to be concerned about.

You have to specifically edit conf files to have stayed in stats v1 so realistically almost all customers are already using stats v2.

If your organization has a Splunk unlimited license you can now create a high availability cluster of license managers behind a loadbalancer. Unfortunately there is no mention of users that do not have an unlimited license, you could still build a solution yourself but Splunk does not support it out of the box.

When installing the Splunk Universal Forwarder 9.1.x on a fresh machine using the RPM/DEB installer it now creates a splunkfwd account instead of a splunk account. This could cause some problems if you added the Splunk user to certain groups that have access to log files. The new splunkfwd will not have the same rights and you will might not see all the logs that you would expect.  If you are upgrading from an older version you might want to change the default user so that you have 1 standard user across your environment. Admin’s should really check the impact/test the upgrade to make sure you do not run into any issues when upgrading your production environment.  

https://docs.splunk.com/Documentation/Splunk/latest/ReleaseNotes

https://docs.splunk.com/Documentation/Splunk/latest/DashStudio/WhatNew

In this blog we will state some of the changes and challenges you might face when you upgrade to Splunk 9.1. After reading this blog and checking the latest release notes you should have a better understanding of the upcoming changes when you upgrade to Splunk 9.1

Read this before upgrading to Splunk 9.1

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

Lately, a lot of people have been asking me about how to deploy web apps using Docker, Inc for their hobby projects. So to help people I threw this quick tutorial about how to deploy an R Shiny web app on Render using their free tier. 


In this tutorial, we are creating a simple R Shiny web app, running it locally, hosting it locally via Docker (desktop), and deploying via Docker and render.com. Sounds fun, right? Let's have a look! 

Deploying R Shiny App via Render Tutorial

Clone this repo
git clone git@github.com:jameshtwose/rshiny-docker-render.git

Open the app in your browser
http://localhost:5000

Build the Docker image
docker build -t rshiny-docker-render .

Run the Docker image
docker run -d -p 5000:5000 rshiny-docker-render

The GitHub repo can be found here: https://github.com/jameshtwose/rshiny-docker-render
And the live demo can be found here: https://rshiny-docker-render.onrender.com/ 

This video tuturial shows you how to deploy an R Shiny webapp, using Docker on Render's free tier.

How to deploy a webapp with Docker on Render

How to deploy an R Shiny webapp with Docker on Render

Our clients are often asking us what is the best technology stack/ architecture to use for their businesses. So today one of our Data Engineers, James Twose, will take us through a comparison of a paid technology stack and an open source technology stack to create, deploy and maintain an MLOps solution. Specifically, a web application that attempts to predict the amount of time the trains in the Netherlands will be disrupted (in minutes) based on the weather conditions on the day (temperature, rain amount).

The following is a presentation of the technology stack comparisons, their learning curves, their pro’s and con’s, and their corresponding prices:

Paid vs open source MLops solution: Introduction

As mentioned in the previous video, here is the setup and demo of the open source, Kubernetes, version of the project:

Paid vs open source MLops solution: Open source version with Kubernetes

And finally, the paid, Databricks, version of the MLOps solution:

Paid vs open source MLops solution: Paid version with Databricks

We hope you found this post enlightening and that what you learned helps you to make decisions for your company, and provided some insights into the process of using these different approaches.  

The GitHub repository for this project, including the presentation, can be found here - https://github.com/cinqict/paid-vs-opensource.

Our clients are often asking us what is the best technology stack/ architecture to use for their businesses. In this video tutorial one of our Data Engineers, James Twose, will take us through a comparison of a paid technology stack and an open source technology stack to create, deploy and maintain an MLOps solution

Paid vs open-source MLops solution

Comparing a paid vs open-source MLops solution

Een van de uitdagingen bij het gebruik van cloudservices is het beheersen van de kosten. Traditioneel betalen bedrijven op basis van het gebruik van resources, wat kan leiden tot onvoorspelbare kosten en mogelijk onaangename verrassingen aan het einde van de maand. Hier komen CUD's in beeld.

CUD's (Committed Use Discounts) zijn een manier om vooraf gereserveerde bronnen in GCP te kopen tegen een aanzienlijk lagere prijs dan de standaard on-demand tarieven. Door een commitment te doen voor een periode van één of drie jaar, ontvang je aanzienlijke kortingen op de kosten van virtuele machines (VM's) en andere services. Dit kan aanzienlijke besparingen opleveren, vooral voor workloads met een voorspelbaar en stabiel gebruik.

Als je meer wilt weten over CUD's en hoe je ze kunt gebruiken in GCP, raad ik je aan de officiële documentatie van GCP over CUD's te raadplegen.

Voorbeeldberekening van kostenbesparingen

Laten we nu eens een voorbeeld bekijken om de potentiële besparingen met CUD's beter te begrijpen. Stel dat jouw bedrijf een applicatie heeft met een constante vraag naar computervermogen. Zonder CUD's zou je betalen op basis van het gebruik van on-demand VM's. Laten we zeggen dat je gemiddeld 10 VM's per maand gebruikt, elk met een maandelijkse kostprijs van €100.

Gemiddeld maandelijkse kosten = 10 VM's * €100/VM = €1000

Met CUD's zou je een toezegging doen voor 1 jaar voor 10 VM's tegen een prijs van €70/VM. Laten we zeggen dat je 30% korting krijgt met CUD's.

Jaarlijkse kosten = 10 VM's * €70/VM * 12 maanden = €8400

Gemiddeld maandelijkse kosten = €8400 / 12 maanden = €700

In dit voorbeeld zou het gebruik van CUD's een besparing van €300 per maand opleveren.

Naast de directe kostenbesparingen bieden CUD's nog andere voordelen. Ten eerste bieden ze stabiliteit en voorspelbaarheid van kosten, omdat je vooraf een toezegging doet voor een bepaalde periode. Dit helpt bij het budgetteren en plannen van IT-uitgaven. Bovendien kunnen CUD's flexibiliteit bieden bij het schalen van resources, omdat je de toegewezen CUD's op verschillende VM's binnen dezelfde regio kunt toepassen, waardoor je kunt profiteren van de kortingen zonder dat je vastzit aan een specifieke VM-configuratie.

Eenvoudig gebruik en beheer van CUD's in GCP

Het gebruik van CUD's in GCP is eenvoudig en intuïtief. Je kunt ze via de GCP-console of de API aanschaffen en beheren. Het platform biedt ook tools en rapporten om je te helpen bij het monitoren van je CUD-gebruik en de kostenbesparingen te volgen.

Als je gedetailleerde instructies en voorbeelden wilt over hoe je CUD's kunt aanschaffen en beheren in GCP, raad ik je aan om de GCP-documentatie over CUD's te raadplegen.

Als je op zoek bent naar manieren om kosten te besparen en de efficiëntie van je cloudinfrastructuur te verbeteren, raad ik je zeker aan om CUD's in GCP te overwegen. Het kan een waardevol instrument zijn om de cloudkosten te beheersen en tegelijkertijd een betere cloudervaring te bieden.

Probeer het zelf en ontdek welke voordelen CUD's in GCP voor jouw organisatie kunnen opleveren!

Een van de uitdagingen bij het gebruik van cloudservices is het beheersen van de kosten. Traditioneel betalen bedrijven op basis van het gebruik van resources, wat kan leiden tot onvoorspelbare kosten en mogelijk onaangename verrassingen aan het einde van de maand. In dit blog lees je hoe je dit in Google Cloud Platform kunt beheersen en beperken.

CUD's in GCP: Kostenbesparing en een betere cloudervaring

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. 

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

Refactor that ugly code (part 2)

Style guides zijn een must-have

Read this before upgrading to Splunk 9.1

Verder kijken dan de populaire Developer Experience

How to deploy an R Shiny webapp with Docker on Render

Comparing a paid vs open-source MLops solution

CUD's in GCP: Kostenbesparing en een betere cloudervaring

Wat is het MQTT protocol?

Mis geen enkele CINQ meetup

Improving your skills with the Debugger - Devoxx France 2023

Meetup: Docker & Kubernetes workshop