Zoekresultaten

Onze maandelijkse kennismiddag was deze keer gevuld met twee onderwerpen, Prometheus en WireMock advanced. Prometheus zien we steeds vaker bij onze klanten gebruikt worden en daarom is dit een goed moment voor verbreding en verdieping van onze kennis van dit monitoring platform. WireMock is al eens eerder aan bod geweest op een kennismiddag en vandaag gingen we verder de diepte in, iets wat we graag doen bij PerformanceArchitecten. Beide onderwerpen zijn als korte workshop voorbereid zodat dit als groep efficiënt opgepakt en uitgewerkt konden worden. Prometheus is een open-source systeemmonitoring- en alerting platform dat oorspronkelijk werd ontwikkeld bij SoundCloud. Sinds de oprichting in 2012 hebben veel bedrijven en organisaties Prometheus omarmd. Het project heeft een actieve community van ontwikkelaars en gebruikers en wordt nu onafhankelijk onderhouden, los van enig bedrijf. In 2016 trad Prometheus toe tot de Cloud Native Computing Foundation als het tweede gehoste project, na Kubernetes. Het bekijken van een aantal video’s uit de playlist ‘Prometheus Monitoring with Julius’ op YouTube heeft ons snel op weg geholpen. Julius Volz is mede-oprichter van Prometheus en hij geeft in deze video’s op een heldere manier uitleg over Prometheus. Daarnaast bevat de website prometheus.io een flink aantal docs, blogs en tutorials. Daarna begon het hands-on gedeelte met installatie van Prometheus middels Docker. Na het verkennen van Prometheus hebben we ervaren hoe eenvoudig nieuwe ‘targets’ toegevoegd kunnen worden aan Prometheus en hebben we instrumentatie middels een sample applicatie in Go bekeken. We hebben het onderwerp Prometheus afgesloten met het maken van een Grafana dashboard waarin de metrics van datasource Prometheus zijn gebruikt. De kant en klare dashboards die geïmporteerd kunnen worden in Grafana zijn zeer handig en besparen je veel werk. In het kort onze bevindingen: het opzetten van een Prometheus instantie, vooral met Docker, is eenvoudig. Het implementeren van monitoring met Prometheus is ook relatief simpel. Het is een efficiënt hulpmiddel met een eenvoudige integratie met Grafana en een grote, actieve community. Echter, er zijn ook enkele nadelen. De grafieken van Prometheus zijn beperkt, dus je hebt snel Grafana of een ander hulpmiddel nodig. Het aanpassen van je eigen applicaties voor Prometheus monitoring lijkt in eerste instantie eenvoudig, maar kan al snel complex worden. Bovendien is er een steile leercurve door het gebruik van Promql.Conclusie: Prometheus biedt een eenvoudige en efficiënte oplossing voor monitoring, met sterke community-ondersteuning en naadloze integratie met Grafana, ondanks een steile leercurve en complexiteit. Het tweede onderwerp die middag was advanced WireMock . WireMock is een krachtige en flexibele open-source tool die is ontworpen voor API-mocking. WireMock stelt je in staat om mock-API’s te maken die echte scenario’s en API’s simuleren. Na kort onze WireMock kennis opgefrist te hebben zijn we met een WireMock docker container aan de gang gegaan. Na het bekijken van diverse mappings zijn we de WireMock admin API gaan gebruiken. Als opdracht hebben we met behulp van een JMeter script mappings aangemaakt en weer verwijderd. Op deze manier kan bijvoorbeeld het testen met mocks in een pipeline gerealiseerd worden. Verder hebben we WireMock cloud (hosted versie van WireMock ), libraries en templates bekeken. Onze bevindingen: WireMock is een gebruiksvriendelijke, open-source tool met handige functies zoals on-the-fly definitie creatie en kant-en-klare stubs via WireMock Templates. Echter, de functionaliteit is simpel (beperkt), de cloudversie kan kosten met zich meebrengen, en de documentatie en kwaliteit van de templates kunnen beter. Conclusie: ondanks enkele uitdagingen, biedt WireMock een gebruiksvriendelijke, veelzijdige en kosteneffectieve oplossing voor het simuleren van API’s. We hebben de dag afgesloten met een gezamenlijke maaltijd en kijken terug op een leuke en leerzame kennismiddag met Prometheus en WireMock waarin we in korte tijd heel veel geleerd hebben over dit monitoring platform en deze mocking tool.

Bij PerformanceArchitecten vinden we het belangrijk om onze kennis en expertise met elkaar te delen. Daarom organiseren we maandelijks een kennismiddag. Tijdens deze middag verdiepen we ons in een bepaald onderwerp. Dit kan gaan over methoden, technieken, nieuwe of bijgewerkte tools en andere actuele onderwerpen die voor ons vakgebied interessant zijn. De eerste kennismiddag van het jaar is altijd een speciale dag. We kijken terug op het afgelopen jaar, bepalen samen waar we de focus op willen leggen in het komende jaar (dit noemen wij de rode draad) en stellen de doelen vast. Afgelopen dinsdag 23 januari hebben we onze kennismiddagenjaar geopend. We begonnen de dag met een M&M retrospective waarbij we op een leuke manier teruggekeken op het afgelopen jaar.  Daarna hebben we met een aantal brainstormsessies, met verschillende werkvormen, ideeën opgedaan en onze doelen opgesteld voor 2024. Uiteindelijk hebben we de volgende rode draad onderwerpen gekozen: AI als hulpmiddel bij ons werk SRE (Site Reliability Engineering) OpenShift / K8s kennis verbeteren Bijblijven met tools DevOps (hoe verandert dit en waarom ontstaan er varianten zoals DevSecOps en DevPerfOps) De kennismiddagen van PerformanceArchitecten zijn een belangrijke motor voor kennisontwikkeling en samenwerking. Ze zijn een moment om elkaar te ontmoeten, te leren van elkaar en samen te werken aan de ontwikkeling van onze vakgebieden. We zijn erg enthousiast over de onderwerpen die we voor het komende jaar hebben gekozen. We zijn ervan overtuigd dat ze ons zullen helpen om onze kennis en expertise verder te ontwikkelen. We zullen hierover ook een aantal blogs schrijven om onze kennis met anderen te delen.

Introductie Tijdens onze maandelijkse kennismiddag hebben we kennisgemaakt met GPT-Engineer, een AI-gebaseerde codegenerator. Met GPT-Engineer kan een complete codebase worden gegenereerd op basis van een beschrijvende tekst in een tekstbestand. Dit wordt verzorgt m.b.v. de artificiële intelligentie van OpenAI ChatGPT. GPT-Engineer is een speciale versie van OpenAI’s GPT-3 die werkt als een software-engineer. Het is in staat om code te schrijven, bestaande code te debuggen en optimaliseren, en dat in verschillende talen. Daarnaast kan het technische vragen beantwoorden en complexe informaticaconcepten uitleggen. In tegenstelling tot ChatGPT, dat een breed scala aan onderwerpen behandelt, is GPT-Engineer specifiek getraind voor software-engineeringtaken. Het heeft toegang tot een uitgebreide dataset van programmeer- en technische inhoud, waardoor het beter in staat is om technische vragen te beantwoorden en code te genereren. Tijdens de generatie van de codebase kan GPT-engineer aanvullende vragen stellen om de beschrijving in de prompt te verduidelijken. Je kunt deze vragen zelf beantwoorden of je kunt de artificiële intelligentie van OpenAI-ChatGPT aannames laten genereren. Het resultaat is een codebase waarvan uit direct gestart kan worden. Voor de visueel ingestelde mensen die nu afhaken vanwege de hoeveelheid tekst, is er ook een video waarin GPT-Engineer wordt uitgelegd. Ook andere video's zijn te vinden op YouTube door te zoeken op "GPT Engineer". In het vervolg van dit artikel staat beschreven wat je kan doen om zelf met GPT-engineer aan de slag te gaan. Let op: GPT-engineer is een betaalde service. Je dient geld te storten op je OpenAI-account om het te kunnen gebruiken. De kosten van GPT-Engineer zijn gebaseerd op de hoeveelheid code die wordt gegenereerd. Voor elke 1000 prompt-tokens wordt er $0,03 in rekening gebracht. Voor elke 1000 completion-tokens wordt er $0,06 in rekening gebracht. Een prompt-token is een teken in de prompt-tekst, inclusief spaties. Een completion-token is een teken in de gegenereerde code. Ter illustratie: na tientallen keren GPT-Engineer te hebben gebruikt is er tot nu toe $2,16 verbruikt. Installatie Allereerst dient het volgende te zijn geïnstalleerd om GPT-Engineer te laten werken: Python versie 3.x Pip Maak een account aan en/of login op de site van OpenAI en selecteer de API. In je account gegevens kun je een API key genereren. 3. Op de GitHub pagina van GPT-Engineer staan de instructies om alles werkend te krijgen voor zowel Linux, Windows als MacOS. GPT-Engineer in actie GPT-Engineer was na diverse pogingen uiteindelijk werkend en werd het voorbeeldproject van de GitHub-repository uitgeprobeerd, waarin het promptbestand de volgende beschrijving had: Hieronder staat een screenshot van GPT-Engineer in actie, waarbij er aanvullende vragen terugkomen om de beschrijving verder te specificeren. Ik heb ervoor gekozen om voor deze vragen aannames te laten genereren door OpenAI. Onderaan in de volgende afbeelding is te zien dat er Python code wordt aangemaakt. Resultaat van het gebruik van GPT-Engineer De resultaten van het voorbeeldproject waren enigzins teleurstellend. De aangemaakte Python-code gebruikte telkens modules die niet compatibel waren met de Python-installatie of probeerde in Windows een dll aan te roepen van een Visual C redist die niet op Windows 11 kon worden geïnstalleerd. Dit kan aan verschillende factoren liggen, zoals de geringe kennis van Python, of dat er een betere creativiteit in het formuleren van de prompt benodigd is. Daarenentegen zullen de mogelijkheden en de kracht van AI alleen maar groter worden en de verwachting is dat binnen zeer korte tijd de resultaten beter kunnen zijn. Ondanks de enigzins teleurstellende resultaten, kunnen we GPT-Engineer niet bij voorbaat afschrijven. We raden aan om op de hoogte te blijven van de nieuwste ontwikkelingen op dit gebied, bijvoorbeeld door af en toe een filmpje te bekijken over GPT-Engineer op YouTube.

Bij PerformanceArchitecten vinden we het belangrijk een gezellige sfeer te creëren binnen ons team, niet alleen tijdens de werkuren maar ook daarbuiten. Om die reden organiseren we meerdere keren per jaar informele uitstapjes. Minstens één keer per jaar, veelal in september, gaan ook onze partners mee met het uitje. Op zaterdag 23 september was het opnieuw zo ver, en dit keer hadden we gekozen voor een bijzondere ervaring bij 'Eenden Tours Westland'. Voordat we aan ons avontuur begonnen, kregen we een uitleg over hoe de eendjes functioneerden en wat we konden verwachten. In groepjes van drie stapten we vervolgens in onze eigen eendjes en begonnen we aan de Westland Route. Het weer was typisch Nederlands: afwisselend gingen de raampjes open om van het frisse briesje te genieten en weer dicht om de regenbuien te ontwijken. Desondanks weerstonden onze eendjes moedig alle weersomstandigheden. Na dit avontuur, waarbij we onze stuurmanskunsten mochten aanspreken zonder enige stuurbekrachtiging, hadden we allemaal een smakelijke maaltijd verdiend. Het was weer een geslaagde dag!

Het Next Web (TNW) Conference is een jaarlijks evenement dat professionals uit de wereld van technologie, innovatie en ondernemerschap samenbrengt. Dit jaar vond TNW 2023 plaats in Amsterdam (eigenlijk Zaandam). Ik kreeg de kans om aanwezig te zijn en wil graag mijn ervaringen delen in deze blogpost. Het centrale thema van dit tweedaagse evenement was kunstmatige intelligentie (AI) en de impact hiervan op organisaties maar ook individuen. Eenander onderwerp dat naar voren kwam, was een verfrissende kijk op het verzamelen van data, vaak in combinatie met AI. Het congres bood een breed scala aaninspirerende keynotes van toonaangevende professionals uit de industrie. Daarnaast waren er boeiende paneldiscussies waar de nieuwste trends en ontwikkelingen in de technologiewereld werden besproken. Er werden veel maatschappelijke kwesties aangekaart, zoals inclusiviteit, de rol van AI, privacy en digitale ongelijkheid. Hier volgen enkele hoogtepunten: Met de opkomst van AI is de rol van developers aanzienlijk aan het veranderen. AI en low-code technologieën brengen verschuivingen teweeg waarbij er meer nadruk wordt gelegd op controle en businessanalyse. De rol van een developer zal dus verschuiven van het genereren van code naar het controleren van code. Softwarebedrijven moeten zich ook aanpassen en naast het generen van code ook meer richten op het bieden van tools voor de controle van code. Na Covid is hybride werken op kantoor de norm geworden. Dus het gebruik van kantoorruimtes zal moeten veranderen om te voldoen aan de huidige en toekomstige behoeften. Dit is mogelijk door het inrichten van multifunctionele ruimtes die ook buiten werktijden gebruikt kunnen worden door bijvoorbeeld verenigingen en scholen. Een effectieve kantoorruimte gaat verder dan alleen bureaus en zorgt voor optimaal gebruik van de ruimte. Er werd een demo gegeven van het genereren van audioadvertenties met behulp van ChatGPT en Alexa. Dit was indrukwekkend vanwege de kwaliteit en de mogelijkheid om tijdens het creatieproces vervolg- en detailvragen te stellen. De populariteit van audio neemt toe, met radio, streamingdiensten en vooral podcasts als belangrijke spelers. Het maken van audio is gemakkelijker dan video en de consumptie ervan is minder belastend. Daarom zullen audioadvertenties naar verwachting toenemen, vooral in passende contexten zoals podcasts. De metaverse wint terrein als marketinginstrument. Het verschil tussen het streamen van een product, fysiek aanwezig zijn en de metaverse is dat streamen statisch is, fysiek aanwezig zijn reistijd en wachttijd met zich meebrengt, terwijl het ‘ruimtelijke web’ deze problemen oplost. BMW heeft een interessant experiment uitgevoerd in samenwerking met Warner Music, Epic/Unreal. Door de samenwerking met deze vooraanstaande bedrijven, krijg je daadwerkelijk een mooi product wat aanspreekt. Cijfers (mogelijk bevooroordeeld, “wij van WC-eend”) geven aan dat het effectief is. Steden (niet-Amerikaanse) streven ernaar auto’s te beperken en wegen efficiënter te gebruiken voor fietsers, voetgangers en openbaar vervoer. Het integreren van planning, routes, efficiëntie, kosten en betaalgemak blijft echter een uitdaging. Elektrificatie, gedeelde mobiliteit en efficiëntie zijn op dit moment belangrijke aandachtspunten, maar er is nog veel werk te doen. Oplossingen, zoals het verbannen van dieselvoertuigen, zijn nog niet volledig beschikbaar, maar er wordt hard aan gewerkt. AI speelt een steeds grotere rol in de gamingindustrie, zowel bij het genereren van reacties van niet-speelbare personages (NPC’s) met behulp van grote taalmodellen als bij het verbeteren van de gameplay in open wereld-spellen. Een NPC is een karakter in een videogame dat door de computer wordt gecontroleerd en niet door een speler. Ze worden vaak gebruikt om de spelwereld te bevolken, missies te geven of interactie te hebben met spelers. AI wordt steeds meer geïntegreerd in game-ontwikkelingsframeworks zoals Unity, waardoor ontwikkelaars toegang hebben tot krachtige tools en mogelijkheden om de game-ervaring te transformeren. Een hoogtepunt van het evenement was de presentatie van Nagin Cox, een NASA-engineer die een belangrijke rol speelt in robotische ruimtemissies, waaronder de Mars Rover-missies. Ze is verantwoordelijk voor het plannen en uitvoeren van operationele activiteiten voor de rovers op Mars. Met haar inspirerende en enthousiaste persoonlijkheid wist ze het publiek te motiveren en aan het denken te zetten over de toekomst van ruimtevaart en onze rol daarin. TNW 2023 Conferences bood inspirerende keynotes, boeiende paneldiscussies en inzichten in maatschappelijke vraagstukken. Klein kritiek punt is dat bij dit soort congressen bepaalde sprekers vooral bezig zijn met zichzelf horen praten, zonder daadwerkelijk veel toegevoegde waarde te bieden. Maar al met al heeft het congres mij en de deelnemers geïnspireerd en uitgedaagd om na te denken over de toekomst van technologie en onze rol daarin.

Work hard, play hard! Dat laatste hebben we vrijdag 2 juni letterlijk genomen. We zijn naar een museum geweest, het Nationaal Videogame Museum in het stadshart van Zoetermeer. Voor gamefanaten is dit echt een feestje. We kregen een interessante rondleiding waarbij we van alles te weten kwamen over de ontwikkeling van videogames, vanaf de vroege jaren ’70 tot nu. We zagen de allereerste arcadespellen, de legendarische Commodore 64, verschillende videogameconsoles, handhelds en natuurlijk de moderne interactieve spellen. Na de rondleiding mochten we zelfs onze favoriete oude games spelen, of de voor ons nieuwe Japanse spellen uitproberen. Er was zoveel te spelen, het was moeilijk om een keuze te maken. Kortom, het was een leuke middag waarin we konden genieten van onze (oude) liefde voor videogames. Het Nationaal Videogame Museum is echt een aanrader!

Zijn we klaar voor AI-gestuurde testautomatiseringstools? Een blik op testRigor. Bij PerformanceArchitecten vinden we het belangrijk om continu onze kennis te ontwikkelen en bij te houden. Daarom organiseren we elke maand een kennismiddag waarbij we ons verdiepen in verschillende onderwerpen die relevant zijn voor ons werk. Onze laatste kennismiddag stond in het teken van testRigor. Testautomatisering is een essentieel onderdeel van softwareontwikkeling, maar het kan ook veel tijd en moeite kosten om testen te schrijven, uit te voeren en te onderhouden. Vooral als je een snel veranderend product hebt, kan het lastig zijn om je tests stabiel en up-to-date te houden. Volgens de makers is testRigors de oplossing hiervoor: het is een AI-gebaseerd testautomatiseringstool die je in staat stelt om tests te maken in gewoon geschreven taal (in dit geval Engels), zonder code of locators te gebruiken. Met testRigor kun je tests maken die mensen simuleren die web-, mobiele en desktopapplicaties gebruiken. In deze blogpost zullen we je laten zien hoe testRigor werkt en wat onze bevindingen zijn ten opzichte van andere testautomatiseringstools. Hoe werkt testRigor? testRigor maakt gebruik van natuurlijke taalverwerking en machine learning om je tests te begrijpen en uit te voeren. Je kunt tests schrijven als een reeks stappen in gewone taal (Engels). Een bijvoorbeeld: go to "https://testRigor.com/" click "Request a Demo" enter "Name" with "Jan Jansen" enter "Email" with "jan.jansen@testRigor.com" enter "Phone" with "+31 6 12345678" click "Submit" check that a confirmation message appears testRigor zal deze stappen vertalen naar acties die worden uitgevoerd op de browser of het apparaat van je keuze. Je kunt tests uitvoeren op bijna alle browsers op meerdere besturingssystemen, zoals bijvoorbeeld Internet Explorer op Windows en Safari op Mac en iOS. Je kunt ook mobiele tests uitvoeren, inclusief tests op fysieke apparaten en testen van hybride apps. testRigor is compleet web-gebaseerd. De uitvoering gebeurd in de “cloud”. Als een test is uitgevoerd laat testRigor voor elke stap een screenshot zien via de webinterface te zien. Dit wordt zelf dynamisch opgebouwd tijdens het draaien van de testen zodat je de test kan volgen. Het laat alle stappen duidelijk zien en ook kan je eventuele fouten hierin terugvinden. Highlights (en lowlights): testRigor biedt veel opties voor het selecteren, invullen en controleren van objecten, waardoor testcases flexibel en uitgebreid kunnen zijn. Het specifieke taalgebruik van testRigor zorgt voor duidelijkheid en precisie in de teststappen. Maar het vereist een zeer precieze formulering in natuurlijke taal en kan niet vergeleken worden met nieuw en opkomende AI-ondersteunde tooling. Een uitdaging bij testRigor is dat het een trial-and-error-proces kan zijn, waarbij feedback alleen tijdens de uitvoering wordt gegeven. Dit kan de snelheid van het creëren van testen belemmeren en frustratie veroorzaken bij testers. Door binnen de browser de F12-toets te gebruiken en de technische details te bekijken van de website, kan je problemen oplossen. Dit is echter (te) technisch en we hadden verwacht dat dit door het testtool zou worden opgelost. Dan is de vraag waar wordt testRigor uitgevoerd? Ergens in de Cloud. Met de standaard optie/abonnement is het niet duidelijk waar je test uitgevoerd wordt. Onduidelijk is of GDPR compliancy wel voor testRigor ingesteld kan worden: waar staat de data precies? Ook wanneer je test wordt uitgevoerd is onduidelijk; de test wordt gequeued en dan uitgevoerd. Bij onze testen ging dat eigenlijk altijd snel maar het kan zomaar dat er veel testen voor je in de queue staan en je moet wachten op resultaten. Dit zou lastig kunnen worden omdat onze ervaring is dat je qua testontwikkeling veel van trial-and-error afhankelijk bent. Er is een browserplugin beschikbaar om tests op te nemen. Alhoewel testRigor belooft dat veel met natuurlijke tekst kan, hebben we gemerkt dat via het opnemen via de browserplugin de tekst meteen goed staat dus dat heeft wat ons betreft wel een voorkeur. Het is goed om op te merken dat bij testRigor de resultaten en uitvoeringsinformatie (inclusief gegevens) openbaar zijn, tenzij een betaald abonnement wordt gebruikt. Dit is een overweging bij het uitproberen van de tool dat je geen gevoelige informatie in je tests opneemt. testRigor zegt op hun website dat het gebaseerd is op BDD 2.0 oftewel Specification-Driven Development (SDD). BDD is een bekende methode binnen de testcommunity. Als je met Google zoekt op “BDD 2.0” dan vind je alleen maar de site van testRigor, verder heeft niemand het nog over BDD 2.0. Met onze ervaring vinden we eigenlijk dat testRigor niet van BDD 2.0 moet spreken maar van keyword driven 2.0 omdat dit meer op de aloude manier van keyword driven testautomatisering lijkt. De tool biedt flexibiliteit en efficiëntie, maar de stevige prijs van het abonnement kan een overweging zijn. Voor de betaalde versie moet op dit moment $900 per maand betaald worden, oftewel $10.800 per jaar. Conclusie: Voor zover wij kunnen zien is het niet echt AI-gestuurde testautomatisering wat testRigor biedt. Het biedt een intelligente manier van tekst gedreven testautomatisering. Eerlijk is eerlijk: we hadden hier meer van verwacht, zeker als je de prijs voor de betaalde versie in overweging neemt. Het is qua product leuk uitgewerkt met een goede webinterface. We zien wel wat haken en ogen aan het product maar voor een specifieke doelgroep zal dit een goed tool zijn. We hebben een leuke middag met deze tool gehad. We verwachten nog veel van AI-ondersteunde tools in de toekomst. Hopelijk zal testRigor zich nog verder ontwikkelen op dit vlak. Disclaimer: natuurlijk hebben we niet alles kunnen testen, dus wellicht zitten er nog mooie, onontdekte features in de tool die de moeite waard zijn.

Tijdens de laatste maandelijkse kennismiddag van PerformanceArchitecten hebben we ons verdiept in het onderwerp SRE (Site Reliability Engineering). SRE combineert software engineering en operationele principes om grootschalige en complexe systemen te bouwen en beheren. Ter introductie hebben we verschillende video’s bekeken waarin de definitie van SRE werd gegeven en het verschil tussen SRE en DevOps werd uitgelegd. Vervolgens hebben we deelgenomen aan een workshop getiteld “The Art of SLO”. Tijdens deze workshop werd niet alleen uitgebreid de theorie behandeld, maar kregen we ook de gelegenheid om zelf aan de slag te gaan met het bepalen van SLI’s (Service Level Indicators) en SLO’s (Service Level Objectives) aan de hand van enkele opdrachten. Tenslotte hebben we geëvalueerd in welke mate de kennis en vaardigheden die we hebben opgedaan direct toepasbaar zijn in ons werk. We zien zeker raakvlakken met ons werk als performance engineer en denken dat er met name mogelijkheden liggen bij onze klanten die bezig zijn met cloudtechnologie. Concluderend kunnen we stellen dat onze kennismiddag zeer geslaagd was. We hebben veel geleerd over SRE en we kijken uit naar de volgende kennismiddag en het volgende onderwerp dat we gaan verkennen.

Bij PerformanceArchitecten vinden we het belangrijk om continu onze kennis te ontwikkelen en bij te houden. Daarom organiseren we elke maand een kennismiddag, waarbij we ons verdiepen in verschillende onderwerpen die relevant zijn voor ons werk. Onze laatste kennismiddag stond in het teken van het RealBrowser “protocol” binnen het performancetesttool NeoLoad van Tricentis. Voor degenen die niet bekend zijn met NeoLoad, het is een tool die wordt gebruikt voor het testen van de performance van webapplicaties en -diensten. Het is een tool onder performancetesters die steeds populairder wordt vanwege de vele mogelijkheden en maar vooral ook de concurrerende prijsstelling van dit commerciële tool. Sinds versie 9.0 is RealBrowser toegevoegd aan NeoLoad. Dit biedt testers de mogelijkheid om tests uit te voeren die nog realistischer zijn dan voorheen. Met RealBrowser kunnen testers nu de performance van hun applicaties testen op basis van echte browsers zoals Chrome en Firefox. Anders dan het standaard HTTP gebaseerde protocol dat voorheen de standaard in NeoLoad was, wordt ook de client-side rendering en verwerking binnen de browser meegenomen. Hiermee krijg je dus een realistischere transactietijden zoals ook de eindgebruiker ervaart. Daarnaast is het niet nodig om moeilijke correlatie te doen om het gedrag van de browser goed te simuleren. Om tijdens de kennismiddag praktijkervaring op te doen met RealBrowser, was het belangrijk dat alle deelnemers de nieuwste versie van NeoLoad, versie 9.2.1, hadden geïnstalleerd op hun laptops. Dit zorgde ervoor dat we optimaal gebruik konden maken van de laatste mogelijkheden van RealBrowser en de functionaliteiten ervan goed konden verkennen en testen. De basis van RealBrowser is gebaseerd op Playwright, een open source testing framework dat is geïntegreerd in het NeoLoad-tool. Hierdoor krijg je grotendeels de functionaliteit van Playwright. Bij de installatie worden meerdere browsers meegeleverd en geïnstalleerd. NeoLoad biedt de functionaliteit van Playwright door middel van nieuwe scriptacties, die handmatig kunnen worden toegevoegd aan het script, maar ook kunnen worden opgenomen. Wanneer de opname wordt gestart, wordt eerst een Chromium-browser gestart, waarna alle acties die in de browser worden uitgevoerd automatisch worden omgezet in NeoLoad-scriptacties. Dit zorgt voor een snelle manier om testscripts op te zetten. Onze ervaringen met het RealBrowser-protocol binnen NeoLoad laten zien dat het goed werkt, maar dat het nog steeds in ontwikkeling is. Het was een slimme keuze van Tricentis om het protocol te baseren op Playwright, omdat het snel, stabiel en compatibel is met verschillende browsers, zowel in headless als in GUI-modus. Het blijkt dat de extra resources die nodig zijn voor browser-gebaseerde tests meevallen. Om echter veel gebruikers te simuleren, is het ook mogelijk om een mix te maken van zowel het traditionele HTTP-gebaseerde protocol als het RealBrowser-protocol. Voor de echte belasting van de applicatie kan je het “oude” protocol gebruiken, wat relatief weinig resources vereist, en enkele RealBrowser-gebruikers toevoegen om een realistischer beeld te krijgen van hoe eindgebruikers de applicatie ervaren. Dit biedt een goede balans tussen belasting en realisme tijdens het uitvoeren van performancetests. Hoewel het RealBrowser-protocol binnen NeoLoad goed werkt, valt er zeker nog wel het een en ander op aan te merken. Tijdens het gebruik wordt het duidelijk dat het nog steeds een versie 1.0 is. Sommige functionaliteiten zijn nog niet volledig geïntegreerd op een eenduidige manier en er is nog weinig documentatie beschikbaar. Dit kan leiden tot enige uitdagingen bij het opzetten van performancetests met het RealBrowser-protocol. Nog wat expliciete voor- en nadelen: Het opgeven van welke browser gebruikt moet worden is niet consequent met de andere protocollen Voor de loadgeneratoren kan een Linux gebaseerde Docker-image worden gebruikt wat ook weer minder resources inneemt en meer gebruikt wordt dan Windows gebaseerde Docker images Record from here: een handige functie die eerst de voorgaande stappen afspeelt en dan de recording start Assertions zijn onduidelijk hoe je die toevoegt of gebruikt Zoeken/vervangen werkt niet goed in RealBrowser Tijdens de recording worden alleen screenshots bewaard waardoor het lastig is om onderhoud te doen en doot de CSS/Xpath uit de source te halen De ondersteuning van vreemde browser frameworks (bv Vaadim) is geen probleem voor RealBrowser terwijl dit heel moeilijk/onmogelijk te scripten is met het HTTP protocol Het recorden van zaken die niet standaard zijn kosten exponentieel meer moeite. Al met al was onze kennismiddag over RealBrowser en NeoLoad zeer leerzaam en interessant. We zijn blij dat we ons kunnen blijven ontwikkelen en op de hoogte kunnen blijven van de nieuwste ontwikkelingen op ons vakgebied. We kijken alweer uit naar de volgende kennismiddag!

Als je binnen JMeter iets wilt doen wat niet standaard in de tool zit, gebruik je plugins of ga je zelf code schrijven. In het geval dat je zelf code gaat schrijven, wordt aangeraden de groovy functie en JSR223 sampler te gebruiken. Ik wil hieronder graag bespreken welke mogelijkheden deze 2 opties je bieden, maar ook waar ik de beperkingen hiervan zie. Groovy JMeter functie In JMeter heb je de __groovy functie. Je kan hier je eigen code in kwijt, maar je kan ook een functie aanroepen uit een (eigen geschreven) groovy file. Voor de laatste optie moet je property groovy.utilities definiëren met het pad naar de groovy file. Deze property is beschikbaar in jmeter.properties. Na aanpassen van de property is een herstart van JMeter vereist. JMeter bevat in de installatie ook een voorbeeld (zie jmeter.properties van je eigen JMeter installatie). Daarin wordt verwezen naar bin/utility.groovy en daarin staat een factorial functie. Aanroepen van deze functie kan dan via: ${__groovy(factorial(10))} Het grootste nadeel van de JMeter functies, waar __groovy er 1 van is, is dat ze niet overal gebruikt mogen/kunnen worden: https://jmeter.apache.org/usermanual/functions.html#where. Waarvan, voor mij, de belangrijkste het “Script” veld is van de JSR223 sampler. Het gebruik van de groovy functie kan in mijn ogen vooral heel handig zijn bij het definiëren van waardes van variabelen (User Defined Variables of User Parameters). Maar ik denk niet dat het handig is voor uitvoerende functies zoals het openen van bijvoorbeeld een database connectie of een MQ queue connectie omdat er geen goede plek is om deze functies uit te laten voeren (het werkt in ieder geval niet vanuit het Script veld van de JSR223 sampler). JSR223 sampler De JSR223 sampler is de andere aangeraden manier om zelf code te schrijven. Bij het gebruik van de JSR223 sampler kan je op 2 manieren groovy code aanroepen/uitvoeren. Dit zijn: Gebruik van veld “Script file (overrides script) -> File Name” Code schrijven in “Script” veld JSR223 sampler – Script file De eerste optie spreekt voor zich: Je kan verwijzen naar een groovy file die de code bevat die je uit wil voeren. Hierbij kan je ook parameters meegeven. Deze kan je bijvoorbeeld gebruiken om de code wat generieker te maken. Je kan dan bijv. code maken voor het connecten met een MQ queue waarbij de parameter de queue naam bevat. Je kan vanuit de JSR223 sampler geen functies aanroepen binnen die groovy file. Je zou hier wel een work-around voor kunnen bedenken zoals een switch statement die een parameter met functie naam als input gebruikt en op basis daarvan een functie aanroept. Voorbeeld: String function = args[0] switch (function) { case "factorial": factorial(10) break case "someFunction": someFunction() break } def factorial(n) { n == 1 ? 1 : n * factorial(n - 1) } Het grote nadeel van “externe” groovy scripts vind ik dat je het JMeter script moet “verlaten” om de code te bekijken of te bewerken. Dit probleem is opgelost door de code in het Script veld te zetten. Het nadeel hiervan is dan weer dat je (mogelijk) die code op meerdere plekken in je JMeter script gaat krijgen. In het volgende stuk bespreek ik welke manieren ik gevonden heb om daarmee om te gaan. JSR223 sampler – Script veld Mijn voorkeur heeft dus het schrijven van de code in het veld Script van de JSR223 sampler. Wat zijn dan de manieren om te voorkomen dat de code niet op meerdere plekken in het JMeter script terecht komt? Dit heeft vooral te maken met de plaatsing van de sampler en de vulling ervan. Ik heb dit opgesplitst in 2 manieren: Gebruik van Test Fragments Functies definiëren en in props of vars zetten JSR223 sampler – Script veld – Test Fragments Je kan een Test Fragment maken en met behulp van een Controller verschillende JSR223 samplers daar onderbrengen. Vanuit de Thread Groups kan je dan door middel van de Module Controller deze functies aanroepen. Voorbeeld: Deze methode werkt heel fijn. Deze functies kan je echter niet aanroepen met parameters. Ik gaf eerder het voorbeeld bij de JSR223 sampler dat je bijvoorbeeld code kan schrijven voor het openen van een MQ queue connectie en dat je dan de parameters kon gebruiken om bijv. de queue naam mee te geven. Dat werkt nu niet. Ik heb dit opgelost door voor het aanroepen van de functie de waardes van een aantal JMeter vars aan te passen m.b.v. User Defined Variables, User Parameters of JSR223 sampler. Een nadeel van deze methode, los van gemis van gebruik van parameters, is dat je alsnog per functie een aanroep controller (module controller) nodig hebt. Mijn voorkeur is 1 JSR223 sampler waarin je de verschillende functies aanroept die je nodig hebt in een iteratie. Dit komt de leesbaarheid van het script ten goede. Hoe je dit doet, wordt in het volgende stuk beschreven. JSR223 sampler – Script veld – Functies in props of vars Een andere mogelijkheid om de groovy code modulair te maken, is door de referentie naar een functie op te slaan in een prop of var: props.put('factorial', this.&factorial) vars.putObject('factorial', this.&factorial) En verder in het script weer aan te roepen: def factorial = props.get('factorial') factorial(10) of in 1 regel: props.get('factorial')(10) Voor vars gebruik je dan vars.getObject(‘factorial’). Het gebruik van groovy code op deze manier heeft zijn voor- en nadelen. Je hebt meerdere mogelijkheden om dit te doen. Een aantal die ik geprobeerd heb: Functies definiëren in JSR223 Pre-Processors. Funtie reference wordt dan opgeslagen in vars object. Functies definiëren in setUp Thread Group. Functie reference wordt dan opgeslagen in props object. JSR223 sampler – Script veld – Functies in props of vars – Pre-processor Als je gebruik maakt van de JSR223 Pre-Processor kan je deze op verschillende niveaus in het Test Plan plaatsen. Ook op het hoogste niveau. Maar bedenk dan wel dat deze pre-processor uitgevoerd wordt bij elke sampler in het Test Plan dat uitgevoerd wordt. Bij heel veel samplers zal dit dan een overbodige actie zijn en zonde van de beschikbare resources. Het voordeel is dan natuurlijk wel dat je op het hoogste niveau al je functies kan definiëren wat het geheel overzichtelijker maakt. Je kan ook de pre-processor op een lager niveau zetten. Maar als een bepaalde functie door verschillende Thread Groups gebruikt wordt, dan heb je alsnog de code op verschillende plekken staan. Dus als je dan toch de pre-processors gebruikt, zou ik dat op het hoogste niveau doen. JSR223 sampler – Script veld – Functies in props of vars – setUp Thread Group De andere optie die ik gaf, was het gebruik van JSR223 samplers in de setUp Thread Group. Dan heb je een mooie verzamelplaats voor je functies. De referentie naar die functies moeten dan wel opgeslagen worden in een prop. De voordelen hiervan zijn: Alle functies zijn mooi verzameld. (dit geldt ook voor gebruik van pre-processor) De JSR223 sampler wordt niet bij elke sampler in Test Plan uitgevoerd. Je kan de code voor 1 iteratie met aanroep naar verschillende functies in 1 JSR223 sampler kwijt. (dit geldt ook voor gebruik van pre-processor) Het nadeel van deze methode is dat de functies in de setUp Thread Group “gemaakt” worden. De vars.get en vars.getObject in de functies werken niet als de functies vanuit een andere Thread Group worden aangeroepen (wat dus wel het idee is van deze methode). Dat betekent dus dat de functies zo gemaakt moeten worden dat ze alle dynamische parameters moeten ontvangen die ze nodig hebben. Variabelen op Test Plan niveau werken hier natuurlijk wel. Maar de functie zal dan wel altijd de oorspronkelijke waarde gebruiken. Dus mocht de waarde van die var aangepast worden, dan zie je dat niet terug in de functie. vars.put of vars.putObject werken ook niet. Dit is ook meteen een voordeel aangezien het best onoverzichtelijk kan zijn waar de verschillende vars binnen het Test Plan een waarde krijgen of waar deze waarde wordt aangepast. Dus in dat opzicht zijn het “schone” functies die niets doen met de bestaande vars. Conclusie Ik heb een aantal manieren beschreven waarop je zelf geschreven groovy code kan gebruiken binnen JMeter. Ik ben heel benieuwd of er nog andere manieren zijn en ook welke ervaringen jullie hiermee hebben.

Op dinsdag 14 februari hebben we weer onze maandelijkse kennismiddag gehad. Een kennismiddag biedt ons de mogelijkheid om als collega’s bij elkaar te komen en een of meerdere onderwerpen op te pakken, uit te zoeken en kennis over op te doen. Naast wat andere onderwerpen stond deze middag in het teken van de ontwikkelingen rondom ChatGPT, wie heeft er tegenwoordig nog niet van gehoord. Tijdens deze middag zijn we in tweetallen gaan kijken naar waarbij ChatGPT ons kan ondersteunen in het werk. Er is gekeken of deze blog-post gegenereerd kan worden door ChatGPT. En er is onderzocht of de AI ondersteuning kan geven bij de SEO (Search Engine Optimization) of kan helpen bij het schrijven van (automatisering) scripts. Al deze categorieën kunnen handig zijn bij uitvoering van ons werk, maar helpt het ook echt? Deze blogpost is in ieder geval niet geschreven door ChatGPT! De algemene conclusie is dat ChatGPT een prachtige tool is met verrassende resultaten. Het begin van AI gegenereerde resultaten is er, maar het is nog niet perfect! Er moeten heel specifieke instructies gegeven worden om het juiste te bereiken. Het hoewel ChatGPT de invoer van jou als gebruiker ‘onthoudt’, is het soms wel mogelijk om onjuiste of niet volledige resultaten terug te krijgen. Soms omdat het verkeerde gevraagd wordt, of dat er een maximum aan uitvoer karakters bereikt is. Gelukkig kan je via een ‘undo’- of ‘continue’-commando wel verder blijven werken. Bij de SEO- of scripting-ondersteuning merkten we ook op dat de gegenereerde resultaten een goede eerste opzet zijn, maar wel degelijk verdere input van een gebruiker nodig heeft. Hierbij zal de domein-kennis of vak-expertise nog steeds nodig blijven. Kortom, het is een tool dat veel potentieel heeft en zeker kan helpen in diverse situaties. Maar volledig over op AI kan zeker nog niet! Op naar een volgende Kennismiddag en nieuwe onderwerpen!

We zien bij onze klanten een duidelijke verschuiving van verantwoordelijkheden van centrale teams naar DevOps teams. “You build it, you run it” zorgt ervoor dat teams niet alleen zelf software moeten bouwen, testen en in productie brengen, maar ook verantwoordelijk zijn voor hoe de applicatie in productie draait. Eén van de activiteiten die we zien verschuiven, is het performancetesten. In deze blog willen we onze visie delen m.b.t. het overdragen van performancetesten van een centraal team of CoE (Center of Expertise) naar DevOps teams. De initiële reactie van performancetesters is vaak dat performancetesten een expertise is die niet zomaar overgedragen kan worden. Meestal zijn dit specialisten die al vele jaren met het vak bezig zijn en zij zien deze transitie dus ook als een gevaar. Zowel voor hun eigen rol, maar ook voor de kwaliteit van performancetesten. Door lage kwaliteit performancetesten kunnen problemen verborgen blijven en dit kan grote gevolgen hebben voor de beschikbaarheid van applicaties in productie. Een veel gehoord argument is dat er specifieke kennis nodig is voor het performancetesten. Deze kennis is meestal niet aanwezig bij de teams. Teams hebben al zoveel taken en verantwoordelijkheden en het is simpelweg niet mogelijk om overal specialist in te zijn. En dat is natuurlijk een valide argument. Toch is het (deels) mogelijk om performancetesten succesvol over te dragen aan DevOps teams. Mits aan een aantal voorwaarden wordt voldaan. Deze voorwaarden worden hieronder opgesomd en later verder toegelicht: Automatiseren – Automatiseer het uitvoeren van performancetesten. Korte herhaaldelijke testen – Maak onderscheid in korte testen (voor regressie) en specialistische testen. Specialist behouden – Binnen de organisatie moet een performancetestspecialist beschikbaar zijn voor ondersteuning en kwaliteitscontrole. Affiniteit en basiskennis – Affiniteit met performance en basiskennis van performancetesten (scripting, analyse e.d.) moet binnen het team aanwezig zijn. Tijd en aandacht – Product owner moet adoptie van en overdracht naar het team (onder)steunen en daar tijd voor inplannen. Automatiseren Door het automatiseren van het uitvoeren van performancetesten kan er een flinke versnelling in het opleveren van de performancetestresultaten worden bereikt. Bij het automatiseren moet je denken aan: Het voorbereiden van de test (zoals klaarzetten van testdata en monitoring) Het starten van de simulatie Het verzamelen van monitoringgegevens en de resultaten van de test Het analyseren en rapporten van de testresultaten (inclusief vergelijken met vorige resultaten) Dit bespaart een hoop tijd en voorkomt ook dat de performancetester (of degene die met die taak belast is) herhaaldelijk werk moet doen en zorgt ervoor dat deze zich enkel hoeft te focussen op wijzigingen in scope, volumes en andere requirements. Korte herhaaldelijke testen Er bestaan meerdere type performancetesten die voor verschillende doelen worden ingezet. Door onderscheid te maken tussen eenvoudige herhaalbare testen en specialistische testen is het mogelijk om eenvoudige testen over te dragen naar het team en specialistische testen bij de performancetestspecialisten neer te leggen. Bij korte, herhaaldelijke testen is automatiseren van de uitvoer van performancetesten een prima aanpak maar bij specialistische testen is dit vaak minder bruikbaar. Specialistische testen (zoals duurtest, failover test) worden met minder regelmaat uitgevoerd en het scenario zal vaak anders zijn. Specialist behouden Binnen de organisatie moet een performancetestspecialist beschikbaar zijn voor ondersteuning en kwaliteitscontrole. Bij grotere organisaties zullen dat wellicht meerdere specialisten zijn. De hierboven genoemde specialistische testen kunnen door deze performancetestspecialisten worden uitgevoerd. Door het uitvoeren van kwaliteitscontrole kunnen performancetestspecialisten de teams helpen om de kwaliteit van performancetesten op een goed niveau te houden. Affiniteit en basiskennis Om performancetesten succesvol te kunnen overdragen naar teams moet er wel een zekere basiskennis van performancetesten binnen het team aanwezig zijn. Toolkennis is nodig om het bestaande script te kunnen aanpassen aan de gewijzigde functionaliteit en om analyse van de resultaten te kunnen doen. Naast deze basiskennis zal er in het team ook enige affiniteit met performance moeten zijn. Dit zal het team nodig hebben om regelmatig na te gaan of er nieuwe risico’s op het gebied van performance zijn. Denk hierbij aan responstijd, stabiliteit, capaciteit en andere aspecten van performance. Tijd en aandacht Het overdragen van performancetesten van performancetestspecialisten naar teams zal alleen succesvol zijn als de product owner van het team ook het belang van performancetesten inziet en voldoende tijd zal inruimen in de sprint planning voor de overdracht van performancetesten. Naast de overdracht naar het team is ook de adoptie van performancetesten door het team van belang. Hierbij is het belangrijk dat het niet bij één persoon komt te liggen maar dat het breed gedragen wordt. Anders bestaat het gevaar dat de kennis van performancetesten verdwijnt bij wisseling in het team. Tot slot Hierboven hebben wij onze visie gedeeld over hoe performancetesten overgedragen kan worden naar teams en wat de voorwaarden hiervoor zijn. We horen graag wat jouw ervaring is.