2008-11-21

Now in English

Det har varit bråda dagar med två veckors konfererande i USA (OOPSLA och Microsoft PDC), en kort paus och sedan Øredev som jag nu är på väg hem i från. Jag hade tänkt blogga en del om PDC, men istället lade jag min tid på att installera och komma i gång med Wordpress med vilket jag har börjat blogga på engelska på http://www.joakimsunden.com/. Jag vet inte om jag kommer att fortsätta blogga på svenska också. Vad tycker du?

2008-10-24

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.


2008-10-22

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.

2008-10-20

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.

2008-09-24

ALT.NET Unconference

Foto:Ola Lindberg
Foto: Ola Lindberg

Lördagen den 13 september arrangerade svenska ALT.NET-gruppen en "unconference" baserad på Open Space Technology i Avegas lokaler i centrala Stockholm. Ett trettiotal personer träffades utan att egentligen veta vad som skulle komma att avhandlas under dagen. Vi hade minst fyra olika mötesplatser till vårt förfogande under fem tidspass på ca 45 minuter vardera. I praktiken blev det ungefär tre ämnen per tidspass.

Några av de ämnen som diskuterades var TDD, BDD, NHibernate, MVC, Agile och SOA, "Slightly ALT.NET", anti-patterns, JQuery och andra script-bibliotek, Continuous Integration, Dependecy Injection/Inversion of Control, huruvida WCF uppmuntrar en anemisk domänmodell, om objektorienterad programmering är död och alternativa språk på .NET-plattformen. Ungefär hälften av deltagarna fortsatte sedan konversationen över en bit italiensk mat på Vapiano.

För min del var det en mycket trevlig och givande dag och det verkar jag ha varit långt i från ensam om att tycka. Förhoppningsvis blir det fler liknande tillställningar och fler coding dojos framöver. Håll ett öga på Sweden ALT.NET Google Group så kan du vara med när det händer.

2008-09-05

ALT.NET Unconference, lördagen den 13 september

Lördagen den 13 september har svenska ALT.NET-gruppen en kostnadsfri s.k. "unconference". Vi träffas kl 11 på Avega och kör i gång öppna forum enligt Open Space Technology där alla ämnen är välkomna. Temat är ALT.NET i bred bemärkelse, d.v.s. kontinuerlig inlärning/förbättring, vad kan vi lära oss från Java/Ruby/agile/lean/Open Source/dagisverksamhet/tårttillverkning/whatever, alternativa verktyg och tekniker o.s.v. En mer precis tolkning av ALT.NETs kärna har levererats av Martin Fowler:

"The alt.net mind-set is one that is very familiar to me. It has that mix of agile + object-orientation + patterns + TDD + DDD which is very much the school of software development that I favor. (Lacking a proper name for it, I'm inclined to call it the OOPSLA school of software development.) There is certainly a belief that there is a mainstream Microsoft orthodoxy at the moment, one that doesn't fit the OOSPLA school. And there's some frustration with that. But the point here is that it's not that the alt.net community thinks that the perceived mainstream Microsoft route should be erased, but that the Microsoft world is big enough for different approaches."

Avega sponsrar med kaffe och macka, vi håller på till ca 17:00 och sedan går vi ut och käkar på en restaurang tillsammans. För mer information och anmälan, se http://www.altdotnet.se/.

Välkommen!

2008-06-09

Du kodar väl på svenska?

Agila Sverige, Sveriges första agila konferens med blixttal och "Open Space"-möten, höll jag ett blixttal (max 10 minuter långt) om att koda på svenska. Mina slides (finns det ett bra svenskt ord för detta?) ser du nedan via eminenta tjänsten Slideshare.

Dessa slides är inte så innehållsrika eftersom jag föredrar att publiken lyssnar på vad jag har att säga istället för att försöka hinna läsa vad som projiceras på en duk. För den som är intresserad av vad jag sa kommer här istället mitt manusutkast i mer eller mindre oredigerad form.

Slide 1 - "Du kodar väl på svenska?"
Hej!
Jag heter Joakim Sundén och kommer från konsultbolaget Avega. Jag tänkte prata lite om att koda på svenska.

Slide 2 - "Working together"
“Business people and developers must work together daily throughout the project.” Det är en av principerna bakom Agile Manifesto.

I agila utvecklingsprocesser jobbar utvecklarna nära domänexperterna under hela projektets livstid. Man förfinar hela tiden design och domänmodell allt eftersom den gemensamma förståelsen för hur mjukvaran ska fungera ökar. För att det här ska fungera är det viktigt att kommunikationen mellan utvecklare och domänexperter fungerar bra. Man behöver ett gemensamt språk.

Slide 3 - "Ubiquitous language"
Eric Evans är en av de som bäst formulerat detta behov med sitt begrepp “ubiquitous language”, allestädes närvarande språk, som vi här kallar gemensamt språk.

Enligt Evans har ett projekt allvarliga problem när dess språk är splittrat. Domänexperter använder sin jargong medan tekniska teammedlemmar har sitt eget språk för att diskutera design. Terminologin i det dagliga diskussionerna blir bortkopplad från terminologin i koden. Till och med samma person kanske använder olika språk i tal och skrift och då går man kanske miste om några av de skarpaste uttrycken för problemdomänen.

För att komma till rätta med de här problemen bör man använda domänmodellen som grund för ett gemensamt språk och få teamet att använda det språket konsekvent i all kommunikation inom teamet och i koden.

Det är särskilt viktigt att använda det gemensamma språket när man pratar eftersom vår hjärna verkar vara specialiserad på att hantera komplexitet i det talade språket. Att leka med ord och fraser och experimentera med språket förbises ofta i modelleringsarbete.

Slide 4 - "Varför svenska?"
Om vill få till stånd ett gemensamt språk som genomsyrar allt från kod till samtal i en svensk verksamhet där domänexperterna talar svenska, borde det vara självklart att använda svenska i koden? Vi vill väl knappast tvinga resten av verksamheten att börja tala engelska?

Jag har jobbat en del i försäkringsbranschen på sistone och där kodade vi på svenska i problemdomänen. Att sitta och översätta termer som fribrevshavare, tiotaggare och skuggvärde till engelska hade försvårat samtal med domänexperter och kravanalytiker. Det var svårt redan på svenska att lära sig och komma ihåg vad de olika termerna betydde. Men det var ovärderligt att koden och verksamhetstermerna var samma när man satte sig tillsammans med en domänexpert för att försöka förstå olika affärsregler.

Men frågan i rubriken här är egentligen felaktigt ställd; lika lite som vi frågar oss varför vi ska prata och skriva på svenska i resten av verksamheten, lika lite borde vi fråga oss varför vi ska använda svenska i koden. Den fråga vi istället borde ställ oss är - varför inte?

Slide 5 - "Varför inte?"
Vad finns det egentligen för skäl att inte välja svenska? Annat än att “det är så vi alltid har gjort”? För engelsktalande som Eric Evans tycks det självklart att man kodar på verksamhetens språk, oavsett om det är engelska, spanska eller svenska. Men bland svenska utvecklare verkar det ofta närmast otänkbart; även bland de som arbetar agilt eller t.o.m. säger sig ha en DDD-approach.

Hur kommer det sig? Finns det särskilda svårigheter med att koda på svenska som engelskatalande har svårt att se? Eller är det bara födsel och ohejdad vana som håller svenska utvecklare tillbaka? Vilka är egentligen invändningarna mot svenska?

Slide 6 - "Men om vi ska outsourca då?"
Outsourcing, offshoring, eventuell sammanslagning med eller uppköp av andra företag, engelska som koncernspråk etc. Visst finns det många goda skäl att välja engelska, men de här skälen är knappast relevanta för annat än en minoritet av svenska utvecklingsprojekt. I många fall måste det också bli en bedömningsfråga där sannolikheten för t.ex. outsourcing till annat land får vägas mot kostnaden för ett försvårande av det gemensamma språket.

Att däremot reflexmässigt välja engelska bara "utifall att" innebär i många fall spekulativ övergeneralisering som komplicerar arbetet utan att ge några uppenbara fördelar. Här kan man verkligen tala om YAGNI - “You Aint Gonna Need It!”

Slide 7 - "Det känns konstigt"
Det här verkar vara ryggradsreflexen för många...

"Det känns konstigt..."
"Det känns helt fel. Skitjobbigt!"

Har man jobbat ett tag med svenska i koden inser man ganska snabbt att det är en vanesak. Jag har träffat utvecklare som bara kodat på svenska som tycker det är obegripligt att det finns folk som sitter och översätter svenska verksamhetsbegrepp till engelska i koden.

Slide 8 - "Svengelska"
Det går inte att koda på svenska. Programmeringsspråken är ju på engelska. Man måste ju skriva if(försäkringSaknas). Jo, så är det. Men är det verkligen ett problem? Det är för domänmodellen vi vill ha ett gemensamt språk, inte för infrastruktur, den tekniska domänen eller så låg nivå som if-satser och for-loopar. Det är inte på den nivån domänmodellen mejslas ut.

(Hur många utvecklare som diskuterar en while-loop säger för övrigt "while försäkring saknas kommer koden att do X men bara if lönen samtidigt är över Y"?)

Men även för domänmodellen blir det ju svengelska, eller ska man översätta Exception och Factory o.s.v.? Annars blir det ju FörsäkringException och FörsäkringFactory? En del personer tycks initialt ha problem med det. “Det är inte estetiskt”, “det har inte samma visuella känsla” eller “det ger en sämre helhetskänsla”. Jag vill inte påstå att sådana känslor är helt irrelevanta, men kan det verkligen vara mer än en vanesak? Kan det vara en tillräckligt stark invändning mot svenska för att börja översätta dröjsmålsränta och fribrevshavare?

Själv tycker jag att det inte tog särskilt lång tid att tycka att FöräkringFactory och FörsäkringException inte är konstigare än hedgefond, kundworkshop, trekkingskor, bilens airbag eller e-mailprogram.

Slide 9
Enligt min erfarenhet är valet att koda på engelska allt som oftast ett icke-val. Det har helt enkelt inte föresvävat personen i fråga att svenska är möjligt. Och när man presenterar det som ett alternativ blir den ryggradsmässiga reaktionen att “nej, men går det verkligen” eller “det blir konstigt”. Men det ÄR en vanesak. Prova! Det finns fördelar med att ha samma språk i koden som i skrift och konversationer i teamet, med domänexperter.

Om vi tror att det är fördelaktigt att använda samma språk och termer i koden som i det vardagliga samtalet - att i sanning ha ett gemensamt språk - och vi inte kan se några reella problem med att använda svenska i koden - då borde vi väl också koda på svenska?


Lustigt nog stötte jag kort därefter på mitt första problem med svenska tecken i koden när det visade sig att NVelocity vägrar känna igen variabler och metoder som innehåller åäö. :-) Det blir väl till att försöka fixa det helt enkelt, men att NVelocity använder CVS och inte verkar vara uppdaterat sedan januari 2003 gör ju inte att man känner sig helt sugen...