Shoptalk

Er is wat .net code dat ik moet aanpassen. Ik heb hiervoor een Windows XP VMware image met Visual Studio ingericht. Ik dacht slim te zijn en de code uit te checken op een OS X shared folder. Hierdoor kan ik ook terugvallen op mijn Unix tools, met name voor versie beheer, of op Textmate.

So far so good. Er is echter een klein probleempje: een shared network folder zit in een andere security zone voor het .net framework. Mijn gecompileerde assemblies willen dan niet draaien. De vraag is waarom dit op deze manier is geregeld. Ik zou bij het aanmaken van een share op OS nivo willen classificeren of iets veilig is of niet. Waarom het .net framework apart bepaald dat een netwerk share minder veilig is, is mij niet helemaal duidelijk. In de Unix wereld heb je een mount en is er geen onderscheid tussen remote en lokaal. Nu moet ik expliciet de assemblies gaan “trusten” en dan heb ik weer certificaten nodig e.d. Een beetje omslachtig voor een scriptje dat ik nog een laatste keer moet draaien.

Handige user story template.

Nog even arrogant als altijd maar toch wel nuttig dit praatje van DHH.

Take notes:

• het payed subscription model werkt beter dan gokken op een volgende Facebook.
• het is belangrijker focus te hebben dan lange dagen te maken. Niet werken om ‘binnen’ te zijn en dan van het leven genieten, nu werken en ook nu genieten.

Individuals and interactions over processes and tools

Zat gisteren bij een lezing over Visual Studio Team System en ik kreeg er een wat benauwd gevoel bij. Toen ik bovenstaande quote las, wist ik weer waarom.

Ik hoop niet dat organisaties de individuals en interactions vergeten als ze VSTS willen gebruiken. De verleiding is namelijk groot om er even een software factory mee op te willen zetten.

Ben weer even getriggered door wat sessies op J-Spring om wat aandacht te besteden aan modelleren. Ik doe al jaren TDD en intussen ook al veel met rspec en BDD en ik merk dat de kwaliteit van de code daardoor enorm is verbeterd, maar over de resulterende ontwerpen ben ik nog niet helemaal tevreden.

De reden blijkt dat ik me nog steeds laat leiden door de infrastructuur, want uiteindelijk moet de code ook op een platform draaien en moet ik gebruik maken van beschikbare libraries. Maar dat is dus geen excuus. Zowel Rob Vens, als Marc Evers en Rob Westgeest, gaven aan dat je je best wel kan focussen op het probleem domein en dat je benodigde infrastructuur via wrappers of adapters van je domein kunt scheiden.

Een tweede is dat ik me nog steeds focus op het statische model en niet op gedrag. Zowel in rspec als Junit, gebruik ik wel mock’s om gedrag te controleren, maar dat doe ik meestal als ik er niet uitkom met gewone asserts, of als deze te duur zijn. Bijvoorbeeld bij communicatie met externe systemen en/of database requests.

Met rspec ben ik nu aan het proberen om de sessie’s in de praktijk te brengen. Juist doordat je zo goed kunt uitdrukken in gewone taal, lijkt het me makkelijker dan de jmock manier.

Met een CRC card als basis gaat het vrij simpel. De responsibilities kun je zo opschrijven in je spec’s met “it should” en van je collaboraters maak je mock’s. Daarna kun je verwachte interacties tussen je class en zijn collobaraters definieren.
Je kunt je class dan implementeren ook al bestaat de rest van je systeem nog niet. In ruby of een andere dynamische taal dan. Met java zul je toch eerst interfaces naar je collaboraters moeten maken, anders compileert het gewoon niet.

Ik merk dat mijn classes, zich nu net wat anders beginnen te ontwikkelen, maar ik heb nog geen complete applicatie op deze manier gebouwd om het resultaat goed te beoordelen.

Heb me geregistreerd bij de Smalltalk gebruikersgroep. Was gisteren weer wat enthousiast gemaakt over smalltalk bij de presentatie van Rob Vens. Enthousiast, in de zin dat er nog wat mee gedaan wordt.