Internet-App of Smartphone-App

Wie tien jaar geleden investeerde in desktop-software werd voor gek verklaard. Alles moest online. In de browser. De pendule van de software-industrie is tegenwoordig weer terug. Desktop is hot, of beter gezegd: Apps op een smartphone zijn hot. Het lijkt wel of iedereen een iPhone-App wil, en ook één voor Android natuurlijk. Maar heeft een smartphone dan geen browser? Ja! En kun je met die browser niet hetzelfde als met een App? Misschien! Ik zie vier voordelen van een App boven een internetapplicatie.

Icoon op desktop          

Apps worden geïnstalleerd op de telefoon en hebben een icoon waar de telefoonbezitter regelmatig mee geconfronteerd wordt. Dit is pure reclame voor de App. Reclame die met een internetapplicatie niet kan worden gemaakt. Daar kun je het internetadres van een website hooguit in de bookmarks plaatsen. Dikke plus voor Apps hier.

Niet opnieuw inloggen

Apps kunnen onthouden wie je bent. Hierdoor hoeft de gebruiker niet telkens opnieuw in te loggen. In combinatie met het eerstgenoemde voordeel wordt de plus heel groot. Stel je voor dat je iedere keer dat je een App gebruikt opnieuw je e-mailadres en wachtwoord moet intypen. Dat ben je snel beu.

Local storage

Apps kunnen gebruik maken van de harde schijf van de smartphone. Internetapplicaties kunnen dit niet. Dit betekent dat Apps informatie kunnen onthouden en informatie niet telkens opnieuw hoeven op te vragen via het internet. Dit maakt Apps sneller en zorgt er bovendien voor dat er minder gedownload hoeft te worden wat scheelt in het dataverkeer, en dus lagere kosten voor de hosting.

User experience

Apps maken gebruik van mooiere controls dan internetapplicaties. Daarom zien Apps er beter uit, en voelen ze beter aan. Ze lijken robuster, ook al bieden ze dezelfde functionaliteit. Soms kun je met Apps dingen die internetapplicaties (lees: websites) gewoon überhaupt niet kunnen. De camera-functie is daar een goed voorbeeld van.

De gemakkelijke toegankelijkheid, het niet hoeven in te loggen, de snelheid en vloeiende user interface bieden veel voordelen. Dat gezegd hebben zal een App in de achtergrond altijd communiceren met een internetapplicatie. In mijn ogen is de App een mooi toevoeging, maar zeker geen vervanging.

Bug-oorzaken

Bij Octavalent houden we netjes bij welke bugs wij ontdekken en onze klanten melden. In sommige weken zijn het er veel, andere weken zijn het er heel weinig. Maar er zijn helaas altijd wel een paar onvolkomenheden in onze software. Het drama is niet zo groot: de meeste bugs zijn binnen korte tijd en zonder al te veel moeite opgelost. En (maatwerk) software is nooit bug-vrij. Desondanks zijn fouten vervelend, vooral als eindgebruikers er mee geconfronteerd worden en daardoor hun werk niet kunnen doen.

Om het aantal bugs te verlagen heb ik gekeken naar de oorzaken. Ik kwam tot de volgende vijf oer-redenen (in willekeurige volgorde):

  • Slordigheid
  • Componenten van derden
  • Onvolledig functioneel ontwerp
  • Incorrecte technische oplossing
  • Architectuur

Slordigheid

Bij bugs is er een natuurlijke neiging om de programmeur te beschuldigen. En dat klopt natuurlijk. Als je iemand de schuld zou moeten geven, dan is het degene die de software gemaakt heeft. Dit is tegelijkertijd er kort door de bocht. Software schrijven is mensenwerk, en waar mensen werken, worden fouten gemaakt. Waar gehakt wordt, vallen spaanders. Het resultaat van een individu is de resultante van zichzelf en zijn omgeving. En het blijkt dat slechts een heel klein gedeelte van de bugs toegewezen kan worden aan slordigheid, domheid of andersoortige onhandigheid van de programmeur. Althans bij ons in het bedrijf. De discipline om goed op te letten waar je mee bezig bent is hoog. En dat moeten we zo houden.

Componenten van derden

We gebruiken regelmatig componenten van derden. Voorbeelden hiervan zijn: een component om PDF-documenten te genereren, een tekstverwerker in de webbrowser, en ook de webbrowser zelf (zoals Internet Explorer of Firefox). Het blijkt dat deze componenten niet altijd foutloos zijn, waardoor onze software onderuit gaat. Dit is geen excuus. Wij kiezen de componenten en dienen goed te testen. Desondanks is het wel een oorzaak. En tegelijkertijd mogen wij er in bepaalde mate vanuit gaan dat een veelgebruikte webbrowser als Internet Explorer backwards compatible is (dat wil zeggen: wat werkt in versie 8, werkt nog steeds in versie 9). De werkelijkheid is echter anders.

Onvolledig functioneel ontwerp

Voor de ontwikkelaar aan de slag gaat wordt een functioneel ontwerp gemaakt. In dit ontwerp staat precies beschreven hoe de te ontwikkelen software moet gaan werken. Vooral bij aanpassingen aan bestaande software treden problemen op. Een voorbeeld ter illustratie. In onze software wordt na een gebruikersactie (zoals het opslaan van een product) een tekst getoond met feedback (zoals “Product ‘ABC’ is opgeslagen.”) Er waren problemen met de manier waarop deze feedback getoond wordt, dat moest anders. Anders schrijf ik expres cursief, omdat het niet duidelijk was hoe het anders moest. Dit was aan de ontwikkelaar. De ontwikkelaar in kwestie gaat hiermee aan de slag en komt met een heel mooie oplossing. Iedereen tevreden. Tot blijkt dat de feedback-teksten op bepaalde plaatsen in de software net iets anders werken dan standaard gebruikelijk is. Nu valt lang te steggelen over de vraag of dit een fout van de ontwikkelaar was, of van de ontwerper. Feit blijft dat het goed was.

Incorrecte technische oplossing

Soms wordt een technische oplossing gekozen, waarvan we zeggen: dat hadden we beter niet zo kunnen doen. Deze conclusie valt uiteen in twee varianten: a) it seemed like a good idea at the time, en b) we wisten het van te voren. De eerste variant is voor iedereen met een technisch beroep herkenbaar (toch?) En ook niet technici kunnen zich een voorstelling maken van een foutief gekozen oplossingsrichting. We weten veel, maar niet alles. We hebben geen glazen bol. En soms kiezen we een oplossing die later niet blijkt te werken. Het is erger als we van tevoren wel hadden kunnen weten dat het technisch ontwerp niet klopt. Redenen hiervoor zijn een niet eenduidige architectuur. Er zijn meerdere oplossing voor het zelfde probleem, waardoor een ontwikkelaar sneller geneigd is een geheel eigen oplossing te bedenken, die hoe briljant ook, kinderziektes heeft. Communicatie vormt hierbij een belangrijke sleutel.

Architectuur

Ieder ontworpen systeem van een bepaalde omvang heeft een architectuur. Of het nu gaat om een wolkenkrabber of een stuk software. Iemand heeft nagedacht over de vraag welke materialen gebruikt worden en hoe de verschillende structurele componenten aan elkaar vast zitten. Een winkelcentrum bouw je niet met los zand, en software hangt ook niet met elastiekjes aan elkaar. Of soms toch wel? Architectuur-bugs zijn bugs waarbij er ergens iets veranderd wordt, en daardoor ergens anders iets niet meer werkt. Een verandering in één deel van de software leidt tot problemen in een ogenschijnlijk volledig ongerelateerd ander deel. Dit soort problemen zijn onlosmakelijk verbonden met het ontwikkelen van software. Ik speel het ontwikkel-spel al enkele decennia en heb niet anders meegemaakt. Ik schaar deze bugs onder het kopje architectuur, omdat een goede architectuur kan helpen dit soort bugs te voorkomen. Bijvoorbeeld door software op te splitsen in overzichtelijk componenten. Delen die klein genoeg zijn zodat de ontwikkelaar een volledig overzicht heeft op het geheel, en niet verzuipt in meer dan 100k regels code.

Achieving ‘maintainable pace’

Gemiddeld gezien lopen software-projecten uit, staan ontwikkelaars onder druk en raken projectleiders gestresst. Deze optelling is niet goed voor de mensen, niet goed voor de kwaliteit en uiteindelijk niet goed voor de portomonee. Een aantal slimme koppen kwamen bij elkaar en schreef in het Agile manifesto dat de software-productie een ‘maintainable pace’ dient te hebben. Het tempo binnen een project moet vol te houden zijn. Makkelijk gezegd, maar hoe kom je tot zo’n houdbaar tempo? Vorige week hebben we binnen Octavalent opnieuw al het geplande werk afgekregen. Wat betekent dat en hoe doen we dat?

Iedere maandagochtend houden we de zogenaamde weekopening. In deze vergadering, waarbij iedereen aanwezig is, bespreken we de voorgaande week en plannen we het werk voor de komende week. Dit geplande werk is niet zo maar een gedachte, maar zien we als een commitment. Hoe gaat dit plannen in zijn werk?

Een software-project hakken we op in zo klein mogelijk stukken: de stories. Uiteindelijk bestaat een groot project daardoor uit enkele tientallen handzame stories. Iedere story kennen we een aantal punten toe. 1 punt betekent dat het niet veel werk is, niet complex is, en niet veel risico behelst. 2 punten betekent letterlijk 2 keer zoveel als 1, en 8 punten betekent dus 4 keer zoveel als 2 punten. Door punten te gebruiken in plaats van uren (en dit te schatten middels planningpoker) blijkt het aantal punten redelijke goed te kloppen.

Door stories in te plannen in een week, kun je de punten bij elkaar optellen en zo komen tot een totaal aantal punten voor die week. Achteraf kun je tellen hoeveel punten je daadwerkelijk gedaan hebt. Door dit een lange periode vol te houden (en hier zit de crux), bouwden we ervaringsstatistieken op. Zo weten we dat we gemiddeld 9 punten per FTE kunnen doen. Nu wordt het al gemakkelijker.

Tel op maandag de beschikbaarheid van de ontwikkelaars (in FTE), vermenigvuldig dit met 9 en dan hebben we het aantal punten dat we de komende week inplannen. Aangezien de stories punten kregen vóór het maken van deze rekensom, is het daarná slechts een kwestie van bepalen welke stories in de komende week op het planbord komen.

So far, so good. Maar we zijn er niet. Niets garandeerd dat de week niet overhoop wordt gehaald door haastklussen, bugmeldingen en tegenvallers. Haastklussen zijn heel simpel. Dat kan altijd, maar moet geruild worden met eerder ingepland werk. Dit is het principe van: “Je wilt dat XYZ in de planning komt? Wat gaat er dan uit de planning?”.

Bugmeldingen zijn lastiger. Een plotselinge test-woede van een collega of klant kan een stortvloed van kleine verbeterpunten opleveren. Alles is even belangrijk, maar het is de vraag of het nu moet. Bugs die geen showstoppers zijn, stellen we zonder pardon uit tot de volgende week. Blijkt op die maandag dat er veel bugs opgelost moeten worden, dan stellen we de productiviteits-schatting navenant bij van 9 naar 8 (of 7 of 6). Zijn er weinig bugs, dan gaat de productiviteits-schatting naar 10, of wellicht 11. Door bugs niet direct op te pakken, maar in te plannen, creeëren we een hoop rust wat de kwaliteit ten goede komt.

Tot slot kan het werk altijd tegenvallen. Een 2-punter (statistische gezien 6 uur werk) kan 3 dagen in beslag nemen. Weg planning? Niet helemaal. We hebben nog een sluitpost. Die sluitpost heet ‘Verbeteringen’. Verbetering zijn werkzaamheden waarvan het ontwikkelteam vindt dat ze nodig zijn. Voorbeelden zijn: wijzigingen in de architectuur, het inzetten van een nieuw technologie of het upgraden van een component. Dit zijn werkzaamheden die niet onmiddelijk moeten gebeuren. Ze kunnen makkelijk worden uitgesteld naar de volgende week. En dat doen we dan ook.

Hier zit wel een valkuil. Door verbeteringen als sluitpost te hanteren, loop je het risico er nooit aan toe te komen. Wij hebben dit ondervangen door voor verbeteringen een budget te bepalen, en wel 10% van alle ontwikkeluren. Dit tellen we per kwartaal. Stel dat we na drie weken in het kwartaal slechts 5% hebben besteed aan verbeteringen, dan weten we dus dat we voor de volgende week een lagere productiviteit moeten aanhouden.

 

 

 

 

 

 

Wat ik verwacht in een goed CV

Bij Octavalent zijn we op zoek naar een nieuwe ontwikkelaar. Ik krijg daarom weer veel CV’s onder ogen. Sommigen zijn goed, anderen vallen tegen. Het CV van een software-ontwikkelaar is net iets anders dan een gemiddeld CV. Vooral het kopje opleiding en ervaring met bepaalde technologieën. Wat zoek ik precies in een CV?

Algemeen

Gebruik niet te veel tekst. Opsommingen zijn super. Ook de standaard opmaak van een leeg Microsoft Word document voldoet prima. Schrijf maximaal twee kantjes en motiveer in je e-mail waarom je juist voor deze functie, bij dit bedrijf solliciteert.

Personalia

Hier staat puur feitelijke informatie over wie je bent, hoe je te bereiken bent en waar ik op internet meer over je kan vinden. Toon: naam, geboortedatum, adres, telefoonnummer, email en eventuele websites (zoals linkedin, weblog, github- of stackoverflow-pagina). Wees niet de benauwd om een foto bij te voegen. Het gaat er om dat ik je kan herinneren en een foto helpt.

Opleiding

Beschrijf alle opleidingen, cursussen, en trainingen die je gedaan hebt. Let er wel op dat opleidingen minder relevant zijn dan vroeger. Kennis is vluchtiger, dus een training van vier jaar geleden voegt niet veel meer toe. Ook zijn er veel meer mogelijkheden om bij te blijven. Lees je actief weblogs? Luister je podcasts? Zet dit dan bij opleidingen. Bij opleidingen wil ik zien waar je je basiskennis vandaan hebt (HBO/WO), en hoe je op de hoogte blijft van nieuwe ontwikkelingen.

Ik ben altijd een beetje beducht op (oud-)medewerkers van een detacheringsbureau die in wel heel veel opleidingen hebben gedaan. Dit wijst er meestal op dat ze op de ‘bank’ zaten/zitten. Goede medewerkers zitten namelijk op een project en doen alleen certificerings-trajecten als het echt moet.

Werkervaring

Werkervaring is meer dan een lijst met bedrijven waar iemand werkte. Sterker, de bedrijven boeien mij niet zo. Ik ken ze toch niet. Ik ben meer geïnteresseerd in de projecten waar iemand aan werkte: voor welke klant, hoelang, in welke rol en met welke technologieën. Dat gezegd hebbende wil ik wel weten hoelang iemand gemiddeld bij een werkgever werkt. Toon dus werkgevers, en per werkgever de projecten.

Veel werkervaring is goed, veel verschillende ervaringen is minder goed. Ik zoek iemand die focus heeft op een bepaalde technologie en binnen die technologie weet waar hij het over heeft. Een jack-of-all-trades kan over veel meepraten, maar is nergens echt goed in. Dit heeft zo zijn waarde, maar ik zoek het niet. Toon in je werkervaring welke technologieën, frameworks, talen, en bibliotheken je gebruikt hebt. Of je aan veel of weinig projecten hebt gewerkt is niet zo relevant. Als er maar een lijn in zit.

Zeg niet te snel dat je een expert bent in taal XYZ. Toon het mij. Bijvoorbeeld door er een aantal jaren mee gewerkt te hebben. Iemand die na twee jaar claimt C# -expert te zijn is voor mij niet geloofwaardig, en ondermijnt zijn CV. In tegenstelling: wanneer iemand vier jaar ervaring heeft met C#, dan trek ik zelf wel de conclusie dat hij weet waar hij mee bezig is.

Overigen

Iedere medewerker brengt niet alleen zijn hoofd en handen in, maar ook iets extra’s. Dit extra’s is met name in een kleinere organisatie van belang. Dat je op voetbal zit is niet zo relevant, wel als je daar iets speciaals doet: bijvoorbeeld door in de feest-commissie te zitten of voetbaltraining te geven. Spreek je vloeiend een vreemde talen die handig kan zijn? Ben je BHV-er? Heb je gewerkt aan een open-source project? Help je ouderen met het wegwijs worden op de computer? Schrijf je een blog? Doe je vrijwilligerswerk? Schrijf het hier op.

Idee voor een puzzelwebsite

Struinend in mijn (ongepubliceerd) archief kwam ik de specificaties tegen voor een spelletjeswebsite. Ik meen mij te herinneren dat ik deze ooit schreef voor een wedstrijd. Later bleek dat de wedstrijd bedoeld was voor studenten en dat de inschrijving al was gesloten. Zo raakten het idee in de vergetelheid tot ik de tekst zojuist weer tegen kwam. Ik las hem en vond het nog steeds een aardige vonst.

Hierbij het concept: De website biedt puzzels aan. Een puzzel is een raadsel waarbij de bezoeker aan de hand van een hint een locatie moet raden. Dit kan een locatie zijn overal ter wereld. De puzzelaar ziet op het scherm een wereldkaart en hij moet op de kaart de juiste locatie aanklikken. Klikt hij inderdaad juist, dan heeft hij de puzzel gewonnen. Iedere puzzelaar kan zelf puzzels maken. Een puzzel bestaat uit uit de eerder genoemde hint & locatie (latitude en longitude) en een radius. De locatie in combinatie met de radius vormt een cirkel op aarde.

Om de juiste locatie te kunnen raden heeft de puzzelaar twee hulpmiddelen. Allereerst is er de hint. Het tweede hulpmiddel is het commentaar van andere puzzelaars. Je speelt een puzzel namelijk nooit alleen, iedereen kan met dezelfde puzzel meespelen. Als puzzelaar kun je suggestie aan een puzzel toevoegen. Op deze manier speel je tegelijkertijd met elkaar, maar ook tegen elkaar. Suggesties van anderen helpen jou, maar jouw suggesties helpen anderen.

Bij een goed spel valt iets te winnen, zo ook hier: punten. Bij het geven van suggesties kan de bedenker van de puzzel jouw suggesties upvoten en downvoten. Upvoten levert je 10 punten op, downvoten kost je 2 punten. Het totaal aantal punten van de upvotes en downvotes bepaalt de waarde van een puzzel. Win je de puzzel dan krijg je de waarde van de puzzel toegevoegd aan jouw totaal. Hetzelfde geldt voor de bedenker van de puzzel, die krijgt ook dat aantal punten. Je kunt dus op drie manieren punten scoren: door goede suggesties te leveren, door een puzzel te winnen en door een puzzel te verzinnen.

Patenten weren Europese software-ontwikkelaars van Amerikaanse markt

“Patentterreur verjaagt app-makers uit ‘gevaarlijk’ VS” kopte een artikel op de technologie-website Webwereld. Het was een artikel waar ik al een tijdje op zat te wachten. En ik werd er niet blij van. Kun je als Nederlands (of Europees) technologiebedrijf met een software-product mondiaal succes hebben? Met de patentoorlog die gaande is wordt het in ieder geval niet gemakkelijker.

Nederlandse software-makers zijn altijd al huiverig geweest voor verkoop in Amerika. De angst voor torenhoge claims is groot. Geen idee of dit volledig terecht is, maar ik kan mij er iets bij voorstellen. Amerika heeft nu eenmaal de reputatie dat klanten (of zelfs wildvreemden) je voor de raarste dingen voor het gerecht slepen. Vroeger hoefde je praktisch alleen maar bang te zijn dat anderen schade opliepen bij gebruik van jouw producten. En als jouw product goed in elkaar zat, dan waren de risico’s beperkt. De patentoorlog heeft hier een nieuwe dimensie aan toegevoegd.

Software-ontwikkelaars zijn over het algemeen creatieve mensen die features bedenken waar je bij staat. Stop een stel software-savvy mensen in een hok en de ideeën stromen over. Tot de patent-oorlog uitbrak was het een kwestie van prioriteren en bouwen maar. Tegenwoordig moet je rekening houden met patenten. Stel dat je een goed idee hebt voor een nieuwe feature, dan is de kans groot dat jij niet de enige bent met dit ‘briljante’ idee. En als iemand in Amerika dat idee ook had en hij werkt bij een groot bedrijf, dan is de kans groot dat het idee gepatenteerd is.

Maar wat betekent een software-patent eigenlijk? Kort gezegd komt het er op neer dat als je gepatenteerde technologie in jouw software gebruikt, dat je moet betalen aan de patenthouder. Ook als je ten tijde van de software-ontwikkeling niet wist dat er een patent was. Tijdens het ontwikkelen van software kun je dus ongemerkt inbreuk maken op patenten van anderen. Aan het proces van software ontwikkelen is door de patent-oorlog een extra activiteit toegevoegd: onderzoek doen naar patenten en nieuwe patenten aanvragen.

Nu gelden de patenten strikt gezien alleen voor Amerika. In Nederland (en geheel Europa) is het niet mogelijk om patenten op software aan te vragen. Software wordt gezien als algoritmes, wiskundige formules dus. En uitvindingen in de wiskunde kun je in Europa niet patenteren. Is er dus wel een probleem?

De Amerikaanse markt wordt gevormd door de patentoorlog. Amerikaanse softwarebedrijven houden bij de ontwikkeling van software rekening met patenten. Ze gebruiken geen gepatenteerde ideeën of patenteren zelf defensief. Amerikaanse bedrijven groeien op in een ecosysteem waarin patenteren een normaal onderdeel van het leven is. Europese bedrijven komen tot wasdom in een ander model. Omdat zij nooit rekening hoefden te houden met patenten, maken zij ongemerkt inbreuk op allerlei Amerikaanse patenten. Dit is geen enkel probleem, totdat ze de Amerikaanse markt op gaan. Het ‘niet gewend zijn aan patenten’ is een barrière voor toegang tot de Amerikaanse markt.

Op zich is Europa voor een Nederlandse bedrijf groot genoeg. Er zijn groeimogelijkheden zat op ons continent. Er is echter een bepaald type markt waarbij Amerika een must is: de winnner-takes-all-markt. Dit is een markt waarbij één of twee grote spelers (uiteindelijk) domineren. Enkele voorbeelden zijn: zoekmachines (Google, Yahoo, MSN), en sociale netwerken (FaceBook, LinkedIn). In een markt waarbij Europeanen niet naar Amerika kunnen, maar Amerikanen wel naar ons, delven wij per definitie het onderspit.

Er is echter een positieve kant aan de patent-woede. Tegenstanders van (software)patenten claimen dat patenten innovatie in de weg staan. In een systeem van gesloten innovatie kun je niet bij elkaar in de keuken kijken en geen gebruik maken van uitvindingen en ideeën van anderen. Europese bedrijven zijn door de koers van open innovatie wellicht in het voordeel. Hoewel hier ook het principe geldt dat Amerikanen wel in onze keuken kunnen kijken, maar wij niet in die van hen.

We zullen het zien.

Slimme programmeurs gesorteerd per taal

Recent kwam ik op de website van Project Euler. Dit is een website met diverse wiskundige programmeer-raadsels. Voor iemand met een interesse in software is dit een leuke puzzel-site, en weer eens iets anders dan Angry Birds. Voor iedere puzzel is het de bedoeling dat je een heel klein programmatje schrijft wat een oplossing vind voor een bepaald probleem. Voorbeeld: “What is the smallest number divisible by each of the numbers 1 to 20?” Echt voor nerds dus.

Project Euler houdt ook statistieken bij. De twee die ik interessant vond, waren: Number of Users en Average User Rating, per programmeertaal. Vooral de Average User Rating vond ik interessant. Ik ga er van uit dat deze rating aangeeft aan hoevaak een gegeven antwoord goed is.

Aan de hand van de Tiobe-index pakte ik de vijftien meest populaire programmeertalen en kwam zo tot de volgende staatjes.

Rank Taal Rating
1 C/C++ 7%
2 Python 9%
3 Java 7%
4 C# 7%
5 Haskell 10%
6 Ruby 8%
7 Perl 9%
8 PHP 4%
9 BASIC 8%
10 LISP 8%
11 Pascal 8%
12 Delphi 10%
13 JavaScript 5%
14 Lua 7%
15 Assembler 10%
Rank Taal Rating
5 Haskell 10%
12 Delphi 10%
15 Assembler 10%
2 Python 9%
7 Perl 9%
6 Ruby 8%
9 BASIC 8%
10 LISP 8%
11 Pascal 8%
1 C/C++ 7%
3 Java 7%
4 C# 7%
14 Lua 7%
13 JavaScript 5%
8 PHP 4%

Ik vind het grappig dat met name de bovenste drie en onderste twee zo herkenbaar zijn. Bovenin vinden we Haskell (academici), Delphi (veteranen) en Assembler (die-hards). Onderin staan de talen voor de scriptkiddies: JavaScript en PHP. De rating zegt op zich natuurlijk niet zo veel over de intelligentie of snelheid van de programmeur. Maar het is wel zo dat de oplossing van een top-tier-programmeur één op de tien keer goed is. Terwijl een PHP-neefje pas na 25 keer tot een goed resultaat komt.

PowerPoint-educatie

Zoals (bijna) iedereen ben ik mijn schoolloopbaan begonnen toen ik nog heel klein was. En zoals (bijna) niemand ben ik nu pas gestopt met de studie – waarschijnlijk tijdelijk, maar toch. In dertig jaar is er veel veranderd in de klas. Dat kan ook niet anders, met de nieuwe inzichten die zijn opgedaan en nieuwe (ICT-)technologie. Toch moet ik zeggen dat ik geen fan ben.

In 1997 startte ik met een HEAO-opleiding aan de HES in Rotterdam. Elke maandagavond en woensdagavond les, en de zaterdagen en zondagen waren gereserveerd voor lezen en het maken van opdrachten. Er stonden flink wat dikke boeken op de verplichte lijst. Na de HEAO nam ik een educatieve pauze, tot het weer begon te kriebelen en ik in 2003 startte aan de Universiteit Leiden. Opnieuw dikke boeken. Nu, in 2011, is het grote verschil dat de dikke boeken verdwenen zijn. Dat wil zeggen: er is nog wel een lijst, maar niemand leest meer een boek. En ik geef de schuld aan PowerPoint.

Ik kan mij niet herinneren dat we op de HEAO een computer met projector in de klas hadden. Als er al een projector was, dan was het een overhead-projector. In mijn herinnering stond er een docent voor de klas die vertelde. Dat is nu hopeloos ouderwets. Het schijnt – en dit heb ik puur van horen zeggen – dat er op de kleuterschool al een beamer aan ieder plafond hangt. Doodzonde vind ik dat.

Wat is dan precies het probleem van PowerPoint? Natuurlijk gaat het niet om PowerPoint, maar om de manier waar docenten (en daarom studenten) daarmee omgaan. Guns don’t kill people, neither does PowerPoint.Een PowerPoint-presentatie geeft een docent het gemak dat hij een les thuis voor kan bereiden en zo een uur vol kan praten (60 slides lang). Een vaste structuur, met een vaste opbouw, met een vaste tekst. Weg creativiteit, weg spontaniteit, weg betrokkenheid van de leerling of student. En wat heb ik een berg slechte presentaties voorbij zien komen. Zowel qua inhoud als vorm. Serieus, de inhoud kreeg een zesje, de vorm haal de voldoende bijna nooit. Het absolute dieptepunt was overigens een meiske van amper twintig die anderhalf uur lang slides heeft staan voorlezen.

En dan de ergste vraag: “Meneer/mevrouw, staat de presentatie ook op internet?” En het antwoord is een volmondig JA. Docenten zetten de presentatie op internet, ter voorbereiding op het tentamen. Denk hier eens over na. Er is een vak, daar hoort een boek bij, en dan zet men de presentatie over dat vak (lees: boek) op internet. Dus de docent plaatst de belangrijkste punten van het boek (lees: samenvatting) in een overzichtelijk PowerPoint-presentatie op internet. Wat kun je dan verwachten?

Studenten zijn aartslui. Of efficient, zo je wilt. Een gemiddelde (Nederlandse!) student zal niet harder lopen dan strikt noodzakelijk. In deze situatie… Wie gaat dan in hemelsnaam nog het daadwerkelijk boek lezen. Heb je enig idee hoeveel tijd dit kost. Of beter gezegd: hoeveel tijd je hier mee verspilt. Het boek lezen maakt het verschil tussen een 8 en een 9. In Nederland is een 8 echt zeer ruim voldoende, Goed zelfs! Iedereen die in het hoger onderwijs achten haalt mag dik tevreden zijn met zichzelf.

Wie echt slim is, stopt met boeken koepen, en geeft een rondje in de kroeg. Da’s goed voor je netwerk, voor later.

Databases in een OO-paradigma

In de tig+ jaar dat ik nu software schrijf, ontwikkelde ik een grote voorliefde voor het zogenaamde object-georiënteerde programmeren. En gelukkig is dit ook de dominerende trend onder software-architecten. Zeker met de beweging weg van het client-server-model naar het webbased-model heeft de tegenhanger, database-georienteerd programmeren, danig aan populariteit verloren. Begrijp mij niet verkeerd. Ik zie het nut van een database. Maar voor mij is de database onderdeel van de architectuur en niet het uitgangspunt.

Historisch gezien hebben databases altijd een dubbelfunctie gehad: gegevensbeheer en het bieden van allerhande functionaliteiten. Bij functionaliteit denk ik aan stored procedures, views, functions, triggers en (zelfs) default values. In een object-georiënteerde architectuur horen dit soort zaken niet in de database thuis. Als voorbeeld zal ik het meest controversiële punten nemen: default waarden. Gegevens komen in een database terecht omdat een object wordt opgeslagen. Het object wordt geïnstantieerd (ver weg van de database) en dient bij het instantiëren de juiste default waardes te krijgen. Hier zit precies de crux. Functionaliteit dupliceren over zowel het objectmodel als de database leidt tot discrepanties in de implementatie. De default waardes voor eigenschappen van een class kunnen anders zijn dan de default waardes van een corresponderend record in de database. Dat wil je niet, en des harder je een keuze maakt tussen OO en DB, des te makkelijker je het jezelf maakt.

Een database heeft voor mij de volgende doelen: data-opslag, controle op data-integriteit en performanceverbetering. Het eerste doel is gekscherend te illustreren. Wat gebeurd er met een in memory object graph als de stroom uitvalt? Het geheugen is kwetsbaar, dus wil je gegevens op een harde schijf bewaren. Data-integriteit is een allerlaatste controle of de data die in een applicatie beheerd wordt klopt. Zijn de gegevens en hun onderlinge relaties in overeenstemming met de opgestelde integriteits-regels? Tot slot hebben databases rauwe verwerkingscapaciteiten. Databases zitten simpelweg dichter tegen het ‘metaal’ en hebben minder/geen netwerkverkeer nodig bij het doen van bevragingen en bewerkingen.

Als OO-man heb ik voor mijzelf de volgende uitgangspunten op een rijtje gezet. Het zijn richtlijnen over hoe met een database omgegaan moet worden. Deze gaan verder dan het fatsoenlijk normaliseren en denormaliseren. Richtlijn 1 is hierbij: alle (of op z’n minst zo veel mogelijk) functionaliteit en business logic  in de software onderbrengen, niet in de database.

Om de database als concept recht te doen volgt richtlijn 2: neem databases serieus binnen de functie die ze hebben. Als voorbeeld. Een database zonder indexen is een goudmijn voor performance-optimalisatie. Gebruik ze dus. Gebruik ook contraints voor primairy keys, foreign keys, unique values, en waar je maar even kan. Gebruik referentiele integriteit! En houd veldlengtes zo kort mogelijk. Zorg dat je een goed database-administrator hebt, die wil en kan functioneren binnen een OO-architectuur.

Databases hebben een interne structuur van tabellen, velden, constraints en indexen. Deze kun je middels een GUI met het handje aanpassen. Richtlijn 3: doe dit niet. Maak nooit handmatige aanpassingen in het database-schema. Gebruik een migrations framework waarin alle schema-verandering chronologisch zijn gescript. Als je wijzigingen in meerdere databases wilt doorvoeren dan zijn migrations onmisbaar. Denk hierbij alleen al aan een ontwikkel- en live-database.

Richtlijn 4: bepaal hoe je vanuit de software met de database gaat praten. Zoek je harde performance waarbij je als programmeur veel zelf kunt en moet doen? of ga je voor een echt object-georienteerde aanpak? En in welke mate lijken de classes/properties op de tabellen/velden. In het eerste geval kies je voor het simpelere Active Record, anders voor een full-blown Object-Relational-Mapper (ORM). Oftewel: ADO-recordsets, Linq2Sql of Entity Framework (om binnen de officiele Microsoft productcatalogus te blijven). Wie nu nog wil klooien met recordsets, moet zich achter de oren krabben. Deze optie valt heel snel af. Linq2Sql en EF hebben verschillen, maar over het algemeen gezien worden de mogelijkheden van Linq2Sql gezien als een subset van die van EF. EF is daarmee echt de grote broer van.

Toen ik leerde om met databases om te gaan begon de oefening als volgt: CREATE TABLE tblPersonen… Dit is een fout dit ik nu niet meer zou maken. Richtlijn 5 gaat over naamgeving. Allereerst is het de vraag of naamgeving in programmatuur in het Engels moet of in het Nederlands. In Duitsland kan ik mij de nationalistische discussie voorstellen, in Nederland niet. Ik kies zonder enige twijfel voor het Engels. Wat je ook doet: volg altijd de conventies die gebruikt worden in het software. Is de naamgeving in de software in het Engels, dan is de naamgeving in de database dat ook.

De software is leading, de database volgt. Weinig discussie mogelijk. Dit geldt niet alleen voor de taal, maar eigenlijk voor alles. Ik ga uit van de normale conventies die gelden voor C# (volgens de Framework Design Guidelines). Naamgeving van tabellen en velden vloeit  voort uit die van classes en properties. Dus hou ik de volgende conventies aan:

  • gebruik geen prefixen
  • veldnamen zijn nooit dezelfde als de tabelnaam
  • gebruik dezelfde namen voor velden die de zelfde soort gegevens opslaan. Voorbeelden: Order, CodeName, Name, Description, CreateDate. Denk hierbij aan interfaces als: IOrderable, INamed, enzovoort.
  • kies tabelnamen die niet te veel op elkaar lijken. Bij de twee tabellen ProductType and ProductsType kun je er op wachten dat iemand een fout maakt.
  • doe alsof de database case-sensitive is
  • stel conventies op en houd iedereen hier strikt aan (net als in de software)

Tot slot zijn tabelnamen in het meervoud. Product wordt dus Products, met een s. Probeer Meervoud-enkelvoud combinatie te maken die alleen op de uitgangs-s verschillen. Dus niet People-Person, maar Persons-Person. Dit vereist soms wat creativiteit, maar het helpt later. Puur voor het gemak.

De vorige richtlijn gaat vlekkeloos over in richtlijn nummer 6: koppeltabellen bestaan niet. Deze richtlijn is niet geheel onomstreden, maar ik ben er desondanks groot fan van. Koppeltabellen worden gebruikt om relaties tussen records die een n-op-m-cardinaliteit hebben op te slaan. In zo’n geval wordt een nieuwe tabel geintroduceerd die slechts twee foreign keys bevat, naar de gelieerde tabellen. Een voorbeeld met twee tabellen: Persons en Groups. Hoe gaat de koppeltabel heten? Er is een conventies die zegt dat je de namen van de tabellen achter elkaar zet in alfabetische volgorde: GroupsPersons dus. Trouwens, dit is een koppeltabel met twee tabellen. Een koppeltabel kan ook vier tabellen koppelen. Hoe heet de tabel dan? Afgezien van de naamgeving is er een ernstiger probleem. Wat gebeurt er als die koppeltabel een extra veld krijgt? Wat is dan het verschil tussen een ‘normale’ tabel en koppeltabel. Daarom zeg ik: koppeltabellen bestaan niet. Beschouw een koppeltabel als een normale tabel en kies een naam die past. Bijvoorbeeld: GroupMemberships.

Alweer geheel vloeiend komen we bij richtlijn 7: gebruik geen samengesteld primairy keys. Alle tabellen hebben precies 1 Primairy Key field. Aangezien we juist koppeltabellen verbannen hebben (die per definitie samengestelde primaire sleutels hebben) is deze afspraak makkelijk te houden. Gebruik voorts unique-constraints voor data-integriteit. De veldnaam voor de Primairy Key is altijd Id, wat afgeleidt is van de property Id op de class. Handig als je classes met een Id de interface IIdentifyable (met 1 property..) laat implementeren. Kies als datatype altijd voor de GUID boven een auto-increment int (meer smaken zijn er overigens niet echt). Het belangrijkste voordeel van de GUID is dat je van een nieuw object de Id-property zet in de software, en niet in de database. Principeel doe je dit omdat het genereren van id’s functionaliteit is. Praktisch wil je wel eens een sleutel hebben voordat het object is opgeslagen, en niet pas nadat het object in de database zit.

Abrupt tijd voor een geheel ander onderwerp: meertaligheid. Amerikanen hebben het in hun gelikte demos altijd makkelijk. Een veldje Name, een veldje Description en klaar. Wij Nederlands hebben snel te maken met vertalingen. Het is mij opgevallen dat juist in Nederland ontwikkelde software het best is voorbereid op het in kunnen voeren van meerdere vertalingen. Waar een klein landje goed in kan zijn. Maar goed, I digress. Richtlijn 8 heeft betrekking op vertalingen van teksten. De velden Name en Description lijken het zelfde, maar er is een cruciaal verschil dat verder gaat dan veldlengte. De naam van iemand of van een object is in alle talen het zelfde. Mijn naam is ‘Florian’, in het Nederlands, Engels, Duits en zelfs in het Spaans. Mijn omschrijving (of bio) is per taal anders. Dat wil zeggen: de inhoud is het zelfde, maar de tekst is anders. Name is 1 veld; Description is meerdere velden. Goed genormaliseerd stop je vertalingen in twee tabellen: TextEntries en TextTranslations. Het veld Description wordt een foreign key naar de eerstegenoemde tabel waarvoor meerdere vertalingen worden opgeslagen in de laatstgenoemde tabel. TextTranslations hebben twee velden: LCID en Translation. De LCID is een algeheel gebruikte afkorting voor landen en culturen. Voorbeelden zijn: nl-nl, nl-be, en-us, en-gb en fr-fr. Houd deze afkortingen aan, ook als je slechts de het eerste deel (de locale) gebruikt.

Richtlijn 9 gaat ook deels over locaties, maar dan tijdzones. Gebruiker, software en database werken niet op één computer. De website-bezoeker zit in Australie, gebruikt een webserver in Singapore die in verbinding staat met een database op Schiphol. Een extreem voorbeeld, maar ik wil hiermee aangeven dat de vraag: ‘hoe laat is het?’ zo maar drie antwoorden op kan leveren. Daarom is het goed om de ‘tijd’ van één computer/server af te halen. De database-server is hiervoor geen gekke optie. Houd er ook rekening mee dat de database-server fysiek kan verhuizen naar een andere tijdzone. Sla daarom datums op in een tijdzone-onafhankelijk format, het UTC-formaat.

Tot slot (om netjes, doch bij stom toeval, op het ronde aantal van 10 richtlijnen te komen) twee losse tips. Soms zijn properties van de classes die je in een database op wilt slaan zo divers en onvoorspelbaar, dat er op voorhand geen mapping van de maken is. Als een NO-Sql-oplossing  overkill is, sla objecten dan geserialiseerd in de database op. Doe dit niet binair, maar kies voor een XML-formaat. Dit maakt het debuggen, en het maken van wijzigen velen malen eenvoudiger. Kies voor ontwikkelgemak als er geen zwaarwegende performance-argumenten zijn. Kies er om dezelfde reden voor om geen documenten en afbeeldingen in de database op te slaan. Hou deze op de harde schijf en sla in de database alleen het pad naar de bestanden. Deze tip geldt zeker waarneer je werkt met een web-applicatie.

Tips en inzichten zijn welkom.

Het ondernemersbonus-kwadrant

Ik ben het boek Managing the Professional Service Firm van David Maister aan het lezen. In het eerste hoofdstuk legt hij uit dat een onderneming drie doelen kan hebben: winst maken, waardevergroting of een instituut worden. De eerste twee had ik zelf ook al bedacht, de derde is een mooie aanvulling.

Een ondernemer is ondernemer omdat hij/zij iets meer wil dan een vast dienstverband. Zeker in Nederland is het goed toeven als werknemer. Waarom zou je je nek uit steken? Wat is de extra bonus die een ondernemer verwacht te krijgen vanuit het ondernemerschap? Ik zeg hiermee niet dat een ondernemer altijd een bonus krijgt of hier zelfs ook maar recht op heeft. Het gaat mij om de motivatie van ondernemer. Ik ga er, voor het gemak, vanuit dat de ondernemer in kwestie een boterham verdient met zijn bedrijf en bovenop die boterham nog iets extra’s ambieert. Laat ik vanuit die gedacht de drie door David genoemde doelen toelichten.

Winst is een logische. De ondernemer streeft ernaar winst te maken zodat hij als ondernemer meer geld verdient, dan hij in loondienst ooit zou kunnen. Hij kan er ook voor kiezen het geld dat hij zou kunnen verdienen te investeren. Hiermee laat hij zijn bedrijf groeien. Mocht hij een koper vinden dan verzilvert hij de opgebouwde waarde. De Engelse term Capital Gain vat dit principe mooi samen. Tot slot kan een ondernemer een hoger ideaal nastreven. Hij wil iets opbouwen dat groter is dan hemzelf. Een instituut dat hem zal overleven.

Hoewel ik deze drie doelen logisch vind, miste ik er een. Er moest een vierde zijn. Ik had de typische middenstander (kruidenier) in gedachte. Geen van de drie, door David genoemde, doelen lijkt van toepassing. Er zijn genoeg ondernemers die geen grote winst maken, die geen groot bedrijf opbouwen en die van hun onderneming geen instituut maken. Komt dit doordat ze wel het doel hebben, maar mislukken? Ik denk het niet. Er is een vierde doel, en dat is vrijheid. Er zijn zat ondernemers die het allemaal prima vinden en voor wie vrijheid precies de bonus is die ze zoeken.

Aangezien ik een blauwe maandag business-consultant ben geweest, probeerde ik deze vier doelen in een twee-bij-twee-matrix te plaatsen. Wonderbaarlijk genoeg koste dat slechts een luttele vijf minuten. De twee dimensies zijn namelijk als volgt: lange termijn versus korte termijn, en materieel versus immaterieel. Het is denk ik voor iedere ondernemer interessant om te bepalen waar hij in het kwadrant zijn bonus wil halen.

lange termijn bedrijfswaarde instituut
korte termijn winst vrijheid
materieel immaterieel

Waarschijnlijk is een knappe kop hier al eens op gekomen. Ik wist het in ieder geval niet, en vind het een uitvinding. In volgende blog-postings zal ik er meer over schrijven.