Voor Pondres in Tilburg - een bedrijf dat gespecialiseerd is in communicatie en fulfilment - hebben wij een review gedaan op de architectuur van een nieuw te bouwen containerplatform met Docker. 

Voor Pondres in Tilburg hebben wij een review gedaan op de architectuur van een nieuw te bouwen containerplatform met Docker.

Docker architectuur review bij Pondres

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

Vakmensen, dat zijn we. En wat we doen op het gebied van informatie- en communicatietechnologie helpt organisaties slim verder. Effectief en meetbaar bovendien. Aangenaam, CINQ. Specialisten in Data, DevOps en Development. Wij geloven in specialisten, vandaar de driedeling Data, DevOps en Development binnen ons bedrijf. Zo zorgen we dat jij excelleert, want je werkt het best waar je je het meest thuis voelt. Logisch, toch?

cinq_logo.png

cinq_logo_square.png

CINQ ICT

Als front-end developer breng jij beeldbepalende organisaties in het Nederlandse bedrijvenlandschap naar een hoger niveau. Daar ben jij de aangewezen front-end developer voor, die zichzelf continu verder ontwikkelt. 

Ooit gedacht om te werken voor een IT-consultancybureau? Niet? CINQ again, zeggen we dan. Want of je nu veel afwisseling in projecten wilt, of juist langer aan een organisatie verbonden wilt zijn: beide opties zijn mogelijk. Je werkt als front-end developer voor aansprekende klanten die jouw kennis en inzichten nodig hebben. Ondertussen zijn er je CINQ-collega’s met wie je kennis deelt, functionaliteiten bestudeert en nieuwe technieken onderzoekt. Zo kun jij klanten verrassen en van de vrijheid als front-end developer genieten. Een baan uit duizenden, waar je bijvoorbeeld: 

grote of kleine projecten draait, afhankelijk van wat jij wilt.

spreekt op congressen, vakinhoudelijke blogs schrijft en workshops verzorgt.

werkt voor klanten als grote banken, de Politie of luchthaven Schiphol.

Sinds 2013 zetten we onze consultants in op hoogwaardige IT-projecten door heel Nederland. Met de kennis die onze specialisten in huis hebben, adviseren we teams en zetten we koers naar innovatie. Nieuwe tooling helpt ons om klanten keer op keer te verrassen. Tussen alle IT-consultancybureaus vallen we misschien niet direct op in wat we doen. Maar wél in hoe we het doen. Daarmee hebben we naam en faam gemaakt in verschillende sectoren en daar gaan we het liefst nog even mee door.

CINQ is opgesplitst in 3 business units met elk een eigen expertise. Niet dat we ervan houden om in hokjes te denken, maar dit werkt in de praktijk nu eenmaal het beste. Ook voor onze klanten die een beroep doen op jou als front-end developer. Onze developers zitten in heel Nederland. We draaien onze hand niet om voor grote projecten met de nodige complexiteiten. Sterker nog, die doen we misschien wel het liefst. Toch zijn we ook te porren voor kleinere opdrachten, zolang we klanten ermee kunnen helpen. En dat doen we het liefst, terwijl jij nieuwe kennis opdoet en verder groeit als specialist in je vakgebied.

Zo goed als we bij CINQ voor onze klanten zijn, zo goed willen we ook voor jou zijn. Daarom krijg je direct een vast contract voor 36 of 40 uur per week. Bij deze vacature horen de volgende arbeidsvoorwaarden: 

een brutomaandsalaris tussen € 4.000 en € 5.500, afhankelijk van je kennis en ervaring.

8% vakantiegeld en 24 vakantiedagen op basis van een fulltime dienstverband.

een telefoonvergoeding en een laptop naar keuze.

€ 1.000 budget om je thuiswerkplek goed in te richten

een auto van de zaak óf mobiliteitsbudget met een kilometervergoeding.

leuke uitjes, waaronder stedentrips en skiweekenden.

ieder jaar een toffe gadget als eindejaarsgeschenk. Bijvoorbeeld een Sonos One, Beats koptelefoon, Playstation 4 of Google Nest.

bezoek conferenties zoals CSS Day, Fronteers of VueJS Amsterdam

Gedreven, analytisch en voldoende doorzettingsvermogen om succes te boeken. Jij bent als front-end developer niet voor 1 gat te vangen, want voor complexe uitdagingen vind je de beste oplossingen. In deze rol heb je veel contact met de klant en daarom is goed communiceren uiterst belangrijk. Daar mag humor niet in ontbreken. Als er nieuwe ontwikkelingen of tools voorbijkomen, ben jij er als eerste bij om ze te onderzoeken. Het liefst ga je er meteen mee aan de slag. Als front-end developer heb jij:

ongekende front-end coding skills. Die heb je je bijvoorbeeld eigen gemaakt in een rol als software engineer of ontwikkelaar.

ervaring met relevante front-end frameworks, zoals Angular of React.

bedreven in het schrijven van unit testen.

goed oog voor design en vaardig met implementaties van Design Systems, via bijvoorbeeld StencilJS.

ervaring met Agile softwareontwikkeling in een DevOps-omgeving.

En, hoe lijkt het? Ben jij de nieuwe front-end developer die onze klanten verder helpt? Solliciteer dan meteen via de sollicitatiebutton. Doe het wel voor [sluitingsdatum], want daarna sluiten we de vacature.

Wil je de details van deze vacature tot achter de komma? Neem dan contact op met Marc Jacobs via marc@cinqict.nl of 06 – 51 08 74 37.

Als front-end developer kan jij werken met de nieuwste technieken voor toffe klanten zoals grote banken, de Politie of luchthaven Schiphol. Haak je aan bij CINQ?

Front-end developer

Als front-end developer kan jij werken met de nieuwste technieken voor toffe klanten zoals grote banken, de Politie of luchthaven Schiphol.

36 - 40 uur per week

Helemaal thuis in de wereld van back-end development? Als specialist breng jij beeldbepalende organisaties in het Nederlandse bedrijvenlandschap naar een hoger niveau. Daar ben jij de aangewezen software engineer voor die zichzelf continu verder ontwikkelt. 

Ooit gedacht om te werken voor een IT-consultancybureau? Niet? CINQ again, zeggen we dan. Want of je nu veel afwisseling in projecten wilt, of juist langer aan een organisatie verbonden wilt zijn: beide opties zijn mogelijk. Je werkt als software engineer voor aansprekende klanten die jouw kennis en inzichten nodig hebben. Ondertussen zijn er je CINQ-collega’s met wie je kennis deelt, functionaliteiten bestudeert en nieuwe technieken onderzoekt. Zo kun jij klanten verrassen en van de vrijheid als software engineer genieten. Een baan uit duizenden, waar je bijvoorbeeld: 

CINQ is opgesplitst in 3 business units met elk een eigen expertise. Niet dat we ervan houden om in hokjes te denken, maar dit werkt in de praktijk nu eenmaal het beste. Ook voor onze klanten die een beroep doen op jou als back-end developer. Onze developers zitten in heel Nederland. We draaien onze hand niet om voor grote projecten met de nodige complexiteiten. Sterker nog, die doen we misschien wel het liefst. Toch zijn we ook te porren voor kleinere opdrachten, zolang we klanten ermee kunnen helpen. En dat doen we het liefst, terwijl jij nieuwe kennis opdoet en verder groeit.

bezoek conferenties zoals JavaOne, Devoxx en JFall.

Gedreven, analytisch en voldoende doorzettingsvermogen om succes te boeken. Jij bent als software engineer niet voor 1 gat te vangen, want voor complexe uitdagingen vind je de beste oplossingen. In deze rol heb je veel contact met de klant en daarom is goed communiceren uiterst belangrijk. Daar mag humor niet in ontbreken. Als er nieuwe ontwikkelingen of tools voorbijkomen, ben jij er als eerste bij om ze te onderzoeken. Het liefst ga je er meteen mee aan de slag. Als software engineer heb jij:

ongekende coding skills. Die heb je je bijvoorbeeld eigen gemaakt in een rol als software developer of Java ontwikkelaar.

ervaring met relevante back-end frameworks zoals Spring Boot

En, hoe lijkt het? Ben jij de nieuwe software engineer die onze klanten verder helpt? Solliciteer dan meteen via de sollicitatiebutton. Doe het wel voor [sluitingsdatum], want daarna sluiten we de vacature.

Helemaal thuis in back-end development? Als specialist breng jij beeldbepalende organisaties in het Nederlandse bedrijvenlandschap naar een hoger niveau.

Back-end developer

Helemaal thuis in de wereld van Java of Kotlin? Als specialist breng jij beeldbepalende organisaties in het Nederlandse bedrijvenlandschap naar een hoger niveau.

Jij vindt het leuk om aan complexe data-vraagstukken te werken. Je bent de spin in het web als het gaat om data extracten, transformeren en klaarzetten voor verder gebruik binnen organisaties, rekening houdend met de performance van de data-verwerking middels jobs die jij zelf configureert en beheert. Daarnaast zit je boordevol ideeën hoe de omgeving te verbeteren, waarbij je steeds de klant centraal plaatst. Het leren van nieuwe technieken is de reden waarom je dit werk hebt gekozen: nooit saai, en volop mogelijkheden.

CINQ is opgesplitst in 3 business units met ieder een eigen expertise. Niet dat we ervan houden om in hokjes te denken, maar dit werkt in de praktijk nu eenmaal het beste. Ook voor onze klanten die een beroep doen op data engineers. Bij een klant meedraaien in een team tot aan het uit de grond stampen van een splinternieuwe dataomgeving: als dataspecialist komt er van alles op je bord. En je collega’s van CINQ tref je bij een gezamenlijke data-kantoordag, kennissessie of memorabel uitje. 

Zo goed als we bij CINQ voor onze klanten zijn, zo goed willen we ook voor jou zijn. Daarom krijg je een direct een vast contract voor 36 of 40 uur per week. Bij deze vacature horen de volgende arbeidsvoorwaarden:

een bruto maandsalaris tussen € 3.000 en € 5.500, afhankelijk van je kennis en ervaring.

8% vakantiegeld en 24 vakantiedagen op basis van een fulltime dienstverband

eenmalig € 1.000 budget om je thuiswerkplek goed in te richten

leuke events, zoals game-nights, een groot feest met hotelovernachting & het jaarlijkse skiweekend in Oostenrijk

ieder jaar een toffe gadget als eindejaarsgeschenk. Een greep uit het verleden: een Sonos One, Beats koptelefoon, Google Nest of elektrische step.

De ideale kandidaat bestaat misschien niet. Toch zoeken we iemand die er dichtbij in de buurt komt. Want als data engineer ben je je ervan bewust dat jouw rol altijd in ontwikkeling is. Daarom doe je graag nieuwe kennis op en ben je creatief in het bedenken van oplossingen om klanten te verbluffen. Je bent nieuwsgierig, hebt een sterke klantfocus en kan zelfstandig uit de voeten. Dit breng je mee: 

Je kunt zelfstandig een data-omgeving ontwerpen, bouwen, en in gebruik nemen in een Cloud-omgeving (Azure, AWS, of GCP);

Je hebt ruime ervaring met de ETL methode en weet nieuwe data op een efficiënte manier te verwerken tot bruikbare datasets;

Certificeringen zijn geen eis, wel een pré;

Python (en data-libraries zoals Pandas, Numpy, PySpark, Matploblib) lezen en schrijven is geen probleem voor je;

Je hebt de ambitie om de data-engineering tak van de CINQ data-unit mee vorm te geven en verder uit te breiden;

Kennis van DevOps, CI/CD tooling, Docker, Kubernetes, en ook Databricks leveren bonuspunten op.

En, hoe lijkt het? Ben jij de nieuwe data engineer die onze klanten verder helpt? Solliciteer dan meteen via de sollicitatiebutton. Doe het wel voor [sluitingsdatum], want daarna sluiten we de vacature.

Wil je de details van deze vacature tot achter de komma? Neem dan contact op met Marc Jacobs via marc@cinqict.nl of 06-51087437.

Vacature: data engineer bij CINQ ICT in Amsterdam. Bij CINQ staat jouw ontwikkeling centraal!

Data engineer

Door efficiënt datagebruik help jij onze klanten vooruit. In jouw volgende opdracht krijg je volop de ruimte voor eigen inbreng.

Door efficiënt datagebruik help jij onze klanten vooruit. Banken, overheidsinstanties, onderwijsinstellingen: in jouw volgende opdracht krijg je volop de ruimte voor eigen inbreng.

De charme van een IT-consultancybureau als CINQ is dat jij als data engineer over de vloer komt bij meerdere klanten. Soms voor een langdurig project, soms voor een kortere opdracht. Jij helpt ze data te benutten en krijgt de vrijheid om dat te doen op basis van je eigen inzichten. Jij ziet Splunk als de hamer in een gereedschapskist; een onmisbare tool om je werk mee uit te voeren. Meer waarde uit data halen is jouw doel, via proof of concepts verbetertrajecten en implementaties van Splunk-omgevingen. Hierin houd jij je bezig met het:

onderhouden en beheren van een Splunk-omgeving voor een optimale performance.

komen met verbetervoorstellen richting de klant.

CINQ is opgesplitst in 3 business units met ieder een eigen expertise. Niet dat we ervan houden om in hokjes te denken, maar dit werkt in de praktijk nu eenmaal het beste. Ook voor onze klanten die een beroep doen op data engineers. Bij een klant meedraaien in een Splunk-team tot aan het uit de grond stampen van een splinternieuwe dataomgeving: als dataspecialist komt er van alles op je bord. En je collega’s van CINQ tref je bij een gezamenlijke data-kantoordag, kennissessie of memorabel uitje. 

een brutomaandsalaris tussen € 3.000 en € 5.000, afhankelijk van je kennis en ervaring.

ervaring met het zelfstandig ontwerpen, bouwen en implementeren van een data-omgeving. Bijvoorbeeld vanuit een eerdere rol als data consultant, data analist, data architect of data scientist. 

ruime ervaring met Splunk, ELK stack of andere vergelijkbare producten.

kennis van Python of een andere scripttaal.

kennis van DevOps, CI/CD-tooling (Docker, Kubernetes, AWS/Azure, Rancher of Terraform) is beslist een meerwaarde.

Splunk Engineer

Als Splunk specialist help jij verschillende grote klanten om meer waarde uit hun data te halen.

Draai aansprekende projecten die de grootste organisaties in Nederland steviger op de kaart zetten op het vlak van DevOps. Techniek is continu aan het veranderen en daar weet jij alles over vertellen. 

Iedere organisatie heeft een andere DevOps-cultuur door uiteenlopende behoeftes en wensen. Jij sluit naadloos aan op wat klanten willen en komt met een passend antwoord in de vorm van tooling en technieken. Samen met je collega’s van CINQ loop je voorop met je kennis en vanuit die positie voeg jij de meeste waarde toe voor klanten. En omdat de markt steeds weer verandert, blijf je gefocust op de allerlaatste ontwikkelingen. Projecten waar onze DevOps engineers aan werken zijn onder andere:

bouwen van een Kubernetes cluster op Microsoft Azure.

implementeren van Hashicorp Vault op Azure en AWS.

migreren van applicaties van on-premise naar de cloud.

inrichten en verbeteren van CI/CD pipelines.

Sinds 2013 zetten we onze consultants in op hoogwaardige IT-projecten door heel Nederland. Met de kennis die onze specialisten in huis hebben, adviseren we teams en zetten we koers naar innovatie. Nieuwe tooling helpt ons om klanten keer op keer te verrassen. Tussen alle IT-consultancybureaus vallen we misschien niet direct op in wat we doen. Maar wél in hoe we het doen. Daarmee hebben we naam en faam gemaakt in verschillende sectoren en daar gaan we het liefst nog even mee door. 

CINQ is opgesplitst in 3 business units met ieder een eigen expertise. Niet dat we ervan houden om in hokjes te denken, maar dit werkt in de praktijk nu eenmaal het beste. Ook voor onze klanten die een beroep doen op jou als DevOps engineer. Banken, onderwijsinstellingen, overheidsorganisaties: de bedrijven waar wij voor werken zijn groot en divers. Voor jou betekent dat werken aan opdrachten waar je van alles tegenkomt en nieuwe dingen ontdekt. Hoewel je vooral bij klanten werkt, heb je met je CINQ-collega’s een actieve community voor kenniessessies, workshops en game-avonden. Bij CINQ ontwikkel je je in rap tempo en heb je toegang tot alle tooling die je nodig hebt.

Zo goed als we bij CINQ voor onze klanten zijn, zo goed willen we ook voor jou zijn. Daarom krijg je een direct een vast contract voor 36 of 40 uur per week. Al is parttime werken ook mogelijk. Bij deze vacature horen de volgende arbeidsvoorwaarden:

een brutomaandsalaris tussen € 3.500 en € 6.000, afhankelijk van je kennis en ervaring.

bezoeken van conferenties, zoals DockerCon en DevOps Days.

DevOps zit in je bloed. Of je ademt DevOps, mag ook. In ieder geval voel jij je thuis in een DevOps-omgeving. Je hebt een sterke drive om de laatste technieken te leren kennen en toont inlevingsvermogen. Je begrijpt klanten, onderkent hun problemen en gaat vanuit jouw expertise op zoek naar een passend antwoord. Zowel inhoudelijk als communicatief weet jij iedere klant te overtuigen. Daar breng je het volgende voor mee:

ervaring met DevOps-tooling, cloudoplossingen en CI/CD.

kennis van tools als Docker, Kubernetes, Ansible, Jenkins, Terraform, Rancher, AWS, Azure, Google Cloud en Git.

kennis van de programmeertalen Go, Ruby, Python en Java. Dit heb je bijvoorbeeld opgedaan als developer, ontwikkelaar, programmeur of IT-consultant.

En, hoe lijkt het? Ben jij de nieuwe DevOps engineer die onze klanten verder helpt? Solliciteer dan meteen via de sollicitatiebutton. Doe het wel voor [sluitingsdatum], want daarna sluiten we de vacature.

Draai aansprekende projecten die de grootste organisaties in Nederland steviger op de kaart zetten op het vlak van DevOps.

Docker architectuur review bij Pondres

Meer blogs