Elke ingenieur gebruikt tools en iedereen heeft zijn eigen
voorkeur. Vaak gebaseerd op dat wat er toevallig als eerste beschikbaar
kwam. Zo ook de ICT-ingenieur. Ook die gebruik tools, software-tools wel te
verstaan. En daar zijn er oneindig veel van; waardoor de keuze erg lastig
is. Veel handige tools worden niet gebruikt omdat ze onbekend zijn. In de
rubriek 'ToolView' worden maandelijks dergelijke handige tools
voorgesteld. Deze mini-reviews geven een eerste indruk.
Een belangrijke eis was dat alle info op exact één A4tje moest passen. Voor
de html-versie is dat wat lastiger, al heb ik dat getracht met mijn beste
opmaak trucks. De bijgevoegde originele pagina, in PDF-formaat, pas altijd
exact!
Dit is de eerste, oudste reeks. Ze verschenen maandelijks in
dePTSer, het huisblad van mijn toenmalige werkgever. Ze werden veel gelezen, zowel door
collega's als door (externe) relaties.
Zelf kan ik een duidelijke progressie in mijn schrijfstijl zien. Maar ook
het schrijven zelf ging steeds makelijker. Na ruim anderhalf jaar waren de
onderwerpen op en was ik toe aan wat zwaardere, langere artikelen; zie
AWBH.
Het doorgronden van grote hoeveelheden C-code is vaak lastig. Het zoeken naar functie-aanroepen, zeker als dat in tientallen files gebeurd, kan dan veel tijd kosten. Unix-programmeurs kunnen een heel eind komen met grep en dergelijke. Maar ook dat is te langzaam bij honderden directories of duizenden files. Voortdurend find'en en grep'en kost dan te veel tijd. Een tool als cscope kan die taak automatiseren. Het maakt zoeken naar C-symbolen, evenals het vinden van functie definities en aanroepen, gemakkelijk.
Een netwerk is een geweldige uitvinding; jammer dat het per definitie traag is. Als gebruiker bel je dan de helpdesk, als netwerkspecialist hoop je vaak maar dat het beter wordt. Dat is het nadeel van ICT: het is erg onzichtbaar. Soms zou je willen dat er meer te zien was. Zeker als het te traag is en jij moet zeggen waarom! Een tool als Ethereal (nu: Wireshark) geeft dat gewenste inzicht. Het 'snift' alle bits van een netwerk; herkent de protocollen en presenteert alle data netjes gelaagd.
Uit metingen blijkt dat een goede programmeur slechts één regel onjuiste code per scherm schrijft. En dat de meeste fouten triviale verschrijvingen zijn. Spel- of stijlfouten zou men kunnen zeggen. Het verbeteren van zo'n bug is dan secondewerk, tenminste nadat de fout gevonden is. Het probleem is dus niet het oplossen van de fout, maar het -liefst automatisch- vinden van elke fout. Een tool als 'SPlint' kan gezien worden als spellingchecker voor C, waarmee veel fouten automatisch gevonden kunnen worden.
Iedereen weet hoe belangrijk bomen zijn. Voor de informaticus zijn bomen echter
een bijzondere vorm van graven. Een boom heeft takken en bladeren. En knopen,
althans voor ICTers. Het lijkt wel natuurkunde maar toch is graventheorie
onderdeel van de wiskunde. Het zijn dan ook wiskundigen die 'graphviz'
geschreven hebben.
Waarbij het tool 'dot' heel snel inzicht kan geven in een complexe boom.
De meeste programma's bestaan uit functies, waarbij zo'n functie gezien kan worden als het kleinste en belangrijkste onderdeel van een programma. Veel belangrijke dan bijvoorbeeld een file of een coderegel. Het is daarom verbazend hoe weinig aandacht er is voor de relaties tussen functies. Elke programmeur weet hoe belangrijk 'callGraph', of 'invocatieboom' is. Maar slechts weinigen weten exact hoe functies elkaar aanroepen, zelfs in hun eigen code. Het tooltje cflow kan dit automatisch bepalen.
Testen, testen, alsmaar weer testen. Veel programmeurs kunnen er niet genoeg van krijgen. Hoewel, als klanten bugs vinden dan wordt gezegd dat er te weinig getest is. Dus wanneer is voldoende getest? Is daar een test voor. Ja! Zo’n test bestaat! Het tool ‘gcov’ kan tenminste meten of er noch onvoldoende getest is. Maar zijn meer mogelijkheden.
"Als een tester bugs moeten verwijderen" riep een collega ooit, "dan moet de programmeur ze eerst maken". Maar toch; 'debuggen' is werk voor de programmeur. En de debugger is, net als een editor, deel van zijn primaire gereedschap. Maar hoewel er heilige oorlogen gevoerd worden over 'vi', 'emacs' of 'MS-studio'; discussies over 'GDB' zijn er nooit. Iedereen lijkt het eens ...
Elke programmeur is ook schrijver. Althans de echte programmeur, niet de 'klick-and-go' hobbyist. Een echte programmeur schrijft, bij voorkeur pagina's vol code. Het schrijven van documentatie is echter minder populair. Maar dat laatste kunnen we oplossen ...
Soms start je zomaar een oorlog. Bijvoorbeeld door te vragen naar iemands favoriete editor! Eerst was er 'vi', de eerste visual editor. Toen kwam 'emacs' en nu is er 'eclipse'. Er zijn keuzes en dus is er strijd. Niet alleen onderling maar ook met fans van 'MS-Visual'. Daarom hier een objectief verslag van meer dan een editor.
XML en embedded programmeren lijken niet samen te gaan. Toch wordt XML in embedded omgevingen gebruikt, omdat je er gemakkelijk 'boom'-structuren mee kunt beschrijven. Het geeft structuur en flexibiliteit. Ook is het heel eenvoudig om een XML bestand om te schrijven naar een ander formaat. Dat kan met XSLTproc, waarmee je programmeert in XML!
Een programmeur schrijft geen nieuwe code; tenminste niet vaak. Veel vaker wordt bestaande code veranderd. Die veranderingen zijn geregeld belangrijker dan het resultaat. Er zijn dan ook vele programma's gemaakt om twee versies te kunnen 'diffen'. Wanneer code onderhouden wordt door derden, zoals bij opensource software, moeten we onze eigen veranderingen steeds opnieuw maken. Voor elke nieuwe versie opnieuw. Dit kan je automatiseren, met diff en patch. Met patch kun je uit de ene versie en 't verschil, de tweede versie maken!
Wie vindt 'debuggen' leuk? Niemand toch. Zou het niet fijn zijn als de computer dat zelf kan? Met 'askIgor' kan dat! Met 'Delta debugging' vergelijkt het een 'goede' en een 'foute' uitvoering van het te testen programma. Het doet dat telkens opnieuw en stap voor stap, totdat er een minimaal verschil is. Zo blijft alleen over wat het programma fout laat gaan. Het bepaalt dan wat de relevante variables zijn en dan weet jij bijna wat de fout is.
Bij systematisch software ontwikkelen denkt iedereen meteen aan het V-model. Met testen als sluitpost; althans dat is waar testexperts bang voor zijn. Met ‘Early testing’ kan dat voorkomen worden. Maar kunnen we testen voordat we coderen? Ja, dat kan! Een tool als ‘Check’ maakt dat we een test kunnen programmeren voordat we de module implementeren.
Software schrijven wordt vaak als complex gezien. Waarmee bedoeld wordt dat het moeilijk is. Maar geldt dat voor de doe-het-zelver of voor de professionele ontwikkelaar? Complexiteit is relatief, maar ook betrekkelijk. Zo heeft elk algoritme een inherente complexiteit; dat zegt iets over de runtime-efficiëntie. Maar ook elk stukje code, elke functie, kan zowel eenvoudig als ingewikkeld opgeschreven zijn. Die cyclomatische complexiteit is objectief en kan met Metre gemeten worden.