Wil je beginnen met leren? Hieronder een reeks links voor opties in verschillende programmeertalen.
Eerder schreef ik al wat over technische schuld. Het niet hebben van automatische tests wordt vaak beschouwd als een technische schuld.
Testen doe je om er zeker van te zijn dat iets werkt dat het goed werkt. Automatische testen maak je (of laat je maken) omdat zeker weten dat het goed werkt veel tijd kost. Wanneer je applicatie vaak nog wordt veranderd wil je er immers ook zeker van zijn dat het ook blijft werken. Automatische tests zijn kleine programmaatjes die testen of onderdelen onafhankelijk (unit-tests) of in samenhang (integratie-tests) goed werken.
Bij unit-testen worden kleine onderdelen afzonderlijk bekeken of ze nog werken. Zo kan bijvoorbeeld steeds worden gecontroleerd of de bedragen in een offerte wel nog steeds netjes worden opgeteld, en een andere of er nog wel het verwachtte btw bedrag uit blijft komen.
Bij integratie-toetsen, of syst…
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.
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 …
Twee weken geleden was ik op een meetup van ruby-programmeurs in Utrecht (Utrecht.rb). Een spreker was Martina Šimičić (@pazinjanka). Ze stelde voor om het woord te verspreiden dat de mensen daar allemaal al vonden: dat programmeren gewoon leuk is (en dus niet alleen iets is voor bepuiste jongens met pizza dozen in onverzorgde kantoren (ook een cliché natuurlijk)). Duss….
Programmeren is leuk! Reactie volgt bijna direct op actie. Je typt iets, en er ontstaat iets. Typ iets meer en je laat een systeem voor je werken. Typ nog meer en je kunt een systeem voor meerdere mensen laten werken. Er wordt steeds meer geautomatiseerd, en jij het feit dat je daaraan ook richting kunt geven: dat is toch gaaf?
Natuurlijk kun je alles dat geprogrammeerd is ontvluchten. Soms heb ik die neiging ook wel, lekker do…
"Niet slim." zei onlangs een potentiële klant tegen mij toen ik hem vertelde dat ze de code natuurlijk gewoon mochten hebben. Zodat ze er zelf bijvoorbeeld verder mee zouden kunnen gaan.
Ach, het is maar hoe je het wilt zien. Ik vertrouw er op dat ik kwaliteit lever, en dat die kwaliteit bijdraagt aan het bedrijf. Doe ik dat niet langer en denkt het bedrijf het zelf beter te kunnen dan laat ik ze liever gewoon doorwerken met de code die ik uiteindelijk ook deels voor hen heb geschreven1. Frustreren is kinderachtig.
"Maar, Bill Gates is er rijk mee geworden!" Wel ja, ik word dan zo misschien niet in staat gesteld om een fonds op te richten dat probeert bepaalde ziektes de derde wereld landen uit te krijgen, maar om nou te zeggen dat ik verlegen zit om werk… Wanneer ik computercode schrijf, dan schrijf ik dat in de overtuiging dat ik het niet weer zou moeten hoeven te doen. En wat is er mooier dan dat iemand…
“Dat's de bom man.” op een luchthaven zeggen kan waarschijnlijk ook tot problemen leiden. Toch is het, mogelijk alweer achterhaalde, opmerking die positief bedoeld is. En zo is hacken ook een positieve bezigheid, alleen…
Onlangs floepte er bij mij in net de verkeerde context het volgende eruit: “Ik heb wel een beetje een hack mentaliteit”. Ik was op kennismakingsgesprek voor een nieuwe opdracht bij een bank. Aj. In de IT wereld wordt hacking als iets positiefs gezien: schouders er onder, niets is onmogelijk, kijk maar… En als het niet kan zoals we van plan waren, dan lossen we het wel net iets anders op.
In plaats van te zuchten en kreunen over hoe de ideale werkelijkheid - die toch niet bestaat - er uit zou moeten zien probeert een hacker met zo min mogelijk moeite de bestaande systemen zodanig aan te passen dat het doel behaald wordt1. Niet alles eerst proberen te bedenken vanuit dat perfecte ideaal om er vervolgens achter te komen dat dit toch niet werkt of nog ma…
Scrum is hot. Niet alleen als trend. Het is heftig voor iedereen. Intensief. En continue blijven leren. Zo heb ik sinds gisteren ook weer veel geleerd en inzichten erbij.Gisteren een NL Scrum meeting bijgewoond. Onderwerp dit keer was UX en scrum (een zogenaamde agile ontwikkelmethode). Erg interessant. Veel typische misstanden kwamen naar boven (volgens mij ook niet onbekend bij bij traditionelere ontwikkelmethoden): De business mensen zitten wel aan tafel als stakeholder, maar de eindgebruikers zijn voor de bouwers vaak onzichtbaar. Gelukkig kost testen weinig tijd en daarom is tijd ook geen excuus om niet met gebruikers te testen (tot zover de samenvatting van Joris Ketelaar’s presentatie van UserIntelligence). Naast testen met gebruikers is ontwerp voor gebruikers natuurlijk belangrijk. Doe je dat vooraf (soms is design gewoon een eindproduct), in een design sprint voor de productie sprint, of als übersscrum; tegelijkertijd? (een belangrijk thema in het verhaal van Patrick, Fabr…
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .