De rol van user stories
Wie The Art of Agile Development van James Shore doorbladert, doet heel nieuwe opzichten op. Zijn hoofdstuk over stories (ook wel bekend als user stories) deed me wel opveren, in elk geval. Shores stelling - mening? inzicht? - is provocatief: een story moet op een index card passen. de volledige story zou dus uit niet meer dan een zin of een kreet hoeven bestaan.
Hoe machines leren
Met de opkomst van kunstmatige intelligentie en Machine Learning, verschijnen er ook steeds meer toolkits voor softwareontwikkelaars om met deze technieken aan de slag te gaan. Deze bieden handvaten waardoor ontwikkelaars op een laagdrempelige manier kennis kunnen maken met deze techniek. Zulke toolkits schermen echter - met goede reden! - veel van de achterliggende complexiteit af voor hun gebruikers. Ontwikkelaars die zich daarin willen verdiepen, zouden zich kunnen wagen aan Hui Jiangs Machine Learning Fundamentals: A Concise Introduction.
Het probleem met cookbooks
Ik zeg het maar eerlijk, ik lees niet graag cookbooks. Dat ligt voor een deel aan mij, natuurlijk. Ik lees boeken namelijk het liefst van kaft tot kaft. En daar zijn cookbooks simpelweg niet voor bedoeld. Ze fungeren eerder als referentiemateriaal. Je hoort ze uit de kast te trekken wanneer je tegen een bepaald probleem aanloopt. Het probleem is: je hebt pas een goed idee wat erin staat als je het boek gelezen hebt. Hoe weet je anders waar je moet kijken?
De leercurve van Angulartests beklimmen - deel 4
Wat is de kern van ons onderhoudprobleem? Codeduplicatie - of liever: de duplicatie van informatie. Het opzetten van een bepaalde service en haar afhankelijkheden gebeurt voor elke (reeks) test(en) handmatig in de beforeEach-methode. Als dezelfde afhankelijkheid in twee verschillende reeks testen voorkomt, moet de ontwikkelaar deze twee keer uitschrijven. Maar is dat nu echt nodig?
Twee gedichten over liefde en code
Sinds een dag of twee, / vlinders in mijn code.
De leercurve van Angulartests beklimmen - deel 3
Hoe onderhoudbaar was onze testopzet? Onze services verwachtte niet één afhankelijkheid, maar wel vijf of zes of zeven - en soms zelfs meer. En die afhankelijkheden verwachtten op hun beurt ook weer vijf, zes, zeven afhankelijkheden. Het was niet ondenkbaar dat een ontwikkelaar langer bezig zou zijn met het opzetten van al die afhankelijkheden om zijn test te laten compileren, dan het daadwerkelijk verifiëren van het gedrag van het stukje code waar hij in was geïnteresseerd.
Een reflectie op communicatiestijlen
Elk mens is uniek, maar laten we niet overdrijven. Het menselijk vermogen te generaliseren wint het met gemak van de uniciteit van het individu - dat is waar stereotypen vandaan komen. En stereotypen hebben hun functie. Ze geven ons handvaten in de omgang met individuen, in het bijzonder wanneer hun stereotype anders is dan het onze.
De leercurve van Angulartests beklimmen - deel 2
In een vorige blog beschreef ik de keuze van mijn team om de front end van onze Angular-applicatie te testen via end to end-tests - en waarom we daar uiteindelijk op terugkwamen. Nu we besloten hadden inderdaad te willen (nee, moeten) unit testen, doemde er een nieuwe keuze op in de beslisboom: gaan we ons in het zweet werken om Angulars steile leercurve te beklimmen, of bekijken we of er een manier is waarop we het testen voor ons kunnen vergemakkelijken?
Hoe droog wil je je test hebben?
Ik heb in het verleden over droger tests geschreven, want ik ben een softwareontwikkelaar en wij herhalen onszelf niet graag. En precies daarom ga ik het nóg een keer over droger tests hebben - of liever: minder droge tests. Want, anders dan je als naïeve ontwikkelaar zou verwachten, gelden er voor productiecode en testcode andere regels wat betreft de mate waarin herhaling tolerabel of zelfs wenselijk is.
De leercurve van Angulartests beklimmen - deel 1
Niet lang nadat we Angular als front end-framework besloten te gebruiken, maakten we de keuze de unit tests te laten voor wat het was. We waren heus wel overtuigd van het belang ervan, dat was het probleem niet, maar de stijle leercurve van Angulars tests verleidde ons daar niet naar te handelen. Toch lieten we het testen van de front end niet helemaal schieten. Onze tester had zich verdiept in end to end testframework Selenium, en het team wilde graag geloven dat dit een acceptabel alternatief was voor het schrijven van front end tests. Maar uiteindelijk dwong de werkelijkheid ons toch die beslissing te herzien.