In blogpost issue 1a kun je lezen wat het probleem was (kort gezegd, bij het invoeren van een macro kreeg je een stuk HTML in je editor, na het opslaan werden er extra lege regels toegevoegd - wat je niet wilt). Ik had het probleem "al opgelost".
Tenminste, ik had zelf een kort stukje tekst en plakte daar de macro onder. Mijn script haalde netjes de extra regels weg, klaar. Maar dat is geen volledig test. Want vervolgens testte ik het door de macro helemaal vooraan te plaatsen, dus voor mijn tekst. Dat ging helemaal fout. Er kwam ongeldige HTML in de tinyMCE editor, dat werd opgeslagen en vervolgens kon ik de pagina niet meer bewerken, want de tinyMCE editor bleef laden/hangen, alle javascript in de backoffice werkte niet meer. Dus met deze "simpele fix" had ik ervoor gezorgd dat een pagina eigenlijk volledig "kapot" was. Als iemand die pagina opgebouwd heeft uit 100-en componenten en dat allemaal opnieuw moet doen, dan kun je beter met het handje die 2 extra lege regels verwijderen want nu kun je die pagina alleen nog maar verwijderen. Of je moet in de database hacken. Want je kon ook niet eens meer naar het tabblad om een vorige versie terug te zetten, het javascript op de pagina werd volledig unresponsive!
Hierna heb ik ook nog een test gedaan door een macro in te voegen, een stuk tekst toe te voegen, daaronder weer een macro toe te voegen, daaronder nog een stuk tekst en daaronder nog een macro. Als je een lijst met bepaalde artikelen toont is het aannemelijk dat een klant het echt zo gaat gebruiken. Ook dat liep in de soep. Je zag het onderste blok naar boven schuiven, daar werd ineens tekst verwijderd en het leek erop alsof er nog steeds een save-actie - patch-actie - save-actie - patch-actie door bleef lopen. En de volgende dag nog getest met een tekst waarbij de onderste tekst vet en italic was. Een enter voor een nieuwe regel om daar de macro in te voeren, maar de tekst bleef vet en italic. Dat via de knoppen uitgeschakeld. Maar je raadt het al: daardoor kwamen de eind-tags (</i></strong>) in die "lege" paragraaf te staan. Als ik de macro daar invoeg en het script de boel gaat opschonen, worden mogelijk die eind-tags weer verwijderd, waardoor tekst na de ingevoegde HTML van de macro ineens vet en italic worden!
En daar zijn we dan. Ik had gehoopt om dit "even" in een weekend op te lossen, als je de code bekijkt denk je: "had je daar nu zoveel uren voor nodig?", maar dan mis je dus de relevante uitleg waardoor dat gekomen is. Eerst doordat je moet zoeken wat een "goede manier" is om je javascriptcode op te bouwen. Daarna alle problemen die je tegenkomt (waarbij je hier dus een paar voorbeelden hebt kunnen lezen).
Mocht je ontwikkelaar zijn en een klant hebben die klaagt over de factuur die hij/zij moet betalen "waarom kost dit zoveel?", "waarom hebben jullie hier zoveel tijd aan besteedt", deel dan dit artikel met hem/haar en raadt aan om dit eens goed door te lezen. Want ik heb dit in eigen tijd uitgezocht voor mijn collega, maar deze vraag had ook van een klant kunnen komen. De vraag zou waarschijnlijk geweest zijn: "Als ik een macro uitvoer, komen er 2 extra regels om dat blok heen. Kunnen jullie 'even' zorgen dat die 2 regels weggehaald worden?". Zou mijn uurtarief 100 euro zijn, dan was het antwoord geweest (als we dit op basis van nacalculatie gedaan hadden), dat zijn dan 8 uren a 100 euro, graag 800 euro binnen 21 dagen te voldoen op rekeningnummer xx....
Je werkt niet altijd op basis van nacalculatie. Je krijgt van tevoren de vraag: "hoe lang gaat dit duren?". Moeilijk te beantwoorden als je iets moet bouwen wat je nog nooit eerder gedaan hebt. En dat komt best vaak voor. Als developer kijk je ook vaak alleen naar "het bouwen". Had je dit van tevoren moeten inschatten, dan had je het mogelijk op 2 tot 3 uur gehouden. Een beetje een goede projectmanager zet de verdubbelaar in en verkoopt het voor 4 tot 6 uur, met documentatie/correspondentie/overleg opgehoogd naar 8 uren.
Dan hadden we nu "kiet" gespeeld. Alleen... we zijn er nog niet.
Testen
Ik heb hier boven al genoemd dat ik tijdens het ontwikkelen eigenlijk steeds dezelfde handeling uitgevoerd heb, tot het werkte. Voor sommige developers is dat het punt om te stoppen en te zeggen: "het is klaar". Dat is onervarenheid (net afgestudeerd en nog niet bij projecten zo vaak je hoofd gestoten dat je weet: hier moet ik meer controles gaan uitvoeren, want als je in de code alleen maar linksom kunt gaan, krijgen klanten het voor elkaar om rechtsom, van boven, van onderen en ook alle diagonale routes te nemen), dat is doordat de developer bedolven wordt onder het werk (er staan nog 20 projecten te wachten die vorige week al afgerond hadden moeten worden, ik heb er echt geen tijd voor...) of "het zo wel goed vinden" (het werkt toch?).
In dat laatste geval: kijk nog eens goed. Recent op het werk een issue waarbij een HTTP url vervangen werd met een HTTPS url (prima), maar ook een HTTPS url vervangen met een HTTPSS url (neee!). Had er in die oplossing ook een testproject gezeten waarbij een HTTP en een HTTPS test uitgevoerd werd, dan was de test gefaald en had je voordat de code ingecheckt was dit probleem al opgelost. Het is altijd de vraag "is het de moeite waard om allemaal testen te bouwen voor dat kleine stukje code"? Dat is inderdaad niet altijd zo. Maar in dit geval (mijn javascript) dus wel, omdat ik heb laten zien dat bij een foutieve verwerking ik kan zorgen dat teksten verdwijnen en ook dat er ongeldige HTML ontstaat die opgeslagen kan worden en de pagina volledig onbruikbaar maakt. Met zulke potentiële ellende wil je testen hebben om dat uit te kunnen sluiten. Ook omdat ik de code mogelijk nog wil aanpassen. Maar dan wil je ook zeker weten dat door die aanpassingen niet vervolgens de boel die eerst wel goed werkte alsnog kapot gaat.
Als ik nu moet schatten wat dit aan tijd gaat kosten, reken er nog maar 8 uur extra bij.
Want ik moet nu elke keer Umbraco opstarten, inloggen, naar een pagina gaan, daar mijn acties uitvoeren. Een "normale" unit-test van C#-code kun je "gewoon" in Visual Studio uitvoeren en scheelt dus die opstarttijd. Dit is een beetje front-end testen, dan denk je al gauw aan Microsoft Playwright, maar eigenlijk wil ik alleen maar het javascript testen. Is er niet een andere manier om dat te testen? Ik ga dus eerst op zoek naar iets wat mij daarbij kan helpen.
- V8 JavaScript engine
In Hanselminutes aflevering 160 kwam de v8 JavaScript engine van Google voorbij, te vinden op v8.dev. Dit was een aflevering van 2009, maar zo te zien (artikelen van 2024) blijft de boel actueel. Op de site wordt gezegd dat v8 open-source is, ik zag geen rechtstreekse link, maar dat komt omdat je via de documentation-pagina de stappen moet doorlopen, dan kom je er wel. Ook via de tools kom ik op Github en vervolgens op de repository van v8. Dit is "cool spul", maar niet de oplossing voor wat ik wil. Het is allemaal C++, is er niet iets voor .NET?
- Jurassic
In Hanselminutes aflevering 277 wordt Jurassic genoemd (github-repository). Ik heb een xUnit testproject aangemaakt en daar via de nuget-packages gezocht op Jurassic. En ja, in de lijst staat versie 3.2.8 van 22 november 2024, redelijk recent.
Zo te zien kan ik daar inderdaad wel wat mee! Ik zal mijn code moeten ombouwen, zodat ik een soort "Parser-class" krijg die het werk doet, daarmee kan ik mijn test-scenario's opzetten.
Dat is gelukt en daarmee heb ik versie 0.1 op mijn Github-repo online gezet. Met een disclaimer dat er nog foutieve acties uitgevoerd kunnen worden. Ik kom later nog met een artikel over Jurassic, want deze tool heeft me erg goed geholpen!
Security
Nadat je alles eerst "gebouwd" hebt, daarna "getest" en daarbij code aangepast hebt hoop je toch echt klaar te zijn. Helaas, want hoe zit het met "security"? Waarschijnlijk niet het eerste waar je hier aan gedacht hebt, want je zit te stressen om wat af te krijgen en je bent blij dat je eindelijk resultaat hebt. En je wilt eigenlijk alweer verder met je volgende coole project wat ligt te wachten. Als je developer bent is security eigenlijk het item waar je de meeste aandacht aan moet geven. Want als je iets niet goed gebouwd hebt, via-via kan je code gemanipuleerd worden, dan heb je de poppen aan het dansen. Die redirect-module van Wordpress die gemanipuleerd kon worden, waardoor als mensen naar jouw website gingen doorgestuurd werden naar sites met malware... dat wil je niet. Je hebt ook het risico dat er een andere plug-in komt die nuttig lijkt te zijn, maar die code uit mijn plug-in misbruikt om bepaalde acties uit te voeren. Nu ik een snelle blik op mijn code werp vermoed ik dat dit wel mogelijk is. Misschien kom ik daar ook nog in een los artikel op terug, om te laten zien hoe iets waarvan je denkt dat het "handig is", "het werkt" en "veilig is" wel degelijk gaten heeft die misbruikt kunnen worden.
In ieder geval, alpha versie 0.1 staat op mijn Github en mocht je denken dat je het zelf beter kunt, download de code en maak je eigen veilige versie!