developer.overheid.nl

Binnen modern web-development zijn er veel processen waarbij we NPM-packages gebruiken. De meest herkenbare verschijningsvormen van NPM-packages zijn libraries en frameworks, maar in de afgelopen jaren is het scala behoorlijk uitgebreid.

In veel codebases zie je ook: linters , test-engines, type-definitions en CLI-tools. Deze groei is verklaarbaar maar zorgt wel voor een stijging van het aantal dependencies binnen projecten. En dat zorgt weer voor problemen als: de welbekende dependency-hell, grote hoeveelheden onderhoudswerk en trage transpile-processen.

In deze post duiken we wat dieper in het NPM-ecosysteem en lees je hoe je bovenstaande problemen kunt voorkomen.

Het Open Geospatial Consortium (OGC) is een internationale standaardenorganisatie. Hier komen onder andere de OGC API standaarden vandaan: gestandaardiseerde REST APIs die ervoor zorgen dat geodata op een universele manier geserveerd en gebruikt kan worden. Regelmatig organiseert het OGC code sprints: hackathons van drie dagen waar standaarden-experts en ontwikkelaars de OGC standaarden implementeren in software. De OGC standaarden die geimplementeerd worden zijn dan meestal nog in draft; wel stabiel, maar nog niet officieel goedgekeurd. Op basis van de feedback van ontwikkelaars kunnen OGC standaarden-experts meteen de standaarden verbeteren en aanvullen. Zo wordt het ontwikkelen van standaarden net iets meer agile.

De Nederlandse overheid publiceert een deel van haar broncode als vrije opensource software. Om software te beheren is een versiebeheersysteem nodig. Hiermee kun je veranderingen in de broncode traceren en beheren. Een versiebeheersysteem faciliteert ook het samenwerken tussen verschillende software-ontwikkelaars. Een gedistribueerd versiebeheersysteem maakt het mogelijk dat ontwikkelaars op verschillende locaties toch kunnen samenwerken aan één softwareproduct. Het de facto versiebeheersysteem voor software is Git. Git is vrije opensource software. Voor een interessante en leerzame introductie in Git zie deze presentatie.

Er zijn online platforms die werken met Git, en die daaromheen toegevoegde functionaliteit bieden om softwaredevelopment en projectmanagement met Git te ondersteunen. Ik gebruik hieronder de term Git-forge (Git-werkplaats) om zulke platforms aan te duiden. GitLab, Forgejo en GitHub zijn allemaal Git-forges.

In deze blog ga ik in op een aantal aspecten van verschillende Git-forges, om zo de beste keuze voor een Git-forge voor de overheid te kunnen maken.

Hoe bouwen we binnen de overheid software die betrouwbaar, open en herbruikbaar is en goed aansluit op standaarden en beleid?

Tijdens zoBouwenWijSoftwareBijDeOverheid laten we zien hoe we dat in de praktijk doen. Op dinsdag 16 december 2025 nodigen we je uit bij Dev.loer in Utrecht voor een inspirerende en vooral hands-on middag. Samen met developers, product owners en technische leads van verschillende overheden ontdek je hoe bestaande tools, richtlijnen en kennisplatforms je direct kunnen helpen bij jouw softwareprojecten.

Ken je dat? Je gaat aan een nieuw project beginnen en dan vraagt iemand 'Doen jullie wel Privacy by Design?'

Uiteraard is het belangrijk om bij de bouw van nieuwe software meteen te denken aan privacy – en ook aan security, toegankelijkheid en mogelijk meer. Maar hoe past dat binnen een moderne, agile werkwijze?

In vroeger tijden, toen complete, gedetailleerde ontwerpen werden gemaakt nog voor er een letter geprogrammeerd was, konden die ontwerpen vooraf aan al deze eisen getoetst worden. In theorie dan, want onder tijdsdruk kwam het daar veel te vaak niet of onvoldoende van. Of de wereld was alweer veranderd tegen de tijd dat de software in productie ging.

Binnen de publieke sector groeit de behoefte aan goed gedocumenteerde, interoperabele en toekomstbestendige API's. De REST API Design Rules (ADR) vormen daarbij een belangrijk referentiekader: ze stimuleren eenvoud, voorspelbaarheid en brede toepasbaarheid door gebruik te maken van open standaarden.

Regelmatig komt de vraag voorbij of OData, een specificatie ontwikkeld binnen het Microsoft-ecosysteem, een slimme keuze kan zijn voor publieke API's. In dit artikel analyseren we de voor- en nadelen van OData, met nadruk op eenvoud, interoperabiliteit en vendor-neutraliteit. Ook bekijken we hoe OData zich verhoudt tot de ADR, en op welke vlakken deze conflicteren.

In een tijd waarin digitale overheidsdiensten steeds vaker via REST API’s communiceren, is het waarborgen van de veiligheid van deze interfaces cruciaal. WuppieFuzz, ontwikkeld door TNO, is een open-source, coverage-guided fuzzer die specifiek is ontworpen voor het testen van REST API’s. Het doel: kwetsbaarheden en bugs opsporen voordat ze misbruikt kunnen worden, met een sterke focus op gebruiksvriendelijkheid, modulariteit en inzichtelijkheid.

In de meeste projecten is dit de perceptie: node_modules worden door package managers geinstalleerd en zijn dus geen source code die in een git repository thuis hoort. Deze blog post probeert je aan het denken te zetten. Niet om je te overtuigen dat het altijd een goed idee is om node_modules in git repositories te zetten, maar om te realiseren dat in sommige projecten het verstandig kan zijn.

Op 31 oktober 2024 publiceerde Geonovum voor het eerst een JSON-schema bij een informatiemodel. Het betrof de publicatie van versie 3.0 van het Informatiemodel Externe Veiligheid: (IMEV). Daarnaast is er ook een suggestie voor een OpenApi Specificatie (OAS) gepubliceerd. In deze blog worden de ervaringen gedeeld die Geonovum daarmee heeft opgedaan in de hoop dat anderen daar van kunnen leren.

Je kijkt naar je broncode en denkt: als ik had geweten wat ik nu weet, had ik het anders aangepakt. Een typisch voorbeeld van technische schuld. Wat is het, hoe kun je het voorkomen (niet dus) en hoe pak je het aan?