JAOO, dag 1: Domain Specific Languages, Database Testing, Beautiful Code and Debugging

Det första spåret jag besökte på JAOO var "The Programming Experience". Sessionerna i detta spår handlade om hur vi kan ta oss an de stora utmaningar vi ser i dag: komplexa domäner, Multi Core CPUs, utvecklarproduktivitet och allt större och mer komplexa system. Det var i alla fall de utmaningar spårets värd Markus Völter såg, men det kan också ha att göra med att sessionerna i hans spår presenterade lösningar på just dessa problem.

Först ut var Charles Simonyi, mannen som gav oss Word, Excel och ungersk notation (strName, intValue etc). Simonyi har nu företaget Intentional Software Corporation som tillverkar en mjukvara, Intentional Domain Workbench, som låter dig tillverka Domain Specific Languages (DSL). Domänspecifika språk är med Martin Fowlers ord "a limited form of computer language designed for a specific class of problems". För en del handlar dessa språk om att realisera den urgamla drömmen om att domänexperterna själva ska kunna utveckla sina egna lösningar. Redan COBOL sågs av somliga som en revolution som skulle göra programmerare överflödiga eftersom man nu kunde använda ett naturligt språk för att instruera sin datamaskin. För andra handlar det snarare om att domänexperter och mjukvaruteam ska prata samma språk (jämför Domain-Driven Design) och man är på det klara med att det fortfarande är programmerarna som kommer att tillämpa språket i fråga.

Man skulle kunna säga att Intentional Domain Workbench hamnar någonstans mittemellan dessa. Rubriken på Simonyis session var "Democratizing Software Creation" och tanken är någonstans att domänexperterna har sin representation av koden och utvecklarna en annan (fortfarande kod). Med hjälp av Intentional Domain Workbench skapar utvecklarna ett domänspecifikt språk tillsammans med domänexperterna och i verktygets "projectional multi-view editing" kan man sedan representera den producerade domänkoden på olika sätt, anpassade efter rätt publik och sammanhang. Istället för WYSIWYG får vi WYNISWYG - What You Need Is What You Get.

Tycker du att det låter luddigt? Ja, det kan bero på att det var lite för abstrakt för min smak; inte ens när de visade verktyget greppade jag riktigt hur det fungerade... Men om du tycker det låter intressant kan du säkert läsa mer på Intentionals webbplats.

Simonyi höll för övrigt en party keynote som avslutning på dagen, innan festen skulle ta vid. Under en timmes tid visade han bilder från och pratade om sin senaste semesterresa. Låter det ointressant? Det kunde det kanske ha varit om det inte var så att hans senaste resa gick till en rymdstation! I april i år blev Charles Simonyi den femte civilpersonen i rymden någonsin. Det var faktiskt riktigt spännande att höra om allt från de medicinska undersökningarna hos ett 50-tal olika läkare till de åtta månader långa förberedelserna till livet på en rymdstation. Simonyi var mycket nöjd med sin resa och kan varmt rekommendera rymdsemester för den som har råd. Om man tycker det är för dyrt kan man alltid göra som han gjorde innan rymdresan och bjuda in sina tjugo närmaste vänner till tyngdlöshet på en "parabolic flight".

Min nästa session var "What Makes Code Beautiful?" med Marcel Molina Jr, en litteraturstuderande med smak för vackert språk som sadlat om till programmerare. Det lockade så klart mig som gjort en liknande resa (från idé- och lärdomshistoria till programmering ungefär). Molina tyckte länge att det var viktigt att skriva vacker kod men hade ingen teoretisk grund för att rättfärdiga sin inställning. Han studerade därför olika filosofers och tänkares tankar om skönhet och fastnade för Thomas av Aquinos tre utgångspunkter: proportion, integritet och tydlighet. Molina menar att dessa tre måttstockar fungerar som ett system av "checks and balances" för att utvärdera vad som är vackert; man kanske kan hävda en av dem framför de andra från fall till fall, men alla tre bitar måste finnas på plats för att vi ska uppleva något som vackert.

Molina visade sedan exempel på Ruby-kod som i varierande grad uppfyllde hans kriterier. Det var intressanta resonemang, men jag tycker inte att han nådde riktigt ända fram. För mig handlar kodens skönhet om hur ändamålsenlig koden är och då handlar det uteslutande om fungerande kod som är tydlig. "Fungerande" handlar förvisso om integritet och jag föredrar också att uttrycka lösningarna i så lite kod som möjligt (proportioner), men då är det snarare så att dessa principer tjänar den övergripande - den om tydlighet. Molina ger oss i alla fall verktyg att diskutera varför vi tycker viss kod är vacker och annan inte. Den efterföljande diskussionen var också intressant med postmodern kritik av Molinas klassiska skönhetsideal, resonemang kring symmetri som skönhetskriterum med mera.

Senare under dagen besökte jag en session med rubriken "Beautiful debugging" med professor Andreas Zeller från Saarland. Han hade en något annan utgångspunkt än Molina för vad som är vackert när det kommer till debugging. Zeller tycker nämligen att den vackraste debuggingen är ingen debugging alls och slog ett slag för automatisk debugging. I korthet kan man något förenklat säga att han skapat ett program som tar kod med en bugg och kör alla tänkbara varianter av koden, d.v.s. tar bort en rad här och en rad där till dess att samma bugg upptäcks och programmet kan spotta ut vad skillnaden var. Något som imponerade var att hans handledare hade påstått att det var omöjligt och att programmet i slutändan var mindre än en sida!

Zeller har också bedrivit en hel del forskning kring debugging och givit ut en bok med titeln "Why Programs Fail: A Guide to Systematic Debugging". Hur uppstår buggar? Några av Zellers upptäckter överraskar vid en första anblick. Det visar sig nämligen att buggdensitet korrelerar med utvecklarerfarenhet och test coverage, d.v.s. kod skriven av mer erfarna utvecklare och kod omgiven av flest tester har större antal buggar än kod som skrivits av mindre erfarna utvecklare och kod som omges av färre tester. Det handlar dock troligtvis om omvänd kasualitet: erfarna utvecklare får svårare uppgifter och svår kod omges av extra många tester.

Dessa forskningsresultat är inte bara underhållande, de kan ha stor praktisk nytta också. Om man kan integrera mätningar av detta slag i framtida utvecklingsmiljöer kan man till exempel få varningar om vilka delar av koden eller vilken sorts konstruktioner som är buggbenägna. Varningar som dessutom är anpassade till det egna företagets eller projektets historik.

Zellers presentation hade ett oväntat innehåll, var tankeväckande och levererades dessutom på ett inlevelsefullt och roligt sätt. Det var helt klart en av konferensens stora överraskningar för min del.

Om man någon gång har frågat sig hur man effektivt kan enhetstesta, eller snarare integrationstesta, databaser i .NET Framework är sannolikheten stor att man förr eller senare hamnat på Roy Osheroves blogg ISerializable.com. Osherove har länge bloggat om olika tekniker för databastestning och under rubriken "Techniques for testing data access code" sammanfattade han de olika tekniker som står till buds för .NET-utvecklaren.

Problemen med enhetstester av databaser är flera. Ett problem är att det tar betydligt längre tid att testa en metod som läser eller skriver i databasen, ofta upp till femtio till hundra gånger så lång tid. När det börjar bli många tester kommer man inte att vilja eller kunna köra dem tillräckligt ofta. Ett annat problem är att testerna påverkar databasen så att de inte kan återupprepas med exakt samma resultat utan att man t.ex. manuellt återställer data inför varje testomgång. Antag att man till exempel vill testa en rad metoder som raderar rader ur databasen - det kan vara svårt att göra mer än en gång utan att databasen återställts däremellan. Ytterligare ett problem är att om metoderna man testar inte enbart utför dataaccess utan också annan logik, kan man inte separera testet av databasen från testet av den andra logiken och det kan då bli problematiskt att byta implementation samtidigt som testerna hålls intakta.

Av dessa skäl förespråkar många att man ersätter databasen med Mock-objekt eller skapar en Fake, t.ex. en minnesdatabas som implementerar samma interface men lagrar och hämtar data från exempelvis Hashtables. Osherove tycker inte att detta angrepssätt är en bra idé eftersom man då inte testar själva databaslogiken, den som finns i nycklar, index, integritetsregler, triggers och så vidare. Om man använder en Fake eller en Mock måste man i så fall skriva särskilda tester för att testa databaslogiken och det är svårt att hitta bra verktyg för detta.

Osheroves alternativ är att man istället lyfter ut databastesterna från sitt enhetstestprojekt och istället placerar dem bland integrationstesterna, som normalt inte körs lika regelbundet, och använder någon sorts rollback av databasens data. Den smidigaste lösningen för dig som använder .NET Framework 2.0 eller senare är att starta ett TransactionScope inför varje test mot databasen och sedan göra en Rollback efter varje test. Det finns dock hopp även för dem som jobbar med tidigare versioner av ramverket. Mer detaljer finns förstås på Osheroves blogg. Osherove var en ganska rolig presentatör och avslutade sin session med sång och gitarrspel i form av en cover på Simon & Garfunkels "The Sound of Silence" där han skrivit om texten så att den handlade om databaser ("Hello DB my old friend") och tålamod med dem ("It's time for violence").

Jag hann också svänga förbi Ruby-spåret och lyssna på Rich Kilmer tala om "Ruby and the Art of Domain Specific Languages". Kilmer inledde med en kort teoretisk genomgång av möjligheter och problem med domänspecifika språk i Ruby, men större delen av hans presentation gick åt till en rad intressanta demonstrationer av verkliga projekt. Han visade på ett förtjänstfullt sätt hur man kan använda flexibiliteten i Ruby för att skapa domänspecifika språk som gör att domänexperten i princip kan, om inte skriva så i alla läsa koden och förstå det mesta av den. Jag borde verkligen titta mer på Ruby, inte för att jag kommer att gå över till språket, men det är en intressant influens och det händer mycket kring Ruby-communityn.