Ik ga graag op bezoek bij collega’s en concullega’s. Naast dat het goed is voor mijn netwerk, is het gewoon een hele mooie gelegenheid om van elkaar te leren.

Een van de punten waar ik vaak een suggestie toe doe is het maken van een ‘ontwikkelaars manifest’. Niets bijzonders, in de basis gewoon een documentje met een aantal afspraken en richtlijnen voor het ontwikkelteam, maar wat mij betreft een documentje met enorm veel voordelen.

Om te beginnen dwingt het schrijven van een manifest tot reflectie. Hoe wordt er ontwikkeld? Wat wordt er gedaan met tussenresultaten? Waar laten we de programmatuur? Hoe wordt er getest? Hoe wordt er opgeleverd?

Het schrijven zorgt vaak voor een herziening van de (vaak tot dan impliciete) procedures voor ontwikkeling en release. Vaak met snellere/meer foutloze opleveringen als gevolg.

Een ander voordeel is dat het manifest zorgt dat alle ontwikkelaars op dezelfde lijn komen. Door het manifest wordt duidelijk wat men van elkaar kan verwachten en wordt de code geschreven  o.b.v. een gedeelde standaard, waardoor ontwikkelaars flexibeler zullen worden in het aanpassen en beoordelen van elkaars werk. (feitje: een regel code wordt 8 keer vaker gelezen dan geschreven.).

Zelf ééntje schrijven? Neem ter inspiratie onderstaande kopie van het concept manifest voor mijn huidige opdracht. Merk op dat de afspraken redelijk abstract zijn. De concrete procedures worden door het team zelf geschreven in aparte handleidingen.

Maatwerk manifest.

1. Met maatwerk veranderen we geen standaard programmatuur.
   Uitzonderingen worden in het team besproken.

2. Het doel, alle ontwerpbeslissingen en de plaats binnen de architectuur van het maatwerk wordt gedocumenteerd..
3. Al het maatwerk wordt vergezeld door unit-tests.
4. Al het maatwerk wordt vastgelegd in subversion.
   Vermeld story of issue-nr bij checkin.

5. Het maatwerk (de programmatuur) is zelf beschrijvend of wordt vergezeld met verklarend commentaar/(java)doc
6. Maatwerk wordt opgeleverd met buildscript/instructie t.b.v. Jenkins-CI.
   t.b.v. uitvoeren tests, compileren en deployen.

Richtlijnen:

Aan alle teamleden de aanbeveling om ten minsten notie te nemen van de volgende aanbevelingen, en waar relevant toe te passen binnen het eigen werk. Onderstaande betreft een verzameling van tips & regels uit eigen ervaring of literatuur.

Software design

Best practices

1. Weest bewust van veel voorkomende design patterns. Je collega’s gebruiken ze.
2. ‘Designing for test’ zorgt voor een beter ontwerp door vermindering in afhankelijkheden, formelere interfaces en betere abstractie & modularisatie.
3. Identificeer de elementen die mogelijk onderhevig zullen zijn aan verandering. Scheid en isoleer deze.
4. ‘Schets’ je functies/klassen/packages eerst uit op papier. Dit scherpt je concepten, toetst je aanpak en maakt het beheersbaarder.
5. Pas ‘information hiding’ toe. (Wat moet de buitenwereld weten?)
6. Streef naar loose coupling.
   1. Zoveel mogelijk onafhankelijk van andere modules.
   2. Duidelijke lijntjes/relaties.

Code-kwaliteit

Naamgeving

1. De naam beschrijft zo volledig mogelijk het doel.
2. Geen cryptische ambigue termen.
3. Liever lang en duidelijk, dan kort en verwarrend.
4. Namen als i en j zijn geaccepteerd voor simpele loops.
   1. Gebruik een betekenisvolle naam bij lange loops, lange blocks of geneste loops.
   2. Gebruik ook for—each.
5. Houdt status-variabelen specifiek. B.v. dataReady, needsRecalc, containsErrors. Ipv flag, status, error.
6. Ook tijdelijke variabelen hebben een naam.
7. Booleanse variabelen hebben een naam die impliceert dat hij waar/niet waar is.
8. Zorg dat de members van ENUMS herkenbaar zijn. B.v. door prefixing.
   enum color {color_red, color_blue)
9. Java: Baseer je code-style op de java/eclipse conventies. Conformeer je stijl waar nodig.
   1. Probeer bij het aanpassen van code – in een ander zijn stijl- zijn stijl ‘licht’ te adopteren als dit de leesbaarheid vergroot.
   2. I en j zijn indexes.
10. Constanten zijn in CAPS.
11. Class/Interface: Alle woorden beginnen met een hoofdletter.
12. Variabelen: beginnen met een kleine letter, daarna alle woorden met een hoofdletter.
13. Underscore ‘_’ wordt niet gebruikt behalve in CAPS.
14. Afkortingen: prima, als ze maar bekend zijn.
15. Javascript: Schrijven met als doel de filesize klein te houden bestaat niet. Gebruik een buildscript om je jeavascript te compileren, zoals de YUI compressor

Variabelen

1. 1 variabele heeft 1 doel/functie. En nooit een tweede (verborgen) functie.
2. Controlleer of input variabelen valide zijn (precondition checks)
3. Beperk de ‘distance of declaration’. De ruimte tussen assignment en 1^e
4. Declareer (of her initialiseer) een variabele bij voorkeur net voor gebruik.
5. Groepeer gerelateerde statements. Splits ze eventueel op in aparte functies of scope-blocks.
6. Begin altijd met de meest beperkte scope (geldt uiteraard ook voor functies en classes).
7. Wees bekend met de termen/concepten: coding time, compile time, load time, object instantiation time en just im time.
8. Latere binding-time van variabelen verhoogt flexibiliteit.
9. Voorkom in ieder geval magic numbers (coding time).

Classes & packages

1. Betekenisvol, de naam beschrijft het doel.
2. Voorkom imperatieve afhankelijkheden in aanroep tussen publieke functies.

Maatwerk IBM Content Navigator

1. Javascript: Er wordt geen gebruik gemaakt van extra plugins zoals JQuery. Uitgangspunt is Dojo.
2. Gebruik altijd asynchrone communicatie. Ken het scoping concept van closures.
3. Bij plugins buiten het standaard plugin model
   1. Houdt extra rekening met naamgeving / beschrijving.
   2. Documenteer!
4. Verkies ICN services boven webservices.
   1. Juist i.v.m. security.
   2. Plaats ‘generieke services in een generieke service plugin.
   3. Service exposen naar Workflows? Dan wel via webservices, maar met re-use (import) van de service.
5. Voor extensies buiten het plugin model:
   1. Houdt rekening met conflicten door andere plugins (b.v. Enterprise Records).
   2. Weet wanneer je moet/kan kiezen voor een object-override of klasse override.
   3. Gebruik dojo mixin,extend, ..
   4. Je opties zijn: override, monkey patch prototype
6. Zorg voor een passende betekenisvolle naam/omschrijving.

Een tijdje terug sprak ik een aantal conculega’s die nog nooit van ‘continuous integration’ (CI) hadden gehoord. Ze hingen dan ook aan mijn lippen toen ik vertelde hoe ons (scrum)project ondersteund wordt door Jira, Jenkins en Subversion.

Nu is onze CI uitwerking helemaal geen rocket science – en dat hoeft ook helemaal niet gezien het formaat van ons project – maar feit is dat zelfs een simpele implementatie niks hoeft te kosten (tijd/geld) en enorm veel kan opleveren (tijd en kwaliteit).

Aan het einde van het gesprek werd gevraagd of ik onze inrichting zou willen toelichten, welnu bij deze:

Als eerste is het belangrijk te begrijpen dat we een aantal uitgangspunten hebben gesteld.

1. Ontwikkelaars moeten onafhankelijk van elkaar kunnen werken, zonder elkaar in de weg te zitten.
2. Ontwikkelaars moeten hun eigen werk kunnen testen en het werk van anderen ‘collegiaal kunnen toetsen’.
3. Ontwikkelaars dienen zich geen zorgen te maken over de het bouwen, configureren en distribueren van hun software over de systemen.
4. De relatie tussen code en stories/bevindingen is zo zichtbaar mogelijk.

Versiebeheer

Om invulling te geven aan deze doelen zijn we begonnen met het installeren van een versiebeheersysteem. Hoewel een decentraal-versiebeheersysteem wellicht logischer zou zijn (immers doel 1), hebben we in dit geval gekozen voor Subversion(SVN). Primair omdat ons team daar de meeste ervaring mee heeft, secundair omdat Subversion het maken van branche‘s ondersteund, waarmee we precies invulling geven aan de decentrale eis.

De toegang tot SVN is aan de ontwikkelaars zelf. In de praktijk zien we dat sommigen het liefst werken met de Eclipse plugin, anderen prefereren de (windows)shell-extensie ‘Tortoise-SVN’.

Issue tracking & Scrum-board

Voor wat betreft het kunnen registreren/managen van stories en issues hebben we JIRA+Agile geïnstalleerd. Jira is in de basis een issue-tracker, waarin je met wat configuratie de hele developmentflow in kwijt kan. In ons geval wilt dat zeggen dat nieuw geregistreerde issues eerst beoordeeld dienen te worden door een Informatie Analist, deze beoordeeld/geeft prioriteit en wijst ze aan een developer toe. De developer pakt de issues op en na afronding komen ze in de ‘bak’ om collegiaal getoetst te worden door een andere developer. Na goedkeuring worden de issues doorgezet naar de testers, die een volledige integratietest uitvoeren op hun eigen ‘schone’ testomgeving.

Tijdens het gehele proces heeft men de mogelijkheid tijd te registreren & opmerkingen te plaatsen  over het verloop van de bevinding. Hierdoor zijn we in staat om binnen een handomdraai een release-document/samenvatting te maken. Aanvullend zorgt de Subversion-plugin er tevens voor dat wijzigingen in de code gekoppeld worden aan het issue/story, waardoor we het perfecte naslagwerk hebben mochten in de toekomst vragen ontstaan.

Screenshots van Jira + Scrumbord volgen.

Jenkins CI

Last but not least maken we gebruik van Jenkins. Jenkins is het platform dat bijna al onze software ”test’, build’, ‘deployed’ en onze ontwikkelaars op de hoogte stelt wanneer zij code hebben ingechecked die niet functioneert. Dit zowel voor onze .NET als java aonderdelen.

Het configureren van Jenkins is belachelijk simpel, in het simpelste geval koppel je aan de .ant file van je eclipse-project, en specificeer met behulp van wat shell/bat opdrachten waar de resulterende .jar/.exe files naartoe moeten. Leuker wordt het echter wanneer je het uitvoeren je (unit,integratie & GUI) tests meeneemt en de verantwoordelijke developers automatisch op de hoogte stelt van het falen/slagen van de build.

Eigen omgeving per ontwikkelaar

De genoemde software hierboven draait bij ons op 1 server. Hoewel dit op het moment van builds & tests erg krap is, is het voldoende. Dit voornamelijk omdat alle developers beschikken over een eigen sandbox, waarop ze werken totdat ze tevreden zijn over ‘hun’ code. Op dit moment wilt dat ‘slechts’ zoveel zeggen dat iedere developer beschikt over een eigen applicatieserver (Liberty profile 8.5.5. – of zwaarder, afhankelijk van de developer) waar hij ‘live’ zijn aanpassingen kan testen. Hierdoor is er altijd een werkende centrale-ontwikkel-omgeving waarop de developers elkaars werk kunnen testen en beoordelen – en zitten ze elkaar nooit in de weg.

Toekomst

Uiteraard is er ruimte voor veel verbeteringen, punt is echter dat ons project op dit moment niet veel meer nodig heeft dat wat we nu hebben. Developers kunnen ‘hun ding doen’, zitten elkaar niet in de weg en hoeven zich geen zorgen meer te maken over de configuraties. Onze testers ontvangen betere builds en de SCRUM master heeft altijd een up to date overzicht.

Ah, en wellicht mijn persoonlijke favoriet. Alles is traceerbaar!

Relevante links:

Subversion, Eclipse plugin voor Subversion, Windows Shell Client voor Subversion (Tortoise), Jira & Jira Agile, Jenkins

Screenshots volgen.

Ik ben gek op natuur, alles wat groen is en alles wat leeft. Daarbij heb ik vaak fascinatie voor de meest kleine dingen – het soort waar de meeste mensen aan voorbij lopen -, waardoor een wandeling met mij vaak twee keer zo lang duurt (3 als ik mijn camera meer macro-zoom objectief bij me heb).

Sinds ik nu een tijdje een aquarium heb (verjaardagscadeau van mijn broer), kan ik er niet onder uit om om er dan ook het beste van te maken, en daarbij is het met name de plantengroei die me fascineert. De bewoners zijn wat mij betreft bijzaak omdat ik gemerkt heb dat het hebben van een florerende plantengroei een factor 10 lastiger is dan het houden van vissen :).

Welnu, na vele mislukte pogingen het afgelopen jaar om een klein rot plantje (hemianthus callitrichoides) aan het groeien te krijgen zonder algenexplosies, ben ik sinds een week of drie weer met verse moed aan een nieuw initiatief begonnen, dit keer echter gewapend met upgrades om een aantal van de problemen in mijn aquarium op te lossen.

Probleem 1 – Te weinig licht.

Standaard komt de fluval edge 2 met een reeks dag/nacht ledjes die voldoende zijn voor de minder eisende planten & vissen, maar onvoldoende zijn voor de meer licht eisende planten, en in het geval van mijn ambitie – veel te weinig licht opleveren. Dit was voor mij de reden dat mijn planten ‘wegsmolten’.

Geïnspireerd door enkele gasten op het internet heb ik dan ook een soortgelijke implementatie gemaakt. Samengevat is het niets meer dan een set aan cree leds gelijmd op een groot aluminium koelelement. Foto’s/de how to zal ik nog eens verwerken in dit bericht.

Probleem 2 – Te veel organische stoffen

Een ander probleem was een te zware initiële belasting van wat betreft organische stoffen. Deze belasting had ik doordat ik hout gebruikte dat blijkbaar net iets te snel wegrotte. Op het internet vernam ik dat zo’n beetje alle fruitsoorten geschikt hout produceren voor in het aquarium. Dus hoewel die peersoort waarschijnlijk prima moet kunnen in mijn aquarium, lijkt het me verstandiger het en hoewel peer in mijn geval waarschijnlijk ook prima kan, lijkt het me verstandiger hout in de opstartfase achterwegen te laten.

Probleem 3 – Geen / te weinig voedingsstoffen

Tot voor kort voegde ik zelf voedingsstoffen toe a.d.h.v. wat mijn chemisch setje vertelde waar een te kort aan is. Hiermee was ik niet echt in controle en ik kon geen rechtlijnige verbanden vinden in de hoeveelheid gemeten & toegevoegde stoffen.

Na wat googlen kwam ik de theorie van de de ‘Estimative Index of dosing’ (info @Tom Barr) tegen. Bij deze doseermethode doseer je dagelijks om je planten van een niet-limiterende hoeveelheid voedingsstoffen te voorzien, en voer je wekelijks 25-50% waterverversingen uit om te zorgen dat de hoeveelheid voedingsstoffen niet excessief oploopt.

De theorie is overigens ook dat dit algengroei helpt tegen te gaan omdat de meeste algen ontstaan door een tekort aan voedingsstoffen in tegenstelling tot een overvloed. Ik ben echter nog niet overtuigd, maar.. het klinkt goed!

Probleem 4 – Handmatig doseren zorgt voor instabiliteit.

Naast een tekort aan licht, is m.i. het grootste probleem het handmatige doseren van voedingsstoffen. Gezien er – pak ‘m beet – slechts 45 liter in het aquarium zit, is het wel heel erg makkelijk om het ecosysteem te verstoren door een inconsistent doseerritme.

Om dit te verhelpen ben ik aan de slag gegaan met Arduino in combinatie met een tweetal peristaltische pompen.

Arduino is een goedkoop, toegankelijk ‘platform’  (printplaatje met een chipje), waar je met je met zelfgeschreven code in staat moet zijn legio van apparaten aan te sturen. Omdat alles nogal compact is, heb ik kans gezien alles mooi weg te werken in de achter-behuizing van het aquarium.

Welnu, wat ik gemaakt heb: Een Arduino computer, die mijn aquarium volledig bedient. Dat wilt zeggen: bediening van Licht, Co2 en vloeibare voedingsstoffen. Aanvullend heb ik de arduinocomputer ook voorzien van relais & stopcontact voor heater & pomp, waardoor ik (als je de 3 slangetjes + 1 stekker voor de co2 & flesjes voeding wegdenkt), slechts 1 stopcontact nodig heb wat er een stuk cleaner uit ziet!:)

Resultaat:

Al met al staat ‘het bakje’ er erg goed bij (2 weken na dato). In hoeverre het stabiel gaat blijven is de vraag, maar ik heb goede hoop. Tot die tijd heb ik in ieder geval de boel erg elegant weg gewerkt!

Update 16 februari

Sinds ik besloten heb mijn tijd beter te besteden ben ik vrijwel direct weer achter de computer geschoven. En wel om lekker te gaan ‘nerden’.

Het maken van software is al sinds mijn 13e mijn grootste passie. Ik kan er veel creativiteit in kwijt en ik vind er leuke uitdagingen in. Geen wonder dan ook dat het mijn beroep geworden is.

Een van de wat ‘serieuzere’ projecten van de afgelopen weken is IvoFinds: een website waarmee naar producten gezocht kan worden in meerdere webwinkels tegelijk. Het gebruik is simpel, type een zoekwoord in, kies welke webwinkels bezocht dienen te worden en zoek vervolgens tussen de productfoto’s het product uit dat je wilt hebben. Dit is vooral ideaal wanneer je met name geïnteresseerd bent in ‘hoe het product er uit ziet’.

Ivofinds is redelijk snel tot stand gekomen, maar is nu al erg bruikbaar. Vandaar dat vanaf heden dan ook de beta online staat. Voor wat betreft de komende weken zal ik voornamelijk vragen om nieuwe webwinkels aan te sluiten. Op de langere termijn heb ik echter meer geavanceerde ideeën in petto :).

Momenteel kun je gelijktijdig zoeken in de volgende winkels: 12Cook.nl, Amazon (VS, Duitsland en Engeland), BobShop.nl, Body & Fit, Bol.com, Bristol, DealExtreme, Ebay.nl, Fashion 4 Men, Fonq, Gamma, Hema, Ikea, Kijkshoop, Kookpunt, Kruidvat, Kwantum, Label54, MAX Meubels, Modern, Omoda, V&D, Voordelig Vitaal, Wehkamp, Woonexpress, Woonwinkel Online en Zalando.

Check it out:)

http://www.ivofinds.nl

Een tijdje terug had ik weer eens een tv-serie periode. Waarschijnlijk heel herkenbaar, een periode waarin je iedere avond tot laat tv-series kijkt. Voor mij was het een afwisseling van Breaking Bad, Family Guy, Futurama, Under the Dome, Game of Thrones, Once upon a time, da vinci’s demons en nog een paar.

Allemaal leuk en aardig, maar gaande bekroop me het gevoel dat ik mijn tijd aan het verdoen was. Volkomen rationeel overigens, want wat voegt het nu toe? Los van wat solitair vermaak eigenlijk niets, en zo kwam het voornemen om mijn tijd beter te besteden.

Het idee is om te blijven bewegen. Dingen te doen die me uitdagen, waar ik iets van leer, of waar ik mijn tijd in ieder geval beter besteed.

En, om me te helpen herinneren in beweging te blijven, heb ik dit blog gemaakt, waar ik mijn ambities, ideeën en realisaties wil vastleggen.