OOPSLA, dag 5

Fit, Framework for Integrated Test, är ett acceptanstestramverk som jag länge velat använda i mitt arbete. Ramverket är skapat av ingen mindre än XP- och OO-gurun Ward Cunningham och sedan vidareutvecklat, i form av FitNesse, av Robert C. Martin ("Uncle Bob"). Så även om Linda Risings "Project Retrospectives" lockade var det inget svårt val att som sista tutorial på OOPSLA välja "Accept Automated Acceptance Testing - Using FitNesse in the Real World" med Jens Coldewey.

Med Fit kan domänexperter själv mata in tester, eller i alla fall testvärden, i ett Excel-dokument som sedan exekverar och testar produktionskoden med hjälp av "fixtures" som utvecklaren kodar för att koppla ihop tester och produktionskoden. FitNesse använder sig av Fit men tillhandahåller en Wiki för att skriva testerna i tabellform. Något förenklat kan man säga att man uttrycker testerna i form av tabellrader där varannan kolumn är en beskrivande text och varannan en parameter till ett test. Ett exempel:

| check | Client | John Doe | deposits | 50.00 | and the new balance is | 50.00 |
| check | Client | John Doe | withdraws | 30.00 | and the new balance is | 20.00 |

Det första ordet "check" har en särskilt innebörd i Fit, men efter det gäller varannan text, varannan parameter, så att t.ex. "Client" och "deposits" är texter medan "John Doe" och 50.00 är parametrar. I wikisidan anger man också vilken klass testerna ska bindas mot. Klassen måste implementera någon av Fits olika fixture-basklasser. Så som testet är skrivet ovan kommer FitNesse att förvänta sig att klassen har två metoder:

public double ClientDepositsAndTheNewBalanceIs(string clientName, double amount)
public double ClientWithdrawsAndTheNewBalanceIs(string clientName, double amount)

Egentligen är det bara metodnamnen den förväntar sig ska se ut exakt som ovan eftersom de byggs ihop med hjälp av texten i testerna. Vad parametrarna heter är ointressant, det är bara ordningen på dem som är viktig. När testet nu exekveras kommer sista kolumnen i raden att antingen färgas grön om det lyckas eller röd om det misslyckas. I det senare fallet kommer det också att visas vad det faktiska värdet som returnerades är. Implementationen av testmetoderna kanske ser ut ungefär så här:

Account account = new Account(clientName);
account.Deposit(amount);
return account.Balance;

För att testerna ska fungera ihop måste förstås account vara en instansvariabel, annars kommer man att göra en "withdraw" på ett annat objekt. Men svårare än så här är det egentligen inte. Sedan finns det förstås ett antal nyckelord och olika sorters tabeller och fixtures man kan använda; det är exempelvis inte alla tester som låter sig uttryckas enligt mönstret ovan.

Det som lockar mig med FitNesse är att det faktiskt är ett verktyg där domänexperterna själva kan läsa och många gånger även ändra i testerna och lägga till nya rader. Med viss övning är det till och med möjligt för dem att skriva egna tester som utvecklaren sedan ser till att få gröna genom att implementera dels fixtures, dels produktionskod. När man inleder en sprint/iteration eller börjar på en ny story kan utvecklare, testare och domänexpert sätta sig tillsammans och börja skapa testerna i FitNesse, något som är ett utmärkt tillfälle för att utveckla den gemensamma modellen och förfina det gemensamma domänspråket.

Sist ut av keynote-talarna var Mark Jason Dominus, bl.a. känd som Perl-expert, som talade om "Atypical Types" och vad vi kan lära oss från framför allt Haskells typsystem. Dominus lär tydligen normalt vara en mycket underhållande och uppskattad talare - och visst fanns det humoristiska guldkorn här också - men innehållsmässigt var hans föredrag en salig blandning mellan mycket grundläggande och tämligen komplicerat. Den största delen var en sorts argumentation för varför starka typer är bra i ett språk, så om man först trodde han skämtade när han inledde med att säga att detta var ett gammalt föredrag för Perl-utvecklare från 1999, började man nu förstå att det faktiskt var sant. Starka typer var kanske kontroversiellt för Perl-utvecklare på den tiden, men knappast på OOPSLA 2008.

OOPSLA, dag 4

Onsdag morgon var det dags för Rebecca Wirfs-Brocks keynote: "What Drives Design?" Denna genomgång av X-Driven Design/Development motsvarade inte alls mina, förvisso ganska högt ställda, förväntningar. Det var huvudsakligen en mycket översiktlig genomgång av sådant som Domain Driven Design, Test Driven Development, Behaviour Driven Development, Contract Driven Development, Feature Driven Development och så vidare, cirka en eller två slides per område. Visst var det en hyfsad kartläggning, men som en OOPSLA-keynote måste det ha varit en gäspning för många.

Förmiddagen fortsatte med en panel kring domänspecifika språk (DSL, Domain Specific Language): "DSLs: The Good, The Bad, and the Ugly" Den samlade erfarenheten kring DSL:er hos paneldeltagarna var imponerande. Finländske Juha-Pekka Tolvanen hade till exempel varit med och implementerat ett hundratal DSL:er. Han refererade till undersökningar som visade på produktivitetsvinster på hundratals procent när företag ersatt sina tidigare utvecklingsmetoder med ett DSL. Kathleen Fisher från telefonbolaget AT&T vittnade om enorma besparingar på hundratals miljoner dollar som hade möjliggjorts genom införandet av ett DSL för att programmera system som förhindrar telefonbedrägerier (nummerkapning). Kod som tidigare upptagit över 30 sidor fick nu plats på en sida och med ett språk som domänexperterna kunde begripa och verifiera.

Flera av panelmedlemmarna underströk att en viktig förutsättning för ett lyckat DSL är att det behandlar ett tillräckligt specifikt område. Tolvanen gick längst och menade att de största vinsterna hos företagsinterna DSL:er och de mest framgångsrika sådan hör vi väldigt lite om därför att de helt enkelt är en enorm konkurrensfördel.

Dagens tutorial blev "Web API:s on Rails: Using Ruby on Rails for Web APIs Development and Mashups" med E. Michael Maximilien från IBM. Tanken var alltså att vi skulle skapa en webbsajt som använde sig av exempelvis Flickrs och Amazons webtjänster för att leverera innehåll. Tyvärr räckte inte tiden riktigt till för det, något som tyvärr inträffade flera gånger på OOPSLA. Det var uppenbart att materialet egentligen var framtaget för en längre session, typ en heldag. Vi hann därför bara gå igenom Ruby och Rails och flera övningar fick stryka på foten, men det var trots detta väldigt intressant och jag fick ännu en chans att kicka i gång med Ruby och Rails. Ruby är verkligen ett tilltalande språk och Rails är ett coolt ramverk för att otroligt snabbt sätta upp webbprojekt baserade på goda designprinciper som DRY och Separation of Concerns.

OOPSLA, dag 3

På tisdagen inleddes själva konferensdelen av OOPSLA, tidigare dagar innehöll bara workshops och tutorials. Inte för att det är så stor skillnad eftersom OOPSLA inte har traditionella konferenspass a 45-60 min, utan istället en keynote varje förmiddag och eftermiddag och däremellan (och parallellt för den delen) ett stort utbud tutorials, demonstrations, workshops, presentation av papers, lightning talks m.m.

Först ut var egyptologen/arkeologen Mark Lehner med föredraget "Social Programming A Pyramid, and possibly other large projects". Titeln antydde intressanta paralleller mellan pyramidbyggen och mjukvaruprojekt, men höll knappast vad den lovade i detta avseende. Det betyder emellertid inte att den var ointressant, men det intressanta var pyramidernas historia och det arkeologiska arbetet med utgrävningarna av "den förlorade staden". Och även om det inte fanns så många direkta paralleller tycker jag det är ett bra initiativ att bjuda på oväntade ämnen som inte är direkt relaterade till mjukvaruutveckling; förutom att det är kul med variation uppstår det ofta intressanta korsbefruktningar mellan områden och tankegångar där man minst anar det.

OOPSLA presenterar varje år en essä som valts ut av en kommitté som mottagit bidrag under året. Detta års essä var "Designed as Designer" av LISP-experten Richard Gabriel och var en sorts replik på Fred Brooks keynote på förra årets OOPSLA. Brooks jämförde designerns arbete i ett mjukvaruprojekt med konstnärers arbete och menade att de senare alltid har jobbat ensamma eller på sin höjd i par. Mjukvarudesign har mer och mer kommit att bli teamwork. Gabriel, som på gamla dagar börjat skriva poesi, invände mot detta och lyfte istället fram hur varje konstnär bygger vidare på tidigare generationers arbete och hur allt konstnärligt arbete egentligen är en sorts kommunikation med konsten och samhället. Föreläsningen var ganska annorlunda, med långa bildspel med musik, inspelade bokuppläsningar och mycket poesi. Det är märkligt att inte fler föredragshållare drar nytta av modern teknik eller åtminstone jobbar mer med sina slides och presentationer. Jag har inte sett många vackra eller innovativa presentationer här på OOPSLA, men den här var ett vackert undantag.

På eftermiddagen var det dags för tutorials igen, närmare bestämt Introducing New Ideas into Your Organization med Linda Rising. Jag äger sedan tidigare hennes bok "Fearless Change: Patterns for Introducing New Ideas" men har bara bläddrat i den tidigare. Tillsammans med sin medförfattare Mary Lynn Manns samlade Rising under tio års tid ihop olika mönster för hur man introducerar nya idéer i en organisation. Ett exempel på ett mönster är det grundläggande Evangelist; för att införa nya idéer måste du ha en passion för dem som kan smitta av sig på andra. Andra mönster är Brown Bag, använd lunchtid för att skapa en bekväm och avslappnad plats för att berätta om idén; Bridge-Builder, para ihop dem som accepterat den nya idén med sådana som inte har det; Do Food, bryt bröd tillsammans med dem du vill övertyga om din idé.

För många som är intresserade av agila metoder och praktiker, men som jobbar i en miljö där vattenfall är modellen, är Risings mönster naturligtvis mycket intressanta. Jag får ofta frågan hur man introducerar mer agila metoder, t.ex. TDD, på sin arbetsplats och med Risings tutorial har jag fått flera bra idéer och dessutom namn på sådana som jag redan använder mig av.

Till och med hotellen är "test infected" på OOPSLA...

OOPSLA, dag 2

Andra dagen på OOPSLA inleddes med en introduktion till F#. För att vara en introduktion var den ganska avancerad, vilket också förstärktes av en kunnig publik med intressanta frågor utifrån erfarenheter från andra funktionella språk som t.ex. Haskell. F# är ett sorts hybridspråk med stöd för såväl objektiorienterad som funktionell programmering. I funktionell programmering bygger man programmen med matematiska funktioner, d.v.s. en mekanism som konsekvent levererar rätt utvärde när man matar den med ett invärde. Detta innebär bl.a. att funktionell programmering är tillståndslös (stateless) med oföränderlig (immutable) data, något som gör att det lämpar sig väldigt väl för parallell programmering. Det sistnämnda är förmodligen en stor anledning till varför F# och funktionell programmering är så populära just nu: i en värld med multipla processorer är det naturligtvis intressant med programmeringsspråk som enkelt kan dra nytta av detta.

Även om det var en mycket intressant genomgång är F# inte ett språk jag kommer att kasta mig över; det har inte samma omedelbara attraktionskraft (på mig) som t.ex. Ruby. Medan Ruby känns som ett väldigt spännande alternativ som "förstaspråk" upplever jag att F# snarare är ett bra verktyg att ha till hands för t.ex. just parallell programmering.

Eftermiddagen tillbringade jag på Andreas Brinks "Test-Driven Development - Hands On!" som han egentligen skulle ha hållit tillsammans med sin kollega Niclas Nilsson som tyvärr blev tvungen ställa in p.g.a. sjukdom. Det var just p.g.a. Niclas frånvaro som jag satt med på denna tutorial för att eventuellt kunna hjälpa till om det skulle ha blivit många frågor under övningarna. Nu valde emellertid alla att genomföra övningarna i Java istället för C# och det var väldigt lite frågor, förmodligen därför att de flesta redan fuskat lite med enhetstester eller t.o.m. TDD. Andreas och Niclas har satt ihop en bra samling övningar och en bra blandning mellan teori (25%) och praktik (75%). Deltagarna kanske inte precis blir fullfjädrade TDD-praktiserare på drygt tre timmar, men jag tror att en sådan här övning kan vara en bra inspiration för att komma i gång med TDD i sin vardag.

OOPSLA, dag 1

Efter en lång resa befinner jag mig nu i Nashville för att närvara vid OOPSLA, Object-Oriented Programming, Systems, Languages, and Applications conference. Första dagens förkonferens är nu till ända och jag har hunnit med två tutorials: iPhone SDK kickstart och The Art of Telling Your Design Story.

Att programmera mot iPhone SDK var kul och även om Objective-C knappast lär bli mitt favoritspråk var det roligt att se hur snabbt man kan komma i gång med att skriva applikationer för sin iPhone. Och nu när jag installerat all nödvändig programvara och faktiskt skrivit ett par enkla applikationer är det inte helt omöjligt att det blir lite iPhone-programmering framöver.

Rebecca Wirfs-Brock, kvinnan bakom Responsibility-Driven Design, lärde oss konsten att berätta design-stories. Egentligen handlar det rätt mycket om berättarkonst överhuvudtaget och mycket av det hon tog upp var mer eller mindre självklara saker som man kanske inte tänker på, men som nu när de formaliserats kan bli lättare att komma ihåg och använda på ett mer strukturerat sätt. Det gäller allt från sådant som att anpassa sin story efter åhörare till hur man bör organisera sin berättelse beroende på vad det är man vill uppnå (buy-in, feedback, utbilda etc).

Jag börjar känna av en viss jetlag så det är väl bäst att runda av här så att jag är utvilad inför morgondagens F#-tutorial.