A developer’s status update: Test driven deadlock

No worries, I do value testing. But test driven? It depends.

The last few weeks I’ve been working off and on building a crawler. The thing triggers a series of scheduled tasks that could run in parallel, generating (possibly) tasks (that are consequently scheduled again in their own task-specific queue) on its own and so on. The end goal is structured copies of external resources (read: webpages). But I’ve been stuck close to the start for quite a while, setting up the base architecture using the test driven development approach. And I’m failing, it’s going too slow :(

Small victories

Like many developers, this is not my first parser/crawler. But this time I wanted to make a GoodParser™. Make it more extensible, and flexible and foremost robust, building in fault-tolerance from start. But I’m not getting near the end result and it is frustrating.

The TDD-school says make small victories, and oh yes, I had my sheer number of victories already. But the end is nowher…

Ga verder met lezen en/of reageer...

Op de hoogte blijven?

Maandelijks maak ik een selectie artikelen en zorg ik voor wat extra context bij de meer technische stukken. Schrijf je hieronder in:

Mailfrequentie = 1x per maand. Je privacy wordt serieus genomen: de mailinglijst bestaat alleen op onze servers.

Technische schuld

Een artikel, ongeveer 7 jaren geleden geplaatst onder technical debt, schuld, techniek, programmeren, rspec, test, testing, stabiliteit & software.

De software wereld zit vol met Engelse begrippen. “Technical Debt” is ook zo’n begrip. Maar wat is het?

Een dag geleden zag ik dit bericht waarin Technical Debt werd vergeleken met een continue slecht gestapeld Tetris spel. Een rake vergelijking: als je niet oppast wordt de technische structuur van een applicatie een stapeling op zichzelf oplosbare problemen, maar vormt het in z’n geheel een nagenoeg niet te redden constructie.

Maar waar hebben we het dan over?

Technische schuld wijkt af van financiële schuld. Om financiële schuld te maken moet je geld lenen van een ander. Technische schuld ontstaat doordat er geen tijd wordt gestoken in het goed op orde maken van de techniek. Zo is het een goede gewoonte om kritische zaken en/of zaken die erg foutgevoelig zijn in de applicatie te voorzien van automatische tests (“kan die rol wel/niet bij die gegevens?”, “gaat het ook goed als hier een negatief getal …

Ga verder met lezen en/of reageer...

Computer says yes

Een artikel, meer 11 jaar geleden geplaatst onder test, programming, fail, software, structure, testen, computer, little britain, computer says no, controle & unittesting.

Al weer 7 jaar geleden liet Robert Dijkgraaf in Zomergasten zien hoe alles weer uit van alles bestaat. Kleine onderdelen die samen weer grotere gehelen vormen die samen weer nog grotere gehelen vormen en zo verder, en terug. Hij illustreerde dit aan de hand van een alweer 30 jaar oud filmpje: powers of 10.

Powers of 10: Van 100 tot 1024 naar 10-14

Op hun eigen schaal lijken alle onderdelen waaruit iets bestaat weer mooie afgeronde dingen. En op een afstand lijken al deze onderdelen ook nog eens perfect samen te hangen.

Integrated Circuit (public domain image)

Ook in ontworpen zaken zie je dergelijke herhaling en samenhang. Een chip lijkt in detail wel een metropool. En de printplaat waarop deze bevestigd zit eveneens. En in een echte metropool bevinden zi…

Ga verder met lezen en/of reageer...

Het concept achter de hypes

Ontwikkelingen gaan te snel om allemaal bij te houden, dat is wat blogs en tijdschriften je graag willen vertellen. Daarom móet je hen ook volgen. Als je alle nieuwe media trends en technieken echter wilt kennen heb je geen tijd meer over om echte dingen te maken. Geen tijd meer om plezier te beleven aan het bouwen van iets, noch tijd om er aan te verdienen.

Gelukkig zitten er achter veel hypes vaak dezelfde concepten die voortborduren op jaren lopende trends. En die zijn best wel te volgen. Zo stuitte ik onlangs op een artikeltje dat ik negen jaar geleden had geschreven over webstandaarden. En in de basis klopt nog steeds (hoewel we ons nu niet meer druk hoeven te maken over Netscape 4.x). Wanneer je over andere soorten displays (waaronder auditieve) nadacht, dan kon je al weten dat Flash en pixelperfect design nooit duurzaam kunnen zijn, en op den duur vervangen moeten worden (‘hypes’ die het goed doen zijn nu responsive design, …

Ga verder met lezen en/of reageer...

Testen en evalueren.

Evalueren of iets werkt, of testen we of iets werkt? Als u er niet bij stil staat zou staan dan zou u mogelijk denken dat het twee keer dezelfde vraag is…

Afnemers evalueren

Een klant test niet of iets dit of dat doet, die probeert het uit. Een klant vraagt zich niet alleen af of een bepaalt soort functionaliteit voldoet aan de specificatie, maar vraagt zich ook af of dit goed werkt. Of het goed werkt voor hem of haar persoonlijk. Voldoet het aan de verwachtingen? En vraagt zich op zijn of haar beurt weer af of zijn of haar klanten er (minimaal) tevreden mee kunnen zijn.

Testen is te beperkt voor klantgerichtheid

Het fijne van testen is dat er een test geschreven kan worden voor dat de functionaliteit bestaat. Het mooie hiervan is dat er een objectieve manier bestaat om te bepalen of iets voldoet aan de test of niet: de testcriteria. Slagen de tests met een voldoende, dan is het product - volgens de test - af.

Maar vaak strubbelen klanten dan nog tegen. Wa…

Ga verder met lezen en/of reageer...

murb blog