Week 13 werd gekenmerkt door de voltooiing van onze Docker-architectuur en een interessante pivot in een klantproject. Van het oplossen van complexe SSL-configuraties tot het transformeren van een blog naar een persoonlijk journal - deze week toonde aan hoe veelzijdig software development kan zijn.
Docker SSL Debugging: Een Technische Deep Dive
De week begon met het aanpakken van persistente SSL-problemen in onze Docker setup. Het probleem was subtiel maar kritiek: Kestrel, de .NET webserver, probeerde automatisch HTTPS-endpoints op te zetten, wat tot certificaat-gerelateerde crashes leidde in een containeromgeving.
De oplossing vereiste een gerichte Kestrel-configuratie waarbij ik expliciet instructies gaf om alleen op poort 80 te luisteren voor HTTP-verkeer. Dit type low-level webserver configuratie is cruciaal in containerized environments waar je volledige controle wilt over netwerkverkeer en certificaatbeheer.
Een leerzame fout die ik tegenkwam was een Docker container naming conflict. Toen ik een service hernoemde, maar de container_name hetzelfde liet, probeerde Docker een nieuwe container aan te maken met een naam die al bestond. Dit illustreert perfect waarom consistency in naming conventions zo belangrijk is in infrastructure-as-code.
Van Blog naar Journal: Requirements Evolution
Een fascinerende ontwikkeling deze week was de pivot van Jos' blog naar een journal-format. Dit is een perfect voorbeeld van hoe klantbehoeften evolueren tijdens development. Waar oorspronkelijk een traditionele blog-layout werd gevraagd, bleek een meer persoonlijke journal-structuur beter te passen bij de use case.
De nieuwe requirements waren specifiek:
Centrale datum en titel als primary focus
Tag-gebaseerde navigatie rechts in de sidebar
Filtering functionaliteit waarbij klikken op een tag alle gerelateerde posts toont
Het interessante hier was dat ik te maken kreeg met een Ghost CMS compatibility issue - een theme update had sommige templates gebroken. Dit leidde tot een Ghost update en het zoeken naar een geschikt journal theme. Een goede reminder dat dependency management zich uitstrekt tot CMS platforms en themes.
Containerization Strategy: Source vs NuGet
Een significante architecturale beslissing deze week betrof onze package distribution strategy. Na uitvoerig overleg met mijn mentor werd besloten om af te stappen van een NuGet-based approach in Docker containers ten gunste van een source-code gebaseerde build.
Dit had verschillende technische implicaties:
Transitieve dependencies werden eenvoudiger te beheren
Version conflicts kwamen minder voor
Build reproducibility verbeterde significant
Container size nam wel toe door de volledige source tree
Het refactoring proces was intensief - via Beyond Compare 5 moest ik zorgvuldig bepalen welke projecten daadwerkelijk nodig waren voor de solution. Elke build cycle onthulde weer nieuwe missing dependencies, wat een iteratief debug proces vereiste.
Command Worker Containerization
Het tweede grote Docker project was de Command Worker service. Dit was uitdagender dan verwacht door verschillende target framework incompatibiliteiten tussen NuGet packages en lokale projecten.
Een cruciaal inzicht was dat andere developers deze problemen niet ondervonden omdat zij via source builds werkten, waarbij de externe source code mee in de solution zat. NuGet packages daarentegen dwingen strikte version compatibility af, wat subtiele problemen kan blootleggen die anders onopgemerkt blijven.
Het MSBuild SolutionDir variabele probleem kwam opnieuw naar boven, wat ik oploste door de waarde hard-coded mee te geven in de publish step. Niet de elegantste oplossing, maar wel pragmatisch en effectief.
Nginx vs Python Static File Serving
Een interessante architecturale discussie ontstond rond static file serving voor onze Blazor client. Mijn eerste implementatie gebruikte Python als workaround, maar dit was suboptimaal voor performance en best practices.
De terugkeer naar Nginx als reverse proxy was de juiste keuze.
Nginx is specifiek ontworpen voor dit type workload en biedt:
Superior performance voor static content
Built-in caching mechanisms
Proper HTTP headers voor browser caching
Production-ready configuratie opties
Technical Learnings: Docker Volumes en Mounting
Een praktisch inzicht deze week was het verschil tussen Docker volumes en bind mounts. Voor de ArangoDB configuratie switchte ik van named volumes naar bind mounts, wat directe toegang geeft tot database files op de host machine.
Het mounting principe in Docker - van host naar container - lijkt simpel maar heeft belangrijke implicaties voor data persistence en debugging. Zonder een proper docker cp strategy kan data extraction complex worden.
Beyond Technical: Daadkracht en Persoonlijke Groei
Een memorabel moment deze week was het gesprek met mijn mentor over "daadkracht" - de kunst van plannen omzetten in actie. Dit kwam naar boven toen ik mijn interesse uitsprak in lange wandeltochten zoals de Camino de Santiago.
Zijn advies was direct en waardevol: "Doe het, laat het niet bij woorden." Deze mentaliteit - van planning naar execution - is even relevant in software development als in persoonlijke groei.
Project Completion: Attention to Detail
Het afronden van het Docker project vereiste verschillende kleine maar belangrijke refinements:
Service naming consistency across alle componenten
Mount configurations optimization voor verschillende services
Folder structures die logisch en maintainable zijn
Named volumes conversie naar bind mounts waar appropriate
Deze "finishing touches" lijken misschien trivial, maar ze maken het verschil tussen een werkende proof-of-concept en een production-ready solution.
Reflectie: Van Problem Solving naar Solution Architecture
Deze week illustreerde mooi de evolutie van junior naar medior developer skills/mindset. Waar ik eerder focuste op individuele problemen oplossen, ben ik nu meer bezig met system-wide implications en architectural decisions.
Het SSL debugging was niet alleen een technical fix, maar leidde tot een beter begrip van container networking. De Ghost CMS update was niet alleen een compatibility fix, maar een les in dependency management. De Docker source code strategy was niet alleen een build optimization, maar een fundamental architectural decision.
Deze holistische manier van denken - waar elk technical decision wordt bezien in de context van het gehele systeem - is precies wat ervaren software engineers onderscheidt van beginners.