ALbert Mietus' IT Library
ALbert wil het beter
In deze nieuwe rubriek gaat ALbert in op zijn
missie: "Software beter maken". Hij legt uit waarom dat
moet en hij gaat stap voor stap op onderzoek methoden en ideeën
om software beter te maken. Zo is er een probleem met het imago
van software, deels die borrelpraat gewoon waar. En toch, er is
dankzij de software-industrie heeft veel bereikt. Veel moderne,
handige spullen om ons heen zouden niet mogelijk zijn zonder goed
werkende software. Denk aan telefoons, aan GSM of aan de
populaire iPod. Is het veel meer dan wat plastic en een boel
software?
Hoe kunnen we software beter maken? Door betere processen?
Betere tools? Of door beter ons beste te doen? Kan het wellicht
wat goedkoper, of moeten we efficiënter worden om meer tijd over
te houden om aan de kwaliteit te werken. Of moeten we alleen aan
ons imago werken?
Wie het weet mag het zeggen. Wie het niet weet moet mee op
onderzoek; elke 2 maanden maken we een stap.
De stappen tot nu toe
De 'E' van Software Engineer225k
Koop een willekeurig computertijdschrift en je leest de
prachtigste verhalen over computers. Maar ga je naar een
verjaardag, dan hoor je hele andere verhalen anders. Als het
problemen zijn, komt het door de computer. Als hij het al
doet, dan is het weer te ingewikkeld. Bovendien: als je
computers wel leuk vindt, dan ben je een ‘nerd’. Het lijkt
erop dat wij, software engineers, iets fout doen. Maar wat?
En hoe kunnen we dat verbeteren?
Vakmanschap Of Stijlqueeste?495k
In het eerste deel van deze rubriek heb ik betoogd dat
‘software beter maken’ hard nodig is. Door aan ons imago te
werken en door ons ‘ingenieurschap’ uit te buiten. Maar ook
door betere software te maken. In deze afl evering
onderzoeken we wánneer software beter is. En waarom we
wellicht een stukje persoonlijke vrijheid moeten inleveren
voor betere code.
De Computer Analyseert Auto536k
In onze zoektocht om software beter te maken hebben we
vorige keer betoogd dat stijl belangrijk is. Stijl gaat
immers over vakmanschap; stijl maakt code leesbaar en helpt
bij het onderhoud van programmatuur. Maar wat als dat niet
gebeurd is, wat als de code ‘onleesbaar’ is? Dit keer gaan
we daarom een stap verder. We gaan we kijken hoe we code
sneller kunnen lezen. Bijvoorbeeld door de computer te
gebruiken.
Deze rubriek stop (voorlopig): ik heb een andere werkgever en
schrijf (dus) niet meer voor dePTSer. Wel zal ik blijven
schrijven over dit thema.
pdf
Snelle Linux-overstap begint bij toepassing
Linux combineert de kracht van Unix met de vrijheid van
opensource. En is daarom erg geschikt voor de moderne, krachtige
embedded systemen. Maar er zijn veel valkuilen, ...
ToolView's
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.
Gepubliceerde ToolView's
-
Iedereen denkt bij systematisch software ontwikklen
meteen aan het V-model. Met testen als sluitpost; ...
Met 'Early testing' kan dat voorkomen worden. En met een
tool als check kunnen de testen programmeren,
voordat de code geschreven is
askIgor32k
Voor wie debuggen niet leuk vindt, is er een website
AskIgor die dat voor je
automatiseert. Middels 'Delta debugging' kan die site (voor
Linux-exe's) stap voor stap bepalen waar het fout
gaat
-
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 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!
eclipse32k
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.
XSLTproc38k
XML en embedded programmeren lijken niet samen te gaan. Toch
wordt XML embedded 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 geheel nieuwe manier van programeren...
doxygen16k
Elke programmeur is schrijver. Althans de echte programmeur
schrijft; liefst pagina's vol code. Het schrijven van
documentatie is minder populair. Doxygen kan dat (deels)
oplossen ...
gdb-GUI'S15k
'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 dat
kan met gdb.
Maar gdb is vrij oud en heeft geen mooie interface. Maar er
zijn diverse oplossigen voor een goede GUI voor goede
debugger. Lees meer ...
-
Testen, testen, alsmaar weer testen. Veel programmeurs
kunnen er niet genoeg van krijgen. Maar als klanten bugs
vinden er er te weinig getest! Dus wanneer is er voldoende
getest? Kan je dat testen? Ja, dat kan!
Met gcov kan je meten of er al voldoende is
getest. Maar er zijn meer mogelijkheden.
-
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-efficintie. 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.
-
De meeste programma's bestaan uit functies, waarbij zo'n
functie gezien kan worden als het kleinste en belangrijkste
onderdeel van een programma. Veel belangrijker 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 een `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.
dot-graphviz34k
Bomenstructuren zijn belangrijk in de ICT. Maar het tekenen
ervan kost vaak te veel tijd. Dot is een taal waarmee
dergelijke bomen eenvoudig beschreven kunnen worden. Maar
'dot' is ook een tool om zo'n beschrijving automatisch te
tekenen. De toolset 'Graphviz' bevat nog meer van dergelijke
handige tools.
-
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.
ethereal14k
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 geeft dat
gewenste inzicht. Het 'snift' alle bits van een netwerk;
herkent de protocollen en presenteert alle data netjes
gelaagd.
-
Het doorgronden van grote hoeveelheden code is vaak
lastig. Het zoeken naar functie-aanroepen, zeker met
tientallen files gebeurd wordt, kost dan erg veel tijd.
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 en
vinden van functie-definities en -aanroepen makkelijk.
106k
html
De programmeertaal Objective-C is een mooie OO taal, die
onbekender is dan bijvoorbeeld Java. Toch heeft deze taal, die
even oud is als C++ een aantal kenmerken die noch in C++ noch in
Java gevonden worden. Dit artikel geeft een overzicht van deze
taal.
Alternatieve formaten
- dePTSer
Dit stuk is in Aug 2003 gepubliceerd in
dePTSer, het huisblad van PTS. Die versie is in pdf beschikbaar.
24k
html
Eric Meyer on CSS is een boek over hoe CSS, voor moderne
browsers, gebruikt kan worden. Ik vind het een nuttig boek.
Alternatieve formaten
- dePTSer
De review is ook opgenomen de dePTSer van Aug
2003. Daar heet een boekbesprekingen ReadME
Een afdruk van die pagina is, als pdf, beschikbaar.
