Auteur: Danny Holstein

Wanneer een developer in zijn workflow zit, dan gaat het ontwikkelen van applicaties vaak soepel en voortvarend, waarbij complexe problemen en vraagstukken snel en effectief worden opgelost. Maar op sommige dagen doen zich allerlei problemen en andere issues voor. In dit nieuwe Developer Dagboek worden een aantal complexe problemen en andere stekeligheden behandeld.

Omdat wij in de logbestanden hebben gezien dat dit weblog regelmatig werd bestookt door bots op het Internet, is er besloten om de beveiliging op te hogen en tegenmaatregelen te nemen. Voor WordPress zijn er vele plug-ins die de beveiliging op een relatief eenvoudige manier verbeteren. Voordeel is verder dat deze plug-ins actief worden onderhouden en makkelijk zijn te installeren. Door mij zijn een drietal plug-ins geïnstalleerd en geactiveerd en dit weblog leek daarna nog steeds naar behoren te werken.

Een maand later was het bij mij alweer weggezakt dat ik plug-ins had geïnstalleerd om de beveiliging van dit weblog te verbeteren. Een nogal vreemd probleem deed zich voor tijdens het opslaan van concepten tijdens het schrijven van het vorige weblog. Onder normale omstandigheden verschijnt er een bericht dat het concept is opgeslagen, maar de vorige keer verwees de concept knop door naar WordPress’ standaard Block-editor (Gutenberg). Helaas was de opgemaakte tekst weg, maar de afbeeldingen en de tags waren wel opgeslagen. De vraag was: wat ging er hier fout?

Onder het oppervlak was er toch iets fout gegaan tijdens het installeren van de plug-ins. De oorzaak was dat bepaalde plug-ins, waaronder de Classic Editor Plugin, gedeactiveerd wordt in ‘safe mode’ wanneer er plug-ins worden geïnstalleerd die betrekking hebben op de beveiliging. Dit alles is in ‘stille modus’ gebeurd zonder dat er een melding over is verschenen. Na het opnieuw activeren van de Classic Editor Plugin werkte de knop om concepten op te slaan weer naar behoren. Het hierboven beschreven probleem is overigens een bekend conflict en er is een groot verschil tussen de Classic Editor (maakt gebruik van PHP en POST-requests om zaken op te slaan) en de Gutenberg editor (JavaScript, gebruikt een REST API). Beide editors maken wel van dezelfde route gebruik om afbeeldingen en tags op te slaan, dus dat was de reden waarom dit wel was opgeslagen.

Voor verschillende projecten zijn Dockerfiles te hergebruiken voor zowel de frontend als de backend. In grote lijnen doet een Dockerfile het volgende: de image van een programmeertaal of andere applicatie wordt ge-pulled, de applicatie wordt gebouwd, bepaalde environment instellingen worden ingesteld en de applicatie wordt ge-deployed. Dit gaat in verreweg de meeste gevallen goed en fouten worden vaak duidelijk aangegeven en omschreven in het console.

Enige tijd geleden verscheen er echter een foutmelding die niet makkelijk was te duiden. De foutmelding gaf aan dat er een bepaald bestand niet gevonden kon worden. Alleen de naam van het pakket zei mij op dat moment helemaal niets. Het eerste wat is geprobeerd dat is om het pakket in het desbetreffende project te zoeken en te vinden. Het probleem was dat de library waar dit om ging niet te vinden was. Onder de motorkap bleek dit dan ook een dependency te zijn van een andere library.

Na lang zoeken ben ik er achter gekomen dat dit veroorzaakt werd door het schakelen tussen verschillende projecten. Hierbij werd een oudere versie van het bovengenoemde pakket gebruikt, terwijl de meeste projecten van BEE-2B een meer recente versie gebruiken. Het was een ‘mismatch’ tussen de verschillende versies van dit pakket en dit was op te lossen door in de project-bestanden expliciet de nieuwere versie op te geven. Toen deze regels waren opgenomen in het desbetreffende project, kon ik weer opgelucht ademhalen, want het maken van de Docker container slaagde toen weer wel.

Wanneer een Angular applicatie live in productiemodus gaat, dan wordt tijdens het maken van de Docker container de applicatie gebouwd. Dit bouwproces bestaat gewoonlijk uit: bundling (bundelen - er worden 4-5 JavaScript bestanden gemaakt), minification (minificatie - alle spaties en witruimtes in de code worden verwijderd), ‘uglification’ of 'mangling' (alle leesbare code wordt vervangen door een 2-3 karakterlange naam), 'dead code' eliminatie (alle ongebruikte code wordt verwijderd) en tree-shaking (niet gebruikte modules en of libraries worden verwijderd). Wat er overblijft zijn geoptimaliseerde en niet-leesbare JavaScript bestanden.

Om een Angular applicatie te kunnen monitoren is het raadzaam om Sentry/Glitchtip te gebruiken. Daar worden problemen met de applicatie gerapporteerd inclusief de stacktrace (het volgen van de reeks of geneste functies die aangeroepen worden). Enige tijd geleden was hier wel een herhalend patroon terug te zien, maar was de stacktrace weinig eenduidig. Gelukkig deden de problemen zich alleen voor in Safari browsers. Voor wie dacht dat browser incompatibiliteit iets van het verleden was, aangezien de browsers de afgelopen jaren meer naar elkaar zijn toegegroeid, kan snel uit de droom worden geholpen. De Safari browser heeft nog wel redelijk vaak zijn eigenaardigheden (waaronder met localStorage).

Nadat de verschillende logs, stacktraces en andere informatie met elkaar vergeleken was, werd langzaamaan de oorzaak van het probleem duidelijk. Een zwaar verouderde en niet meer onderhouden cookie-bar die gebruik maakt van jQuery was de oorzaak van de problemen. Tegenwoordig is het gebruik van jQuery niet meer nodig, aangezien native JavaScript nu vrijwel hetzelfde kan. De oplossing was om een wel onderhouden cookie-bar te installeren in het project, wat dan ook gedaan is. Toen dit probleem was opgelost, was ook de tijd weer met een aantal uren verstreken.

Zoals hierboven al is beschreven, worden er Dockerfiles gebruikt om projecten te bouwen en live te zetten. Het voordeel is dat Dockerfiles ook voor test-omgevingen zijn te maken, waar verschillende instellingen worden gebruikt. Door middel van een environment instelling – zie de afbeelding hieronder – is de omgeving in te stellen en wordt gewoonlijk automatisch het juiste appsettings bestand ingesteld. Voor de meeste projecten van BEE-2B werkt deze methode zoals verwacht. Maar voor een bepaald project bleef deze methode niet werken.

Hoewel er een typefout was gemaakt en het opgegeven appsettings bestand hoofdlettergevoelig is, loste dit het probleem niet op. In het console waren er fouten te zien dat het desbetreffende appsetttings bestand niet gevonden kon worden. Maar wanneer ik de Docker container van binnen inspecteerde was dit wel te zien. Een vervolgstap was om verschillende AI-tools te raadplegen en na verschillende aanpassingen kon het appsettings bestand wel worden gevonden. Echter deed zich een volgend probleem voor, want de applicatie wilde nu helemaal niet meer opstarten.

Na vervolgvragen aan de verschillende AI-tools werd dit probleem alleen maar merkwaardiger. Lokaal was het wel mogelijk om een Docker container te bouwen, werd er naar de juiste omgeving verwezen, was het juiste appsettings bestand ingesteld en werd de applicatie uitgevoerd zoals verwacht. Op verschillende plaatsen in de code zijn er door mij Console.WriteLine regels toegevoegd, die dit bevestigden. Andere Linux commando’s gaven ook aan dat de omgeving de juiste is (er is door mij vele malen het volgende commando gekopieerd en geplakt: env | grep ASPNETCORE). Op dat moment was ik naar mijn idee alweer veel te lang bezig met dit probleem. Om de applicatie wel up-and-running te krijgen, heb ik besloten om tijdelijk de gewenste instellingen in een ander appsettings bestand te kopiëren en te plakken, deze veranderingen te pushen, de applicatie te deployen en de veranderingen weer terug te draaien.

Uiteindelijk is het probleem opgelost. Niet alleen de benaming van het appsettings bestand is hoofdlettergevoelig, maar dit is ook het geval voor de benaming van de Dockerfile (zoals Dockerfile.test) in een Linux-omgeving. Frank heeft de applicatie met de correcte instellingen en de juiste Dockerfile up-and-running weten te krijgen. Verder zat er een subtiele fout in de connection-string van de database (het is aanbevolen om de verwijzing naar de Port apart te gebruiken). De applicatie zelf kon door middel van 2 regels extra code het juiste appsettings bestand vinden (zie de afbeelding hieronder). Dit issue geeft bovendien aan dat het beter is om iemand anders mee te laten kijken wanneer er al uren is geprobeerd om een probleem op te lossen.

Ondanks dat er af en toe zich problemen voordoen tijdens het ontwikkelen, begin ik vaak vrolijk aan de nieuwe dag om verder te werken. Het is discutabel in hoeverre een rommelig bureau of een rommelig bureaublad op de computer ‘een teken van een genie is’. Op mijn werklaptop is mijn bureaublad altijd wel rommelig, maar wel zo ingericht dat ik zaken bij wijze van spreken geblinddoekt terug kan vinden. Op een bepaalde ochtend echter was er blijkbaar een update geweest. Als developer wordt gebruik gemaakt van 2 schermen, want dat is makkelijker en effectiever, maar tijdens opstarten werden de iconen over 2 schermen door elkaar gehutseld en ook op elkaar gestapeld. Dit laatste was een irritant probleem, waarbij er iedere keer gezocht moest worden waar een bepaalde map, bestand of applicatie was te vinden op het bureaublad. De uiteindelijke oplossing was om DesktopOK te installeren, waarmee de iconen op het bureaublad zijn vast te pinnen.

Alweer een aantal maanden geleden ervaarde ik allerlei verbindingsproblemen, vooral met Slack. Het heeft mij de nodige irritatie bezorgd en tijd gekost om de oorzaak hiervan te achterhalen. Vele keren is het commando ‘ipconfig /flushdns’ en andere zaken geprobeerd, echter zonder resultaat. Om er lekker de vaart in te houden, maak ik geen gebruik van het draadloze netwerk, maar juist van kabels. Draadloze netwerken hebben als nadeel dat zij trager zijn door de overhead die meegestuurd wordt aan het dichtstbijzijnde modem/wifi-hotspot. Mijn werklaptop heeft echter geen ethernetpoort, dus maak ik gebruik van een usb-naar-ethernet switch. Het bleek zo te zijn dat deze oude (en goedkopere) switch voor alle problemen zorgde en aan het eind van zijn Latijn was. Na de aanschaf en aansluiting van een nieuwere en iets duurdere usb-naar-ethernet switch waren de verbindingsproblemen verholpen.