Is kunstmatige intelligentie wel écht intelligent?
Kunstmatige intelligentie (ook wel artificiële intelligentie of kortweg AI genoemd) heeft de laatste jaren een enorme opmars gemaakt. AI neemt een steeds prominentere plek in in het dagelijks leven: van vertaalmachines tot gepersonaliseerde advertenties tot gerobotiseerde obers. Hoog tijd dus om filosofisch op dit fenomeen te reflecteren. Wat is AI? Kunnen computers echt denken? Wat is denken überhaupt? En wat zijn de ethische en politieke implicaties van de steeds grotere rol die AI in de samenleving speelt? Deze en andere vragen komen aan bod in Guido van der Knaaps Van Aristoteles tot algoritme: Filosofie van kunstmatige intelligentie.
Testen via de voordeur
Het ideaal van Test-Driven Development is dit: al coderend breid je je testsuite uit, zonder ooit één test te hoeven herschrijven. Het toevoegen van nieuwe functionaliteit gebeurt op zijn best binnen de kaders van een bestaande API. Op zijn slechtst leidt het tot uitbreidingen daarvan - meer niet. Er is, denk ik, een manier om dichter bij dat ideaal te komen. Dat ideaal bereik je door te testen via de voordeur. Dat houdt kort gezegd in dat je je logica idealiter test via dezelfde route als een gebruiker van je code.
Mijn eerste testgedreven stapjes
Na niet één, niet twee, niet drie, niet vier, maar vijf blogs over Test-Driven Development had ik ervoor nodig, voordat ik het aandurfde. Maar nu is het dan eindelijk zover: onlangs heb ik de eerste testgedreven stapjes gezet in mijn professionele carrière. Een mijlpaal!
Fietsen met tegenwind
Een tijd geleden schreef ik over leren in je codebase. In die blog zette ik uiteen waarom het mijns inziens geen goed idee is om je zelfstudieproject te koppelen aan de productiecode waar je team aan sleutelt. Er is nog een reden waarom je je leerproject verre moet houden van productiecode. - En die reden is dezelfde reden als waarom je niet anderhalf uur naar je werk moet willen fietsen om je buikje weg te werken en/of je hoofd leeg te maken. Als ik die reden in één woord moet vangen, dan is het: druk.
Wat is de O in SOLID nog waard?
Een ontwikkelaar die eens code schrijft en deze nooit meer aan denkt te hoeven passen, is een ontwikkelaar die rot in zijn applicatie verwelkomt. Een al te strikte naleving van het Open-closed principe (OCP) getuigt van een ronduit onverantwoorde houding - in elk geval binnen de context van Agile ontwikkeling. Waar komt de aantrekkingskracht van het OCP dan vandaan?
De Standup is geen statusmeeting
In The Art of Agile Development van James Shore kwam ik een zinsnede tegen die me deed opveren: de Daily Standup (ook wel Daily Scrum genoemd) is geen statusmeeting. - Laten we kijken wat dat betekent.
Heb je die setter echt nodig?
"prop" + tab + tab - welke C#-ontwikkelaar maakt niet bijna dagelijks dankbaar gebruik van dat code snippet om zijn ontwikkelsnelheid te verhogen? Standaard properties zijn zo alomtegenwoordig in de wereld van objectgeoriënteerd programmeren in het algemeen - en C# in het bijzonder - dat je er haast niet meer bij stilstaat dat het ook anders kan. Maar dat het ook anders kan, leerde ik dankzij Spencer Schneidenbach, in een uitstekende lezing over immutability (onveranderlijkheid).
Tip: log uit
Ik heb een soort van ochtendritueeltje als ik mijn laptop aan het begin van de dag opstart. Ik check mijn mail, mijn Facebook, LinkedIn, bekijk de bezoekersaantallen van deze website - en open dan Microsoft Teams om te zien wat ik allemaal gemist heb sinds gisteren. Het is een kwartiertje opstarttijd, een soort-van-rust-momentje voordat ik aan de dagelijkse arbeid begin. Sinds kort voeg ik daar een extra handeling aan toe: ik log uit.
Leren in je codebase
Laatst had ik een gesprek met een collega van me, over een meningsverschil dat hij had met onze leidinggevende over zijn zelfstudieproject. Hij wilde zijn handen vuil maken - dat is hoe hij het liefst leert -, niet in een klein, losstaand codeproject, maar in een branch van onze productiecodebase. Onze leidinggevende vond dat, tot frustratie van mijn collega, een slecht idee. - Daar was ik het, eerlijk gezegd, wel mee eens.
Incidentanalyse zonder schuldigen
Wat doet jouw team na een productieverstoring? En wat doet jouw team als een eindgebruiker een bug meldt? - Wat bij een grote bug? Wat bij een kleine? Neem je het ter kennisgeving aan, en ga je op dezelfde weg door? Ga je met vingers wijzen en mensen uitfoeteren voor hun nalatigheid? Of kijk je naar manieren waarop je de productieverstoring of bug in de toekomst kunt voorkomen? En waar kijk je dan naar - naar het individu, of het systeem?