Maar voor de rest was het mooi om anderen te leren kennen die ook met Smalltalk werken of willen werken. Dat was voor mij de grote meerwaarde voor de conferentie.

Dit is een beetje kortzichtig. Er wordt wel degelijk geld verdient, maar in een andere markt. Je kunt wel Twitter aanhalen, dat nog geen winstgevend business model heeft, maar ook gewoon 37signals. Zij maken wel degelijk winst met hun diensten op basis van rails technologie en zo zijn er nog meer.

Maar uiteraard kan DHH het zelf beter zeggen.

Waarom niet Squeak weer eens proberen dan, alles heeft tenslotte zijn oorsprong in Smalltalk. Van de gui waarmee de hele wereld dagelijks werkt, tot aan de Java virtual machine. TDD heeft inderdaad ook zijn roots in Smalltalk en je merkt al gauw waarom. In Smalltalk kun je je testen volledig schrijven en zelfs uitvoeren zonder maar ook een regel implementatie code te hebben geschreven. In Java krijg je al in je code editor allerlei meldingen als een methode nog niet bestaat en dat moet je leren negeren of je moet steeds even een lege stub implementeren, zodat de meldingen weggaat. In beide gevallen leid het af. En omdat Smalltalk dynamic typed is hoef je tijdens het schrijven van de testen nog niet te focussen op types of classes, maar alleen op het gedrag van de objecten. De bottomline is dat je echt in ontwerp modus zit, en niet in implementatie modus.

setUp
|period |

thisWeek := Week starting:
    (DateAndTime year: 2008 month: 5 day: 11).

nextWeek := Week starting:
    (DateAndTime year: 2008 month: 5 day: 18).

period := Timespan
    starting: (DateAndTime year: 2008 month: 5 day: 15)
    duration: (Duration hours: 2).

codingWork := Action during: period
                describedAs: 'some coding work' for: '1234'.

studying := Action during: period
                describedAs: 'study smalltalk' for: 'myself'.

james := Employee new.
james register: codingWork.
james register: studying.

Maar ook tijdens implementatie zijn er gemakken. De libraries in Smalltalk zijn uitgebreider en simpeler te gebruiken. Er is een hele chronology package in Squeak voor datum en tijd gerelateerde zaken. De Timespan en de Week class zijn precies wat ik nodig heb voor mijn tijdregistratie. In Java had ik zelf wat moeten maken met de Calendar en Date api’s.
Ook de collections in combinatie met closures zijn een genot om mee te werken. Het selecteren van werkzaamheden gedaan in een bepaalde week, doe ik in een paar regels code.

workdoneDuring: aWeek
^ allWorkdone select: [ :workdone| workdone isInWeek: aWeek ].

isInWeek: aWeek
^ timespan between: (aWeek start) and: (aWeek end).

Ik schat zeker een factor 10 minder code dan in Java. In het tweede stuk ben ik wel afhankelijk van library functionaliteit. Als ik in Java een Timespan en Week class zou implementeren zou het waarschijnlijk net zoveel code zijn.

De Java versie zal ik uiteindelijk ook nog maken, omdat ik daarin het TDD verhaal moet uitleggen. Ben echt benieuwd op hoeveel regels code ik meer moet schrijven.
Deze Squeak versie wil ik nog uitbreiden met een frontend in Seaside en wat betere persistence dan de image.

Het is nog steeds een templating language, maar je bent net als in Seaside wel meer met de html structuur bezig dan layout. Wellicht dat ik mijn project dan makkelijker kan overzetten naar Seaside als ik zover ben.

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.

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.

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.

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

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.