Shoptalk

Het duurt vaak een tijdje om echt in OO te denken. Het komt vaak door de associaties die we met software ontwikkeling hebben en misschien moeten we betere metaforen hebben.

We hebben het vaak over bouw en architectuur en dan leg je de associatie met de bouw wereld. In de bouw werk je met blauwdrukken en UML diagrammen hebben wat weg hiervan. Alleen zijn de objecten die je in de bouw gebruikt heel erg statisch, ze hebben alleen attributen, geen gedrag. Een steen kan wel gewicht dragen, een raam kan open gaan, maar toch zul je bij een gebouw niet denken een compositie van objecten met gedrag. Je kunt ook denken aan een machine. Heeft wel wat meer gedrag en zo, maar de individuele tandwieltjes en moertjes niet zo.

Een fabriek komt misschien beter in de buurt. Je hebt de verschillende componenten die met elkaar interactie hebben, er is dus gedrag. Je kunt de data zien als de grondstof die verwerkt wordt door de fabriek. Maar ook hier hebben de grondstoffen geen gedrag. De machines hebben dat en dan krijg je het structureel denken. Procedures die bewerkingen uitvoeren op data.

Oorspronkelijk zat de informatica in de hoek van de wiskunde. In de wiskunde ben je heel veel bezig met functies en algortimes. Dit kun je makkelijk vertalen naar code. Maar in de wiskunde leer je niet echt in objecten denken en het ligt toch meer tegen het functioneel programmeren of sql aan.

Ik heb weleens geprobeerd software te zien als een leger met soldaten. Het is opgedeeld in verschillende onderdelen met verschillende eigenschappen en verantwoordingen. Het delegeren van verantwoordelijkheden is heel natuurlijk, een generaal gaat niet micro managen. Je hebt een duidelijke base class, iedereen is soldaat en je denkt heel natuurlijk in termen van gedrag.
Je ontwikkelt je software net zoals je een leger ontwikkeld: je definieert gedrag in je objecten. Je bereid ze voor op actie. In plaats van architecten heb je nu strategen.

Ondanks mijn morele bezwaren tegen dit metafoor vind ik dat heb beter past bij object georienteerd denken dan de bouw of proces metafoor. De volgende keer dat ik een class ontwerp, zal ik denken aan een soldaatje dat een taak moet uitvoeren.

Ben weer in een coachende rol terecht gekomen en het leek me zinvol om terug te kijken op hoe ik op mijn manier van werken ben gekomen. Ik begin met mijn belangrijkste stokpaardje: Test Driven Development.

In 2001 ben ik begonnen met het schrijven van unit testen voor mijn code. Bij het coderen bedacht ik van tevoren eerst wel de klassen/modules en methodes, maar ging bij het implementeren ervan eerst de testen voor schrijven. Het test first was dus op methode nivo. Het belangrijkste effect was dat ik precies wist wanneer ik klaar was. Voorheen was er toch altijd het knagend gevoel dat je iets vergeten was, of dat je te lang door ging met de code terwijl het al af was.

Een ander gunstig side effect kwam door de beperking van de testframeworks: het moeilijk kunnen testen van de GUI en de database. De gui omdat het vrij lastig is om deze aan te sturen, de database omdat ik met de steeds wijzigende inhoud van de database zat. Om toch zoveel mogelijk code te kunnen testen scheidde ik automatisch mijn gui en database code van mijn midden laag.

De volgende stap was het leren werken met mock’s. In eerste instantie gebruikte ik de mockframeworks als stub voor de database in testen, maar gaandeweg leerde ik dat het bij mock testing om het valideren van gedrag gaat. Het kan best lang duren voordat je dit goed snapt, omdat je best wel veel tijd kwijt kan zijn aan het maken van je mock testen. De testen vergen veel boilerplate code in java, je kunt alleen mocken van een interface, en het resultaat vind ik erg slecht leesbaar.

De stap van mock testing naar Behaviour Driven Development is erg klein. Het rspec framework maakt effectief gebruik van de engelse taal om in de juiste termen te denken. Het ingebouwde mock framework vergt dankzij ruby minder boilerplate code en de examples zijn beter leesbaar hierdoor. Toch maakte ik bij rspec eerst nog de fout om vooral de state van de objecten na een actie te controleren en niet zozeer naar het gedrag van de objecten te kijken.

Ik gebruik nu rspec meer als design tool om tot een ontwerp te komen en inzichten te verkrijgen. Ik ben dan meer bezig met de verantwoordelijkheden van objecten en interactie tussen objecten. Eigenlijk dus een beetje volgens de CRC card methode. Het heeft wel jaren geduurd voordat ik deze context switch heb kunnen maken en waarschijnlijk is het inzicht pas gekomen nadat ik smalltalk had geleerd.

Hoewel het totale leertraject jaren geduurd heeft en ik nog steeds bezig ben, was de eerste stap vrij snel gemaakt en kan ik mij daar geen grote leercurve herinneren. Ook geen discipline problemen, de directe feedback van de groene balk gaf me een ‘rush’ en dat was verslavend. Ik denk dat, dat ook de essentie is van het succesvol omarmen van TDD. Als je er niet dat fijne gevoel van krijgt kost het alleen maar energie. Dat is namelijk de enige verklaring die ik kan bedenken voor het feit dat zoveel programmeurs er nog moeite mee hebben. Ik zal daar rekening mee houden als ik het overbreng en focussen op de snelle feedback.

Ik kwam een artikel tegen met een soort Ruby versie van Seaside. De code heb ik uitgeprobeerd en op github geplaatst. Het is van een sessie met Avi Bryant, waar hij de Seaside concepten probeert uit te leggen aan de hand van Ruby code. De code en artikel maken heel duidelijk dat de concepten bijna haaks staan op die van Rails.

Op dit moment is Rails vele malen succesvoller dan Seaside, maar dat zegt weinig over wat ‘beter’ is, omdat Seaside gewoon minder gebruikt wordt vanwege Squeak. In dit infoq artikel zegt DHH wat meer over de verschillen tussen Seaside en Rails.

In zijn overzicht van ruby implementaties is Charles Nutter eentje vergeten: Maglev. Deze is gebaseerd op Smalltalk VM technologie en heeft een focus op schaalbaarheid. Net als met Smalltalk, zul je ook image based kunnen werken.

Op Railsconf zal er een sessie zijn over Maglev. Charles Nutter kun je op Ruby en Rails Conf horen spreken in Amsterdam.

Dit weekend begonnen met de overstap op Git. Een google code project heb ik overgezet naar github. Github ziet er in elk geval beter uit dan google code, het mist alleen een ticket systeem. Als je eenmaal de git equivalenten van subversion commando’s kent, kun je gewoon verder als normaal. Het belangrijkste verschil is dat je lokaal kunt committen. Het gevolg hiervan is dat ik nog kleinere commits doe dan voorheen.

Ik probeer het nu ook te gebruiken voor mijn deployments. In subversion zet je configuratie bestanden met ip adressen en passworden niet in de public repository. Bij deployment moet je hiervoor een script of iets anders gebruiken om je server specifieke settings in te stellen. Voor de server hou ik nu een server specifieke git repository bij met de settings. Bij deployment pulled deze de wijzigingen van de master repository. Als deze procedure werkt heb ik ook gewoon een log van mijn wijzigingen aan server settings.

Het hoeft natuurlijk niet alleen om configuratie te gaan, maar ook om content. Ik heb nog geen CMS in mijn applicatie en moet html pagina’s nog handmatig aanpassen. De master repository heeft een barebones default html. De server repository heeft aangepaste instantie specifieke html. Hierdoor kan ik het integreren of inbouwen van een CMS in mijn applicatie nog even uitstellen.

Kreeg net een Mac OS X software update binnen en geheel onverwacht zat daar Java 6.0 bij. Helaas alleen voor 64 bit Intel platforms. Ik heb me nog heel weinig verdiept in Java 6.0, mede vanwege het ontbreken ervan op de Mac, dus heb ik dit weekend even wat te doen.

Voor een migratie is een tool geschreven om mainframe data in de vorm van tekst bestanden te converteren naar xml. Het is een winapp met een GUI, waarmee je de juiste import bestanden kan selecteren voor conversie. Het migratie proces bestaat uit meerdere stappen en voor elke stap is er dan weer een knop op het scherm. Een jaar na dato zijn de oorspronkelijke makers van dit tool weg van het project en moet een ander team nog een keer een migratie uitvoeren. In welke volgorde de stappen uitgevoerd moeten worden en welke type bestanden bij welke stap horen vergt behoorlijk wat achtergrond kennis die niet meteen paraat is bij het nieuwe team. Het gevolg is dat het team teveel tijd kwijt is aan uitzoekwerk.

Hoe had dit beter opgelost kunnen worden? Betere documentatie, goede overdracht? Waarom geen script gebruiken i.p.v. een GUI. Een script, en met name een build script, heeft vele voordelen t.o.v. een GUI:

• makkelijker aan te passen dan code dat eerst gecompileerd moet worden: je hoeft dan geen invoerschermen te maken voor user input, argumenten kun je in het script zelf steeds wijzigen. Gecombineered met versie beheer, heb je dan ook nog een historie van wat er allemaal geconverteerd is.
• het is te automatiseren en zorgt voor een Repeatable Process
• je kunt makkelijk dependencies tussen taken definieren als je rake of ant gebruikt
• beschrijvingen zijn makkelijker te maken: aanroep met parameters in een readme file, op de wiki, of als commentaar in het script

Het voordeel van een GUI is dat het intuïtief is, alleen ging dat in dit geval niet op vanwege de relatief complexe achtergrond die je nog moet hebben. Je weet nu dat je een knopje in moet drukken, maar welk bestand je dan moet selecteren is niet meteen duidelijk.

De redenen waarom een GUI is gemaakt zijn waarschijnlijk:

• Windows gebruikers zijn niet comfortabel met de command line
• Scripting talen zijn niet aanwezig op Windows of hebben een negatieve associatie

Er is in elk geval een hemelsbreed verschil tussen Unix ontwikkelaars en Windows ontwikkelaars op dit gebied. Nou hoef je niet zo fanatiek te zijn als de Unix wereld, maar het is belangrijk te weten dat het ook anders kan.

Toen ik een paar jaar geleden overstapte van ontwikkelen met Microsoft producten naar ontwikkelen op Java en Unix, vond ik het best wel lastig om keuzes te maken. Je had verschillende Unix/Linux smaken, een diversiteit aan open source tools en dan heb ik het nog niet over al de Java frameworks die er bestaan. Gelukkig is het gratis en is er een goed package management systeem, zodat software installeren een kwestie is van een apt-get,een port install of een verwijzing naar de maven repository.

Ik ben nu weer even terug op het Windows platform en dan blijk je ook hier intussen veel keuze te hebben. Je hebt verschillende smaken van Windows: 32 bit of 64 bit, XP of Vista en dan nog de varianten: Home Basic, Home Premium, Business en Ultimate. Er er zijn ook nog de server versies. Het is alleen niet gratis, dus moet je vooraf bepalen welke versie het meest geschikt voor je is. Of je neemt een msdn abonnement, zodat je met alle versie’s kan experimenteren.

Dan komt de volgende stap: je ontwikkelomgeving, de IDE. Om een beetje .Net te programmeren heb je Visual Studio nodig. Er is een gratis Express Edition, een Standard Edition van een paar honderd euro en een Professional Editon van duizend euro. Wil ik met Teamsystem werken dan ben ik meteen vijfduizend euro kwijt en moet ik een keuze maken tussen: Architect Edition, Development Edition, Database Edition of Test Edition. Als ik geen keuze kan maken heb ik voor tienduizend euro alle versie’s.

Even ter vergelijking: voor dat bedrag koop ik een 8 core Mac Pro met raid harddisk systeem en twee breedbeeld schermen waarop XCode, Subversion, Python, Java, Ruby, noem maar op reeds is geinstalleerd. Welk platform denk je dat startups kiezen?

Paul Graham:

...Nearly all the people we fund at Y Combinator use Apple laptops. It was the same in the audience at startup school. All the computer people use Macs or Linux now. Windows is for grandmas, like Macs used to be in the 90s…

Maar het gaat me niet zozeer om de prijs, maar om dat het zo lastig is de juiste keuzes te maken. Ik vraag me of deze wildgroei aan variaties door een vraag uit de markt komt of dat dit ergens in een ivoren toren van de marketing afdeling is bedacht. Met deze prijzen zijn het nooit de ontwikkelaars zelf die de keuze maken, dus misschien is dit ook gericht op de managers die over de budgetten gaan, zo van: ik heb een standaard developer, twee professionele developers, een architect, twee testers en een database specialist.

Martin Fowler:

... The reason we have so much bloatware in IT is because IT purchasing decisions are usually made on golf courses by people who have lost meaningful contact with the realities of software development…

Maar om Microsoft te helpen zal ik mijn wensen voor een IDE als een zelfstandig ontwikkelaar die zelf zijn software koopt neer te zetten:

• een prijs van rond de 300 euro, maximaal 500 euro
• integratie met een modern versiebeheer systeem
• integratie met een test unit framework
• een open plugin systeem voor uitbreidingen
• de standaard syntax highlighting, code completion en debugging features
• een refactoring engine

Ik hoef geen database integratie, uml diagrammen, integratie met ticket systeem of integratie met een application server. Dit kan ik allemaal buiten de IDE om doen. Waarschijnlijk komt de Standard Edition aangevuld met een Subversion en NUnit plugin het beste bij mijn ideaal.