Joakim Sundén

Now in English

2008-11-21T22:42:00.005+01:00

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?

OOPSLA, dag 5

2008-10-24T18:15:00.004+02:00

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

2008-10-24T17:54:00.003+02:00

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

2008-10-24T10:54:00.000+02:00

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...

2008-10-22T22:46:00.002+02:00

OOPSLA, dag 2

2008-10-22T15:42:00.004+02:00

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

2008-10-20T06:15:00.002+02:00

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.

ALT.NET Unconference

2008-09-24T20:15:00.007+02:00

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.

ALT.NET Unconference, lördagen den 13 september

2008-09-05T16:40:00.003+02:00

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!

Du kodar väl på svenska?

2008-06-09T20:21:00.002+02:00

På 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.

| View | Upload your own

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...

Detta har hänt

2008-06-09T13:43:00.001+02:00

En lång föräldraledighet börjar snart gå mot sitt slut (nåja, i slutet på augusti i alla fall). Man kan lätt få för sig att jag under denna tid helt kopplat bort allt vad jobb heter, särskilt när man ser till antalet inlägg på denna blogg. Och visst hade det varit trevligt om det var på det viset, men det har stundtals varit ganska hektiskt. Så jag tänkte här ta tillfället i akt och samla ihop lite information om vad som hänt på sistone och lite om vad framtiden har i sitt sköte.

Som jag tidigare bloggat om höll jag en presentation om yrkesetik på Developer Summit i början av april som uppmärksammades bl.a. av Computer Sweden och av MSDN Radio som intervjuade mig.

I början av maj hade hela Avega en fantastisk konferens på Island där jag, framröstad av mina kollegor, utsågs till Årets Avegan med följande värmande motivering: "Joakim får priset för sitt genuina, brinnande intresse för både människa och teknik härligt inpackat i ett ödmjukt, intelligent och underhållande paket. Joakim har både förmågan och lusten att dela med sig av sina kunskaper." Det var verkligen ett sant nöje och en stor ära!

Och knappt hade jag hunnit hem från Island förrän Computer Sweden publicerade sin lista över Sveriges 75 "skarpaste utvecklare och arkitekter" där jag återfanns på en hedersam 44:e plats. På denna lista hamnar enligt Computer Sweden de som:

"…har en prestigelös och pragmatisk hållning till sitt arbete.

…som har stor erfarenhet och blivit rekommenderade av andra som är duktiga.

…som kan förklara kluriga problemställningar och kommunicera med omvärlden"

Jag har även hunnit med att ge ett blixttal på Agila Sverige: Du kodar väl på svenska? Agila Sverige var en riktigt rolig konferens med massor av intressanta människor och blixttal. Jag kan verkligen rekommendera nästa års konferens redan nu!

I november kommer jag att tala på den internationella konferensen Øredev tillsammans med en lång rad storheter som Robert Martin, Ted Neward, Eric Evans, Ayende Rahien m.fl. Ämnet är "ALT.NET - Are You Ready For the Red Pill?":

"Many, if not most, Microsoft shops use whatever tools and practices Microsoft push out, living in blissful ignorance of the many alternatives out there. The path of least resistance is an easy one. There is, however, a minority of shops and developers, not content with swallowing the 'blue pill'. ALT.NET, ('Alternative.NET'), is a movement that challenges the mainstream Microsoft orthodoxy and reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc. If you are comfortable with the blue pill, the story ends here. If you are curious about the red pill, you should come to this session."

Det ska verkligen bli roligt! ALT.NET hoppas jag få tid att skriva mer om på denna blogg. Kom gärna med i den svenska ALT.NET-gruppen vi startade för en tid sedan; vi hade en coding dojo för ett par veckor sedan för att ta fram sajten altdotnet.se med MVC-ramverket MonoRail. Vi är långt i från klara så kom gärna och hjälp till!

I höst ser det ut att bli besök på två riktigt stora konferenser i Nordamerika: OOPSLA den 19-23 oktober och Microsofts PDC den 26-30 oktober. Men där nöjer jag mig med att vara besökare. I år i alla fall... ;-)

Yrkesetik inom mjukvaruutveckling: Vad utmärker en professionell

2008-04-13T18:30:00.003+02:00

Uppdaterad den 15 april 2008, se längst ned.

Tidigare i veckan höll jag en presentation med titeln "Yrkesetik inom mjukvaruutveckling: Vad utmärker en professionell utvecklare?" på Developer Summit i Stockholm inför ca 60-70 personer. Eftersom jag av flera personer fått frågan vad presentationen handlade om och eftersom en kort artikel i Computer Sweden dessutom har väckt en del debatt tänkte jag här kort summera vad jag egentligen pratade om på konferensen.

Årets upplaga av Developer Summit hade "värdeskapande applikationsutveckling" som tema; hur bygger vi "värdeskapande system, system som stöttar kundens affärer och organisation" (från konferensens webbplats). Det gör vi utvecklare framför allt genom att skriva kod som skapar funktionalitet som uppfyller någon sorts önskemål eller specifikation från kunden. Lyckas vi med det skapar vi värde för kunden.

Problemet är att vi inte alltid lyckas med det. Ganska ofta beter sig mjukvara inte som kunden önskat. Då säger vi att den har defekter. Vi bör inte tala om "buggar" eftersom det lätt för tankarna till föreställningar om oförklarlig eller mystisk uppkomst när det i själva verket handlar om att defekter introduceras av människor. Jag gav exempel på defekter som orsakat stor materiell skada, nämnde att de ibland tar människoliv, berättade om statistik som uppskattade kostnaden för defekter i USA till 60 miljarder dollar årligen och om undersökningar som visade att nära hälften av alla användarprogram har icke-triviala defekter. Enligt en undersökning introducerar utvecklare i snitt 5-8 defekter per timme vi kodar!

Givet den stora kostnaden för defekter och det faktum att det verkar finnas så gott om dem: finns det verkligen ingenting vi kan göra för att undvika defekter? Jo, det finns många tekniker som kan hjälpa utvecklare att inte införa defekter: Design by Contract, Testdriven utveckling (TDD), formella kodinspektion (även kallade "Fagan inspections"), parprogrammering, m.fl. Tekniker som bland annat tvingar dig att noga tänka igenom specifikationen för vad som ska göras och koden för att uppfylla den; som leder dig bort från komplexitet genom att exempelvis tvinga dig att dela upp programmet i små och verifierbara delar.

Defekter kan också uppstå på grund av dåligt uttryckta krav, dålig återkoppling från kund eller användare, dålig kommunikation och andra saker som vi inte alltid förknippar med utvecklarrollen i ett team eller ett projekt. Eftersom jag befann mig på en utvecklarkonferens och hade begränsat med tid valde jag att fokusera på mjukvarukonstruktion i snäv bemärkelse. Det betyder inte att de andra delarna är mindre viktiga eller att utvecklarna inte ska bry sig om dessa saker - tvärtom! Men jag var tvungen att dra gränsen någonstans.

Att "uppfylla specifikationen" är emellertid inte allt. Att det fungerar är viktigt, men det ska också gå lätt att arbeta vidare med koden utan att riskera att introducera defekter och utan att produktiviteten lider. Därför bör vi undvika dålig kod (eller "fulkod"). Dålig kod kännetecknas framför allt av att den är svårt att förstå och svår att förändra, till exempel på grund av att den har långa och omständliga klasser och metoder, obegripliga metod- och variabelnamn, duplicering av logik och hårda beroenden.

Vi vet hur man skriver bra kod. Vi vet hur man undviker defekter. Så varför gör vi inte det?

Okunskap är en ursäkt. Den kan inte godtas mer än i början av en yrkeskarriär eftersom det faktiskt går att bli bättre på de här sakerna; även om de är svåra att bemästra är de lätta att lära sig. Tidsbrist är en annan ursäkt. Uppskruvat tempo - av oss själva eller andra - gör att vi gärna tänker att koden kan bättras på och tester skrivas senare. Men senare blir ofta detsamma som aldrig. Kan verkligen brådska vara ett acceptabelt skäl att skriva dålig kod och riskera att introducera defekter? Vad skulle du säga om du var läkare och en patient krävde att du skulle strunta i att tvätta händerna innan en operation för att hon hade bråttom? Eller om du var patient och läkaren struntade i det därför att hon hade bråttom?

Det kanske är någon annans fel? Chefen har satt upp orimliga tidsramar eller kunden vill inte betala för kvalitet? De flesta chefer och kunder vill faktiskt ha bra och defektfri kod även när de är besatta av tidsplaner och budgetar. Men det är deras jobb att passionerat försvara tidsplan och budget. Det är ditt jobb som utvecklare att försvara koden med samma passion! Du måste använda din kompetens för att förklara vad konsekvenserna av dålig kod och inga tester/kodinspektioner/etc blir.

Vi måste helt enkelt sätta ned foten och säga som det är: alla sätt att producera kod är inte lika bra. Vi behöver en "yrkesetik" eller en sorts kollektiv yrkespraktik som definierar vår profession, vårt yrke. Med den kunskap och erfarenhet vi har samlat på oss de senaste 50 åren kan det inte längre vara den enskilde utvecklarens ensak hur hon producerar sin kod. Vi utvecklare borde kunna vara överens om vad det är som skiljer oss från vem som helst med en dator och en kompilator. Vi behöver en gemensam uppfattning om vad som är professionellt och vad som inte är det. Slarv och ursäkter som tidsbrist och okunskap är bara möjliga i en kontext där undermåligt utfört arbete tolereras och där ingen ställer krav på vad som är fackmässigt godtagbart.

Professionalism handlar inte om att använda en viss sorts språk eller en viss sorts verktyg. Det handlar om praktiker och tänkesätt. Det handlar också om att sätta stolthet i det man gör och om att visa omtanke. Omtanke om kunder, användare, medarbetare, kod, affärsvärde o.s.v.

Resten av presentationen ägnade jag åt att gå igenom ett antal praktiker som jag och många andra anser utmärka en professionell utvecklare. Praktiker som TDD, parprogrammering, kontinuerligt lärande med mera. Jag avslutade med en förhoppningsvis inspirerande apell om varför man ska bry sig och om att förändring börjar med dig själv.

Det skall sägas att mitt snäva fokus på kodens kvalitet och mjukvarans korrekthet med rätta kritiserades av Peter Tallungs som anser att det måste vara användaren vi framförallt ska "svära" att skydda med vår yrkesetik. Detta är något jag borde ha tagit upp i min presentation, även om fokus som sagt var på utvecklaren och dennes "kärnverksamhet" denna dag. Vill man se det från den positiva sidan finns det utrymme för förbättring i fall jag skulle få för mig att hålla en liknande presentation i framtiden. :-)

De "slides" jag visade under presentationen kan du ladda ned här. Jag kommer förhoppningsvis att inom kort skriva ett par bloggposter där jag lägger ut texten kring några av de ämnen jag tog upp under presentationen. Om du har kommentarer eller frågor eller vill veta mer om något från min presentation får du gärna lämna en kommentar här på bloggen eller använda e-postadressen högst upp i högerspalten.

Uppdatering den 15 april 2008: Ibland går det för fort, särskilt när man ska sammanfatta något, vilket Henrik Engströms kommentar nedan påminner mig om. Något jag tog upp på Developer Summit - och som jag hoppas framgick där - var att det inte finns några universella best practices, precis som Dan North underströk i sin utmärkta presentation dagen därpå och som även James Bach förklarat på ett förtjänstfullt sätt. De jag lyfte fram är en skola och det finns andra, t.ex sådana som trycker mer på de andra tekniker jag tog upp, så som formella kodinspektioner och prototyping. Robert Martin, som inspirerat mig och som jag lånat mycket från, jämför med kamsporter ("martial arts") där man sällan påstår att någon kampsport är odiskutabelt "bättre" än alla andra, men när man väl valt sin skola så agerar vi som om dess tekniker är de rätta och försöker förfina dem till perfektion. Martin Fowler skrev något liknande häromdagen.

För övrigt var en av de praktiker jag lyfte fram att använda rätt verktyg för rätt uppgift och inte bara samma gamla verktyg som man råkar känna till (eller som Microsoft ger dig, som det ofta fungerar i .NET-världen).

Jag kanske helt enkelt får lov att göra en uttömmande bloggpost om allt jag pratade om...

Varför läsa böcker?

2008-03-02T16:20:00.001+01:00

Många har reagerat på min sista bloggpost 2007, där jag bland annat gick igenom det mesta av den jobbrelaterade facklitteratur jag läste förra året, totalt 26 titlar. "Oj vad många" och "hur hinner du läsa alla böcker" är de vanligaste kommentarerna. På ett sätt är det en ganska konstig reaktion med tanke på att jag huvudsakligen läser på väg till och från jobbet, ca 25 minuters resväg enkel väg. Och jag har alltid grämt mig över att jag läser så långsamt. Det borde alltså inte vara svårt att upprepa "bedriften" om man nu är intresserad av att läsa böcker för att utvecklas i sitt yrkesutövande.

Samtidigt är det egentligen inte alls en förvånande reaktion eftersom jag vet att jag, i jämförelse med många utvecklare jag träffat, läser ovanligt mycket facklitteratur. Jag förstår att alla inte har samma passion för sitt jobb och att det är mycket annat som konkurrerar om de fåtal timmar dygnet ställer till förfogande. Och hur viktigt är det egentligen att läsa en massa böcker? Behöver man verkligen det? Kan man inte hålla sig ajour med vad som händer genom att läsa en artikel eller två på webben då och då? Nja, inte om man talar med Bob Martin (OO- och TDD-guru, initiativtagare till Agile Manifesto) i alla fall:

"Then you don't intent do be a programmer for very long. To be a programmer you have to be an avid reader and studier. If this has to be done on your own time, so be it.

Our profession is one of the most volatile professions in existence. It is changing all the time. There is no way to remain active in this profession if you don't stay up on those changes. An hour per day is not too long to spend on this." (TDD Mailing List, 17 maj 2006)

Eller om man hellre talar med Steve McConnell, författaren till bland annat den moderna klassikern Code Complete:

"Specific features of the technical environment change every 5 to 10 years. If you aren't curious enough to keep up with the changes, you might find yourself down at the old-programmers' home playing cards with T-Bone Rex and the Brontosaurus sisters." (Code Complete, s. 822)

Man kan tycka att Martins och McConnells krav på en programmerare är väl höga, men det är därför att verkligheten ställer höga krav på oss. Visst, det tycks stundtals räcka att få in en fot i branschen och sitta av några år för att hålla sig kvar i programmeraryrket livet ut, särskilt med den senaste tidens bristande återväxt. Eftersom erfarenhet nästan alltid förefaller mätas kvantitativt snarare än kvalitativt så behöver man knappast utvecklas alls för att efter några år mer eller mindre vara garanterad försörjning som programmerare livet ut. Men om man inte är belåten med att bara försörja sig, utan verkligen vill hänga med i utvecklingen, ha koll på det man jobbar med och kunna göra ett bra jobb måste man aktivt läsa och studera.

Att hålla sig uppdaterad om utvecklingen är inte enda skälet att läsa böcker, kanske inte ens det främsta. Inom mjukvaruindustrin har vi nu ett antal decenniers erfarenheter bakom oss och vi har hunnit göra väldigt många misstag, om och om igen dessutom. Vi har också lärt oss av dessa misstag och upptäckt sätt att undvika dem. Det är närmast oansvarigt att inte tillgodogöra sig de erfarenheter som ackumulerats genom åren. Billy McCafferty uttrycker det så här på sin blogg:

"Although there is no single best practice, practices do exist which embody the lessons learned from years of painful experiences and hard won insight. This is not to say that all the practices described are not subject to critique and improvement, but they do serve as a confident starting point for engaging in our own daily practice. Ignoring them outright, which is almost a norm within the world of software development, is an injustice to the science in which we say we engage ourselves."

Steve McConnell gör en intressant jämförelse med andra yrkesgrupper:

"The software-engineering field makes extraordinarily limited use of examples of past successes and failures. If you were interested in architecture, you'd study the drawings of Louis Sullivan, Frank Lloyd Wright, and I. M. Pei. You'd probably visit some of their buildings. If you were interested in structural engineering, you'd study the Brooklyn Bridge; the Tacoma Narrows Bridge; and a variety of other concrete, steel, and wood structures. You would study examples of successes and failures in your field." (Code Complete, s. 823)

Den självklara motsvarigheten i mjukvaruindustrin är förstås att studera andras kod, design och arkitektur. En av fördelarna med konsultyrket är just den möjlighet det ofta erbjuder att få en inblick i många olika lösningar, arbetssätt m.m. Har man inte den möjligheten finns det gott om publierad kod, man kan exempelvis börja med något av alla "Open Source"-projekten på Codeplex och Sourceforge. Lyckligtvis finns det också många som samlat sina erfarenheter i just böcker:

"The first step that each of us can take to better the integrity of our science and assist with its advancement is to pick up a book. Although not all are equal, key texts infuse in us the wisdom of many years of development and the expert knowledge garnered from many mistakes." (McCafferty)

McCafferty presenterar också en lista med böcker i sin bloggpost, "a minimal course of reading for infusing such knowledge", som innehåller många bra titlar väl värda att studera.

Slutligen kan det också vara direkt välgörande för din karriär att läsa böcker och som Steve McConnell skriver i Code Complete behöver du inte ens läsa särskilt mycket för att utmärka dig:

"Pat yourself on the back for reading this book. You're already learning more than most people in the software industry becausse one book is more than most programmers read each year (DeMarco and Lister 1999). A little reading goes a long way toward professional advancement. If you read even one good programming book every two months, roughly 35 pages a week, you'll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you." (Code Complete, s. 824)

35 sidor i veckan. Det är fem sidor om dagen. Det är väl ingen bedrift?

Jim Coplien vs Bob Martin om TDD och professionalism

2008-02-24T21:08:00.001+01:00

Det pratades som sagt en hel del på JAOO 2007 om Jim Copliens påhopp på testdriven utveckling (TDD) ("ruins your architecture") under hans session om "Scrum Architecture", något som resulterade i fortsatt debatt mellan Coplien och bl.a. Roy Osherove under Scrum Open Spaces senare under dagen. Bob Martins inledningsanförande för konferensen handlade bland annat om att man inte kan kalla sig professionell utvecklare om man inte praktiserar TDD, så det fanns goda skäl att anta att det skulle vara intressant att sätta dessa tungviktare framför en kamera för att debattera ämnet. Det är lyckligtvis precis vad InfoQ gjorde och resultatet har nu äntligen publicerats på deras sajt:

Coplien and Martin Debate TDD, CDD and Professionalism (InfoQ)

Testa först eller testa sist?

2008-02-20T12:10:00.001+01:00

Den senaste tiden har jag både följt och själv deltagit i diskussioner kring huruvida man bör skriva sina automatiserade tester först eller om det går lika bra att skriva dem efter att man skrivit koden. För den som inte är bekant med TDD, testdriven utveckling (Test Driven Development), kanske det låter väldigt främmande att skriva ett test för koden innan man skriver själva koden som uppfyller testet (läs i så fall lite mer här). För andra kan det verka som hårklyverier eller åtminstone reducerbart till en smaksak vilket sätt man väljer.

De flesta som arbetar testdrivet (vilket jag åtminstone i denna text betraktar som synonymt med "testa först" och TDD) är emellertid överens om att det faktiskt är av stor betydelse att skriva testet först. När man redan innan koden skrivs är tvungen att tänka på hur den ska anropas blir det gränssnitt/API man utvecklar tydligare och får en bättre design. Om testet skrivs först kan man också vara säker på att koden man skriver faktiskt kommer att vara testbar, något som kan vara nog så svårt att åstadkomma i efterhand på grund av beroenden till andra klasser, initialisering av rätt testdata o.s.v. Dessutom undviker man den i många sammanhang överhängande risken med att skriva testerna sist: att de inte blir skrivna alls på grund av tidsbrist, lättja etc.

Standardiseringsorganisationen IEEE publicerade nyligen en rapport i en av sina tidskrifter, "On the Effectiveness of Test-first Approach to Programming", som jämförde produktiviteten hos team som skrev testerna först med team som skrev dem sist. Slutsatsen från den studien är att de som jobbar testdrivet tenderar att skriva fler tester och att de som skriver fler tester i regel är mer produktiva. Författarna bakom studien förklarade den högre produktiviteten för de testdrivna teamen med ett antal synergieffekter hos detta angreppssätt:

Bättre förståelse för uppgiften eftersom utvecklarna måste uttrycka funktionaliteten otvetydigt i form av ett test innan de börjar programmera.
Bättre fokus på uppgiften eftersom man måste bryta ned uppgifterna i små och lätthanterliga delar när man skriver testet först.
Snabbare inlärningsprocess då för grova improduktiva nedbrytningar av funktionalitet snabbt överges för mer produktiva finkorniga sådana för att kunna testas.
Mindre omarbetning eftersom problem upptäcks direkt när testerna körs varje gång man lagt till eller ändrat i kod och man då vet att det man precis gjorde introducerade problemet. Felaktigheter är billiga att åtgärda direkt då problemet och koden fortfarande är färska i utvecklarnas minne.

Okej, så det finns en hel del goda skäl att skriva testerna först, att driva designen med tester. Varför skulle man då vilja skriva testerna sist istället? Ett vanligt skäl är att man helt enkelt inte har förstått fördelen med TDD ännu och att det, i det vattenfallstänk som fortfarande tycks dominera mjukvaruutvecklingen, verkar mer naturligt att förlägga testerna till slutet av projektet eller iterationen som ett sorts "sluttest" för att allt fungerar som det är tänkt.

Bland annat denna dominerande föreställning om vad tester är och när och hur de bör genomföras, liksom den traditionella uppdelningen mellan testare och utvecklare i olika roller och personer, har gjort att många börjat söka efter andra sätt att förklara TDD. Istället för ”tester” talar man om ”exempel” eller ”specifikationer” eftersom det egentligen säger mer om arbetssättet och gör det lättare att förstå varför man skriver dem först och vilka fördelar det kan ha. Detta alternativa synsätt kallas ofta BDD, Behaviour Driven Development, men dessa intressanta frågor får vänta till en senare bloggpost.

Ett annat argument mot att skriva testerna först är att man då skriver för många tester. Förutom att det därmed krävs en större arbetsinsats och att det blir mer kod att överblicka, kan man hamna i en situation där testkoden håller produktionskoden ”gisslan” (tack för den metaforen Daniel Brolund!) genom att en förändring i koden leder till väldigt många brutna tester och därmed förändringar i även dessa tester. Då får man plötsligt motsatsen till ett av de önskade resultaten: koden blir mer komplex och svårare att ändra.

Ett motargument är att bara dåligt utförd TDD skapar sådan intim koppling mellan enhetstesterna och produktionskoden att detta blir ett stort problem. Naturligtvis kommer du vara tvungen att ändra testerna när du ändrar produktionskoden, men så är det oavsett när du testar och det är dessutom något positivt: testerna visar dig att existerande funktionalitet påverkas.

Men om man skriver testerna sist går man ju miste om fördelar som den positiva effekten på design och bättre fokus genom små steg? Kanske inte, TDD passar inte nödvändigtvis alla och det finns säkert utvecklare som har lättare för att få fram god design och bra kod på andra vägar, särskilt om man har god erfarenhet av att ha jobbat framgångsrikt på andra sätt. Och bara för att man skriver testerna efter koden innebär det inte att man måste jobba med stora steg och skriva alla tester vid slutet av en iteration. Många som jobbar med enhetstester men inte med TDD beskriver en arbetsprocess där de skriver kod och tester ”samtidigt” och inte går vidare med nästa klass eller metod förrän tester är på plats.

Kanske är det också här en del av problemet ligger i debatten kring testa först eller testa sist; man jämför gärna sin valda metods fördelaktiga sidor med den andra metodens misslyckanden. TDD-evangelister utgår ofta från att den som ska övertygas inte jobbar med enhetstester överhuvudtaget och kanske att de producerar kod med mindre god design som är svårtestad och full med beroenden (och varför skulle de inte det med tanke på hur det ofta ser ut :-)). Eller så tittar man på hur arbetet med enhetstester traditionellt sett ut och ser då att de skrivs alldeles för sent, riskerar att inte bli skrivna o.s.v. De som vill testa sist har i sin tur kanske sett misslyckade exempel på omoget införande av TDD i ett projekt med lång inlärningstid och med undermåliga tester som hållit koden gisslan.

Här skulle jag, kanske något resignerat, kunna avsluta texten med att ”bra utvecklare kommer alltid att skriva bra kod oavsett metod” och "välj det som passar bäst i den specifika situationen". Det ligger naturligtvis en hel del sanning i dessa klichéer och de kan dessutom tålas att upprepas så att man än en gång påminns om att vara ödmjuk inför andras erfarenheter och val. Jag tror dock att testa först är det bästa arbetssättet helt enkelt därför att det uppmuntrar dig att följa annan god praxis. Visst, du kan åstadkomma god design och bra API:er utan TDD, du kan bryta ned program i små testbara delar och minimera beroenden utan TDD, du kan skriva bra enhetstester i efterhand, du kan köra testerna kontinuerligt och refaktorisera din kod utan TDD och du kan ha disciplin nog att aldrig fuska och spara testerna till senare. Men varför chansa? Varför inte använda ett arbetssätt som mer eller mindre tvingar dig att göra allt detta? Om det sedan inte är helt lätt att lära sig, ja då beror det kanske på att de goda praktiker som det i sin tur tvingar fram inte heller är helt lätta att lära sig, men när du väl har gjort det kommer du att vara en bättre utvecklare.

Otrohet och uppbrott

2008-01-16T11:24:00.001+01:00

För bara några månader sedan hade jag aldrig trott att det skulle kunna hända. Jag borde ha vetat bättre eftersom det faktiskt hade hänt ett par gånger tidigare. Det kändes bara så avlägset att jag knappt kom ihåg att det hänt. Aldrig mer hade jag sagt. Men så hände något i slutet av förra året. Alla pratade om hur fantastisk hon var och det behövde inte nödvändigtvis sluta med otrohet även om man valde att ta steget. Och hon var ju så vacker och annorlunda.

Kanske var det nyår och känslan av nystart som slutligen fick mig att ta steget. Det första jag gjorde när jag var tillbaka i Stockholm var nämligen att söka upp henne. Och där låg hon, i ett skyltfönster i Sundbyberg, smal och elegant, men ändå utrustad med 2,4 GHz Intel Core 2 Duo, 4 GB RAM och en 200 GB 7200 RPM hårddisk... Apple MacBook Pro.

Jag vet att förälskelsens rus kommer att gå över och att vardagens bekymmer kommer att tära även på vårt förhållande, men jag är övertygad om att vi kommer att ha en stark relation även efter att nyhetens behag har lagt sig. Än så länge är allt fantastisk och hon överraskar mig hela tiden med små hjälpsamma saker som ett tangentbord som lyser upp och en skärm som ändrar ljusstyrka beroende på belysningen i rummet, omsorgsfulla innovationer som den magnetiska sladden som gör att hon inte faller i golvet när barnen snavar på den och vackra detaljer som den pulserande lampan när hon vilar så sött på bordet. Jag saknar nästan inte alls min gamla Zepto, men det börjar kanske bli dags att köra Windows Vista snart; Visual Studio finns inte för OS X tyvärr...

Summering av det gångna året

2007-12-31T23:22:00.001+01:00

Snart är 2007 till ända och det har i många avseenden varit ett händelserikt år för min del, särskilt nu på slutet eftersom jag avvecklat många åtaganden inför den föräldraledighet som tar vid efter nyår. Många böcker som jag läst, frågor jag funderat på och aktiviteter jag deltagit i och som jag tänkt blogga om har inte hunnits med. Jag tänkte därför ägna denna bloggpost åt en liten summering av böcker, föredrag och konferenser från det gångna året. Om du händelsevis skulle vilja veta mer om något av det jag här skriver om får du gärna lämna en kommentar om vad eller skicka ett mejl (se adress till höger) så kan jag återkomma med en mer ingående text.

Böcker

Det har blivit några böcker lästa under året, många nya men också några omläsningar.

Domain-Driven Design: Tackling Complexity in the Heart of Software av Eric Evans. En i många stycken underbar bok om objektorienterad analys och design med fokus på modellering av kärndomänen och ett allestädes närvarande språk. Rekommenderas varmt.

Patterns of Enterprise Application Architecture av Martin Fowler. Fowler har samlat ett 40-tal återkommande mönster för applikationsarkitektur gällande allt från skiktning ("layering") till O/R-mapping till Model-View-Controller. Boken innehåller dessutom en mycket intressant vägledning till hur man använder olika mönster när man utvecklar en enterpriseapplikation, hur man gör avvägningar mellan olika mönster, varför vissa mönster är mer lämpade för .NET än för Java m.m.

Head First Object-Oriented Analysis and Design av Brett D. McLaughlin, Gary Pollice och Dave West. Jag gillade Head Firsts bok om designmönster och tänkte att den här skulle vara lika intressant, men de grepp jag upplevde som tydliga och pedagogiska när det gällde designmönster blev i den här boken övertydlighet och upprepningar. Kanske har det att göra med att ämnet för denna bok är mer bekant och mindre tekniskt komplicerat. Möjligtvis mer intressant för OO-nybörjare.

The Pragmatic Programmer: From Journeyman to Master av Andrew Hunt och David Thomas. Pragmatiska programmernas bok är redan en klassiker och en ovärderlig följeslagare för den som vill ta steget från gesäll ("Journeyman") till mästare. Boken är fullspäckad med fina råd och praktiker hämtade från Andys och Daves långa karriärer som mjukvaruutvecklare; designprinciper, vilka verktyg man bör använda, sätt användarna i fokus, så bygger du ett framgångsrikt team, automatisera mera, lär dig ett nytt programmerinsspråk varje år och mycket mera. Principer och filosofi blandas med handfasta och konkreta tips.

Writing Effective Use Cases av Alistair Cockburn. En bibel för många kravanalytiker och intressant läsning för alla intressenter i ett mjukvaruutvecklingsprojekt. Cockburn (uttalas co-burn) har en pragmatisk och agil syn på användningsfall som ett (av många) praktiskt arbetsdokument, snarare än som en heltäckande kravspecifikation med detaljnivå motsvarande en användarmanual.

UML Distilled: A Brief Guide to the Standard Object Modeling Language av Martin Fowler. Bra introduktion till UML och objektorienterad analys och design som jag skrivit mer om här.

Software Estimation: Demystifying the Black Art av Steve McConnell. Författaren till Code Complete avmystifierar här tidsuppskattningens svarta konst och visar att realistiska tidsuppskattningar faktiskt är möjliga. Framför allt innehåller boken bra tekniker och tillvägagångssätt för att förbättra ditt projekts och dina egna tidsuppskattningar.

Peopleware: Productive Projects and Teams av Tom DeMarco och Timothy Lister. Vad gör vissa projekt och företag mer framgångsrika än andra? Mycket talar för att det överhuvudtaget inte handlar om teknik och processer, utan om människor. Peopleware sätter människorna i fokus och visar med hårda data hur man bäst organiserar arbetsmiljöer och team för att få fram det bästa av dessa människor. En mycket viktig och bra bok!

Agile Principles, Patterns, and Practices in C# av Robert C. Martin. Bob Martin, även kallad "Uncle Bob", var en av initiativtagarna till Agile Manifesto och en förgrundsfigur inom objektorientering och testdriven utveckling (TDD). Med boken "Agile Software Development, Principles, Patterns, and Practices" (2002) förde Bob Martin fram designprinciper som Single Responsibility Principle (SRP) och Dependency Inversion Principle (DIP), TDD, desinmönster och agil utveckling, framför allt till en Java- och C++-publik. Förra året (2006) gav han ut den här nya utgåvan anpassad, tillsammans med sonen Micah Martin, för C# och .NET. Förutom nämnda principer och mönster är boken full av konkreta kodexempel. En riktigt bra bok om god design, särskilt objektorienterad sådan.

Refactoring: Improving the Design of Existing Code, Martin Fowler. Ännu en modern klassiker av Fowler med stöd från bl.a. XP-grundaren Kent Beck. Boken innehåller bl.a. en mycket omfattande katalog med olika refaktoriseringar (sätt att förbättra kodens struktur och design utan att förändra dess beteende), en genomgång av så kallade "code smells" för att identifiera dålig design och en kort introduktion till enhetstester. Boken är en guldgruva med goda designprinciper, inte minst för ett objektorienterat angreppssätt.

Software Configuration Management Patterns: Effective Teamwork, Practical Integration av Stephen P. Berczuk och Brad Appleton. En mycket bra introduktion till configuration management med många bra mönster för versionshanteringssystem, till exempel Branching, Codeline Policy, Release Line och Private Workspace.

Working Effectively with Legacy Code av Michael Feathers. Det är egentligen underligt att det inte finns fler böcker som behandlar samma ämne som detta banbrytande verk: hur man steg för steg städar upp legacy-kod (i detta sammanhang liktydigt med dålig design, snårig kod och avsaknad av enhetstester) och ger den struktur och god design. Feathers bok innehåller en stor mängd tekniker för hur man åstadkommer detta och får sin legacy-kod testbar. Under resans gång lär man sig en hel del om god design och Feathers har dessutom ett mycket inspirerande tonfall i sin bok; det han föreskriver är inte bara möjligt, det är nödvändigt. Den här boken och Andreas Brinks föredrag och workshop under Developer Summit var vad som fick mig att faktiskt börja skriva enhetstester och använda TDD i legacy-projekt.

xUnit Test Patterns: Refactoring Test Code av Gerard Meszaros. Förutom en avsevärd samling mönster för automatiserade enhetstester innehåller den här boken också en rad "test smells" (jmf Fowlers "Refactoring" ovan) och en vägledning för hur man organiserar sina tester och för olika avvägningar mellan olika mönster (jmf Fowlers "Patterns of Enterprise Application Architecture" ovan). Det är den definitiva guiden till automatiserade enhetstester och därmed en oumbärlig bok för alla utvecklare.

Pair Programming Illuminated av Laurie Williams och Robert Kessler. En heltäckande introduktion till parprogrammering som med stöd i såväl forskningsdata som anekdoter från erfarna utövare berättar om förtjänsterna och fallgroparna i parprogrammering. Boken innehåller också gott om råd för hur man inför parprogrammering i en organisation, hur man (inte) parar ihop olika individer, hur man tar itu med olika problem förknippade med parprogrammering och, sist men inte minst, hur man parprogrammerar.

Test Driven Development: By Example av Kent Beck. Introduktion till testdriven utveckling av mannen som kan sägas ha uppfunnit tekniken (och Extreme Programming). Det är roligt att se hur Kent Beck faktiskt testdriver fram utvecklingen av JUnit och samtidigt använder det han skapar för att automatisera sina tester, men jag kan tyvärr inte säga att det är någon bra introduktion till TDD för nybörjare.

Refactoring Workbook av William Wake. En bra följeslagare till Fowlers "Refactoring" (se ovan), fylld med olika exempel och övningar. Lämpar sig väl för t.ex. en studiecirkel eller för den som läst Fowlers bok men behöver mer konkreta exempel för att bättre förstå hur man jobbar på det sättet. Boken är också en bra repetition av Fowlers bok eftersom den omformulerar flera motiveringar och code smells samt inför några nya. Bra om goda designprinciper mellan raderna.

Refactoring to Patterns av Joshua Kerievsky. Den som lärt sig designmönster genom böcker eller utbildningar blir ofta "pattern happy" och vill tillämpa sin nyvunna kunskap var helst det ser ut att vara möjligt. Resultatet blir ofta en onödigt komplicerad design. Den här boken visar hur det istället bör gå till; den lär dig identifiera problem ("code smells") där designmönster kan vara en bra lösning och visar dig hur du kan refaktorisera din kod till denna lösning.

Continuous Integration: Improving Software Quality and Reducing Risk av Paul Duvall, Steve Matyas och Andrew Glover. En komplett vägledning till Continuous Integration med allt från nyttan för olika intressenter till kodexempel för hur man faktiskt sätter ihop hela processen. Gott om råd för olika kodanalysverktyg, notifieringsmekanismer (som Ambient Orb) och annat som kan användas för att öka nyttan med CI.

Agile Retrospectives: Making Good Teams Great av Esther Derby och Diana Larsen. Derby och Larsen har omsatt sin omfattande erfarenhet av retrospektiv i ett ramverk och en bok full med olika tekniker och tips för ett lyckat retrospektiv. Jag hade förmånen att deltaga i en hel dags tutorial om Agile Retrospectives med Esther Derby på JAOO; läs mer om den här.

Pragmatic Unit Testing in C# with NUnit, 2nd edition av Andrew Hunt, David Thomas och Matt Hargett. Den här boken är en god introduktion till automatiserade enhetstester i C# med att bra fokus på hur och vad man bör testa. Den ger dig allt du behöver för att komma i gång med NUnit och innehåller även en del mer avancerade koncept. Tyvärr har boken ett svagt TDD-fokus och tycks reducera frågan om huruvida testerna ska skrivas först eller sist till en smaksak. Lite överraskande med tanke på att "pragmatiska programmerarna" i andra sammanhang starkt förordar TDD.

Software Craftsmanship: The New Imperative av Pete McBreen. McBreens bok är en uppgörelse med tunga processer och synen på mjukvaruutveckling som en industri där utvecklarna är utbytbara kuggar i en process där de mekaniskt implementerar systemanalytikernas ritningar. Hans alternativ är ett system där mjukvaruutveckling erkänns som ett hantverk och där kunskap och erfarenheter traderas från mästare till gesäll till lärling. En sådan utvecklare tar ett stort ansvar för kvalitet och genomförande, men ställer också krav på vilka kunder hon väljer att arbeta med och hur arbetet kan gå till (här bekänner sig McBreen, om än inte uttryckligen, till de agila metoderna). En mycket intressant och tankeväckande bok.

Fit for Developing Software: Framework for Integrated Tests av Rick Mugridge och Ward Cunningham. Jag har länge sneglat på Fit men aldrig kommit till skott eftersom jag inte jobbat i projekt där det varit möjligt/lägligt att automatisera acceptanstesterna. Kanske är det just det sistnämnda som gjort mig allt mer övertygad om att detta är vägen man måste gå, om än inte nödvändigtvis med just Fit. Efter att ha läst den här boken och tittat lite på Fit och Fitnesse kommer jag emellertid att slåss med näbbar och klor för att få använda det i nästa projekt. Fit är ett utmärkt sätt att involvera verksamhetspersoner i test- och utvecklingsarbete och därigenom få fram ett allestädes närvarande språk ("ubiquitous language") och en domänmodell (se DDD). Rekommenderas varmt, särskilt för dig som är intresserad av agil utveckling och DDD.

Implementation Patterns av Kent Beck. Jag hade höga förväntningar på den här boken och måste tyvärr säga att jag blev en smula besviken. Vissa av bokens implementationsmönster är mycket banala, t.ex. mönstret "Class" som säger att det är bra att placera data och beteende som hör ihop i en klass. På andra ställen ges mer komplicerade mönster mycket fåordiga förklaringar som gör det svårt att följa med i Becks tankegångar. Denna ojämnhet gör det svårt att bestämma en lämplig publik för boken: riktar den sig till nybörjare eller till mer erfarna utvecklare? Ingen av dem skulle jag säga. (När jag skulle klistra in länken för denna bok från Amazon.com ser jag att en recensent fångat samma känska som jag på ett mycket bra sätt.) Bokens största värde för mig ligger i att man i vissa mönster och motiveringar ändå får en inblick i filosofin bakom vissa goda designprinciper och en inblick i hur en riktigt duktig objektorienterad utvecklare tänker.

Practices of an Agile Developer: Working in the Real World av Venkat Subramaniam och Andy Hunt. Bra samling agila praktiker och principer, kärnfullt och bra sammanfattade i en rad korta kapitel. Mer för den agile nybörjaren än för den som redan praktiserat korta iterationer, Continuous Integration, TDD, o.v.s. i några år.

Extreme Programming Explained: Embrace Change (2nd edition) av Kent Beck och Cynthia Andres. Becks moderna klassiker i ny och helt omarbetad utgåva. En bra introduktion till agil utveckling och mycket bra om de principer och värderingar som vägleder många som fastnat för agila metoder. Gott om värdefulla tips och praktiker även för den som inte vill ta till sig allt i XP.

Managing Agile Projects av Kevin J. Aguano (editor). Intressant, om än något spretig, sammanställning av olika agila metoder ur framförallt ett "icke-utvecklarperspektiv", vilket inte på något sätt betyder att det är ointressant för utvecklare. En intressant del är det XP-kritiska kapitlet i slutet av boken, som även om det i sin tur stött på stark kritik är tankeväckande då även de agila metoderna naturligtvis behöver utmanas även i "de egna leden".

Föredrag och konferenser

Jag har tidigare rapporterat från Developer Summit och JAOO. När det gäller den sistnämnda har jag bara haft tid att ta upp de första dagarna så jag tänkte i korthet nämna några höjdpunkter från resten av dagarna här.

JAOO, 23-28 september i Århus, Danmark. Jag har tidigare rapporterat från de första dagarna på JAOO, fram till och med tisdag förmiddag, så jag tänkte här i korthet nämna några av höjdpunkterna från resten av konferensen.

Tisdag eftermiddag bjöd på en av de presentationer jag mest sett fram emot, Eric Evans om "Strategic Design: Making Models Work in Large Projects". Evans presentation infriade mina förväntningar. Jag blev omedelbart mycket förtjust i hans lågmälda och eftertänksamma framtoning och sätt att presentera. Han framstår verkligen som en underfundig och djupsinnig man. Jag hade även förmånen att åtnjuta en hel dags tutorial med Evans under rubriken "Domain Driven Development" på JAOOs sista dag (dag 5, fredag). Tyvärr överlappade denna tutorial delvis föredraget, även om han gick mer på djupet i dessa frågor under heldagen. Eric Evans förtjänar förstås en egen bloggpost, men tills vidare kan jag inte annat än starkt rekommendera någon av hans presentationer eller kurser.

Under tisdagen bevittnade jag även upprinnelsen till vad som skulle bli en stor "konferens-snackis" - Jim O. Copliens påhopp på TDD: "[it] will deteriorate your design". Dagen avslutades med en intressant analys av hur LINQ kan användas för DDD, förtjänstfullt utförd av Jimmy Nilsson och Kim Harding Christensen. De viktigaste slutsatserna var att LINQ to SQL är ett steg i rätt riktning och troligtvis kommer att göra att fler får upp ögonen för DDD, men presentatörerna saknade stöd för Value Objects.

Dag 3, onsdagen, spenderade jag till stor del på Bob Martins spår "Professional Developer" som innehöll många intressanta presentationer, bl.a. den alltid lika underhållande Kevlin Henney ("With Economy and Elegance") och Michael Feathers ("The Ethics of Error-Prevention"), en av mina favoritförfattare (se ovan). Jag hann också med en intressant case study från Guardian.co.uk där ThoughtWorks Erik Dörnenburg varit involverad i ett intressant projekt som inbegrep bl.a. DDD, Spring, AJAX och AOP. Dagen avslutades med två paneldiskussioner: en med den föga utmanande frågan "Does Architecture Quality Matter?" och en avslutande paneldiskussion under ledning av Martin Fowler där Erik Meijer, Eric Evans, Erik Doernenburg ("the three Eriks") och Esther Derby fick välja var sin höjdpunkt från JAOO att samtal vid. Av någon anledning kom mycket av samtalet att kretsa kring JavaScript, kanske lite oväntat med tanke på deltagarna.

Den fjärde dagen (torsdag) ägnade jag åt en hel dags tutorial med Kevlin Henney och Frank Buschmann: "Pattern-Oriented Software Architecture". Förvisso intressant, men på en lite väl abstrakt och hög nivå för att ge mig något mer direkt användbart. Jag kommer emellertid definitivt att läsa Henneys och Buschmanns bok och de andra i POSA-serien.

Femte dagen deltog jag som sagt i en tutorial med Eric Evans om "Domain Driven Development".

Förutom själva konferensen var det en trevlig fest på måndagen och ett lopp man kunde delta i under tisdageftermiddagen med efterföljande jazzkväll där vem som ville kunde gå upp och spela. Bland annat Roy Osherove (egenkomponerat) och Bob Martin (Jonathan Coultons "Code Monkey") gjorde framträdanden.

En rolig detalj som Johan Lindfors redan bloggat om är att han, Senior Developer Evangelist för Microsoft i Sverige, fick en lite Duke (Javas maskot) rakt i huvudet när Matt Thompson, som leder Suns "technology evangelism efforts worldwide" slängde ut dessa under sin keynoye på tisdagkvällen.

Något som verkligen hörde till höjdpunkterna på JAOO var min torsdagkväll. Efter dagens tutorial på SAS Scandinavian Center stötte jag i hotellbaren ihop med Bob Martin och en trevlig spanjorska som var volontär på konferensen. Efter ett par timmars drinkintag gick vi tillsammans med ytterligare en volontär vidare till uteserveringen på en italiensk restaurang som jag rekommenderat. Precis när vi skulle beställa mat kom plötsligt Michael Feathers gående och beslutade sig för att göra oss sällskap (han arbetar, från Florida, på Bob Martins Chicago-baserade företag ObjectMentor). Efter middagen vidtog en pubrunda där så småningom även Erik Dörnenburg anslut. Jag bombarderade dem naturligtvis med frågor under hela kvällen och försökte lära mig så mycket som möjligt från dessa erfarna utvecklare. Dessutom hade vi väldigt roligt också...

"How hard can it be?" med Andy Hunt. Valtech bjöd in till ett mycket underhållande föredrag med pragmatiska programmeraren Andy Hunt. Han hade precis varit på Öredev och passade på att dra samma presentation i Stockholm. Jag fick tyvärr aldrig chansen att prata med Andy under minglet efteråt, jag hade gärna frågat honom om de stora likheterna mellan hans föredrag och Erik Dörnenburgs och Dan Norths "How Simple Is Too Simple?" - bara en slump därför att de verkar inom samma område eller har de sneglat på varandra?

"SOA & Web Services" med Ole Matzura och Niclas Reimertz, Eviware. Det här är killarna bakom Open Source-verktyget soapUI. Det var ett intressant föredrag som däremot befästa mina fördomar (?) om att Java-världen i många sammanhang har en mindre mogen syn på vad SOA innebär som mestadels handlar om antingen web services och SOAP eller middleware som t.ex. Enterprise Service Bus (ESB).

"DDD, O/RM och lite TDD" med Jimmy Nilsson, factor10, som du kan läsa mer om här.

"Dependency Injection och Aspektorienterad programmering (AOP)" med Niclas Nilsson, factor10, som jag tidigare skrivit om här.

"Scrum i praktiken" med Henrik Kniberg, Crisp, som skrivit gratisboken "Scrum and XP from the Trenches". Bra och hands-on om Scrum och XP. Rekommenderas.

"Windows Workflow Foundation" med Fredrik Gunne, f.d. Microsoft, som du kan läsa om här.

"Pragmatic SOA" med Objectware (halvdag med olika presentatörer). Peter Tallungs nya bolag verkar onekligen intressant. På denna halvdag på Berns visade de ett moget SOA-tänk och väldigt intressanta implementationer på .NET-plattformen som såg ut att hålla en kvalitet man onekligen inte är bortskämd med: fullt med enhetstester och genomtänkt domänmodell. Och detta i en mycket väl genomförd SOA-lösning. Verkligen intressant och jag ser fram emot fler seminarier från Objectware.

"TDD i praktiken" med Joakim Holm som jag tidigare berättat om här.

"Learning from Legacy" med Andreas Brink, factor 10, som på mitt initiativ besökte Avega. Innehållet var ungefär detsamma som på Developer Summit men lite mer och ännu mer diskussion.

"Spelutveckling på DICE" med Henrik Karlsson, DICE. Otroligt intressant inblick i spelprogrammeringens heta värld. Henrik Karlsson berättade ingående om nya Battlefield och visade i en utvecklarversion av spelet för X-Box hur det han pratade om i teorin gestaltades i praktiken. Hur konstigt det än kan låta är jag dock relativt ointresserad av spelutveckling på utvecklarnivå - alldeles för mycket lågnivåprogrammering för min smak - jag föredrar faktiskt utveckling av affärsapplikationer. Men jag beundrar det arbete andra lägger ned; jag kan knappt förstå att de någonsin blir klara med ett spel med tanke på hur många detaljer det är att tänka på.

"MSF 4 Agile" med Michael Herkommer, Inexor. Jag var med och arrangerade en SweNug-sammankomst på Avega där Herkommer höll en intressant och engagerad presentation av hur man kan använda MSF 4 Agile med Team Foundation Server och Visual Studio Team System.

Det är allt jag hinner med just nu. Nu ska jag gå och ta fram champagneflaskan och göra mig redo för tolvslaget. Och för ett nytt år fyllt av nya böcker, föredrag och konferenser, spännande uppdrag, roliga hobbyprojekt och en hel del bloggande. Och föräldraledighet förstås...

Gott nytt år!

Välkommen till Avega!

2007-11-05T22:36:00.001+01:00

Sedan några dagar tillbaka kan du bli delägare i Avega: den 1 november börsintroducerades Avega på Stockholmsbörsens First North. Samma dag kunde man läsa i ett pressmeddelande på Avegas nya webbsajt att vi startar ett nytt dotterbolag inom verksamhetsområdet Business Intelligence. För knappt en månad sedan startade vi ett annat dotterbolag, Qurio AB, med specialistkonsulter inom SAP. Avega är alltså inne i en mycket spännande och expansiv fas just nu och jag är väldigt nyfiken på att få lära mig mer om våra nya verksamhetsområden. De nya bolagen kommer att vara ganska fristående från Avega, ha egna kontor och så vidare, något jag tror kan vara positivt för fortsatt fokus på att vara ledande inom systemarkitektur, integration och IT-ledning för "Avega Classic".

Nu kan vem som helst ta del av den spännande utvecklingen genom att bli aktieägare i Avega. Är du dessutom en erfaren konsult, kanske specialist inom något av våra verksamhesområden, kan du förstås ta en än mer aktiv del av utvecklingen genom att arbeta på Avega. Om du vill veta mer om detta eller bara undrar hur det är att arbeta på vårt företag kan du alltid höra av dig till mig på blogg snabel-a joakimsunden punkt se.

JAOO, dag 2: Castle ActiveRecord med Ayende

2007-11-05T21:38:00.001+01:00

Efter Erik Meijers keynote kändes det på något sätt ännu mer som dagen efter festen och den korta introduktionen på spåret Architecture Quality väckte inte mitt intresse tillräckligt för att jag skulle vilja stanna kvar på det spåret. Jag tänkte att något mer handgripligt skulle få i gång mig och bestämde mig för att istället besöka spåret "Enterprise Application Frameworks" och presentationen "Painless Persistance with Castle ActiveRecord". Castle ActiveRecord är en NHibernate-baserad implementation av ActiveRecord pattern för .NET. ActiveRecord är ett vanligt designmönster när man jobbar med O/R-mappers och definieras på följande sätt i Martin Fowlers Patterns of Enterprise Application Architecture:

"An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data."

Den stora fördelen med att använda Castle ActiveRecord, istället för bara NHibernate, är att det är betydligt enklare att komma igång, du får ytterligare en abstraktionsnivå som gör att du slipper mappningsschemat i NHibernate och annan komplexitet. Castle ActiveRecord låter dig enkelt via attribut specificera vilka objekt och egenskaper som ska mappas och hur de ska mappas. Det finns även en generell basklass man kan ärva från och på så sätt få en hel del standardoperationer, t.ex. CRUD, gratis. Priset du betalar är förstås mindre flexibilitet i mappningen, men om du inte har en mycket komplicerad databasstruktur eller särskilda behov är sannolikheten stor att du inte behöver denna flexibilitet.

Presentatörerna Hamilton Verrissimo och Oren Eini var inga namn jag direkt kände igen, men det visade sig snart att Oren Eini i bloggvärlden är mer känd under namnet Ayende Rahien vars blogg jag följt till och från under en längre tid. Att jag gjort det till och från beror inte på ojämn kvalitet utan på att Ayende är så produktiv att det ibland har varit svårt att hinna med att läsa alla hans inlägg. Förutom denna bloggproduktivitet är han alltså medarbetare i Castle ActiveRecord, men också upphovsman till NHibernate Analyzer, mockbiblioteket Rhino Mocks och MVC-ramverket MonoRail (jmf Ruby On Rails). Han är dessutom medarbetare/bidragsgivare i NHibernate, Python-liknande CLI-språket Boo m.fl. På sin blogg skriver han mycket om dessa ämnen, samt om TDD, DDD, agil utveckling, Open Source för .NET och mycket annat intressant. Ayende är också konsult på israeliska företaget We! och på JAOO deltog han i totalt fyra presentationer. En ganska produktiv person med andra ord. Lägg till detta att han är 26 år gammal och för blott två år sedan muckade från en fyra år lång isrealisk värnplikt!

För den som vill veta mer om Castle ActiveRecord och alla andra spännande "Open Source"-projekt Ayende/Oren är involverad i kan jag varmt rekommendera hans blogg som jag i och med denna presentation lägger till i min blogglista.

Även Hamilton Verrissimo har ett blogalias, Hammett, och är liksom Ayende djupt engagerad i Open Source för .NET, inte minst genom Castle Project. Detta projekt är en samling verktyg, där bland annat Castle ActiveRecord och MonoRail ingår, som ska underlätta utveckling av enterprise- och webbapplikationer.

JAOO, dag 2: Democratizing the Cloud (Erik Meijer)

2007-10-18T23:18:00.001+02:00

Erik Meijer är arkitekt på Microsofts SQL Server Division och jobbar där med dataintegration i programmeringsspråk tillsammans med språkdesignteamen för Visual Basic och C#. På JAOO fick han den otacksamma uppgiften att väcka deltagarna efter måndagkvällens fest. Man skulle kunna tro att han psykedeliska t-shirt - den innehöll förmodligen alla färger människan kan uppfatta och sedan ytterligare några - var ett knep han tog till för att lyckas, men han verkar jämt gå runt i den, så jag vet inte riktigt. Nåväl, tröjan till trots lyckades han inte riktigt med sin uppgift; det var svårt att se den röda tråden i hans keynote och med tanke på att hinkarna vid utgången innehöll många röda och gula lappar verkar det inte gälla bara mig (på JAOO utvärderar man sessionerna direkt vid utgången genom att lägga en grön, gul eller röd lapp i en hink).

Föredragets titel var "Democratizing the Cloud" och redan där verkade han tappa många åhörare som tydligen aldrig sett skisser där molnet används för att illustrera Internet. Den utmaning Meijer ville ta itu med var hur man löser "the Multi-Tier Application Problem"; hur kan vi, i en allt mer distribuerad och serviceorienterad värld, underlätta utvecklingen av distribuerade applikationer? Ja, inte genom att uppfinna något nytt i alla fall ("Stop inventing stuff!"). Vi bör istället göra det möjligt att återanvända gamla beprövade metoder: "stretch the current single-tier client applications design patterns to cover the Cloud". Det innebär att vi vill avvakta med oåterkalleliga beslut om våra distribuerade applikationer till sista möjliga anvsvarsfulla ögonblick (jmf YAGNI). Om Meijer får som han vill utvecklar vi snart våra applikationer utan en tanke på om de ska vara distribuerade eller ej och om behovet uppstår kan vi relativt enkelt genom successiva, verktygsstödda refaktoriseringar partitionera om den till en distribuerad flerskiktad applikation.

Det ska dessutom gå att köra applikationerna på vilken server eller klient som helst, utan att behöva ladda ned annat än applikationskoden. Ett sätt att åstadkomma detta är att utnyttja JavaScript. Meijers team har implementerat en inbäddning av MSIL i JavaScript för just detta syfte. Han visade bland annat hur de med hjälp av JavaScript och CSS gjort det möjligt att rendera 3D-grafik i alla webbläsare med stöd för JavaScript.

Den teknik Meijer talade om är inte alls långt borta, det är nämligen LINQ 2.0. Det verkar onekligen intressant och Meijer & Co har säkert tänkt igenom modellen noga. Jag kan dock inte skaka av mig min skepsis till själva grundtanken: är det verkligen klokt att använda samma programmeringsmodell för distribuerade applikationer som för ickedistribuerade? Abstraherar man inte bort en skillnad som det i själva verket ofta är högst relevant att hänsyn till? (Se t.ex. Martin Fowlers First Law of Distributed Object Design.) Det ska bli intressant att se om och hur Microsoft besvarar dessa frågor i LINQ 2.0.

Meijers webbplats har en hel del intressant material om LINQ 2.0 och de ämnen han berörde i sin keynote. En bra introduktion för den som vill veta mer är just "LINQ 2.0: Democratizing the Cloud" (PDF).

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

2007-10-01T23:08:00.001+02:00

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.

JAOO, dag 1: Craftsmanship and Ethics

2007-09-29T21:29:00.001+02:00

JAOOs webbplats är på många vis en ganska dålig källa till information. Det är exempelvis svårt, för att inte säga omöjligt, att hitta någon som helst information om vad JAOO står för. "Java Object Orientation" är svaret man kan hitta på enstaka bloggar om man googlar. Jag gissar att man helt enkelt tonar ned denna bit därför att konferensen nu har en bredare publik än vad den förmodligen hade från början. En annan detalj som jag missat, liksom många andra förstagångsbesökare jag pratade med, var att det faktiskt är ett företag, Trifork, som arrangerar konferensen. Trots detta har konferensen väldigt stark "community"-prägel och mottot "for developers by developers" känns faktiskt äkta. Triforks CTO Kresten Krab Thorup inledde konferensen på måndagen med att betona att vad som gör JAOO annorlunda är att det är ett "software company setting up a software conference, not to sell, but to learn themselves".

Den som fick äran att öppna konferensen med en keynote var ingen mindre än Robert C. Martin (alias "Uncle Bob") som talade under rubriken "Clean Code II: Craftsmanship and Ethics". Bob Martin visade sig vara en fartfylld välartikulerad man som gestikulerar med hela kroppen för att engagera publiken och han fick i alla fall mig att bli riktigt inspirerad och engagerad. Faktum är att jag tycker ämnet för hans keynote var så pass intressant att jag ska försöka redogöra för det i detalj.

Efter en effektfull, men kanske något för lång och irrelevant, inledning där han använde Kresten Krab Thorups kropp som material för en historisk exposé över jordens historia och människans lilla del däri, ställde Martin den provocerande frågan: "do we have a profession"? Hans svar var tvekande; under en lång tid gjorde utvecklare lite som de ville, valde sig egen stil. Yrket har inte några regler och riktlinjer, ingen historia med ritualer som till exempel advokater och läkare. Men runt millennieskiftet något hända, vårt hantverk definieras och vi börjar få en historia som vår praxis kan luta sig mot. Det börjar bli möjligt att definiera ett yrke som kan luta sig mot en disciplin snarare än förlita sig på dokumenterade processer. Den disciplin Bob Martin förespråkar är förstås Agile.

För att visa sin hängivenhet till de principer och praktiker som denna disciplin bygger på bär Martin, och numera även många av JAOOs deltagare inklusive undertecknad, ett grönt armband med påminnelsen/uppmaningen "Test first". Men exakt vilka principer och praktiker är det vi talar om?

Short iterations
Martin förspråkar en eller två veckors iterationer, fyra är alldeles för lång tid. I slutet av varje iteration ska det finnas exekverbar kod, dokumentation, tester etc. Det ska i princip vara möjligt att leverera mjukvaran varannan vecka.
Don't wait for definition
Sitt inte och vänta på att någon annan ska definiera vad som ska göras, utan bidrag själv till definitionsprocessen genom att bygga kod och få feedback.
Abstract away volatility
Kod som är en mer trolig kandidat för förändring ska vara på ett ställe och kod som troligtvis inte behöver förändras ska vara på ett annat. "No JavaScript doing business logic in the GUI!"
Decouple from others
Koda inte direkt mot andras implementationer, då kan du lätt bli sittande och vänta på att de ska bli klara. Använd stubs, mocks, simulators och så vidare - då berättar du också för andra hur du vill att interfacen ska se ut.
Never be blocked
Detta är "The Prime Directive". Martin använde ett exempel med en grupp testare som "inte kunde göra något" eftersom deras testserver inte var konfigurerad. Har inte utvecklarna fungerande mjukvara på sina datorer? Sätt er vid en av dem! Något kan man göra medan man väntar...
Avoid turgid viscous architectures
En del arkitektur hindrar mer än den hjälper. Den skapas ofta av arkitekter som vill lösa allting. Ett sätt att komma till rätta med problemet är att låta arkitekterna utveckla: "If architects have to write code they have to live in the mess they've created."
Incremental improvement
Koden är obegriplig, svårföränderlig, otestbar o.s.v. Vad gör du? "Admit you have a mess and clean it up! Bit by bit, day by day, slowly clean it up." Gör det till en regel att alltid checka in lite bättre kod än du checkade ut. Vi gör ofta tvärtom - det är inte professionellt.
No grand redesigns
Ledningen är aldrig intresserade av detta. "But then the developers begin to bang the drums... And management resigns. Enter the Tiger Team!" De bästa utvecklarna bildar toppteamet som ska bygga det nya fantastiska systemet. "Det gamla systemet" är specifikationen, så hur svårt kan det vara? Samtidigt sitter andra utvecklare kvar och förvaltar och vidareutvecklar systemet i drift. Det blir som Zenons paradox: hur fort Aristoteles än springer måste han alltid först ta sig dit sköldpaddan började med sitt försprång, men då har sköldpaddan hunnit ytterligare en bit och så vidare i all oändlighet...
Progressive widening
Pragmatic Programmers kallar det tracing bullets, i XP kallar man det spikes: lägg till en liten feature som går hela vägen uppifrån GUI ned till databasen och fortsätt därifrån. "Add a thin slice, widen it progressively."
Progressive deepening
Få den tunna skivan att fungera ett lager i taget. "Make it run, make it work, make it fast."
Don't write bad code
Varför skriver man dålig kod? "Vi hade inte tid att skriva bra kod" är ett vanligt svar. Men har man i så fall verkligen tid att hantera konsekvenserna av dålig kod i form av fler defekter, svårare underhåll och så vidare? "Bad code is not something that slows someone else down months from now - it slows you down immediately!" Vad är det vi producerar, vad är vår artefakt? Ett systems beteende? Nej, det är koden som är vår produkt. "If the code is a mess, the product is a mess. Bad code stays forever, dragging the team down, eventually dragging the company down."
Go fast, go well
"The only way to go fast is to go well."
Clean code
"What is clean code? It is when the code reads in such a way that, as you read it, each line is what you expect it to be."
Test-Driven Development
"The jury was out on this one, but now they have come back and it is a best practice." När Bob Martin frågade publiken om de ägnade sig åt testdriven utveckling räcktes ett anmärkningsvärt stort antal händer upp. "All the time?" Något färre händer. Robert Martin använder puristens definition av TDD:
1. Ingen produktionskod får skrivas innan du har ett test som misslyckas.
2. Du måste sluta skriva enhetstest när det misslyckas och skriva produktionskod så att det lyckas.
3. Du får inte skriva mer produktionskod än vad som behövs för att få testet att lyckas.
Något färre händer kvar efter denna definition.
Att bedriva TDD på detta vis tvingar oss att ha exekverbar kod hela tiden. "What makes code flexible? The effects of architecture and design are secondary. Tests are what makes code flexible and maintainable."
QA Should Find Nothing
Det är i alla fall den inställningen vi bör ha när vi kodar.
100% Code Coverage
Använd ett verktyg som t.ex. NCover för att se till att din code coverage är i närheten av 100% (i närheten räcker eftersom de flesta verktyg aldrig når 100% eftersom de inte räknar in interface).
Avoid debugging
Titta på koden och hitta buggen där - koden fungerade ju för två minuter sedan (se TDD ovan).
Manual Test Scripts Are Immoral
"Tryck på den knappen, skriv in det och det i inmatningsfälten, kontrollera att resultatet blir XYZ..." Om och om igen. "Could you imagine doing that for a job?! It's immoral!" Låt testarna fokusera på kreativa, utforskande tester.
Definition of done
"What is the definition of done? All tests are passing."
Test through the right interface
Testa inte via ett grafisk gränssnitt. Om det inte är det grafiska gränssnittet som ska testas och då ska affärslogiken simuleras/stubbas.
Apprenticeship
Det bästa sättet att lära sig är att sitta med erfarna utvecklare vecka ut och vecka in. Parprogrammera.
Use good tools
Det finns mängder av verktyg där ute, de bästa är ofta Open Source. Varför? "They put care into code."

Ovanstående är hämtat från mina egna minnesanteckningar så vissa citat kanske inte är helt korrekta och möjligen har jag missat ett par punkter. Många av dessa punkter, ja förmodligen alla, är i någon variant kända för de flesta som intresserat sig för agila metoder de senaste åren. Och vissa av de Java-människor jag pratade med tyckte inte det var något att höja på ögonbrynen åt. Kanske beror det på min annorlunda bakgrund (.NET, icke-agila projekt), men jag tycker det var fantastiskt inspirerande att höra en prominent person som Bob Martin med självklarhet, glöd och passion konstatera att "så här är det, så här ska man arbeta - låt ingen intala dig motsatsen". Jag hoppas verkligen att min inspiration ska smitta av sig på andra i de projekt och sammanhang jag deltar i och att jag får tillfälle och möjlighet att tillämpa dessa goda riktlinjer i mitt yrkesutövande. Nu har jag i alla fall ett grönt band som påminner mig. :-)

JAOO, dag 0: "Leading Agile Retrospectives"

2007-09-29T20:40:00.001+02:00

I lördags anlände jag äntligen till Århus efter en smått hektiskt period med en veckas solsemester med kraftigt försenad hemresa, två intensiva arbetsdagar och ett snabbt besök hos vänner i Köpenhamn. För dig som inte besökt Århus kan jag berätta att det är en trevlig liten storstad, en universitetsstad som med ett invånarantal på 300 000 är Danmarks näst största stad. Den är dessutom sedan 1987 säte för konferensen JAOO.

Själva konferensen och dess sessioner började egentligen först på måndagen och slutade i onsdags, men den vetgirige går på tutorials redan dagen innan och avslutar också med tutorials torsdag och fredag. För söndagens tjuvstart hade jag valt "Leading Agile Retrospectives: A Simple, Pragmatic Framework" som leddes av Diana Larsen, en av de människor som förmodligen lett flest agile retrospectives i världen och som tillsammans med Esther Derby författat boken "Agile Retrospectives: Making Good Teams Great!" (Pragmatic Bookshelf, 2006).

Ett retrospektiv är med Larsens och Derbys ord "a special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork" och som "enable whole-team learning, act as catalysts for change, and generate action". Till skillnad från mer traditionella projektutvärderingar fokuserar ett retrospektiv inte bara på utvecklingsprocessen, utan också på projektgruppen.

Enligt programbeskrivningen skulle vi under denna heldag introduceras i ett enkelt ramverk för retrospektivdesign och få prova på att själva designa ett retrospektiv. Vår 20 personer starka klass blev nästan omedelbart indelade i grupper enligt principen om att "7+-2" är det optimala antalet projektmedlemmar och fick genast i uppgift att simulera ett projekt så att vi skulle ha något att göra ett retrospektiv om. Det simulerade projektet gick ut på att skapa en 3D-modell (!) för "Agile Team Leadership & Management" med fem olika stakeholders: konsulten som ska sälja den, teamet, teammedlemmen, Scrum Master/coach och Functional/Project Manager. Vi hade ungefär en halvtimme på oss och det material som stod till vårt förfogande var huvudsakligen piprensare, post-its, papper, klistermärken, gem, gummiband och tejp. Jag vill faktiskt påstå att vårt team producerade den tydligaste och mest användbara modellen...

Efter denna övning hade vi så ett projekt att utgå i från för att göra ett retrospektiv. Diana Larsen hade redan en färdig design som vi använde oss av. Det började med att hon presenterade agendan och målet med dagens retrospektiv: "Focus on improving the balance and flow between our planning and activities". Sedan fick alla göra en övning hon kallade "Sense of the room" där vi fick skriva ned en känsla (förvirring, tyst, lycklig, engagerad o.s.v.) och ett behov (respekt, kommunikation, vila, utmaning etc.) på olikfärgade lappar. Lapparna samlades in, blandades och lästes upp. Syftet med denna övning var tvåfalt: att få alla att deltaga redan från början och att få en uppfattning om stämningen i teamet. Denna inledning kallas för "Set the stage" i Derbys/Larsens ramverk.

Nästa steg i ramverket är att samla data ("Gather Data"). Den metod Larsen hade valt var att vi var och en under fem minuter på post-its skulle skriva ned observationer från projektet: saker vi iakttog, vad folk gjorde, sådant som stack ut eller andra händelser från projektet. Sedan klistrade vi upp våra lappar under en av fyra kategorier i form av olika ansiktsuttryck som hon förberett på väggen: glad, ledsen, arg, likgiltig. På detta sätt fick vi fram både fakta (lapparna) och reaktioner (kategoriseringen).

Nu var det dags att få fram insikter ("Generate Insights"). För detta använde vi något som kallas inlärningsmatris ("Learning Matrix"). Matrisen har fyra fält för att kategorisera erfarenheter från projektet: "Do same/more", "Do less/stop", "Try/Do differently" och "Appreciation". Vi började med en kort brainstorming för att fylla de olika fälten. Bland annat kom det fram att vi haft kul ("Appreciation"), att vi borde ha brainstormat för att komma på idéer till vår modell ("Do differently") och att vi borde ha jobbat mer iterativt ("Do more"). Därefter fick vi var sin handfull klistermärken med olika valörer (typ 5 cent till 10 dollar) som vi använde för att gradera de idéer vi tyckte det fanns mest "energi" kring i gruppen. De tre idéer som fick det högsta sammanräknade värdet valdes ut för diskussion.

Utifrån de idéer som kom fram kunde vi sedan avgöra vad som borde prövas i nästa iteration ("Decide What to Do"). För att undvika att fastna på första bästa idé, brainstormade vi fram en lista med aktiviteter där vi sedan fick tre röster var för att avgöra vilken eller vilka som var viktigast ("First fit vs Best fit"). Vi valde ut en av våra idéer och fick sedan skapa en "Action Report" för den:

What is the action?
Who has the zeal to carry it?
When will "who" check in with the team?
Why will this succeed?
How will we measure success/progress?

Till sist avslutades retrospektivet med en summerering av vad som ska göras så att alla i teamet är införstådda med vad man kommit överens om. Det är också viktigt att tacka alla för ett gott arbete. ("Close the Retrospective")

Detta är förstås bara ett exempel på hur man kan genomföra ett retrospektiv. Det viktiga är att den innehåller alla delar i ramverket:

Set the Stage
Gather Data
Generate Insights
Decide What to Do
Close the Retrospective

Vi hann också med att utifrån förberedda scenarier, alltjämt indelade i samma grupper, designa egna retrospektiv utifrån ramverket. Diana Larsens och Esther Derbys bok innehåller en rad olika aktiviteter man kan använda för de olika stegen; vilka man använder handlar dels om tycke och smak, dels om den specifika situation man står inför. Det kan till exempel vara så, som i det scenario min grupp tilldelades, att deltagarna är oroliga för att bli beskyllda för det som gått fel och då är det viktigt att få dem att känna sig trygga och använda aktiviteter där deltagarnas åsikter i stor utsträckning är anonyma.

Dagen avslutades med en "clinic" där vi gick igenom frågor och funderingar kring retrospektiv, dels sådana vi formulerat i början av dagen och klistrat upp på väggen, dels sådana som dykt upp under dagen.

Jag hade väntat mig något mer teori kring ramverket och att få lära mig fler tekniker, men det var bra att få erfarenheten av att praktiskt ha deltagit i och designat ett retrospektiv. Det gör förhoppningsvis att barriären för att testa det i sitt arbetsliv är lättare att komma över och jag vill verkligen försöka få in mer av denna teknik i de projekt jag arbetar med. Det är allt för ofta så att man bara rusar fram längs en kurs man tagit ut tidigt i projektet och aldrig stannar upp och reflekterar över vad man gör och var man är på väg.

Att anlända till JAOO innan majoriteten av deltagarna och att dessutom börja med en handgriplig tutorial med mycket grupparbete var en perfekt mjukstart på konferensen och flera av deltagarna fortsatte att umgås under hela veckan. Man slapp dessutom trängas med alla andra under den stora registreringen på måndagen.

JAOO - her kommer jeg!

2007-09-06T22:48:00.001+02:00

Nu har jag anmält mig till konferensen JAOO i Århus, Danmark. JAOO tycks stå för "Java Object-Oriented", men det är nog mycket en historisk kvarleva och konferensens innehåll torde attrahera en vidare krets än namnet antyder. Bland årets spår finns t.ex. LINQ, The .NET Road, Scrum, Web 2.0, Real-World Ruby, Modeling och Agility on the Edge.

Själv ser jag särskilt fram emot den heldagstutorial jag bokat in för fredagen: "Domain Driven Development" med Eric Evans. Andra talare som fångar mitt intresse är Martin Fowler, Michael Feathers och Robert C. Martin, som alla hör till mina absoluta favoritförfattare just nu (mer om deras böcker på denna blogg senare).

Om du ska till JAOO och har lust att ses, hör av dig! Jag kommer att vara där alla sex dagar, från och med söndagen den 23 till och med fredagen den 28 september.

A Low-Tech Approach to Understanding SOA

2007-09-04T22:43:00.001+02:00

I våras på Developer Summit deltog jag i en workshop med Thoughtworks Dan North. Rubriken var "SOA for Human Beings" och jag försökte sammanfatta en del av mina intryck här. Utgångspunkten för Dan Norths presentation var de tankar och erfarenheter han tidigare sammanfattat i en artikel för tidningen Better Software Magazines majnummer. Han har nu lagt ut artikeln, "A Low-Tech Approach to Understanding SOA", på sin blogg:

This article presents a simple, technology-agnostic approach to designing and evolving SOAs. You will not see acronyms such as WSDL, SOAP, or REST, and I promise not to use technical terms like “orchestration,” “realization,” and “governance.” Because of this, you will be able to design and implement service-oriented architectures that truly serve your business.

Ladda ned den som PDF eller läs den direkt på webben.

Avegan nominerad till .NET Awards

2007-08-27T10:52:00.001+02:00

Min kollega Jens Andersson (Team Shmup) har blivit nominerad till .NET Awards med sitt hobbyprojekt Bullet Hell Tactics! Spelet är ett shoot-em-up utvecklat med C# i Game Studio Express och använder sig av Microsoft XNA Framework som fungerar på både Windows och Xbox 360. Du kan själv ladda ned spelet från Team Shmups blogg.

Se mer om nomineringen och vad Jens har att säga om sitt spel på sajten för .NET Awards. Och glöm inte att rösta på Team Shmup och Bullet Hell Tactics när du ändå är i farten!

Äntligen tillbaka

2007-08-16T20:30:00.001+02:00

Nu är en lång och skön semester över och jag börjar så sakteliga komma igång ordentligt med arbete, läsande, bloggande och annat. Jag har faktiskt varit tillbaka på jobbet i snart två veckor, men eftersom det inte bara är min semester som tagit slut, utan också Premier Leagues, har en del fotbollstittande kommit i vägen för annat. I helgen lyckades jag hinna med Sunderland - Tottenham, West Ham - Manchester City, Aston Villa - Liverpool, Sevilla - Real Madrid, halva Arsenal - Fulham, Chelsea - Birmingham, Manchester United - Reading och AIK - Gefle (på plats)! Och så ytterligare fem matcher hittills i veckan, ej inräknat Liepajas Metalurgs - AIK som ljuder i webbradion just nu.

Snart lugnar det förhoppningsvis ned sig lite på fotbollsfronten, men just nu är nyhetens behag stort. Säsongspremiärer är särskilt roliga, inte bara för att man fått vänta så länge, utan också därför att ligan fortfarande känns ganska öppen och nykomlingarna ofta skräller trots storklubbarnas för varje år allt mer bisarra satsningar. Okej, det kanske kan verka magstarkt med tanke på att det kommer från en Chelsea-supporter, men det är i alla fall roligt när de andra elefanterna (läs: Manchester United) faller...

Jag hade sett fram emot Microsofts Professional Developer Conference 2007 i Los Angeles i höst, men den blev ju tyvärr uppskjuten. Tur då att jag upptäckte JAOO istället: en mycket intressant konferens så nära som Århus och med talare som Martin Fowler, Eric Evans, Robert C. Martin, Ken Schwaber och Jeff Sutherland. Med tanke på de intressanta namnen och den geografiska närheten är det lite konstigt att man inte hör talas om JAOO så mycket.

Ska du på JAOO? Har du varit där tidigare?

Joakim Holm hos Avega: TDD i praktiken

2007-06-28T22:40:00.001+02:00

Den bloggande terriern Joakim Holm var den sista i raden av föredragshållare som besökte Avega innan vi nu gör ett kort uppehåll över sommaren. Joakim Holm är en systemutvecklingskonsult med fokus på agila processer som Extreme Programming och Scrum. Han var inbjuden till Avega för att leda en kata för testdriven utveckling (TDD) i Java. "Kata" är ett uttryck från japansk kampsport där det är liktydigt med ett koerograferat mönster av rörelser, t.ex. slag och sparkar. I detta sammanhang syftade det väl närmast på en koreograferad TDD-utvecklingssession där Holm vid tangentbordet med fast hand lotsade oss igenom hela övningen.

Holm tog sin utgångspunkt i Robert C. Martins (alias "Uncle Bob") exempel med ett program som ska beräkna poäng för en bowlingserie. Detta exempel återfinns i den eminenta boken "Agile Software Development, Principles, Patterns, and Practices" (finns även i nyutgiven version för C#), men Holms förlaga var om jag förstod saken rätt en live-dragning av Robert Martin själv som skiljde sig lite från (mitt minne av) boken. Kraven är lika enkla som uppenbara: poängberäkningsreglerna för bowling. Först av allt tas en enkel design fram, ett UML-diagram med några till synes självklara klasser: Game, Roll, Frame och Score. Som sig bör i TDD börjar man koda genom att först skriva ett så enkelt test som möjligt:

public void testCanCreateGame {
BowlingGame bowlingGame = new BowlingGame();
assertNotEquals(null, bowlingGame);
}

Eftersom detta är den första kod vi skriver kan vi inte ens kompilera - det finns ju ingen BowlingGame-klass. Med hjälp av refaktoriseringsverktyget ("refactoring tool") i vår utvecklingsmiljö (Eclipse för Java i det här fallet, för Visual Studio måste man använda ett tredjepartstillägg som ReSharper) skapar vi enkelt klassen automatiskt. Efter det kan vi köra vår testsvit, som än så länge bara består av ett test, och få grönt ljus när testet passerar. Nästa test blir lite svårare, men är fortfarande väldigt enkelt: poängen när alla slag hamnar i rännan ska vara noll. Eftersom man maximalt kan slå 21 slag i en serie borde testet se ut så här:

public void testGutterGame {
BowlingGame bowlingGame = new BowlingGame();
for(int i = 1; i <= 21; i++) {
bowlingGame.roll(0);
}
assertEquals(0, bowlingGame.score());
}

Testet kompilerar naturligtvis inte, utan vi får lägga till metoderna roll(int) som tar antal nedslagna käglor som inparameter och score() som returnerar den totala poängen i spelet. Denna gång lägger vi emellertid till ett viktigt element i TDD som vi hoppade över i det första testet; när vi fått programmet att kompileras ser vi till att få rött ljus på testet. Vi kodar vår score()-metod så att den returnerar -1 bara för att få testet att misslyckas. Om vi inte gör det kan vi inte vara säkra på att testet verkligen testar det vi tänkt. När vi fått rött ljus ändrar vi "produktionskoden" så att den returnerar summan av de 21 slagen och vi får grönt ljus. Här framhåller Holm en viktig regel i TDD: innan vi får skriva en enda rad produktionskod måste vi få rött ljus från ett test. Därför är det positivt med rött ljus - då får vi koda!

En annan regel i TDD är att alltid välja den enklaste lösningen för att få ett test att passera och aldrig skriva mer kod än nödvändigt. Sålunda tänker vi inte på spärr och strike när vi skriver vår score()-metod utan summerar alla slag rakt av (vid spärr och strike får man en bonus som är lika stor som ett eller två nästföljande slag). Vi bryr oss inte heller om duplicering och funderar kanske inte så mycket på att bryta ut koden i egna metoder. Detta gör vi istället när vi har ett passerande test på plats - då kan vi refaktorisera vår kod steg för steg och köra testerna för att se att vi fortfarande får grönt ljus. Detta sätt att arbeta gör att man med stor trygghet gradvis kan förbättra designen i systemet utan att behöva oroa sig för att bryta existerande funktionalitet.

För att sammanfatta ser stegen för testdriven utveckling ut så här:

Skriv ett test som misslyckas (rött ljus).
Se till att det kompilerar.
Skriv kod så att testet lyckas (grönt ljus).
Ta bort duplicering och förbättra design.
Repetera.

Följandes detta mönster gick vi tillsammans med Holm framåt steg för steg till dess att vi slutligen hade ett program som klarade att beräkna poängen för bowlingserier med såväl rännslag som spärr och strike. Förutom att testerna hjälper oss att gå framåt och är ovärderliga vid förvaltning och vidareutveckling av programmet, gav de oss också en applikationsdesign som var en annan än den vi från början skissade fram. Faktum är att BowlingGame blev applikationens enda klass och att den hade ett mycket begränsat antal metoder som dessutom var korta och koncisa. Inledningsvis var det nog ingen som hade trott att programmet skulle bli så litet och enkelt och hade vi inte använt oss av TDD hade det förmodligen inte blivit det heller. Jag har själv sysslat en del med TDD på sistone och gillar det verkligen. Något som jag dock inte riktigt kopplat greppet om var just den "top-down-design" som Holm/Martin använder. Genom att börja uppifrån med användarcentrerade funktioner som "testGutterGame", snarare än börja på låg nivå med t.ex. Frame.GetScore() om vi utgått från det initiala UML-diagrammet, blir det lättare att undvika överdesign.

Jag är övertygad om att jag kommer att jobba allt mer med testdriven utveckling i framtiden och Holms roliga TDD-kata inspirerade mig ytterligare. Om du ännu inte testat TDD råder jag dig att göra det. Det kan vara en liten tröskel innan man kommer i gång, särskilt om man inte är van att jobba på det objektorienterade sätt som i alla fall jag har svårt att separera från TDD och det kan även vara svårt att vänja sig vid tanken på att skriva ett test innan det finns kod, men man kommer snabbt över den och då är det verkligen ett roligt och belönande arbetssätt.

Mer från Developer Summit

2007-06-25T22:51:00.001+02:00

Från början hade jag tänkt bjuda på ganska detaljerade redogörelser från de föredrag jag valde att besöka på Developer Summit 2007 i slutet av maj, men tyvärr har jag inte lyckats ge mig själv tid till detta. Det blev i alla fall ganska långa referat av Beat Schweglers keynote om SOA och Erik Doernenburgs keynote "How Simple is Too Simple", samt lite från ett par andra sessioner från konferensens första dag. I dag är det emellertid en månad sedan konferensen gick av stapeln och arrangören Cornerstone har dessutom lagt ut nästan alla presentationer på sin webbplats, så det känns inte längre särskilt angeläget att blogga om dem. Jag skulle dock kort vilja nämna något om några av de sessioner jag bevistade andra dagen, samt om de intressanta workshops det bjöds på den tredje dagen.

Niclas Nilsson - "Dynamic Languages for Statically Typed Minds"
Jag har länge känt till Ruby och Ruby On Rails men aldrig orkat undersöka det närmare. (Jag kommer inte heller att lägga ut texten om Ruby här, men den som är intresserad kan t.ex. kolla in introduktionsartikeln "Rolling with Ruby on Rails".) Det jag har snappat upp har förvisso låtit intressant, inte minst den påstådda produktiviteten och fokuseringen på test och testbarhet. På något sätt har jag ändå haft känslan av att det är mer intressant för utvecklare intresserade av Linux, Apache och PHP eller möjligtvis Java. Språk och miljöer som marknadsförs som produktiva och snabba att komma i gång med brukar också ofta visa sig ha brister så snart man kliver utanför ramarna för marknadsföringsexemplen. Dessutom har min erfarenhet lärt mig att produktivitet och snabbhet vid nyutveckling är av marginell betydelse jämfört med andra kvaliteter som exempelvis hur lätt kod och design är att förstå och hur lätt den är att förändra. Förresten trivs jag ganska bra med Windows och .NET Framework så varför skulle jag byta till en annan plattform och ett annat språk och lära mig allt på nytt?

Förutsatt att man (som jag) tycker att det finns fördelar med Ruby, såsom duck typing, mixins och extensions, är ett svar på den frågan IronRuby, d.v.s. Ruby för .NET Framework. Eller IronPython för den delen, som ju är ett annat populärt dynamiskt språk. IronRuby gör det möjligt att använda styrkan i programmeringsspråket Ruby tillsammans med .NET Frameworks alla välbeprövade klassbibliotek, tredjepartskomponenter, ramverk etc. Dessutom ska man inte underskatta det lärorika i att med jämna mellanrum lära sig ett nytt programmeringsspråk för att få nya perspektiv på utveckling och ta till sig tekniker och tankesätt som man kanske kan tillämpa i sitt "eget" programmeringsspråk. Exempelvis C# har ju tagit starka intryck av de dynamiska språken, något som syns redan i C# 2.0 och som blir ännu tydligare i 3.0 med t.ex. Extension Methods.

Niclas Nilssons trevliga och avslappnade genomgång av de dynamiska språkens fördelar gjorde mig riktigt nyfiken på att börja experimentera med Ruby och en före detta Sogeti-kollegas blogg fick mig att inse hur enkelt det är att komma i gång. Nu ska jag bara se till att få det installerat på min PS3 också...

(Läs gärna mina tidigare blogginlägg om när de båda kollegorna på factor10 Jimmy Nilsson och Niclas Nilsson under våren var för sig besökte Avega för att tala om TDD och DDD respektive Spring.NET.)

Andreas Brink - "Learning From Legacy: Making Software Maintainable" och "Testing and Refactoring Legacy Code"
För ett par månader sedan snubblade jag över en artikel av Michael C. Feathers som handlade om hur man kan göra "legacy code" testbar. Efter att artikeln publicerades har han skrivit en hel bok i ämnet, "Working Effectively with Legacy Code". Feathers har jobbat länge med Extreme Programming och testdriven utveckling och har bland annat skapat CppUnit, C++-versionen av JUnit/NUnit, det mest populära ramverket för enhetstester. "Legacy code" är enligt Feathers all kod som saknar tester, oavsett när den är skriven. Det kan tyckas vara en ganska extrem hållning, men det ligger något i den definitionen trots allt. Även om "legacy" ("arv" på svenska) mer ordagrannt har med gammal kod och gamla system att göra, använder man ofta termen för att beteckna kod som är svår att förändra och svår att förstå, vilket enligt Feathers erfarenhet i princip är all kod som saknar tester. Att arbeta effektivt med "legacy code" handlar därför väldigt mycket om att få in koden i ett testramverk, om att göra den testbar.

Detta var också något av Andreas Brinks, konsult från Consignit, perspektiv under hans föredrag "Learning From Legacy: Making Software Maintainable". Brink lånade, dock med stor självständighet, en del från Feathers och hade dessutom en hel del annat bidra med. En intressant poäng han gjorde var vilken bra erfarenhet det är att jobba med det som, ofta nedlåtande, kallas för "förvaltning"; det är här man verkligen kan lära sig vad som är bra respektive dålig design och det är här man har chansen att i praktiken förbättra design och arkitektur. Men då är det också viktigt att de som utvecklat ett system får fortsätta vara med även i underhåll och förvaltning. Enligt Brink är det därför ett misstag att dela upp arbetet med ett system i utveckling respektive förvaltning, något som är snarare regel än undantag.

Andreas Brink var en av de största överraskningarna för mig under Developer Summit. Förutom hans föredrag hade jag också förmånen att delta i den mycket lärorika workshop han ledde om "Testing and Refactoring Legacy Code" under Developer Summits tredje dag. Brink var en duktig talare med ett intressant ämne som jag hade praktisk nytta av redan nästa arbetsvecka och dessutom var det inspirerande med någon som talade sig varm för förvaltning och underhåll av kod. Jag hoppas vi kan få se honom besöka Avega framöver.

Dan North - "SOA for Human Beings"
Jag hade hört att Dan North skulle vara en intressant och fascinerande person och titeln på hans workshop var minst sagt intressant. Mina förväntningar var följaktligen högt ställda, men jag visste inte riktigt vad jag förväntade mig. Tre timmar senare var jag mycket nöjd med mitt val av workshop men jag var fortfarande osäker på vad jag fått. Det är väldigt svårt att återge Dan Norths workshop, men man kan i alla fall säga att det handlade om SOA. North använde en sorts associationsteknik för att presentera sitt ämne; han beskrev det själv vid ett tillfälle som att han skapade mind maps och använde whiteboardtavlan som en slide show. Så fort han kom på att det var något som han skulle återkomma till senare skrev han ned ett minnesord för det i tavlans ena hörn och fortsatte med huvudspåret. Vad nu huvudspåret var, för han tvekade sannerligen inte att sväva ut i anekdoter om än det ena, än det andra; vi fick oss till livs en egensinnig exposé över den serviceorienterade arkitekturens historik från stordatortiden fram till våra dagar, en snabb genomgång av bröderna Dreyfus inlärningsteori och mycket annat.

Hade det varit en mindre intressant talare, mindre intressanta anekdoter och mindre lärorika utsvävningar hade jag blivit besviken på avsaknad av röd tråd och bristande förmåga att inrymma ämnet inom de givna tidsramarna. Men North lovade oss aldrig något särskilt utan inledde med att fråga vad vi hade för förväntningar på de tre timmarna, stannade upp halvvägs för att värdera vad vi hunnit med och eventuellt omvärdera hur vi skulle gå vidare. Framför allt var dock det mesta han hade att säga fruktansvärt intressant. Om du någonsin får tillfälle att lyssna på Dan North rekommenderar jag att du tar chansen, vad än ämnet är; han är ett fenomen.

Någon redogörelse för vad Norths workshop handlade om tänker jag som sagt inte försöka ge, men några citat kan vara roliga och ge en liten vink om vad det är för person vi har att göra med.

"SOA is how departments help other departments getting work done."
"Service providers should match departments."
"It is not SOA if it needs a computer."
En extrem version av SOA-mantrat att det handlar om vad, inte om hur.

"A CIO is the person who manages the people software licenses."
"The CIO and the Enterprise Architect get together in a room - usually with a crack pipe - and produce something they call an 'Enterprise Data Dictionary'."
Dan Norths syn på en viss sorts informationsarkitektur...

Developer Summit, dag 1

2007-06-20T23:03:00.001+02:00

Utöver de båda keynotes jag skrivit om tidigare (Beat Schwegler och Erik Doernenburg) bjöds det på en del andra intressanta föredrag under Developer Summits första dag.

Tess Ferrandez - "Common problems in ASP.NET Production environments"
Jag har länge sporadiskt följt Tess Ferrandez blogg "If broken it is, fix it you should". Ferrandez är Escalation Engineer på Microsoft Product Support Services och hennes bloggande syftar till att hjälpa .NET-utvecklare "resolve issues on production system, mainly using Windbg.exe from http://www.microsoft.com/whdc/devtools/debugging/default.mspx along with sos.dll that ships with the debugging tools". Det var precis vad hennes session på Developer Summit handlade om också. Det är egentligen inte något av mina främsta intresseområden, men jag har alltid fascinerats personer som förstår vad som händer under huven och obehindrat kastar sig över textbaserade konsolapplikationer med kryptiska kommandonamn och switchar. Ferrandez talade samtidigt som den till synes intressanta arkitektsessionen "The New Role of the System Architect" med Kentors Peter Tallungs och Visabs Fredrik Wahlstedt, men jag valde Ferrandez eftersom man aldrig vet när hon kommer till Sverige igen medan åtminstone Tallungs dyker upp lite här och där. Döm därför om min förvåning när Tess Ferrandez inleder på svenska och berättar att hon jobbar på Microsoft i Kista! Jag har tydligen läst hennes blogg lite för sporadiskt för där kan man tydligt se att hon är svenska (och spanjorska).

Ferrandez delade in sitt föredrag i tre delar: Performance Issues, Memory Issues och Crashes and Exceptions. Det verktyg hon använde för att analysera problemen inom alla områden var det tidigare nämnda WinDbg. Med detta program kan man bl.a. se exakt hur många instanser av olika objekttyper som ligger på heapen, hur stort ett enskilt objekt är och skriva ut ett objekts innehåll. För den som är intresserad av den här typen av frågor, har problem med ASP.NETs minneshantering, laddning av assemblies etc, eller vill lära sig mer om WinDbg kan jag rekommendera en närmare titt på "If broken it is, fix it you should", där man också kan hitta mycket av innehållet från Ferrandez session.

Jimmy Nilsson – "Beyond Agile"
Jimmy Nilsson har tidigare gästat Avega och jag läste med stort nöje hans senaste bok, så det var med stor förväntan jag såg fram emot hans föredrag med det spännande ämnet "Beyond Agile". Han började lite trevande och konstaterade att allt fler arbetar agilt nu för tiden; men har verkligen de agila metoderna löst alla våra problem? Frågan är förstås retorisk och med utgångspunkt i ett antal problemområden gav Nilsson sin syn på vad han skymtar bortom de agila metoderna.

"Teamwork doesn't work"
"Requirement descriptions are poor"
Ett sätt att komma till rätta med dessa problem är BDD, Behavior-Driven Development. BDD handlar i sin enklaste och ursprungliga form om ett annat sätt att tänka testdriven utveckling (TDD). Istället för att formulera testerna som "TestWithdraw" bör man formulera dem som "CanWithdrawMoney", "ShouldIssueWarning" o.s.v. I ett lite större perspektiv handlar det om att definiera acceptanskriterier i ett tidigt skede, göra det på verksamhetens språk och göra kriterierna exekverbara. Ett exempel på hur det skulle kunna se ut:

"Money can be withdrawn"
GIVEN
Account has money
Card is valid
WHEN
Card is inserted
Money is requested
THEN
Card is output
Money is output
Account is credited

Nilsson gav inget exempel på något verktyg eller någon miljö där detta är möjligt, men mina tankar under föredraget gick till FitNesse som jag länge tänkt titta närmare på. Med tanke på vad Dan North tillkännagav och Jimmy Nilssons kollega Niclas Nilsson bloggade om härom dagen antar jag emellertid att rbehave var vad han hade i tankarna. Med denna form av BDD skulle också testarna kunna komma in tidigare i projektet än vad som ofta är fallet i många utvecklingsprojekt, något som kanske kan bidra till att stärka teamkänslan och samarbetet.

"Lack of focus on understanding the domain"
"Focus on large scale and overview is missing"
Domain-Driven Designs (DDD) fokus på problemdomänen och på ett gemensamt språk för verksamheten och utvecklingsteamet kan vara en lösning på dessa problem. Vad gäller ett mer övergripande perspektiv och DDD kan man konstatera att Eric Evans ägnar ett antal kapitel i sin bok "Domain-Driven Design" åt "strategic patterns"; Nilsson berättade att Evans sagt att om han skulle skriva om boken i dag skulle han lägga denna del först, istället för som nu sist, i boken. Jag kommer att återkomma till DDD och dessa strategiska mönster i en separat bloggpost om Evans bok, men tills vidare kan jag varmt rekommendera boken för den som vill veta mer.

"Developers get partly wrong tasks"
"'Wrong' abstraction level is used"
Vi behöver inte nödvändigtvis högre och högre abstraktioner, utan rätt abstraktion. ("Att abstrahera högt är stort, men att abstrahera rätt är större" för att parafrasera den devis av Thomas Thorild som pryder ingången till Uppsala universitetshus aula. J) Det här är något som Nilsson varit inne på redan i sin senaste bok och som också berördes av andra under Developer Summit. Här lyfter Nilsson fram domänspecifika språk (Domain Specific Languages, DSL) som ett motmedel. DSL:er är egentligen inget nytt utan handlar om att skapa problemspecifika "programmeringsspråk" som bättre än de generella uttrycker problematiken i en särskild problemdomän, gärna på ett språk som ligger nära domänexperternas. Språket behöver inte nödvändigtvis vara textbaserat utan kan bestå av diagram, t.ex. de som användes för arbetsflöden i Windows Workflow Foundation. För Nilssons del är säkert tankarna kring DSL kopplade till DDD:s betoning av "ubiquitous language" och vad Martin Fowler och Eric Evans benämner "fluent interfaces", men det är också en viktig beståndsdel i Microsofts satsning på software factories.

Erik Doernenburg, "How Simple is Too Simple?" (Developer Summit)

2007-06-10T22:21:00.001+02:00

Developer Summits första dag innehöll två keynotes. Efter Beat Schweglers "Architecting Applications for a Service-Oriented World" var det dags för Thoughtworks-kollegorna Dan North och Erik Doernenburg, men tyvärr kunde inte Dan North infinna sig förrän till fredagens workshop (mer om detta senare). Doernenburg lämnade dock knappast någon besviken när han istället på egen hand besvarade frågan i föredragets titel: "How simple is too simple?"

De flesta är säkert överens om att enkelhet är en eftersträvansvärd kvalitet i mjukvaruutveckling, även vi som emellanåt gör oss skyldiga till det fåfänga misstaget att välja "snygga" eller "smarta" lösningar framför enkla. Även enkelhet kan dock drivas för långt, men frågan är hur enkelt är för enkelt? För att besvara sin fråga ville Doernenburg göra skillnad på enkel ("simple" ) och simplistisk/överförenklad ("simplistic"). En metafor begagnades för att visa skillnaden. Antag att en mur blockerar din väg. En simplistisk lösning är att springa in i muren med full kraft till dess att den rämnas eller nöts ned. En enkel lösning är att ta ett steg tillbaka, konstatera att muren bara är två meter bred och sedan gå runt den.

Motsvarande åtskillnad kan göras mellan komplex ("complex") och komplicerad ("complicated"). Skillnaden i ordalydelse här känns inte lika klockren, men här lutade sig Doernenburg mot Frederick P Brooks särskiljande mellan oavsiktlig ("accidental") respektive väsentlig ("essential") komplexitet för att förklara vad han menar. Exempel på den förra sorten, "komplicerad" med Doernenburgs terminologi, är all kod du för tio år sedan var tvungen skriva för att hämta data från en databashanterare och visa den på en webbsida. Det är här fråga om en komplicerad teknisk implementation och inte om en komplex problemdomän. Ett aktiehandelsystem kan däremot utgöra en mycket komplex problemdomän och då talar vi istället om väsentlig komplexitet ("komplex" enligt Doernenburg).

Efter att ha klargjort dessa distinktioner gick Doernenburg in på lösningar som är för komplicerade ("solutions too complicated") och lösningar som är för enkla ("solutions too simplistic"). Ett intressant exempel Doernenburg lyfte fram på en för komplicerad lösning är när en senior utvecklare med långa bakgrund inom ett företag får för sig att han, istället för att delta i det dagliga arbetet, ska skriva ett ramverk för att underlätta för mindre seniora och/eller nya utvecklare. Ett problem med detta tillvägagångssätt är att det är svårt att veta vad som behöver finnas i ramverket och vad som hör bättre hemma i den konkreta applikationen; det blir i bästa fall kvalificerade gissningar. Man riskerar att på detta sätt öka komplexiteten istället för att underlätta för utvecklarna, inte minst genom att man skapar en abstraktion istället för en konkret lösning. Ett bättre sätt att ta fram ramverk är att "skörda" dem utifrån fungerande praktiker och erfarenheter (se HarvestedFramework). Doernenburg exemplifierade med Spring som växte fram utifrån erfarenheter av vad som saknades i eller inte fungerade med Enterprise Java Beans.

Vi kan säkert alla komma på bra exempel på för komplicerade lösningar, men exempel på för simplistiska lösningar kanske inte poppar upp lika lätt. Ett bra exempel Doernenburg tog upp var transparent distribution av objekt, d.v.s. idén att den som använder ett objekt inte ska behöva bry sig om huruvida objektet instansieras lokalt eller på en annan maskin (via t.ex. .NET Remoting). Detta är en dålig idé eftersom det ofta är av stor betydelse för prestanda om man gör på det ena eller andra sättet och detta bör ha konsekvenser för hur man designar sina objekt (se t.ex. Martin Fowlers First Law of Distributed Object Design: Don't distribute). Ett annat exempel på en simplistisk lösning är att med en O/R-mappers hjälp låtsas att det inte finns någon databas; förr eller senare kommer det att straffa sig, t.ex. i prestandaproblem för vissa typer av frågor som ser enkla ut i objektmodellen men som översätts till mycket komplicerad och krävande SQL. (Detta är inget argument mot O/R-mappers, bara mot ett huvudlöst sätt att använda dem.)

Vad som är enkelt är också relativt. Det som förenklar för en expert kan samtidigt försvåra för en novis. Doernenburg exemplifierade med en kaffemaskin på Thoughtworks som hade sifferkombinationer som gränssnitt. "347" kan t.ex. betyda kaffe med mjölk och socker. Ett tämligen icke-intuitivt gränssnitt för den ovane, men efter en tids tillvänjning kan en person med gott sifferminne, som kanske aldrig annars skulle komma ihåg sina kollegors dryckespreferenser, hämta tio olika sorters kaffe till alla projektmedlemmar genom att memorera några olika sifferkombinationer. Ett mer IT-relaterat exempel är aspektorienterad programmering som för den invigde samlar "cross-cutting concerns" på ett ställe, men som för novisen innebär att man inte förstår vad som händer var.

Ytterligare en viktig aspekt av "enkelt" är den innebörd som är synonym med tidsbesparande. Många utvecklare upplever exempelvis att deras vardag blivit enklare sedan de börjat använda Resharper. "Put effort into being lazy" citerade Doernenburg sin frånvarande kollega Dan North innan han med en summering rundade av sin keynote.

Under denna konferens och vid en del andra tillfällen har jag gjort det till en (o)vana att fråga personer som, precis som Doernenburg, säger sig syssla med objektorienterad och domändriven design och inte har engelska som modersmål vad de anser angående språkval för "ubiquituous language" och därmed kod. Senare under kvällen hade jag förmånen att svinga en bägare med Doernenburg och tog då fram denna käpphäst för en ridtur. Som tysk hade han sett en hel del hemska exempel på tyska utvecklare som efter bästa förmåga suttit med ordböcker för att översätta verksamhetens tyska till engelska. Det säger sig självt att kommunikationen blir lidande med detta sätt och att "hemspråket" oftast är att föredra om man verkligen ska kunna dela modellen med verksamheten.

Beat Schwegler, "Architecting Applications for a Service-Oriented World" (Developer Summit 2007)

2007-06-10T12:23:00.001+02:00

Developer Summit inleddes med en keynote av Beat Schwegler, Microsoft Architect Evangelist för EMEA (Europe Middle East and Africa). Ämnet var "Architecting Applications for a Service-Oriented World" och Schwegler inledde med att ställa sig frågan vad han möjligtvis kunde ha att säga om detta, med IT-världens mått mätt, relativt gamla buzzword. "En modell är ej tillräckligt" var hans svar. Han exemplifierade med en karta över Londons tunnelbanesystem - "one of the best abstractions I know" - och jämförde det med kartor över busslinjer och flodtrafik, andra system som har beröringspunkter med tunnelbanesystemet för den som är intresserad av att transportera sig genom London. På samma sätt som det finns "interconnection points" mellan dessa behövs det knytpunkter mellan verksamheten och IT.

Grundförutsättningen var, som alltid med SOA (eller IT överhuvudtaget för den delen), att verkligheten är stadd i förändring. Eller som Beat Schwegler uttrycker det med ett citat av Charles Darwin i undertiteln till sin blogg:

"It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change."

Ett scenario med låneansökan i ett banksystem fick tjäna som exempel, inte heller det särskilt ovanligt för att exemplifiera serviceorienterade lösningar. Det tradtitionella fallet, att en sökande laddar ned en ansökan i form av ett PDF-dokument och skickar in det till en handläggare, var utgångspunkten. Ett in-house call center som tar emot en ansökan och på motsvarande sätt fyller i och skickar PDF-dokumentet till handläggaren var det andra användningsfallet. Vad vi än vill tro ser det tyvärr ut så här på många ställen än i dag.

Förändringsbehovet innehåller inte heller några överraskningar: ledningen vill att kunder ska kunna sköta sina ärenden online, vill outsourcea sitt call center och vill ha samma system för alla inblandade så att t.ex. en kund ska kunna börja fylla i sin ansökan online och sedan genast kunna fortsätta processen via telefon med kundtjänsten. Lösningen är inte helt oväntat en serviceorienterad arkitektur. Men vad innebär det?

Schwegler menar att det i den traditionella systemmodellen finns en klyfta mellan verksamhetsmodellen och den tekniska modellen. IT ses som en kostnad och kanske till och med som en kostnad man borde skära ned. Istället borde IT ses som en möjlighet att tillföra värde till verksamheten, men det är bara möjligt om IT närmar sig verksamheten. Schwegler hade ett småroligt sätt att uttrycka "exakt" hur stor klyftan mellan verksamheten och IT är; lika stor som den mellan en bok och filmatiseringen av den. När en bok ska filmatiseras finns det ett oändligt sätt att göra det på och det kan göras hundra filmer som alla är olika och som alla är sämre än boken (eftersom du läste den först). Analogin är att verksamheten inte riktigt vet vad de får från IT. Ett sätt att komma till rätta med det är att sluta fokusera på Hur systemen ska byggas och börja fokusera på Vad som behövs: "You have to separate the 'how' from the 'what'."

Ett enkelt men effektivt exempel Schwegler använde var en processbeskrivning som "A skickar ett fax till B som bekräftar med SMS till A". Om några år kanske vi inte ens använder fax och SMS utan någon helt annan teknologi som vi inte ens kan föreställa oss i dag (telepati?) och då är processbeskrivningen, liksom naturligtvis även själva systemet, värdelös. Verksamheten bör istället beskriva sina förväntningar på vad som behöver ske och sedan inte bry sig om hur det åstadkoms. För att överbrygga klyftan mellan verksamhetsmodellen och teknikmodellen inför Schwegler den servicebaserade modellen ("the service based model"). I denna systemmodell fokuserar verksamheten på Vad, vilka generella "capabilities" som behövs och på Service Level Expectations (SLE) istället för på detaljerade Service Level Agreements (SLA). Servicemodellen blir bryggan som tillhandahåller ett kontrakt för att uppfylla behoven och som orkestrerar verksamhetsprocesserna, IT implementerar dem.

Så långt var det inte mycket som kändes nytt, men som en introduktion till SOA var det bra och lättfattligt. Ofta slutar SOA-introduktioner ungefär här och det som var mest intressant med Schweglers presentation var att han gick vidare och försökte ge en bild av hur man kan implementera en servicemodell med existerande teknik utan att bygga allt på nytt. Han kallar sitt tillvägagångssätt för "Lift and Shift" och det innehåller ungefär dessa steg:

Analyze "as-is" architecture
Define the service model
Define the logical "to-be" architecture
Refactor ("Lift"): Refactor the existing system to be aligned with the "to-be" model
Migrate ("Shift"): Move the refactored assets to the target system and technology

"Lift and Shift" tillämpades sedan, på en mycket översiktlig nivå, på lånesystemet från det tidigare exemplet. Tyvärr har jag svårt att återge den här delen av presentationen, jag saknar t.ex. Schweglers fina skisser och diagram, så den som är intresserad får helt enkelt hålla utkik efter PowerPoint-presentationen på Developer Summits webbplats eller ta nästa tillfälle i akt att lyssna på Schwegler.

Avslutningsvis framhöll Schwegler att serviceorientering inte bara handlar om "back-end services" utan också om användargränssnitt. Microsofts två strategier för detta är "Software and Services" (även kallat "Software as a Service", SaaS) och Office Business Applications.

Live från Developer Summit...

2007-05-23T13:09:00.001+02:00

Sitter just nu på årets upplaga av Developer Summit. Tess Ferrandez, .NET Escalation Engineer på Microsoft ska precis börja tala under rubriken "Common problems in ASP.NET production environments". Ferrandez rycker ut när kunder har problem och debuggar bl.a. hängningar, kraschar och annat som inte går att debugga med Visual Studio. Förmiddagens keynotes med Microsofts Beat Schwegler och sedan ThoughtWorks Eric Doernenburg var båda mycket intressanta och jag kommer att posta mer om mina intryck från dessa och andra sessioner senare.

Någon annan som är här?

UPPDATERING: Nu har jag postat fler intryck under etiketten Developer Summit.

UML Distilled: A Brief Guide to the Standard Object Modeling Language

2007-05-22T20:46:00.001+02:00

Under hösten hade vi en föreläsningsserie om projekt- och systemutvecklingsmodeller på Avega. Under en av föreläsningarna fick alla deltagare göra ett test som visade sig ge svar på vilka inlärningsmetoder man var mest mottaglig för: visuella, hörsel, läsa/skriva eller "göra/prova på". Jag kommer inte ihåg exakt vilka värden jag hade, men jag hade i alla fall en tydlig preferens för läsa/skriva samtidigt som jag var minst mottaglig för visuella metoder som grafer och diagram. Kanske är det en förklaring till varför jag länge hade svårt att se nyttan med UML, Unified Modeling Language.

UML föddes 1997 genom ett enande (därav "unified") av de många objektorienterade grafiska modelleringsspråk som var populära under 80- och 90-talen. Grady Booch, Ivar Jacobson och Jim Rumbaugh brukar nämnas som UMLs skapare, men mycket av det faktiska arbetet har skett i kommittéer där långt fler givit viktiga bidrag. Mycket förenklat uttryckt är UML en familj grafiska notationer, uppbyggd av en enda meta-modell, som hjälper oss beskriva och designa mjukvarusystem, särskilt system som byggs med en objektorienterad ansats.

I den sista bisatsen ligger kanske en viktigare förklaring till min tidigare avoga inställning till UML: när jag inledde min karriär som Microsoft-, VB- och webbutvecklare var det inte precis i en objketorienterad metod jag fostrades. I takt med att jag rört mig från VB/ASP till C#/.NET, från webbutveckling till allt mer domänlogikutveckling och från konstruktion till allt mer design och arkitektur har ett objektorienterat angreppssätt blivit allt mer intressant, för att inte säga nödvändigt. Och då har också intresset för UML ökat.

För att fräscha upp mina UML-kunskaper, inte minst inom andra områden än klassdiagram, läste jag för en tid sedan Martin Fowlers "UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd edition" (det är från denna bok den tidigare korta definitionen och historiken är hämtad). Fowlers bok är en kort (ca 150 sidor) och kärnfull genomgång av UML, inklusive en kort historik, ett avsnitt om utvecklingsprocesser och ett appendix om skillnader mellan olika UML-versioner.

Fowler identifierar tre olika sätt att använda UML: skiss ("sketch"), ritning ("blueprint") och programmeringsspråk ("programming language"). UML som skiss handlar om att kommunicera olika aspekter av ett system eller olika designidéer utvecklare emellan. Detta användningssätt är informellt, man tummar ofta på en del UML-regler och kompletterar med egna notationer.

UML som ritning bygger på idén om en designer som skapar en detaljerad design av systemet som sedan kodas av programmerare utan nämnvärd tankemöda. Sådan UML måste vara betydligt mer heltäckande och exakt än skissvarianten, kräver mer avancerade verktyg och kombineras ofta med någons sorts forward och/eller reverse engineering, d.v.s. verktyg som bygger kod av UML och vice versa.

UML som programmeringsspråk tar ritningen ett steg längre: all programmering sker via UML-diagram som kompileras av sofistikerade verktyg till körbar kod. UML-diagrammen blir källkoden. Här ställs naturligtvis höga krav på exakt följande av strikta UML-regler.

UML Distilled fokuseras framför allt på UML som skiss; det är Fowlers åsikt (liksom min egen) att ritningsvarianten är svår att utföra väl och att det inte är ett särskilt effektivt arbetssätt. Även om designer och kodare kan vara samma person känns det inte som ett särskilt agilt sätt att arbeta. UML som programmeringsspråk är en trevlig idé, men knappast något som kommer att få stort genomslag. Dessutom är det inte säkert att grafiska sätt är bättre än textuella för alla programmeringsuppgifter, menar Fowler.

Boken tar upp alla tretton officiella diagram i UML 2 (den senaste versionen), men tyngdpunkten ligger på klass- och sekvensdiagram som upptar nästan lika många sidor (ca 50) som de andra diagramtyperna tillsammans (ca 60). Det är dessa diagram som används mest i objektorienterad design och som man oftast stöter på i böcker, artiklar och dokumentation. Eller för att använda Fowlers ord, som också är ett bra exempel på hans stil:

"If someone were to come up to you in a dark alley and say, 'Psst, wanna see a UML diagram?' that diagram would probably be a class diagram."

Fowler beskriver inte bara notationen på ett förtjänstfullt sätt utan sätter in diagrammen i de sammanhang och på de sätt de ofta används i designarbete. Och han gör det så väl att många menar att UML Distilled också är en bra introduktion till objektorienterad metod. De formella notationerna kompletteras med Fowlers kunskap om informell praxis, både sådan som levt kvar från de gamla modeller som tillhörde "förlorarna" vid föreningen till UML och sådan som växt fram snabbare än kommittéerna hunnit med och därför antingen anses bättre än, eller ännu inte har någon motsvarighet i, UML-specifikationen. Han är inte heller rädd för att lyfta fram onödiga eller krångliga konstruktioner i UML eller påpeka hur oanvändbara vissa delar är:

"Aggregation is strictly meaningless; as a result, I recommend that you ignore it in your own diagrams."

UML Distilled är en bra och underhållande introduktion till såväl UML som objektorienterad metod. Den är kort och lätt att ta till sig. Om man huvudsakligen tänkt använda UML som skiss på det sätt Fowler beskriver är det här troligtvis den enda UML-bok man behöver. Om man har särskilda behov av fördjupning i andra diagram än klass- och skevensdiagram eller om man är intresserad av UML som ritning eller som programmeringspråk tjänar denna bok ändå som en bra utgångspunkt vare sig du är en nybörjare eller om du är en van UML-användare som behöver en repetition.

Fredrik Gunne hos Avega: Windows Workflow Foundation

2007-05-20T23:06:00.000+02:00

I veckan var det dags för ännu en föredragshållare på Avega. Jag missade tyvärr Suns Tohrbiörn Fritzon om Javas framtid och när vår egen Manuel Palacio tog upp JSF och Seam, ett nytt applikationsramverk för webbutveckling med Java. Den här gången var det konsulten Fredrik Gunne, med nästan ett decennium på Microsoft (utvecklingsgruppen för Microsoft Exchange) och Microsoft Consulting Services bakom sig, som bjöd på en presentation av Windows Workflow Foundation (förkortas WF, inte WWF).

Det är aldrig någon höjdare när en talare inleder med att förklara hur illa insatt han är i sitt ämne och att han aldrig jobbat med det, men när det gäller så pass nya teknologier som Workflow Foundation kan det möjligtvis passera. Trots de därmed dämpade förväntningarna levererades en ganska grundlig genomgång av ämnet och vi fick se en hel del intressanta demonstrationer och kodexempel. Däremot blev det av lätta insedda skäl något sämre med konkreta exempel på tillämpningar och fallstudier.

För den som missat det är alltså Workflow Foundation den motor för arbetsflöden ("workflow engine") på Windowsplattformen som levereras som en del av .NET Framework från och med version 3.0 av ramverket. "Workflow engine" för kanske tankarna till BizTalk, affärsprocesser, Enterprise Application Integration och andra dyrare, tyngre och högre abstraktionsnivåer än vi normalt stöter på i .NET-utveckling på ramverksnivån. Ett utdrag från Wikipedia ger ett mer jordnära perspektiv på begreppet workflow:

"Workflow is the operational aspect of a work procedure: how tasks are structured, who performs them, what their relative order is, how they are synchronized, how information flows to support the tasks (wordflow) and how tasks are being tracked."

Ganska många utvecklare har förmodligen skrivit procedurer som hanterar hur uppgifter är strukturerade, vilken deras relativa ordning är och hur de spåras, för att ta några av de delar som har uppenbara kopplingar till många programmeringsuppdrag. Med Workflow Foundation vill Microsoft också göra workflow engine mer "mainstream"; det ska bli en lika naturlig del i utvecklarnas verktygslåda som t.ex. ADO.NET eller .NET Remoting. Genom .NET Framework finns det alltid tillgängligt, är mycket enkelt att använda och kräver därmed inget större godkännandeprocedur från chefen eller kunden än t.ex. ett beslut att använda System.Transactions.

Det var förmodligen också det viktigaste intrycket jag tar med mig från presentationen: att Workflow Foundation kan komma till användning i långt fler situationer än jag tidigare tänkt mig. Från att ha betraktat Workflow Foundation som en relativt marginell del av ramverket, ämnad för särskilda scenarier såsom SOA-orkestreringsperspektiv och liknande, inser jag nu att det är ett verktyg också för många av de små arbetsflöden och processer som förekommer i många applikationer.

Jag får förhoppningsvis anledning att återkomma till Workflow Foundation i framtiden, men tills vidare vill jag uppmana alla som ännu inte tittat närmare på det att göra det, särskilt om man - som jag - inte förstått hur användbart det kan vara.

Ny adress för bloggläsare

2007-05-18T17:32:00.001+02:00

Jag har länge irriterat mig på att alla postningar under ett år i bloggar på Blogger/Blogspot har samma datum: den första januari det året. Nu har jag därför valt att syndikera min blogg via Feedburner istället så att alla ni som följer min blogg som "feed" via en bloggläsare slipper detta och genast kan se vilken dag och tid mina inlägg är publicerade. Det enda ni behöver göra är att klicka på den lilla ikonen längst upp till höger eller på den här länken: http://feeds.feedburner.com/JoakimSundenBlogg. Jag har dessutom ändrat i min bloggmall så att autodiscovery i många bloggläsare, IE7 och Firefox nu ska använda den feeden automatiskt om ni väljer att lägga till bloggen via inbyggda funktioner i dessa applikationer.

Jag uppmanar alla andra som bloggar via Blogger/Blogspot att göra samma sak, särskilt de bloggar jag läser. Om inte altruistiska skäl är tillräckliga finns det också fördelar för den som bloggar i form av statistik över hur många som följer din blogg via feed, något som saknas i de flesta statistiktjänster som Google Analytics och Site Meter.

Niclas Nilsson hos Avega: Dependency Injection och AOP med Spring.NET

2007-05-17T13:47:00.001+02:00

Dryga månaden efter Jimmy Nilssons besök på Avega förärades vi i slutet av mars med ett besök av dennes kollega från factor10 - Niclas Nilsson. Ämnen för kvällen var Dependency Injection och aspektorienterad programmering (AOP) med Spring.NET.

Dependency injection, även känt som Inversion of Control innan Martin Fowler m.fl. myntade det mer specifika begreppet, handlar i grund och botten om att minska beroenden mellan olika objekt genom att injicera de objekt man behöver. Det traditionella sättet att använda ett objekt från ett annat är ju att instantiera det direkt på det här sättet:

public class SalesController
{
// Code...

ItemRepository items = new ItemRepository();

// More code...
}

Med dependency injection kan det istället se ut så här:

public class SalesController
{
   // Code...
   IItemRepository items;

   public SalesController(IItemRepository items)
   {
      this.items = items;
   }

   // More code....
}

I det första, traditionella, fallet har SalesController ett beroende av ItemRepository och måste anpassa sig efter ändringar i denna klass. I varianten med dependency injection förser man istället SalesController med en abstraktion (ett Interface i exemplet) av klassen och gör det därmed möjligt att ändra och byta ut implementationen av ItemRepository utan att SalesController påverkas.

En nackdel med dependency injection är att man nu måste skapa objekten som ska injiceras någon annanstans än i objektet som ska använda dem. Här kan Spring.NET hjälpa oss genom att låta oss konfigurera olika injections i XML och samla dem på ett ställe. Vi kan t.ex. ange vilken klass i vilken assembly vi avser när vi frågar efter "ItemRepository" och sedan ange att ItemRepository ska vara en konstruktorparameter för SalesController i samma eller en annan assembly. När vi sedan ber Spring.NET om ett SalesController-objekt levereras det initierat och klart med en referens till den ItemRepository vi angav. Spring.NET har stöd för en rad olika sätt att skapa objekt, t.ex. via Factory Method, och kan även utifrån typ eller namn själv lista ut vilka objekt som ska injiceras.

Spring.NET är också ett ramverk för aspektorienterad programmering och design. Ett vanligt sätt att beskriva AOP är att lyfta fram hur man kan använda det för att hantera "cross-cutting concerns" som loggning, säkerhet och transaktioner samtidigt som man håller fast vid principen "separation of concerns" och inte blandar in dessa aspekter där de egentligen inte hör hemma, t.ex. i domänobjekt. Säg att man vill logga varje metodanrop i t.ex. ett Service Layer. Principen om separation of concerns säger oss att vi helst inte bör blanda in koden för loggning i varje metod som kan anropas. Vi vill dessutom gärna slippa upprepa denna kod om och om igen i varje metod.

Med AOP definierar vi helt enkelt vår "cross-cutting concern", i detta fall loggningen, i vad som med AOP-terminologi kallas för ett "advice". Sedan anger vi på vilka platser i koden - "pointcuts" - vårt advice ska tillämpas. En pointcut kan anges med Regular Expression och vi kan till exempel ange att alla metoder i en assembly som börjar med "Save" ska omfattas av vårt advice "LoggingAdvice". Så här skulle det sedan kunna se ut i koden:

class LoggingAdvice : IMethodInterceptor
{
   public object Invoke(IMethodInvocation invocation)
   {
      Console.WriteLine("Calling " + invocation.Method.Name +
      " " + DateTime.Now);

      object result = invocation.Proceed();

      Console.WriteLine("Finished calling " + invocation.Method.Name +
      " " + DateTime.Now);

      return result;
   }
}

Nu kommer alla våra Save-metoder att meddela till Console när de anropas och när anropet är klart. Man behöver inte lägga till särskilt mycket kod till det här enkla exemplet för att få fram bra statistik på vilka metoder som tar längst tid att exekvera och därigenom använda AOP för att hitta flaskhalsar i ett system.

Transaktioner är en annan cross-cutting concern där AOP kommer väl till pass och faktum är att transaktionsmodellen i Enterprise Services/COM+ använder sig av AOP. När man sätter attribut som [Transaction(TransactionOption.Required)] på en klass för att få den att delta i transaktioner är det i själva verket en pointcut för ett transaktions-advice man skapar, även om Microsoft inte använder den terminologin.

Jag har tidigare stiftat bekantskap med dependency injection och AOP, Jimmy Nilsson har t.ex. ett kapitel om just detta i sin senaste bok (för övrigt delvis författat av Eric Doernenbourg som kommer till Developer Summit i nästa vecka), men jag har aldrig använt Spring.NET. Det var därför en nyhet för mig att ramverket innehåller mycket mer än stöd för dessa tekniker. Förutom en rad "nyckelfärdiga" advice för loggning, säkerhet med mera finns det ramverk för dependency injection för ASP.NET; klassbibliotek med olika nyttiga funktioner för datahantering med ADO.NET, collections, threading med mera; en objektorienterad modell för databasoperationer som mappar resultatset till objekt och mycket annat intressant.

En rolig sak som händer under kvällen var att vi under middagspausen fick besök av Arjen Poutsma från Interface21, företaget bakom Java-ramverket Spring som Spring.NET är inspirerat av. Poutsma var i Stockholm för att delta i grundandet av en Spring User Group nästa dag och passade då på att träffa Niclas Nilsson. Konsekvensen av detta blev att andra halvan av kvällen avhandlades på engelska och Poutsma flikade ständigt in i (för att inte säga tog över) föredraget. Han sammanfattade kärnfullt syftet med AOP: att hålla sina sockor torra. "DRY SOCS" - Don't Repeat Yourself (samla koden i advice) och Separation Of ConcernS (använd aspekter istället för att besudla klasser med sådant som inte hör dit). Han berättade också att Interface21 numera har en utvecklare av Spring.NET på sin lönelista vilket troligtvis innebär ännu bättre utveckling av och support för detta ramverk i framtiden.

Det kan också vara värt att nämna Microsofts satsningar inom dessa områden även om det inte var något som togs upp under kvällen på Avega. Microsoft Patterns and Practices Team skapade Object Builder som ett ramverk för dependency injection (och ett ramverk för att bygga ramverk/dependency injection containers) för sitt Enterprise Library och nu lever projektet ett eget liv på Codeplex. Jag har inte tittat närmare på det själv, men det verkar inte ha någon större spridning med bara drygt 1200 nedladdningar (källkod och binärkod) sedan i januari. Spring.NET har som jämförelse drygt 2 500 nedladdningar i månaden.

I Enterprise Library 3.0 som släpptes i april ingår något som heter Policy Injection Application Block och som utvecklare kan använda "to specify crosscutting behavior of objects in terms of a set of policies". Det handlar alltså om AOP, men ingenstans i beskrivningen av applikationsblocket nämns vare sig aspekter, AOP, pointcuts eller advice. Man kan fråga sig varför Microsoft väljer att skapa en helt ny terminologi, men det är i alla fall troligt att aspektorienterad programmering med .NET Framework får ett uppsving i och med detta.

Blandat

2007-05-03T23:19:00.001+02:00

Microsofts MIX07 har precis avslutats, men jag hade tyvärr inte möjlighet att närvara på årets upplaga av "a 72 hour conversation" om webbutveckling (läs om mitt besök på förra årets konferens här) eftersom jag istället var på Sardinien och förde en 72-timmars konversation om Avega tillsammans med mina kollegor. För den som inte hängt med finns det, förutom den officiella sajten, ett antal bloggar där man kan uppdatera sig, till exempel svenska som min f.d. kollega Anders Jönssons, Magnus Mårtenssons och Robert Folkessons (Microsoft).

Dessutom finns en chans att ta del av några av presentationerna från MIX07 på plats i Stockholm när Cornerstones Developer Summit går av stapeln i slutet av maj. Det är emellertid inte bara Re-MIX07 som lockar mig till den konferensen, eller vad sägs om namn och ämnen som Dan North ("the BDD guy" från Thoughtworks, företaget där Martin Fowler är Chief Scientist) med workshopen "SOA for human beings" och Beat Schwegler (arkitekt, Microsoft) om "Architecting Applications for a Service-Oriented World".

Det har varit tyst på bloggen ett tag. Förutom att jag befunnit mig på Sardinien har jag bl.a. som traditionen bjuder haft en längre påskledighet i Boden, varit toastmaster på min brors bröllop (grattis Henrik och Lina!), fixat tjejens 30-årsfest, umgåtts med mina två små döttrar i vårsolen och kämpat mot ett en segdragen förkylning. Dessutom befinner vi oss i den hektiska tid på året då alla utländska fotbollsligor fortfarande pågår samtidigt som Champions League når sin kulmen och Allsvenskan börjat. Men misströsta icke; en hel del boktips, några referat av föreläsningar på Avega, ytterligare funderingar kring bästa praxis, fler bloggtips och annat smått och gott ligger och väntar på att bli nedtecknat. Stay tuned!

Min blogglista

2007-03-22T21:54:00.001+01:00

Jag har många gånger fått frågan vilka bloggar jag läser och jag har minst lika många gånger funderat på att skapa en liten "blog roll", en blogglista. Det som hindrat mig är att jag i så fall vill välja ut några verkligt speciella (för mig) och berätta lite om varje blogg och då har det genast blivit ett större projekt. Från och med i dag publicerar jag äntligen en början till en blogglista tillsammans med en kortare beskrivning av varje blogg i denna bloggpost. När jag i framtiden lägger till bloggar till listan kommer jag att försöka posta kort om vad den handlar om.

En snabb överblick i min bloggläsare (jag använder just nu två olika: RssBandit och Outlook 2007) visar att jag just nu prenumererar på ca 120 bloggar. Mer än hälften av dem läser jag så pass regelbundet att jag åtminstone skummar igenom allt som skrivs och de allra flesta skummar jag igenom då och då. Några ligger i frysboxen och väntar på att jag ska inse att jag inte kommer att läsa dem och avsluta prenumerationen. En annan kategori är proffsbloggare som Robert Scoble, TechCrunch och liknande som producerar så många inlägg att det nästan är en heltidssysselsättning att följa dem. Dessa skummar jag oftast bara igenom rubrikvis på jakt efter intressanta nyheter, information om spännande Web 2.0 start-ups m.m. Även med denna metod blir det snabbt svårt att komma i kapp om man inte lästa dem på några dagar. Då markerar jag bara den katalogen som "läst" och börjar om nästa dag.

Av alla dessa bloggar vill jag lyfta fram de jag personligen tycker är mest läsvärda, men huvudsakligen sådana som jag inte ser i så många andras blogglistor. Det innebär att bloggare som Johan Lindfors, André Henriksson, Dag König, Scott Guthrie och andra microsoftare inte finns med på listan eftersom jag räknar med att den som hittat till min blogg redan känner till dem. Och om man inte gör det så återfinns de ändå refererade tillräckligt frekvent i min blogg för att man ska hitta till dem förr eller senare.

Nåväl, här följer en kort presentation av några av de bloggar jag tycker är mest intressanta just nu:

Coding Horror: Jeff Atwood har valt en symbol från Steve McConnells bok "Code Complete" som titel för sin blogg och det är tydligt att McConnell är en viktig inspirationskälla. Atwood är i sin blogg lika mycket av en eklektiker och skriver ingående och inkännande om allt som har med programmering och datorer att göra. Det som särskiljer Coding Horror från många andra tekniknörd- och programmeringsbloggar är Atwoods vurmande för och kunskaper om de mänskliga faktorerna och processerna. Tekniska (men begripliga!) utredningar kring hur slumptal genereras och ingående jämförelser mellan olika processorer blandas med insiktsfulla texter om användargränssnitt och tankar kring vilka egenskaper en bra utvecklare bör besitta.

Inside Architecture: Nick Malik är verksamhetsarkitekt på Microsofts Enterprise Architecture, enligt honom själv "probably the best work on the planet" inte minst eftersom man får jobba med "some of the most experienced and varied folks you can imagine". Malik är naturligtvis en mycket erfaren och kompetent person själv och skriver mycker initierat om två av mina favoritämnen: Serviceorienterad Arkitektur (SOA) och Objektorienterad Analys och Design (OOAD). Jag har länge haft svårt att hitta bra böcker och texter om praktisk erfarenhet av att implementera SOA-lösningar, men Inside Architecture fyller en del av detta tomrum.

Dare Obasanjo: Obasanjo är Program Manager för ett av teamen i Microsofts Windows Live, bland annat ansvarig för utvecklarsajten http://dev.live.com/. Han ägde tidigare XML I/O- och Schema-API:erna i .NET Framework, liksom XSD-implementationen och står med anledning av detta för en del kommentarer angående XML i Framework Design Guidelines. Tillsammans med Torsten Rendelmann har han utvecklat en av de RSS-läsare jag använder: RSSBandit.

Dare Obasanjo skriver mycket intressant om Web 2.0, men han skulle förmodligen inte gilla att jag skriver så eftersom han inte är så förtjust i begreppet. Han skriver dock ofta och gärna om AJAX, "social software", "web startups", webbsatsningar från "GYM" (Google-Yahoo-Microsoft) och andra tydliga "Web 2.0"-ämnen. Jag ser hans blogg som en mer kritisk, mer fokuserad, lite argare och mer webbinriktad Robert Scoble som blivit ännu mer intressant att läsa sedan Scoble lämnade Microsoft.

Om du inte hört talas om honom tidigare men tycker att namnet låter bekant kan det bero på att han är son till Nigerias nuvarande president, Olusegun Obasanjo.

Julie Lerman: En kvinnlig .NET-utvecklare med ett lite annorlunda anslag och perspektiv. Medan många andra bra bloggar ibland kan upplevas som super-experter som talar till oss vanliga dödliga, känns det som om Julia Lerman är en av oss och talar med oss. Det betyder absolut inte att hennes blogg är mindre intressant. Hon brottas med samma problem som många andra, till exempel har hon på sistone publicerat en serie inlägg där hon brottas med att förstå ADO.NET Entity Framework och LINQ. Hon har en prestigelös attityd och är bra på att förmedla saker på ett rakt och enkelt sätt.

Lerman har nyligen bytt bloggmotor. Missa inte hennes gamla bloggposter.

Det får räcka med bloggtips vidare. Fortsättning följer.

SOA - rena fakta

2007-03-11T22:26:00.001+01:00

Äntligen en riktigt bra förklaring till SOA... ;-)

http://soafacts.com/

(Via Patrik Löwendahls blogg.)

Mer om .NET properties

2007-03-10T16:51:00.001+01:00

Sedan jag skrev om att använda .NET properties istället för get- och set-metoder och varför det är en god praxis att använda properties istället för publika medlemsvariabler, har ämnet diskuterats en hel del i bloggosfären. Bland annat Eric Gunnerson har skrivit ett inlägg och en uppföljning där han lutar lite mot publika medlemsvariabler, Jay Bazuzi håller mer än helhjärtat med och Jimmy Nilsson instämmer. Chris Hedgate köper inte argumenten, en ståndpunkt han delar med flera kommentatorer på Gunnersons blogg. Alla påpekar förstås att det beror på kontext och hela diskussionen kan förefalla vara hårklyveri. Trots detta, eller kanske just därför, kan jag inte hejda mig själv från att fortsätta delge er mina synpunkter i frågan.

Flera förespråkare av publika medlemsvariabler hänvisar till Rico Morianis prestandaargument som jag redan tagit upp i min andra uppdatering i mitt första inlägg (längst ned). Den prestandaförlust och den marginellt större assemblystorlek som kan bli följden av att använda properties måste i de allra flesta fall anses vara försumbar. Denna princip kan i alla fall inte gälla som tumregel utan måste i så fall snarare ses som förhastad optimering och som Donald Knuth sa:

"Premature optimization is the root of all evil (or at least most of it) in programming."

Gunnersons andra invändning, att properties som används "just in case" innebär "extra clutter in the class", äger väl viss tyngd, men det är enligt min mening dels något av en vanesak, dels något som kan hanteras av regions och andra sätt att strukturera sin kod. Dessutom kommer man från och med nästa version av C# och VB.NET kunna deklarera properties mer koncist.

Bazuzi vidareutvecklar Gunnersons argument om det onödiga i att använda properties bara för säkerhets skull; om man använder properties bara för att undvika att bryta binär kompatibilitet, varför då inte som tumregel också alltid använda en factory method som returnerar ett interface istället för att använda konstruktorer? Då skulle man i framtiden kunna byta ut vilket objekt som returneras utan att bryta binär kompatibilitet. Bazuzi förväntar sig att man ska välja allt eller intet:

"If you still believe that you need to use properties in the trivial cases, I hope you will examine these constructs and consider them seriously in your own code. I suspect you should be choosing all or nothing."

Den här typen av argument brukar kallas "reductio ad absurdum" och kan vara intressanta i formallogik, men använt på det här viset är det inte mycket mer än ett retoriskt knep; bara för att man argumenterar för att det är säkrast att använda properties som tumregel innebär det inte per automatik att man måste göra allt annat som står i ens makt för att bibehålla binär kompatibilitet. Att använda en factory method för att returnera ett interface är betydligt mer "clutter in the class" än properties, det är ett betydligt mindre vanligt koncept och förstås inte naturligt av alla utvecklare på samma sätt som properties. En bästa praxis betyder inte att man aldrig någonsin får bryta mot den, utan den är ett stöd inte minst för de som inte är fullt medvetna om konsekvenserna av att avvika från den. Därför anser jag fortfarande att properties är bästa praxis.

Jimmy Nilsson hos Avega (eller Svenska som allestädes närvarande språk)

2007-03-06T23:51:00.001+01:00

Härom veckan gästades Avega av Jimmy Nilsson som talade lite om Test-Driven Development (TDD), Domain-Driven Design (DDD) och O/R-mappers. Det var en ganska lättillgänglig introduktion, inte minst om man läst hans senaste bok, men frågor och diskussioner var (som alltid på Avega) riktigt intressanta. Eftersom många aveganer i publiken var Java-människor fanns det ganska mycket kunskap om DDD och O/R-mappers i rummet. En intressant fråga som dryftades och som jag själv funderat mycket på var om man i regel bör använda svenska för ett projekts "ubiquitous language".

En förklaring av "ubiquitous language" kanske kan vara på sin plats för den som inte är bekant med DDD. Ett "allestädes närvarande språk", för att prata svenska, är en central ingrediens i DDD. Eric Evans understryker i sin bok "Domain-Driven Desgin: Tackling Complexity in the Heart of Software" vikten av en för domänexperterna och utvecklingsteamet gemensam modell och ett gemensamt språk:

"A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design. [...] Translation blunts communication and makes knowledge crunching anemic."

Lösningen är att tillsammans arbeta fram ett "ubiquitous language" som är mer fylligt och robust än den minsta gemensamma nämnaren för de olika språken och att verkligen konsekvent använda detta språk i allt som har med projektet att göra. Språket bör inbegripa allt från klassnamn och viktiga operationer, verksamhetens termer för att diskutera explicita affärsregler och till och med designmönster (och andra typer av mönster, t.ex. analysis patterns), som teamet tillämpar på domänmodellen. Det bör användas när utvecklare och domänexperter kommunicerar med varandra, men också i utvecklarnas egna grupp för att beskriva system, uppgifter och funktionalitet, liksom i domänexperternas egna kommunikation och arbete med krav, featurelistor m.m. Refactoring av koden kan leda till refactoring av språket och när språket ändras måste klassdiagrammen anpassas, klasser och metoder döpas om. På samma sätt som "continuous integration" är en bästa praxis bör man enligt Evans även tillämpa något han kallar "conceptual integration":

"Constant exercise of the UBIQUITOUS LANGUAGE in discussions of the model and application."

Åter till Jimmy Nilsson och diskussionen om svenska. Även om man inte känner till DDD eller har dragit samma långtgående och djuptänkta slutsatser som Evans och andra DDD-förespråkare, är det lätt att känna igen problematiken och behovet av ett gemensamt språk; jag har själv funderat mycket på detta och gillar därför verkligen hur en gemensam modell och "ett allestädes närvarande språk" ges en så pass central roll i domändriven design. Och utifrån denna roll är det åtminstone för mig uppenbart att modellen och språket, liksom i förlängningen därmed även koden, bör vara på svenska för svenska projekt i svenska verksamheter.

Alla åhörare var emellertid inte överens om detta och jag vet från andra diskussioner att många till och med föredrar engelska för sina kommentarer och för dokumentation, så länge det inte finns uttryckliga önskemål om något annat. Ofta används argumentet att koden kan komma att sättas i händerna på engelskspråkiga utvecklare, inte minst med den växande offshoremarknaden. Det kan dock knappast vara så pass vanligt förekommande att man alltid skulle vara tvungen ta höjd för det till priset av alla problem språkförbistringen innebär (YAGNI!).

Ett problem med svenska har varit att man inte kunnat använda svenska tecken (åäö) i koden och att det därför minskat tydligheten, men det är inte längre något problem i moderna utvecklingsmiljöer. Lite värre är kanske att det i mjukvaruvärlden finns en hel del begrepp som saknar bra eller i alla fall naturliga svenska översättningar, t.ex. namn på designmönster (Factory, Composite, State etc) eller något så grundläggande som Set- och Get-prefix. Programmeringsspråk, befintliga ramverk och klassbibliotek har sällan (aldrig?) översättningar vilket leder till att man antingen måste blanda språken (KnappEvent) eller använda olika språk för ramverk och applikation(OnClickEvent, KnappHändelse).

Dessa invändningar är tämligen bagatellartade enligt min mening och förtjänsterna med att använda svenska, snarare än att tvinga domänexperter och utvecklare att hitta på mer eller mindre krystade översättningar, överstiger vida nackdelarna. Nu undrar väl alla vad Jimmy Nilsson tyckte, men det här är ju trots allt min blogg... Okej då, han skämtade först om att problemet enklast löses genom att avskaffa svenska språket och att han skriver på engelska för att slippa ta itu med problemet, men menade sedan att så länge vi måste dras med svenska bör det förstås vara regel snarare än undantag att använda svenska för sitt ubiquit... förlåt, allestädes närvarande språk.

SOA enligt Microsoft

2007-02-18T22:05:00.001+01:00

John Evdemon, arkitekt med fokus på BPM och SOA i Microsofts Architecture Strategy Team, har sammanställt en ganska stor samling länkar till resurser från Microsoft som har att göra med serviceorienterad arkitektur. En av resurserna är en nedladdningsbar bok (gratis), "Readings in Service Orientation", som också delades ut gratis på TechEd. Den beskrivs som "an interesting set of classical papers on architecting services by a variety of well-known authors in the architectural space" (bl.a. Pat Helland och Maarten Mullender) och är indelad i fem delar:

Design and Modeling: Aligning Business and IT
Data: Information Management for Services
Process: Services Composition and Consumption
Identity: Who are you? Can you use my service?
Protocols and Practice: Services-based Infrastructure

Jag har tyvärr inte hunnit läsa den ännu, men den verkar onekligen intressant.

Head First Design Patterns

2007-02-06T22:33:00.001+01:00

De flesta utvecklare har väl någon gång kommit i kontakt med designmönster ("design patterns"), men för många har det stannat vid ett flyktigt möte, inte minst bland dem som räknar sig som .NET-utvecklare. Det är i alla fall min erfarenhet efter samtal med kollegor, kunder och andra .NET-utvecklare jag mött genom åren. Detta förhållande har sannolikt att göra med att .NET-plattformen i allmänhet, och verktygsstödet i form av Visual Studio i synnerhet, uppmuntrar utveckling enligt vad Martin Fowler kallar Table Module pattern (som är ett arkitekturmönster). Något förenklat handlar Table Module om att en instans (.NET DataSet) representerar, och hanterar affärslogiken för, alla rader i en databastabell eller -vy. Istället för en domänmodell (Domain Model pattern) och ett mer objektorienterat förhållningssätt underlättar .NET och Visual Studio utveckling med DataSet. I exempelkod och tutorials från Microsoft, liksom i de flesta projekt och kundprojekt jag arbetat med, blir det också ofta proceduriell programmering med metoder som hanterar DataSet som såväl in- som utparametrar (jmf Fowlers Transaction Script pattern). Jag antar att även Microsofts historik, inte minst Visual Basics ställning, gjort att det ser ut på detta sätt. Mot denna bakgrund är det förståeligt om intresset för objektorienterade designmönster inte är särskilt stort bland .NET-utvecklare.

Nu kanske någon tycker att jag målar fan på väggen bara för att få nöjet att piska honom och visst är det så att det finns gott om .NET-utvecklare som är såväl OO-purister som designmönsterevangelister. Enligt min erfarenhet är dessa dock undantagen som bekräftar regeln. Samtidigt är något på väg att hända. Domänmodellen vinner allt större inflytande (som jag varit inne på tidigare här) och Microsofts stora satsning med LINQ, O/R-mapping och den nya Entity Data Model i nästa version av ADO.NET ("Orcas") lär ge ännu mer näring åt denna utveckling. Om inte denna utveckling gör dig mer intresserad av att titta närmare på designmönster kanske ett boktips kan övertala dig? ;-)

Boken "Head First Design Patterns" (Eric & Elisabeth Freeman, Kathy Sierra, Bert Bates; O'Reilly Media 2004; 638 sidor) är utgiven i O'Reillys annorlunda, men populära "Head First"-serie. Head First har tagit fasta på de senaste rönen inom neurobiologi, kognitionsforskning och inlärningsteori och utifrån dessa skapat böcker som är fokuserade på att läsaren verkligen ska lära sig innehållet i dem. Detta har resulterat i visuellt rika framställningar som är fyllda med ingående, pedagogiska och tydliga exempel samt gott om inlärningsövningar av olika slag. Men framför allt är de väldigt underhållande (och lätta) att läsa och det är väl till syvende og sist det som gör dem så lärorika. Själv föll jag omedelbart pladask för det härliga bildspråket, den snygga presentationen, den nördiga humorn (även dåliga skämt underlättar inlärningen enligt folket på Head First) och de käcka 50-talsbilderna med välklädda och välfriserade män och kvinnor som i pratbubblor kläcker ur sig diverse klokskaper:

"I used to think real men subclassed everything. That was until I learned the power of extension at runtime, rather than at compile time. Now look at me!"

Utseendet är förstås inte allt. Head First Design Patterns tar upp ett dussintal (de mest användbara enligt dem själva) av de klassiska mönster som lades fram av "The Gang of Four" (Gamma, Helm, Johnson, Vlissides) i "Design Patterns: Elements of Reusable Object-Oriented Software": Observer, Decorator, Factory, Singleton, Command, Adapter, Facade, Template Method, Iterator, Composite, State och Proxy. Författarna ägnar ungefär 30-60 luftiga och lättlästa sidor åt varje mönster. En mycket liten del, ofta mot slutet av varje kapitel, ägnas åt den formella definitionen av mönstret som diskuteras. Man har istället valt att använda konkreta exempel på problem som kan lösas med hjälp av mönstret i fråga för att sedan på ett pedagogiskt vis arbeta - och inte minst omarbeta - in designmönstret i lösningen. Ett stort fokus ges de objektorienterade designprinciper som ligger bakom designmönstren ("Encapsulate what varies", "Open for extension, closed for modification" o.s.v.).

Även om det är ganska länge sedan jag första gången intresserade mig för designmönster har jag aldrig känt att jag haft särskilt stor användning för dem. Jag har naturligtvis stött på de vanliga och även vid något tillfälle skapat en Factory eller använt Singleton. Men när jag bläddrat i Gang of Fours bok eller ögnat igenom mönsterkataloger har det mesta känts väl abstrakt och lite grann som om det mer berör en annan värld än den där jag bedriver mitt dagliga arbete. Denna känsla har säkert att göra med den bakgrund jag tecknade i början av denna text och det faktum att jag nu tagit designmönster till hjärtat har säkert att göra med att jag i allt högre utsträckning kommit att ägna mig åt verklig objektorienterad analys, design och utveckling. Det sistnämnda skulle i så fall också förklara varför jag var så förtjust i boken Head First Design Patterns. Samtidigt kan jag dock inte göra mig fri från tanken att Head First faktiskt lyckats förklara designmönster på ett sådant sätt att de känns omedelbart användbara.

Om jag ska nämna någon nackdel med boken är det att den efter ett tag kan upplevas som lite tjatig och närmast överpedagogisk, exempel och förklaringar upprepas o.s.v. Å andra sidan vore det orättvist att förvänta sig ett kompakt och faktaspäckat referensverk - i så fall är nog Gamma et al att föredra.

UPPDATERING: Jag glömde nämna att Head First Design Patterns utgår från Java i kodexempel och annat, men denna lapsus beror troligtvis på att det knappast är något man tänker på om man är bevandrad i C#. Några exempel i avsnitten "patterns in the wild" tar upp Javas klassbibliotek, men även i dessa fall är likheterna med .NET Framework så stora att det inte är några problem att förstå för den som inte är bekant med Java.

Hjälp till att hitta Jim Gray!

2007-02-05T09:14:00.000+01:00

Jim (James) Gray, en av Microsofts främsta databasforskare, är försvunnen sedan han för en vecka sedan begav sig ut på en segeltur för att sprida sin avlidna mors aska. Efter att kustbevakningen har givit upp letandet har företag som Microsoft, Google och Amazon slutit upp och gjort det möjligt för människor över hela världen att via Amazons mekaniska turk söka efter Jim Gray genom att studera satelittbilder från området där han seglade. Hjälp till du med!

Windows Live SDK

2007-02-04T22:26:00.001+01:00

Windows Live SDK lanserades utan pompa och ståt i dagarna. Trots den ouppmärksammade lanseringen innehåller Windows Live SDK en hel del intressanta API:er till Microsofts Live-tjänster som också ytterligare förstärker bilden av att Microsoft öppnar upp sig allt mer som jag varit inne på tidigare (andra färska exempel är att man förra veckan släppte källkoden till ASP.NET AJAX). Windows Live SDK innehåller följande digra samling API:er och SDK:er:

Kolla även in http://dev.live.com/ och Windows Live Developer Center om du vill följa vad som händer på denna front i framtiden.

Mitt Windows Experience Index

2007-02-01T22:46:00.001+01:00

Nu när Windows Vista har lanserats på riktigt har Nvidia äntligen släppt drivrutiner som fungerar med mitt GeForce Go 7600 512 MB grafikkort. Trots att jag kört Vista sedan i somras är det först nu jag kan njuta fullt ut av det nya vackra operativsystemet. Och jag måste säga att jag verkligen gillar utseendet - allt från Aero till det nya teckensnittet.

Med drivrutinerna på plats kan jag också slutligen få reda på vad mitt Windows Experience Index är. Detta Experience Index är ett sorts mått på din dators prestanda och tanken är att det ska gå att använda för att avgöra vilka spel och andra programvaror din dator klarar av. Med tanke på att en "base score of 5 were the highest performing computers available when Windows Vista was released", enligt operativsystemets hjälptext om ämnet, verkar min nya bärbara Zepto 6615WD hålla vad vissa tester har utlovat:

Hur ser ditt Experience Index ut? Vinner jag? ;-)

.NET bästa praxis: properties

2007-01-26T07:37:00.000+01:00

För ganska länge sedan hjälpte jag ett företag att vidareutveckla ett system på .NET-plattformen (ASP.NET, IIS, SQL Server) med ett av företaget egenutvecklat ramverk som skulle användas för alla deras webbapplikationer. Personen som hade varit "arkitekt" för ramverket kom från en Java- och Oraclebakgrund och hade ingen större erfarenhet av .NET. C#-syntax är inte så svårt att lära sig, särskilt inte om man kan Java, och har man flera års erfarenhet av att utveckla Java-baserade webblösningar borde det väl inte vara så svårt att få till något för .NET?

Så tycks man ha resonerat, men tyvärr är det ju inte riktigt så enkelt i verkligheten. Förutom en syntax måste man ha hyfsad koll på .NET Frameworks klassbibliotek och god kännedom om hur modellen för att utveckla webbapplikationer ser ut för ASP.NET; den skiljer sig en del från JSP och andra modeller. Men även om man läser in sig på dessa delar saknas en mycket viktig del, nämligen bästa praxis ("best practices"). Hur mycket man än vet om vad man kan göra med .NET, är det en annan fråga vad man bör göra.

För att fortsätta med exemplet med "Java-arkitekten"; i Java använder man get- och set-metoder för att kapsla in privata medlemmar. Exempel:

private int mAntal;

public int getAntal()
{
return mAntal;
}

public void setAntal(int varde)
{
mAntal = varde;
}

I .NET använder man isället egenskaper, "properties":

private int mAntal;

public int Antal
{
get { return mAntal; }
set { mAntal = value; }
}

Nu kan man lätt få för sig att det inte har någon betydelse vad man använder, utan att det mer är en fråga om tycke och smak, som till exempel när det gäller vilken rad man ska ha första måsvingen på. En del tror till och med (felaktigt) att get- och set-metoder är att föredra, även i .NET. Faktum är dock att det finns flera goda skäl till att properties är bästa praxis i .NET.

I .NET används i regel properties för att representera data, medan metoder används för att utföra handlingar på ett objekt. Genom att utrusta sin klass med en property signalerar man därför att det handlar om enkel dataåtkomst medan metodnamn med "Get" framför propertyns namn (t.ex. GetAntal i exemplet ovan) reserveras för att ge en fingervisning om att det då istället handlar om en relativt kostsam operation. Om man regelmässigt använder getters och setters förlorar man denna informativa distinktion.

Genom att namnet för både läsning och skrivning är detsamma för en property är det enkelt att använda reflection för properties. Det gör att många funktioner och verktyg har stöd för propertys, men inte för get- och set-metoder, till exempel databinding och designläget i Visual Studio som automatiskt visar properties på egentillverkade kontroller ("custom controls").

Sedan kan man förstås fråga sig varför man bör använda något annat än publika medlemsvariabler överhuvudtaget, oavsett om väljer properties eller get- och set-metoder. Till de främsta skälen hör, förutom vad som ovan nämnts, att man med properties (eller motsvarande) enkelt kan lägga till validering eller transformering utan att behöva ändra klassens interface. Eftersom man oftast inte kan vara helt säker på att detta inte kommer att behövas bör man alltid använda properties redan från början; att ändra en publik medlemsvariabel till en property i efterhand bryter nämligen binär kompatibilitet och innebär att du måste kompilera om beroende kod.

Det här är det första inlägget i vad som är tänkt att bli en serie om bästa praxis för programmering och design, särskilt på .NET-plattformen, som ni kommer att hitta under taggen "Bästa praxis" på denna blogg. Kom gärna med kommentarer, invändningar eller kompletteringar! (Använd kommentarsfunktionen.)

UPPDATERING: Jag använde tidigare getter/setter som benämning på get- och set-metoder, men det slog mig att även en property kan kallas getter/setter så jag använder nu konsekvent "get- och set-metoder".

UPPDATERING 2: Delar av ovanstående är baserat på riktlinjer från Framework Design Guidelines. En av kommentatorerna i boken, Rico Mariani, har många tänkvärda kommentarer utifrån ett prestandaperspektiv, så även gällande properties vs. public fields. Hans bloggpost om just detta är en bra påminnelse om att det ibland kan vara nödvändigt att frångå vad som i vanliga fall är bästa praxis. Även Eric Gunnersons kommentar i ämnet är läsvärd.

ASP.NET AJAX är här!

2007-01-23T22:12:00.001+01:00

Nu har Microsoft släppt ASP.NET AJAX 1.0 så nu är det bara att tuta och köra. Läs mer på Scott Guthries blogg. I samband med detta släpptes även fyra nya kontroller i projektet ASP.NET AJAX Control Toolkit (länkarna nedan tar dig till live-demos av kontrollerna):

AutoComplete. En Extender-kontroll som förser din TextBox med automatisk komplettering av inmatade värden utifrån en web service som du kopplar den till.
Calendar. Extender som ger en "DatePicker" till din TextBox.
MaskedEdit. Ännu en Extender som vid fokus utrustar din TextBox med anvisningar för hur den ska fyllas i (t.ex. ett särskilt datumformat i formen "____-__-__") samt validering av tillåtna värden (t.ex. siffror inom ett visst intervall).
Tabs. Växla mellan flikar och spara utan att ladda om sidan (PostBack).

Hur ser ditt IP-nummer ut?

2007-01-22T20:02:00.001+01:00

Don Park har hittat på ett sätt att visualisera människors IP-nummer som ett s.k. "9 Block Pattern". Han kallar sitt påhitt för "identicon" och det är inte bara för skojs skull:

I think identicons have many use cases. One use is embedding them in wiki pages to identify authors. Another is using them in CRM to identify customers. I can go on and on. It's not just about IP addresses but information that tends to move in 'herds'.

Den lilla bilden du ser är min "identicon". Du kan se din egen i kommentarfunktionen på Don Parks blogg eller ladda ned .NET-kod för att själv skapa identicons från Coding Horror (där jag först läste om detta).

Dags för en universalfjärrkontroll?

2007-01-21T21:12:00.001+01:00

När detta är vad du måste rada upp för att se på TV inser du att det är dags att införskaffa något sorts universalfjärrkontroll...

Om jag nu bara kunde använda mobilen för att svara på vanliga telefonsamtal och lagra alla betal- och kreditkort, bensinkort, medlemskort, bonuskort o.s.v. på ett enda kort så skulle min lycka vara gjord.

Domain Driven Design Quickly

2007-01-21T20:51:00.001+01:00

För den som är intresserad av Domain-Driven Design (t.ex. efter att ha läst mitt inlägg om Jimmy Nilssons bok "Applying Domain-Driven Desgin and Patterns") kan gratisboken "Domain Driven Design Quickly" (nedladdningsbar PDF) från InfoQ vara av intresse. Ja, även själva InfoQ-sajten för den delen; de vänder sig enligt egen utsago huvudsakligen till "the technical architect, technical team lead (senior developer), and project manager" och har artiklar, videomaterial och miniböcker indelade i de fem kategorierna Java, .NET, SOA, Ruby och Agile.

Applying Domain-Driven Design and Patterns

2007-01-17T23:29:00.001+01:00

Domain-Driven Design (DDD) är en design- och utvecklingsmetodik som det talas mer och mer om. Eric Evans, den mest namnkunnige DDD-förespråkaren tillika författaren till "Domain-Driven Design: Tackling Complexity in the Heart of Software", sammanfattar DDD på följande vis:

Fundamentally, DDD is the principle that we should be focusing on the deep issues of the domain our users are engaged in, that the best part of our minds should be devoted to understanding that domain, and collaborating with experts in that domain to wrestle it into a conceptual form that we can use to build powerful, flexible software. ("Eric Evans on why DDD Matters Today", http://www.infoq.com/)

I praktiken handlar det mycket om gammal hederlig objektorienterad design och analys, fokus på en renodlad domän-/verksamhetsmodell och verksamhetslogik (innebär ofta att någon sorts O/R-mapper används för att slippa lägga onödig tid och energi på dataaccess/persitering) och betoning av ett så kallat "ubiquitous language" (allestädes närvarande språk), d.v.s. ett gemensamt språk för, och en god kontinuerlig dialog mellan, verksamhet och utvecklingsprojekt. För läsare av den här bloggen kanske det bör tilläggas att DDD huvudsakligen har sina rötter i Java-världen, men metodiken är på frammarsch i .NET-världen också.

Jimmy Nilsson är en svensk utvecklare och Microsoft Most Valuable Professional (MVP) inom Solutions Architecture som tillsammans med Eric Evans och kanadensiskan Ying Hu driver domaindrivendesign.org. För ett halvår sedan utkom han med boken "Applying Domain-Driven Design and Patterns: With Examples in C# and .NET" (ADDDP; utgiven av Addison-Wesley, 2006).

Jimmy Nilssons bok handlar förstås till stor del om DDD, men en hel del andra intressanta ämnen konkurrerar om utrymmet bland bokens ca 500 sidor. Bland dessa ämnen framträder Test Driven Development (TDD) med refactoring, design patterns och O/R-mapping (med NHibernate) som de mest centrala och för framställningen genomgående. Andra ämnen som tas upp till behandling är bl.a. Service Oriented Architecture (SOA), Aspect Oriented Programming (AOP) med Spring.NET och hur man utvecklar testbara gränssnitt.

Bokens titel gör klart att den handlar om tillämpning av DDD och detta är ett löfte som infrias. Efter att i bokens första del av fem ha tecknat en bakgrund med beskrivningar av DDD, Design patterns och TDD, som redan den karakteriseras av många exempel, kastar sig Nilsson i den andra delen över ett exempelprojekt i form av en kort och koncis, men inte alls okomplicerad, kravlista. I tämligen detaljerade kodexempel visar han steg för steg hur man kan använda sig av TDD för att ta fram och förfina sin domänmodell och hur man kan hålla den fri från beroenden till exempelvis databas/persistering.

Just renodlingen av modellen och önskan att hålla isär den från annan kod för att verkligen kunna fokusera på domänproblemen är grundläggande i DDD och därmed också ett skäl till att O/R-mappers är så populära inom denna metodik, så även i ADDDP varför en icke föraktlig del (den tredje) av boken som sagt handlar om detta. Nilsson, med en stadig bakgrund inom databasutveckling, vrider och vänder på för- och nackdelarna med O/R-mappers, vilka kriterierna för en bra O/R-mapper är och slutligen hur exemplet NHibernate kan användas tillsammans med den domänmodell vi tillsammans - ja, det känns nästan så! - tagit fram under bokens gång.

Det märks att författaren har stor erfarenhet av såväl utvecklings- som verksamhetsproblematik och det är uppfriskande att se Nilsson söka upp de problemställningar som så ofta förekommer i verkliga projekt, men är ack så sällsynta i de många tillrättalagda handledningar man kan hitta i dokumentation och exempel på Internet, såväl från Microsoft som från andra, eller i andra böcker för den delen.

Bokens näst sista del handlar om "other design techniques to keep an eye on and start using" (med några av de tidigare nämnda ämnena så som SOA och AOP) och den sista är ett appendix med exempel på hur andra tillfrågade utvecklare skulle ha löst samma kravlista som Nilsson löst på sitt sätt i resten av boken. Båda dessa delar är nästan uteslutande författade av gästskribenter (bl.a. bloggarna Udi Dahan och Mats Helander). Några av dessa skribenter - och ytterligare ett par där till - har dessutom skrivit dels kortare texter, dels små noter inskjutna lite här och där i hela Nilssons framställning.

Jimmy Nilssons stil är en "prövande" stil, som på sätt och vis liknar den programmeringsstil han förordar, med många frågor, försök till lösningar, nya frågor och "refactoring" av de tidigare svaren. Lägg till detta en mycket ödmjuk hållning i övrigt och stilen blir stundtals för prövande och osäker med ständiga reservationer och försäkringar om att det ena eller andra inte är "the silver bullet". Samtidigt är det också denna stil som involverar läsaren och ger en inblick i hur en duktig utvecklare går till väga för att lösa ett problem, ja till och med en känsla för hur han tänker. Ett större problem blir det dock i kombination med gästtexterna, de insprängda noterna och bokens bredd av ämnen; det blir helt enkelt lite väl osammanhållet och spretigt ibland, vissa avsnitt känns malplacerade, t.e.x Udi Dahans annars intressanta text om SOA och den del av boken som handlar om designtekniker att hålla ett öga på kanske borde ha hamnat i bokens appendix istället för kapitlet med alternativa lösningsförslag.

På det stora hela utgör dessa problem dock inga avgörande invändningar mot Jimmy Nilssons bok som utan tvekan är mycket läsvärd. För den som likt jag är intresserad av, men ännu inte sysslat så mycket med, TDD och O/R-mappers är bokens praktiska orientering en guldgruva och en inspirationskälla till att äntligen komma igång.

Pageflakes

2007-01-17T06:31:00.000+01:00

Pageflakes är en AJAX Desktop (se t.ex. min tidigare post om Windows Live) som är byggd med Microsoft ASP.NET AJAX. Jag har använt den som startsida en tid eftersom det är ett enkelt och bekvämt sätt att samla sådant som jag vill ha snabb och enkel tillgång till samtidigt som jag håller mig uppdaterad/påminns varje gång jag startar en ny webbläsarsession. Jag använder den framför allt för att följa ett par av de mest uppdaterade och intressanta bloggarna jag följer samt för mina favoriter/bokmärken på del.icio.us.

En häftig feature med Pageflakes är att man kan mycket enkelt kan exportera de gadgets (eller "flakes" som de kallas här) som finns till sin hemsida eller blogg. Jag har till exempel lagt in mina del.icio.us-favoriter i högerkolumnen här på min blogg. Det är så enkelt att till och med din mormor skulle klara av det. Omar AL Zabir, Microsoft MVP (Most Valuable Professional) och grundare av Pageflakes, skriver om detta i sin blogg. Där finns också en hel del matnyttigt för den som använder ASP.NET AJAX. Kolla även in hans hemsida som är ett ganska coolt showcase för vad man kan åstadkomma med JavaScript och DHTML.

MIX07 vs MIX06

2007-01-14T18:27:00.001+01:00

Jag reflekterade tidigare omkring MIX07 och konstaterade att det måste vara svårt att skapa samma attraktionskraft och hype detta år som föregående. Nu har det börjat komma en del information kring keynotes, sessioner m.m. som förstärker mitt första intryck. Ämnena är ungefär samma som förra året: Microsoft AJAX (Atlas), WPF, IE7, RSS, Windows Live o.s.v. På många sätt kanske årets innehåll är mer intressant eftersom teknikerna inte längre är i betastadiet och flera av sessionerna verkar gå mer på djupet, men om man besökte förra årets konferens och har hängt med hyfsat i teknikernas utveckling sedan dess känns inte årets upplaga lika spännande.

Jag tror däremot att MIX07 har en hel del att erbjuda beslutsfattare och andra som är intresserade av affärsmodeller och hur man kan dra nytta av de olika teknikerna. Om jag skulle få förmånen att besöka årets konferens är det sessioner kring dessa ämnen som skulle få min uppmärksamhet. Vi får väl se vad chefen tycker...

Snap Preview Anywhere

2007-01-14T15:29:00.003+01:00

Snap är en ny söktjänst som erbjuder ett annorlunda sätt att söka på webben. Den mest intressanta delen handlar om det visuella, hur sökresultatet presenteras. Utöver den vanliga sökresultatlistningen ägnas en stor del av skärmutrymmet åt att förhandsvisa hur sidorna som döljer sig bakom länkarna i sökresultatet ser ut.

Det häftigaste med Snap är dock inte själva sökmotorn utan den finess som heter Snap Preview Anywhere och som du från och med i dag kan åtnjuta på denna blogg. Genom att klistra in en liten JavaScript-kodsnutt i din bloggmall/hemsida får alla länkar på den en liten förhandsvisning av hur sidan det länkas till ser ut. Det här är en finess jag har efterfrågat länge, särskilt för bloggar eftersom bloggare ofta lägger in länkar lite överallt i texten utan att tydliggöra var de leder. Med Snap Preview Anywhere kan jag stilla min nyfikenhet utan att behöva lämna texten jag läser eller öppna en massa nya webbläsarfönster. Testa själv med länkarna i denna blogg och om du gillar vad du ser kan du mycket enkelt skaffa Snap Preview Anyhwere själv här.

Five Things People Don't Know About Me

2007-01-13T14:06:00.001+01:00

I am IT! I have been tagged by Johan Lindfors and have to tell you five things you probably don't know about me (the "5 Things People Don't Know About Me" meme is of English speaking origin, hence the English).

I arrived to Uppsala University to study political science and philosophy. The orientation of my education changed slightly over the years and I eventually ended up with a bachelor’s degree in History of Science and Ideas (Idé- och lärdomshistoria). I wrote my paper about the Swedish editor and writer Leonard Ljunglund (1867-1946) and hoped for a while to be able to write a Ph.D. thesis about the Lebensphilosophie (Bergson, Dilthey, Nietzsche, Schopenhauer, among others) around 1900.
Until I reached the age of 20 something I practically only ate meat, primarily pure beef, and potatoes. I never ate fish or pizza (did not even taste them once as I can remember), avoided vegetables and rice, sauces, gratins etc. I mostly ate plain burgers (no mayo, cheese or vegetables!) or steak and fries (no sauce or vegetables). I did not even eat pasta except spaghetti with a "sauce" made only out of minced meat and spices. When I was about 25 and met my fiancé I turned 180 degrees and became a vegetarian. Later I also added fish and shellfish to my diet (my fiancé and two daughters are still 100% vegetarians though).
I used to be politically engaged. I opposed the current Prime Minister Fredrik Reinfeldt as he battled his way to Chairman of Moderata Ungdomsförbundet in the early 90s and I was the Vice Chairman of the political student organization the current Minister for Finance Anders E. Borg chaired a few years earlier.
When it was time for me to be at kindergarten (2 years old) I started to cry as soon as my parents left me there. So instead of kindergarten, my daycare was provided by my paternal grandparents Albin and Ingeborg. Perhaps this explains the somewhat "spoiled" eating habits I mentioned as my second thing.
As you may have seen in my profile's picture of me, I am wearing both glasses and a goatee. I am not particularly fond of either (I'd prefer contact lenses and a clean shave), but my fiancé insists it suits me and who am I to criticize her apperently good taste in men...

I'm tagging the following five (actually six) bloggers:

You're it!

Ny bloggadress: http://blogg.joakimsunden.se/

2007-01-12T11:22:00.000+01:00

Efter mycket om och men verkar det nu som om min nya domän slutligen fungerar. De gamla adresserna kommer att fortsätta fungera under en tid framöver, men från och med nu kommer alltså http://blogg.joakimsunden.se/ att vara den riktiga adressen till denna blogg, så nu är det dags att ändra era bokmärken/favoriter om ni inte redan gjort det. Om ni prenumererar på RSS eller ATOM är det så klart nya adresser även för dessa.

2006 års bästa "Web 2.0"-tjänster

2007-01-09T20:51:00.000+01:00

I min första bloggpostning om Web 2.0 för drygt ett år sedan länkade jag till Dion Hinchcliffes "The Best Web 2.0 Software of 2005". Nu har Hinchcliffe, med en av de mest populära och läsvärda bloggarna om Web 2.0, gjort en ny lista för 2006 som innehåller en hel del förväntade kioskvältare (YouTube, MySpace, Netscape), men också en del mindre kända uppstickare. Det är en bra utgångspunkt och länksamling för den som är intresserad av Web 2.0.

Nytt! Nytt! Nytt!

2007-01-09T14:15:00.000+01:00

Gott nytt år!

Ny dotter: Saga, 2006-12-22 20:21.

Nytt jobb: konsult på Avega, ledande inom systemarkitektur och integration i Stockholm.

Ny bloggadress: http://blogg.joakimsunden.se/ Ändra era länkar och Atom-/RSS-prenumerationer. (Ändringen håller på att genomföras just nu vilket kan innebära bloggen inte kommer att vara tillgänglig under en kortare period.)

Nytt bloggutseende: igen... (Eftersom den förra ärligt talat inte var särskilt snygg och inte heller funktionell på det vis jag hoppats och för att kunna dra nytta av ny funktionalitet hos Blogspot/Blogger).

Code Complete: A practical handbook of software construction

2006-12-18T23:44:00.001+01:00

Steve McConnells ”Code Complete: A practical handbook of software construction” (Microsoft Press, 1993) har länge tillhört programmeringslitteraturens klassiker. Den anses av många vara den definitiva guiden till mjukvarukonstruktion och har kallats för både programmerarens bibel och programmeringsmetodikens heliga graal. Trots de fantastiska lovords som östs över boken har jag länge tvekat att läsa den eftersom den är så pass gammal för ett sådant snabbföränderligt område som programmering. Den utkom förvisso i en andra utgåva häromåret (Microsoft Press, 2004), men jag var osäker på om den verkligen skulle vara väsentligt uppdaterad. Denna farhåga verkar jag för övrigt vara långt i från ensam att hysa angående denna bok; kanske bidrar bokens sidantal (960 sidor) till att man inte gärna chansar.

Vad som ändå gjorde att jag slutligen läste boken var en kort, men initierad, användarrecension på Amazon.com som menade att andra utgåvan faktiskt är en rejält genom- och omarbetad sådan. Nu har jag inte möjlighet att jämföra med den första utgåvan (eftersom jag inte läst den), men jag kan däremot till fullo hålla med om att boken helt klart är mycket väl värd att läsa även i dag.

Code Complete har enligt McConnell själv tillkommit för att överbrygga klyftan mellan den kunskap om mjukvarukonstruktion som finns bland professorer och ”industry gurus” å ena sidan och vanliga kommersiella utövare å den andra. Han citerar vetenskapliga studier som menar att det tar mellan 5 och 15 år för kunskapen hos den förra gruppen att nå fram till den senare – Code Complete är tänkt som en genväg som gör denna kunskap tillgänglig för programmerare här och nu. Boken är också full av hänvisningar till vetenskapliga studier och undersökningar av alla de slag. Jag tycker detta är en av bokens styrkor: välkända programmeringsprinciper får här förklaringar och uppbackning i hårda data. Dessutom strör McConnell små guldkorn av forskningsresultat genom hela boken, t.ex. att ett idealiskt variabelnamn ligger på någonstans mellan 10-16, eller i alla fall 8-20, tecken.

Eftersom 50 till 65 procent av ett mjukvaruprojekt handlar om den aktivitet som kallas konstruktion och detta område trots detta är underrepresenterat i litteraturen har McConnell valt att låta detta ämne spela huvudrollen i Code Complete. Trots att detta syfte varit tydligt uttalat har en del av den kritik som ändå riktats mot boken gått ut på att den för ensidigt fokuserat på detta område. Jag tycker personligen absolut inte att det är en brist, men oavsett vad man tycker om detta kan man knappast undgå att imponeras av hur uttömmande McConnell lyckas beskriva ämnet för sin studie – en mer komplett bok om mjukvarukonstruktion och programmeringsmetodik är svår att föreställa sig om man vill att den ska vara heltäckande och samtidigt detaljrik.

På de drygt 860 sidor av boken som återstår sedan man räknat bort index och den omfattande bibliografin, kan man läsa om allt från generella principer och grundfilosofi för mjukvarukonstruktion till konkreta riktlinjer för hur man bäst skriver en for-loop; från integrationsstrategier och systematisk uppföljning av testning till hur du bör utforma dina kommentarer och var du bu bör placera blanka rader mellan kodblocken; från statistiska bevis för vikten av ordentligt utformade krav och för hur programstorlek påverkar konstruktion till personliga resonemang om mjukvarukonstruktion som ett hantverk snarare än en ingenjörskonst och om vilka egenskaper en programmerare bör besitta för att bli framstående inom sitt förvärv. Så länge det gäller konstruktion finns det kort sagt inget ämne som är för stort eller för litet för att McConnell ska behandla det och oavsett storlek behandlar han dem med stor omsorg och har alltid personliga erfarenheter, vetenskapliga studier eller välgrundade argument att bidra med för att förtydliga, bevisa och övertyga.

En kort genomgång av bokens beståndsdelar kan vara på sin plats. Code Complete är indelad i sju delar:

1. Laying the Foundation (ca 70 sidor)
De inledande kapitlen handlar om den grund som enligt McConnell måste vara på plats innan man kan börja med konstruktionen: framför allt problemformulering/vision, krav och arkitektur, men även val av programmeringsspråk, programmeringskonventioner/kodstandard och konstruktionspraxis (integrationsmetod, parprogrammering, obligatoriska enhetstester, verktyg för source control o.s.v.).

2. Creating High Quality Code (160 s.)
McConnell börjar med att slå fast det för resten av boken helt centrala “Software’s Primary Technical Imperative”: Managing Complexity. Med detta imperativ i bakhuvudet går han sedan igenom en rad välbekanta grundprinciper för mjukvarudesign, såsom enkelt, återanvändbart, löst kopplat, utbyggbart, lätt att förvalta. Från denna abstraktionsnivå fortsätter detaljerandet via klassiska byggstenar för design som ”real world objects”, abstraktion, inkapsling och arv, via designmönster ner till grunderna för klasser, riktlinjer för bra klassinterface och konstruktordesign. Slutligen landar vi i ett kapitel om rutiner; rutindesign, bra rutinnamn, hur lång en rutin får vara, hur rutinparametrar bör användas och vilken ordning de ska ha m.m. Ett kapitel om defensiv programmering (validering, felhantering, exceptions) och ett kapitel om Pseudocode Programming Process (PPP), lågnivådesign i form av pseudokod som sedan tjänar som kommentarer till koden, avslutar denna del av boken.

3. Variables (110 s.)
Här tar McConnell upp allt man behöver tänka på när det gäller variabler: hur och när de bäst initieras, hur länge de bör leva, hur ett bra namn ser ut beroende på typ och hur långt det ska vara, hur olika datatyper bör användas, när man ska använda arrays, varför man ska undvika globala variabler etcetera, etcetera.

4. Statements (110 s.)
Hur strukturerar du bäst dina koddeklarationer? I vilken ordning ska villkoren testas i if-satser med flera villkor? I case-satser? När bör du använda en while-loop och när passar en for-loop bättre? Hur och när ska loopens villkor kontrolleras? Hur får man lämna en loop? Hur och när använder man tabelldrivna metoder istället för komplicerade if-satser? När ska man använda parenteser? Ingenting får lämnas åt slumpen när det gäller att organisera och strukturera sin kod, enligt McConnell som här delger oss sina synpunkter på hur dessa och många andra liknande frågor bör besvaras. Avsnittet innehåller också ett referat av den klassiska debatten för och emot ”goto”.

5. Code Improvements (190 s.)
Denna del av boken handlar om hur man (fortfarande i konstruktionsfasen) kan förbättra kodens kvalitet genom utvecklartestning (och uppföljning av denna), ”collaborative construction” (parprogrammering, kodgranskning, kodinspektioner), debugging, refactoring och code-tuning. Särskilt avsnittet om ”collaborative construction” är intressant; även om jag läst en del XP-litteratur (eXtreme Programming) och därigenom tilltalats av parprogrammering, hade jag ingen aning om hur enig forskningen är om dessa teknikers (särskilt formella kodinspektioner) effektivitet när det gäller att kvalitetssäkra och undvika defekter i kod.

6. System Considerations (180 s.)
Programmets storlek, projektledning och projektmetod, integrationsmetod och utvecklingsverktyg är externa faktorer som i allra högsta grad påverkar konstruktionen. Här går McConnell igenom denna påverkan och kommer med förslag på hur man hanterar detta, t.ex. olika angreppssätt för integration, hur projektledare och ledning bör behandla utvecklare och hur ”managing your manager” ibland kan vara en nödvändighet.

7. Craftsmanship (130 s.)
Den avslutande delen av boken upptas till största delen av rekommendationer för layout, kodningsstil och hur man skriver självdokumenterande kod. Det handlar dels om vikten av gemensamma konventioner, dels om personliga åsikter i (ofta med en väl underbyggd argumentation så klart!) sådana gamla olösliga religiösa strider som på vilken rad den inledande måsvingen ska vara placerad. McConnell lyfter här också fram ett antal egenskaper han anser utmärker en god mjukvarukonstruktör (bl.a. ödmjukhet, nyfikenhet, intellektuell hederlighet, samarbetsvilja, kreativitet och disciplin). Bokens sista kapitel innehåller en rad tips på var man kan hitta mer information i såväl litteratur och tidskrifter som på nätet och genom användargrupper.

Varje kapitel avslutas med listor med titlar och korta beskrivningar av böcker som fördjupar sig i ämnet för kapitlet i fråga. I slutet av många kapitel finns också ämnesindelade checklistor som man kan använda för att testa sin design/kod/layout mot de principer kapitlet redogjort för.

För den som läst så här långt kommer det väl knappast som en överraskning att jag tycker att Code Complete är en mycket läsvärd bok. Faktum är att det kanske är en av de bästa, eller i alla fall för min vardag mest givande, böcker jag någonsin läst. Den har, om inte förändrat, i alla fall starkt påverkat det sätt jag vardagligen arbetar med och tänker på programmering. Väldigt många designprinciper och praktiska råd har jag kunnat tillämpa direkt i mitt dagliga kodningsarbete och för många saker jag ”alltid” tänkt på har jag nu fått en förklaring till varför jag gjort det och varför det är bra (jag har även fått veta att visa saker är dåliga och tvingats ändra mig ;-)). McConnells uppfordrande och auktoritativa tonläge har också inspirerat mig att ännu mer oförtrutet stå upp för genomtänkt design och noggrann kodning när deadlines kryper allt närmare och röster höjs för quick-and-dirty-lösningar som i slutändan ändå alltid straffar sig i form av fler defekter och svårare vidareutveckling och förvaltning.

Naturligtvis har boken även ett par svagheter. Bland annat kan detaljrikedomen vara kvävande för vissa med rad efter rad med resonemang om parentesers placeringar, olika förslag på förkortningsregler, parametrars ordningsföljd etc. Jag vill dock gärna tro att många programmerare, likt jag själv, är intresserade av sådana detaljer; de starka känslor en diskussion om måsvingens placering brukar kunna väcka tyder i alla fall på det.

Samtidigt som jag verkligen uppskattar all statistik och de flitiga citeringarna av vetenskapliga studierna är de också ett av bokens problem, om än ett mindre sådant. Ett antal hänvisningar är till studier utförda under tidigt 90-tal eller till och med 80- och 70-tal. Vid denna tid gav t.ex. utvecklingsmiljöerna inte utvecklaren samma stöd som i dag med färgkodning av syntax, automatisk komplettering av variabel- och typnamn m.m. Detta gör att en studie från 1990 om optimal längd på ett variabelnamn kanske inte äger samma värde som om den varit utförd på 2000-talet. Till McConnells försvar bör man dock tillägga att han, med goda skäl, är en stark förespråkare av kodgranskning, formella kodinspektioner och andra former av ”collaborative construction” där kodutskrifter förstås är av central betydelse.

Sammanfattningsvis är Code Complete en modern klassiker inom programmeringslitteraturen som innehåller mycket matnyttigt för såväl erfarna utvecklare som nybörjare, ja för alla som på allvar är intresserade av att bli en bättre programmerare eller mjukvarukpnstruktör. Jag kan varmt rekommendera boken och hoppas att den har en lika positiv och inspirerande effekt på ditt yrkesliv som den redan haft på mitt.

Windows Vista för nedladdning

2006-11-21T22:50:00.001+01:00

Sedan några dagar finns Windows Vista, liksom Office 2007, tillgängligt för nedladdning för MSDN-prenumeranter. Det officiella releasedatumet är som jag tidigare rapporterat den 30 november och då kommer Microsoft Sverige att anordna ett stort releaseparty i Stockholm. Jag kommer att vara där - kommer du?

.NET Framework 3.0 och ASP.NET AJAX Beta 2 lanserat

2006-11-08T09:18:00.000+01:00

Mycket riktigt tillkännagavs lanseringen av .NET Framework 3.0 i samband med att TechEd Europe for Developers drog i gång i går. Samtidigt lanserades också ASP.NET AJAX Beta 2 som nu är "feature complete" vilket troligtvis innebär att vi får se en skarp release redan i år.

MIX07

2006-11-08T08:46:00.000+01:00

Nu har Microsoft lanserat tid och plats för nästa års MIX-konferens - MIX07. Konferensen äger rum på The Venetian i Las Vegas, precis som förra året. Den pågår från 30 april till 2 maj och öppnar för anmälan i januari 2007. Förra årets konferens var mycket intressant, men då kändes Web 2.0, AJAX, Windows Vista och Windows Presentation Foundation ganska nytt och hett - inte minst för en svensk microsoftutvecklare som undertecknad. Frågan är om man kommer att kunna skapa samma attraktionskraft kring nästa års upplaga? Följ utvecklingen på http://visitmix.com/.

.NET Framework 3.0 - vad är det?

2006-11-06T15:48:00.001+01:00

I morgon börjar Microsofts TechEd Europe för utvecklare och jag skulle bli mycket förvånad om vi inte får se en release, eller åtminstone ett tydligt releasdatum, av såväl Windows Vista som .NET Framework 3.0. Trots detta verkar det fortfarande råda förvirring om vad .NET Framework 3.0 egentligen innebär, till exempel verkade inte ens Microsoft Sveriges Johan Lindfors helt säker i sin dragning på MSDN Live om just .NET Framework 3.0 härom veckan (okej, han skämtade förhoppningsvis). Jag tänkte därför försöka reda ut begreppen lite.

.NET Framework 3.0 innebär inte några större ändringar av Base Class Libraries, C#, VB .NET eller övriga delar av .NET Framework 2.0 (bara ändringar som kommer att motsvaras av Service Pack för 2.0), utan är en utökning av funktionalitet genom vad som kallas .NET 3.0 Components:

Windows Presentation Foundation (WPF, tidigare känt som "Avalon").
Windows CardSpace (tidigare "InfoCard").
Windows Communication Foundation (WCF, tidigare "Indigo").
Windows Workflow Foundation (WF).

Microsoft har fått en del kritik för att de kallar denna ändring av ramverket för "3.0" då många menar att det kanske hade varit mer lämpligt med 2.5 eller liknande. En del kritiker menar att skälet till det jämna och fina versionsnumret är att 3.0 kommer att vara förinstallerat på Windows Vista och att det skulle vara osnyggt att ha en mellanversion till detta flaggskepp. (För den som är intresserad av att följa den, faktiskt ganska intressanta, versionsdebatten är Brad Abrams blogginlägg "Toward .NET Framework 3.0" en bra utgångspunkt.)

Okej, nu vet jag vad 3.0 är - men vad är det jag hör om 3.5?!

Det är väl bara halvofficiellt än så länge, men innovationer som C# 3.0, VB 9, .NET vNext och LINQ kommer sannolikt att släppas under versionsnumret 3.5. Samtidigt med denna version kommer en ny version av Visual Studio, kodnamn "Orcas", som i grunden är samma som Visual Studio 2005 men med stöd för WPF-, WCF- och LINQ-projekt m.m. Förhoppningsvis kommer även Microsoft ASP.NET AJAX (tidigare Atlas) att släppas i skarp version och med bättre stöd för JavaScript-utveckling m.m. tillsammans med Orcas.

Microsoft AJAX Extensions Beta Release

2006-10-23T20:13:00.001+02:00

Ni har säkert redan läst det annorstädes, men jag måste bara berätta att Microsoft AJAX Extensions (tidigare känt som Atlas) i fredags släppts i Beta-version.

Man kan läsa mer på webbplatsen, som nu bytt adress från http://atlas.asp.net/ till http://ajax.asp.net/, eller i Scott Guthries uttömmande bloggpost, men jag tänkte dra de mest intressanta nyheterna i korthet.

Istället för en enda JavaScript-fil med alla features har olika delar delats upp i mindre filer som laddas vid behov och som dessutom packats ihop ytterligare.
Fullt stöd för Safari. Bra stöd för Opera, ännu bättre på gång.
Bättre debuggingstöd för JavaScript-koden.
Förbättrad UpdatePanel; bl.a. möjligheten att dynamiskt skapa och lägga till UpdatePanels på en sida (bra för composite controls), möjligheten att koppla olika UpdateProgress- och Animation-kontroller till olika UpdatePanels, samt ökad tillgänglighet genom t.ex. bättre stöd för skärmläsare.
Förbättrat och förenklat klientscriptbibliotek (AJAX Script Library).
Bättre kompatibilitet med andra AJAX-bibliotek för att undvika "språk"-krockar med t.ex. Scriptaculus och Prototype.
Licens för och möjlighet att tweaka och modifiera AJAX Script Library och distribuera detta i egna produkter/lösningar.
Ett antal nya kontroller i AJAX Control Toolkit; DropDown, MutuallyExclusiveCheckBox och ValidatorCallout.

Sedan finns det dessvärre en baksida med Beta-versionen, men det gäller mest de som tillverkat egna kontroller eller utvecklat mot klientscriptbiblioteket: förändringarna i AJAX Script Library är ganska stora och eftersom man inte har någon kompileringshjälp och JavaScript inte är det roligaste språket att felsöka, kommer det att vara ganska besvärligt att migrera till Betan. (Faktum är att releasen av Betan försenades p.g.a. att teamet bakom Control Toolkit hade underskattat svårigheterna med migreringen.)

Om du ännu inte riktigt förstått vad som är så coolt med Microsoft AJAX Extensions är det hög tid att du tar reda på det på http://ajax.asp.net/ - nu är det inte länge kvar innan ramverket är en del av .NET Framework.

ASP.NET 2.0 och webbstandards

2006-10-16T07:18:00.000+02:00

ASP.NET for Designers heter en intressant sektion på MSDN som egentligen har ett något missvisande namn. Det är ganska sällan ASP.NET-utvecklare kan ignorera designfrågor och om det förekommer är det i princip aldrig positivt. Förutom den mycket läsvärda artikeln Building ASP.NET 2.0 Web Sites Using Web Standards och andra artiklar hittar du här ett gäng CSS-baserade mallar som du kan använda för att snabbt och enkelt kan modifiera smälla upp en egen sajt.

Kortare byggtider för webbutveckling med Visual Studio 2005

2006-09-23T14:33:00.000+02:00

Scott Guthrie har publicerat en mycket intressant artikel om hur du kan få kortare byggtider för webbutvecklingsprojekt i Visual Studio 2005. Förutom en rad generella tips skriver Guthrie en del, och länkar till ännu mer, om skillnaderna mellan Web Site Projects, som är den nya modellen för VS 2005, och Web Applications Projects, som kommer med Service Pack 1, mer liknar modellen i VS 2003 med bl.a. en enda assembly och som redan nu finns att ladda ned "fully supported" från Microsoft.

Access to the path 'C:\Documents and Settings\username\Local Settings\Temp\~5a72\bin\App_Code.compiled' is denied

2006-09-22T22:33:00.000+02:00

Häromdagen råkade vi ut för felmeddelandet "Access to the path 'C:\Documents and Settings\username\Local
Settings\Temp\~5a72\bin\App_Code.compiled' is denied" när vi försökte göra en "Publish Web Site" i Visual Studio 2005. Efter en del efterforskningar, bland annat med hjälp av utmärkta verktyget FileMon från SysInternals (numera uppköpta av Microsoft!), lyckades vi hitta problemets orsak. Det visade sig att det användarkonto vi angivit för identity impersonate i Web.config måste ha rättigheter att skriva till den kompilerande användarens lokala temp-mapp (C:\Documents and Settings\username\Local Settings\Temp\)! Det enklaste, och förmodligen även säkraste, sättet att komma runt problemet är förstås att tillfälligt kommentera bort denna rad i Web.config medan man kör "Publish Web Site".

Bloggändringar

2006-09-17T19:42:00.000+02:00

Om du inte följer denna blogg via en RSS-läsare borde du vid det här laget ha upptäckt att jag ändrat utseendet på min blogg. Det gamla formatet utnyttjade inte riktigt utrymmet på moderna bildskärmar och jag hoppas att det här utseendet ska kännas lite läsvänligare.

Jag har också lagt till statistik för bloggen via SiteMeter och jag måste säga att jag är något överraskad av vilka som besöker min blogg. Nu har det förvisso bara gått ett par veckor sedan jag började kolla, men det verkar som om majoriteten av mina läsare faktiskt inte är mina närmast sörjande (jag har inte precis marknadsfört min blogg), utan folk som hamnar här efter att ha sökt information eller lösningar på problem via Google. Detta är en positiv överraskning eftersom ett av huvudsyftena med bloggen är att hjälpa människor att enkelt hitta lösningar på de problem som jag själv varit tvungen brottas med.

Med tanke på denna besöksstatistik och med tanke på att jag just nu sitter i ett uppdrag där jag dagligen hjälper utvecklare med .NET 2.0 tänkte jag den närmaste tiden försöka posta en del inlägg om olika problem jag stött på den senaste tiden. Jag hoppas att det blir till hjälp för någon.

Jag funderar också på att testa Google AdSense och se hur det fungerar; med min blygsamma trafik blir det knappast mer än kaffepengar, men det kan bli en intressant erfarenhet.

Adjö Atlas, välkommen AJAX Library och AJAX Extensions

2006-09-11T22:21:00.000+02:00

Atlas finns inte längre. Eller rättare sagt, kodnamnet Atlas har nu blivit ersatt av ett officiellt namn eftersom Microsoft nu har besämt sig för att göra produkten "fully supported" och kommer att leverera en 1.0-version i slutet av året. Det blev tyvärr inget av de roliga namnen från Atlas Naming Game, till exempel Client-side Rich Asynchronous Product (CRAP) och Asynchrounous POST Platform Leveraging Enterprise Javascript And XML (APPLEJAX).

Klientdelen kommer att få namnet Microsoft AJAX Library och serverdelen får heta ASP.NET 2.0 AJAX Extensions. Serverkontrollerna kommer att finnas med i ASP.NET "Orcas" (kodnamnet för nästa version) och det kommer att finnas WYSIWYG-designstöd för dem i Visual Studio "Orcas", som också kommer att få bättre JavaScript-IntelliSense och -debugging.

Läs mer om nya namnen, leveransplaner m.m. på Scott Guthries blogg.

Ny version av CSS-vänliga ASP.NET-kontroller

2006-09-11T14:46:00.000+02:00

Nu finns det en ny version av kontrolladaptrarna för att bygga CSS-vänliga (icke-TABLE) ASP.NET-kontroller som jag bloggat om tidigare. Nedladdningen innehåller också ytterligare ett antal nya tabellfria implementationer av ASP.NET-kontroller. Läs mer på Scott Guthries blogg.

Lyssna på podcasts!

2006-09-10T17:37:00.000+02:00

Ett bra och roligt sätt att lära sig mer om utveckling och arkitektur är att lyssna på några av de många podcasts som finns i dessa ämnen. Det senaste halvåret har jag tagit för vana att ladda ned podcasts till min Qtek-telefon, eller bränt dem på CD för bilen, som jag sedan passat på att lyssna på när jag skottat jord, klippt gräsmattan, kört bil till jobbet eller utfört någon annan monoton syssla.

Mina favoritställen att ladda ned podcasts från är Channel 9 (som jag bloggat om tidigare) och Dag Königs (numera evangelist hos Microsoft) "Another Visitor".

Framework Design Guidelines

2006-09-06T22:58:00.000+02:00

Sedan ett halvår eller så tillbaka i tiden har jag följt Brad Abrams blogg, inte minst genom hans inblandning i Microsofts Atlas-projekt (faktum är att jag växlade några ord med honom om detta på Mix06 i våras). Brad Abrams är Lead Program Manager för Microsofts .NET Framework Team, en position han tidigare haft också i Common Language Runtime Team. Han har designat olika delar av .NET Framework sedan 1998, var Lead Editor för Common Language Specification (CLS) och ECMA/ISO CLI Standard. Med denna bakgrund är det inte konstigt att hans bok Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (en bok i Microsofts .NET Development Series) är så full av goda råd. Att hans medförfattare heter Krzysztof Cwalina och är Program Manager för Common Language Runtime Team med ansvar för namespaces som System.Collections, System.Diagnostics m.m., gör förstås också sitt till.

Under de år .NET Framework har funnits har Microsoft förstås fått enormt mycket återkoppling från mjukvaruindustrin och utvecklarcommunityn kring ramverket. Man har dessutom själva bedrivit omfattande användbarhetstester och ägnat mycket tid åt att internt utveckla designriktlinjer för såväl .NET Framework som andra produkter. Det är erfarenheterna från denna tid som författarna vill dela med sig av i Framework Design Guidelines.

Boken täcker allt från den grundläggande filosofin bakom ramverksdesign till designriktlinjer som när du bör välja en struct framför en class till specifika detaljer för hur du bör namnge dina parametrar ("endpoint" ska till exempel skrivas just så och inte "endPoint"). Det går alldeles utmärkt att läsa de ca 350 sidorna från pärm till pärm, men man kan också nöja sig med de första 30 sidorna om "Framework Design Fundamentals", skumma igenom intressanta riktlinjer och i övrigt använda boken som referens. Riktlinjerna är indelade efter ämnen som "Naming Guidelines", "Type Design Guidelines", "Usage Guidelines" och "Common Design Patterns", och finns av fyra olika slag: "Do", "Don't", "Consider" och "Avoid". Naturligtvis åtföljs riktlinjerna av resonemang och exempel. Dessutom, och det här är verkligen en av bokens stora behållningar, har man överallt sprängt in typografiskt distinkta kommentarer/anekdoter från ett 20-tal microsoftare och Microsoft-nära industriexperter som t.ex. Jeffrey Richter ("Applied Microsoft .NET Framework Programming") och Anders Hejlsberg (skaparen av C#). I kommentarerna kan man läsa många intressanta resonemang och motiveringar till varför .NET Framework ser ut som det gör och man kan även skönja en del av de trätoämnen som omgärdat utvecklingen av ramverket (prestanda- och C++-gänget mot lättanvänt- och VB-gänget, förenklat uttryckt).

Riktlinjerna i Framework Design Guidelines är i första hand utformade för att passa just ramverk och publika API:er, särskilt sådana som bokens författare kallar "progressive frameworks" och definierar sålunda:

"Framework that is easy to use in basic scenarios yet powerful enough to be used in advanced scenarios."

Och man kan lugnt säga att "easy to use" är den princip som väger tyngst i riktlinjerna; ofta får lösningar som kanske är mer finurliga eller skulle ge bättre prestanda vika på foten för de som är mer lättanvända, och av utvecklarna förväntade, enligt Microsofts erfarenheter och användbarhetstester. Det gör att alla råd kanske inte passar lika bra för just ditt ramverk, men enligt min mening är majoriteten av riktlinjerna tillämpliga även vid applikationsutveckling. Dessutom är det ju så som en av kommentatorerna skriver: "Performance gets better over time, ease of use doesn't."

Framework Design Guidelines är en mycket bra bok som egentligen alla .NET-utvecklare borde läsa, i synnerhet de med intresse/ansvar för design- och arkitekturfrågor.

Vad gick egentligen snett när du råkat ut för System.Data.ConstraintException?

2006-09-03T21:06:00.000+02:00

Det händer då och då att man som utvecklare råkar ut för System.Data.ConstraintException när man via DataAdapter.Merge försökt fylla ett typed DataSet med data. Felmeddelandets detaljrikedom lämnar en del att önska:

"System.Data.ConstraintException: Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints."

Det kan alltså vara i princip vad som helst som gått snett och om ditt DataSet är någorlunda komplext är det inte särskilt lätt att gissa sig till det heller. Lösningen ligger i att fånga detta exception och använda DataSet.GetErrors() för att få reda på exakt vilka rader det var problem med och vilka problemen var:

try { myTypedDataSet1.Merge(ds.Tables[0], false, MissingSchemaAction.Error); } catch(System.Data.ConstraintException exc) { DataRow[] rows = myTypedDataSet1.myDataTable.GetErrors(); foreach(DataRow row in rows) { string error = row.RowError; // Visa/logga felmeddelande etc. } }

Windows Live Writer

2006-08-22T23:01:00.000+02:00

Denna bloggpost skriver jag på Windows Live Writer (Beta) som är Microsofts nya WYSIWYG-skrivbordsapplikation för att skriva blogginlägg. Som ni ser fungerar det bra även för andra bloggar än de på Windows Live Spaces (f.d. MSN Spaces), till exempel Blogger/BlogSpot som jag använder.

Förutom ett smidigt gränssnitt för text och länkar finns det funktioner för att enkelt lägga in bilder och kartor (från Windows Live Map). Det mest intressanta för framtiden är emellertid att Windows Live Writer har ett öppet API och utvecklare kan ladda ned en SDK för att bygga egna add-ons och applikationer. Det finns redan en Flickr4Writer som gör att du kan lägga in Flickr-bilder i dina blogginlägg.

Torrperiod

2006-07-28T12:15:00.000+02:00

Vilken fantastisk sommar det har varit med sol och höga temperaturer. Bönderna, eller vi med nylagda gräsmattor, har kanske inte alltid varit lika förtjusta i denna torrperiod. Torrperiod har det även varit för min blogg som ni kanske märkt. Fotbolls-VM, nytt uppdrag, semester, altanbygge och annat huspyssel, allmän semesterlättja och nytt operativsystem är vad som satt käppar i hjulet. Nytt operativsystem ja; jag har försökt installera Windows Vista Beta 2 sedan det kom i maj. Ja, jag började egentligen redan med Beta 1, men har fått samma felmeddelande för båda versionerna innan installationsprogrammet ens kommit igång ordentligt:

"Setup could not get information about the disks on your computer"

Googlande, formatering av alla diskar, radering av Master Boot Record med bootdisk och fdisk har inte hjälpt - felmeddelandet har kvarstått. Efter många om och men upptäckte jag slutligen att jag var tvungen att fysiskt koppla bort min andra interna hårddisk. Det gjorde jag i går och i dag skriver jag detta inlägg på Internet Explorer 7 från Windows Vista. Jag gillar verkligen känslan och utseendet i det nya operativsystemet, trots att jag inte har ett grafikkort som klarar de snygga glaseffekterna ("Aero"). Kanske blir det en del bloggposter om Vista framöver.

Nu ska jag sätta i gång installationen av Office 2007 innan jag går ut i solen och svalkar mig med ett stort glas iste och börjar njuta av slutet på semestern (en vecka kvar efter helgen).

Mer om Microsoft Motion

2006-06-12T08:10:00.000+02:00

I slutet av maj publicerade Microsoft en intressant introduktion till sitt projekt Motion (som jag skrivit om tidigare) som handlar om så kallad business capability modelling:

Motion Lite: A Rapid Application of the Business Architecture Techniques Used by Microsoft Motion

Låt INTE ditt exception ärva från ApplicationException

2006-05-30T17:29:00.000+02:00

Jag har alltid fått lära mig, både från böcker och från Microsofts egna råd, att egna Exceptions alltid ska ärva från ApplicationException. Jag blev därför väldigt förvånad när jag upptäckte att Microsofts kodanalysverktyg (FxCop) ger ett "TypesShouldNotExtendCertainBaseTypes"-meddelande på exceptions som ärver från ApplicationException.

Lite efterforskningar ger vid handen att Microsoft ändrat sig i frågan, men att de ändringarna inte slagit igenom i dokumentationen (se till exempel här). Vad värre är uppmärksammades ändringen inte heller i .NET Framework 2.0 där klassen fortfarande finns utan att vara markerad som "obsolete" och där samma felaktiga rekommendation länge gavs i dokumentationen. Nu har dokumentationen emellertid ändrats och man påpekar att ApplicationException inte längre tjänar något syfte (se här).

Det är egentligen inte fel att ärva från ApplicationException - det finns helt enkelt bara ingen vits med det. Du behöver följaktligen inte kasta dig över alla gamla projekt och ändra i dem, men du bör i framtiden istället ärva från Exception.

Läs mer om detta i FxCop-bloggen eller i Brad Abrams (tidigare ägare av design guidelines) blogg.

Windows Live Gadget SDK

2006-05-28T14:37:00.000+02:00

Nu har Microsoft släppt ett Software Development Kit (SDK) för Windows Live Gadgets som jag skrivit om tidigare. Förutom API hittar man där även en Developer's Guide, Design Guidelines, en Visual Studio Live Gadget Project Template, ett antal exempel och en del annat nyttigt. Det har med andra ord nu blivit mycket enklare att komma i gång med sitt första Gadget-projekt.

Intellisense för SQL-frågor

2006-05-23T13:45:00.000+02:00

Intellisense-hjälp för SQL-frågor är något jag efterlyst länge och det var något av en besvikelse att Microsoft inte hade med detta i SQL Server 2005. Red-Gate är ett företag som tillverkar ypperliga SQL-verktyg; jag har tidigare använt deras svit för att synkronisera lagrade procedurer mellan databaser - något som är ganska knepigt att göra manuellt. De släpper nu sitt verktyg SQL Prompt, med just Intellisense för SQL-frågor, gratis för den som laddar ned det innan 1 september.

Detta tips fick jag via Scott Guthries blogg.

Varför behöver man en arkitekt?

2006-05-23T09:56:00.000+02:00

Varför behöver man en arkitekt? Svaret på den frågan kan man hitta i form av en tecknad film med en käck sång på Microsofts nya webbplats om arkitektur, Skyscrapr. Det är fortfarande lite oklart vilken som är målgruppen, men enligt sajtens initiativtagare, Program Manager för Microsofts Architecture Strategy Team, är det bland annat min mamma:

"My hope for this site is to make architecture accessible to all. Does your mother not quite understand what you do, send her here? Are you a BDM or COO and need to better understand the guidence your chief architect has just given you? Come here. No assumptions made, no prequal required."

De lättillgängliga tecknade filmerna på sajten stämmer bra överens med denna vision, men samtidigt finns där ett gäng intressanta och avancerade podcasts med personer som Clemens Vasters, Martin Fowler och Jeff Richter. Det bjuds även på utdrag från gamla nummer av Architecture Journal, en tidskrift som knappast har mamma i målgruppen. (Om inte mamma är, eller aspirerar på att bli, mjukvaruarkitekt förstås.)

För den som är nyfiken på det här med arkitektur kan Skyscrapr vara intressant att hålla ett öga på. Just nu känns det lite mer som en sajt för utvecklare som börjat nosa på arkitekturfrågor, snarare än en sajt för mamma; men skicka henne för all del länken till den tecknade filmen!

Resharper 2.0 Beta är här

2006-05-22T09:20:00.000+02:00

Med tanke på det evangelium jag förkunnat om ReSharper får jag nästan skämmas som inte betatestat den nya versionen förrän nu. ReSharper 2.0 Beta ger dig äntligen samma stöd i Visual Studio 2005 som ReSharper 1.5 skämt bord dig med i tidigare versioner av Visual Studio - och mer därtill. Visst finns det invändningar - det tar till exempel alldeles för lång tid att starta upp ReSharper med Visual Studio 2005 ibland - men det är ju än så länge bara en betaversion. Testa den gratis du med! (Glöm inte att använda länken till "license key" för att få demo-nyckeln.)

AJAX och tillgänglighet

2006-05-19T11:31:00.000+02:00

Från att ha varit ett okänt begrepp för de flesta som sysslat med webbutveckling, har tillgänglighet under de senaste 2-3 åren blivit en fråga som ingen professionell webbutvecklare har råd att ignorera. (För den som fortfarande inte vet vad det handlar om föreslår jag ett besök på W3C:s avdelning för Web Accessibility Initiative (WAI), http://www.w3.org/WAI/.) Stödet för utvecklare att arbeta i enlighet med riktlinjer för tillgänglighet har förbättrats avsevärt, till exempel genom automatisk validering i Visual Studio 2005 och Internet Explorer Developer Toolbar.

En annan trend, som knappast kunna undgå någon läsare av denna blogg, är AJAX som teknik för att bygga webbapplikationer med rika användarupplevelser. Tyvärr medför denna teknik en hel del problem ur ett tillgänglighetsperspektiv. Bland annat är JavaScript något man inte bör förlita sig på om man vill bygga en tillgänglig webbplats och det innebär naturligtvis bekymmer för en webbplats byggd med AJAX-tekniker. En del av lösningen på detta problem är förstås att se till att webbplatsen fungerar även utan AJAX, men i många fall kanske just AJAX-teknikerna är en stor del av webbplatsens profil eller till och med nytta.

Ett annat problem är att skärmläsare, som många blinda använder sig av, inte märker när delar av en webbplats uppdaters via AJAX-teknik och därför inte vet att det laddats ny information som den ska läsa upp. Och även om det skulle gå att signalera att ny information tillkommit blir det också ett problem att identifiera vilken del av informationen som är ny.

Två svenska bloggare (de skriver dock på engelska båda två) som skriver bra om de här frågorna, liksom om webbutveckling och webbstandards i allmänhet, är Robert Nyman (Robert's Talk) och Roger Johansson (456 Berea Street). På 456 Berea Street finns en bra bloggpost med flera länkar för den som vill fördjupa sig ytterligare i just problematiken med AJAX och tillgänglighet.

O/R-mapping - vad är det?

2006-05-15T21:53:00.000+02:00

En vanlig modell vid programmering mot databaser är att all logik för att kommunicera med databasen placeras i ett separat lager, ett så kallat data access layer (DAL, även data access logic). Detta lager innehåller vanligtvis en mängd olika CRUD-metoder (Create-Read-Update-Delete) som använder hårdkodade SQL-frågor och/eller anrop av lagrade procedurer för att returnera datatransfer objects (DTO, t.ex. DataSet) eller "business objects" (t.ex. Customer, Product) till anropande lager. Så här brukar det, något förenklat, se ut i koden:

Person myPerson = dataAccessLayer.GetPerson(id);
myPerson.Name = "Nytt namn";
dataAccessLayer.SavePerson(myPerson);

Mönstret känns igen från Microsofts egna kodexempel, liksom från deras architecture guidelines och best practices.

En annan modell är så kallad Object Relational Mapping eller O/R-mapping (även automated mapping). Vissa skulle säga att O/R-mapping är ett mer objektorienterat sätt att närma sig problemet; i denna modell skapar man "mappningar" mellan databasen tabeller/vyer och deras fält, och objektorienterade klasser och deras attribut. Detta görs enklast via en O/R-mapper som förutom att automatiskt generera klasserna utifrån databasen, även innehåller ett ramverk som bland annat genererar dynamisk SQL för att hantera kommunikationen mellan objekten och databasen. Med en O/R-mappers dynamiska SQL och ramverk blir det också enkelt att byta databas; koden ser likadan ut, men annan kod genereras och de dynamiska SQL-satserna kanske ser annorlunda ut. Så här kan koden se ut med en O/R-mapper:

Person myPerson = new Person(id);
myPerson.Name = ”Nytt namn”;
myPerson.Save();

Man skulle kunna säga att en O/R-mapper låter den objektorienterade utvecklaren att spara objektens tillstånd (”state”) utan att behöva tänka på var och hur detta sker.
Förespråkare för O/R-mapping brukar framhålla fördelarna med det automatiska kodgenererandet; förutom den uppenbara tidsbesparingen minskar även risken för buggar. Det är onekligen ett tilltalande argument, men det finns bra verktyg för att automatiskt generera DAL även utan O/R-mapping. Ett exempel är DataSet Designer i Visual Studio, ett annat och mer kraftfullt är CodeSmith. O/R-mapperns dynamiska natur gör dock att du redan från början har en väldigt komplett lösning, medan du med en traditionell kodgenerator kan få lägga ned en hel del arbete på att finjustera mallar och annat för att få fram kod som är lika flexibel.

Modellen har förstås sina kritiker också. Den vanligaste invändningen är att O/R-mappers dynamiska SQL förvisso är flexibel, men att det man vinner i flexibilitet lätt kan förloras i prestanda; en skicklig databasutvecklare kan optimera enskilda frågor, särskilt mer komplicerade sådana, bättre än en O/R-mapper. En del kritiker menar till och med att många som använder O/R-mappers gör det därför att de inte kan sin SQL; intressant nog finns det dem som menar att det är en fördel med O/R-mappers att de genererar bättre SQL än en normal utvecklare. Frågan är hur allvarlig denna kritik är – de flesta O/R-mappers erbjuder en möjlighet att gå runt ramverket och specialskriva metoder och använda lagrade procedurer.

O/R-mapping är ingenting nytt, men jag tycker det talats allt mer om modellen på sistone. Jag tror att en del av förklaringen kan vara att Microsoft, från att ha varit ganska ointresserade av modellen och satsat mer på data transfer objects som recordsets och datasets, för en tid sedan började tala om egen O/R-mapper. Arbetsnamnet var ObjectSpaces och tanken var att det skulle lanseras med Visual Studio 2005. Samtidigt som detta ökade intresset för O/R-mapping hade det på kort sikt en motsatt effekt; man väntade hellre på Microsofts lösning än investerade tid och resurser på en produkt med osäker framtid. En hel del hann dock hända på vägen, ObjectSpaces lades ned och allt talar nu för att det är LINQ/dLINQ, som jag skrivit om tidigare, som kommer att bli Microsofts bidrag till O/R-mapping. Om jag förstått saken rätt kommer LINQ dessutom att vara utbyggbart på ett sådant sätt att dagens O/R-mappers kommer att kunna bygga på LINQ i framtiden, snarare än konkurrera med teknologin.

Till syvende og sist blir det som vanligt projektets förutsättningar som får bestämma om man bör använda en O/R-mapper eller inte. I väldigt många projekt räcker en O/R-mapper väldigt långt och du får väldigt mycket gratis, i en del fall kanske det krävs mycket specialskriven dataaccesslogik som gör att en O/R-mapper inte tillför särskilt mycket. Ibland kanske det är fråga om så pass lite affärslogik att det blir suboptimalt att baka om data till objekt, till exempel i rapporter som utgår från en tabell eller vy i databasen.

Oavsett om man tycker att O/R-mapping är en bra modell eller inte kan man vara säker på att vi kommer att se ännu mer av den i och med LINQ som kommer med nästa version av C#/VB.NET och Visual Studio redan i höst. Vill man inte använda en O/R-mapper bör man i alla fall titta närmare på kodgeneratorer; här är trenden än tydligare – allt mer kod kommer i framtiden att genereras av olika verktyg.

Länkar till information om O/R-mapping och LINQ

Vanatec OpenAccess - en populär O/R-mapper
LLBLGen Pro - ännu en populär O/R-mapper
nHibernate - portning till .NET av den klassiska O/R-mappern för Java
nPersist - svensk O/R-mapper för .NET av Mats Helander
Kriterier för att välja O/R-mapper, omfattande lista på O/R-mappers
Scott Guthrie om LINQ och ASP.NET
Har Microsoft andra O/R-mappers på gång..?

Upplev Mix06 i din dator

2006-05-05T10:00:00.000+02:00

Alla sessioner från Mix06 är nu tillgängliga för nedladdning på konferensens webbplats.

Ny version av Atlas Control Toolkit

2006-05-05T09:49:00.000+02:00

Nu finns den nya versionen av Atlas Control Toolkit att ladda ned. Den innehåller huvudsakligen buggfixar, men också fyra nya kontroller:

AlwaysVisibleControl: gör så att valfri kontroll alltid hänger kvar "ovanpå" sidan när du scrollar.
DropShadow: ger en Panel skugga runt kanterna. Kan till exempel användas med AlwaysVisibleControl för att tydliggöra att den svävar ovanpå sidan.
ModalPopup: en popup som visar innehållet som en modal dialog så att resten av sidan gråas ut och inte går att klicka på eller navigera inom förrän du gjort ditt val och/eller besvarat dialogen.
RoundedCorners: lägger automatiskt till rundade hörn på till exempel en panel.

Microsoft och de 101 kodexemplen

2006-05-04T10:07:00.000+02:00

Microsoft har skapat en rad referenskodexempel för Visual Studio 2005 som man kan använda och vidareutveckla för att lösa vanligt förekommande uppgifter, till exempel hur man använder SQLCacheDependency för cache, hur man skapar egna menyer i Outlook eller hur man använder serieporten med den nya Port-klassen. Det rör sig om totalt 101 olika exempel indelade i åtta kategorier:

Base Class Libraries - Group 1 Samples
Base Class Libraries - Group 2 Samples
Data Access Samples
Web Development Samples
Windows Forms Samples
Visual Studio Tools for Office Samples
Tablet PC Samples
.NET Compact Framework Samples

Du kan ladda ned dem i antingen C# eller VB.NET från http://msdn.microsoft.com/vstudio/downloads/101samples/.

Bygg egna Atlas-kontroller med Atlas Control Toolkit

2006-05-03T10:25:00.000+02:00

Atlas Control Toolkit har funnits ute sedan i påskas, men jag tycker ändå det är värt att nämna det eftersom jag dels tycker hela Atlas-projektet är mycket intressant, dels gillar trenden mot allt större öppenhet och deltagandekultur som blir allt tydligare hos Microsoft. Atlas Control Toolkit är ett ramverk med mallar och basklasser för att bygga återanvändbara Atlas-kontroller. Det kan till exempel vara en CascadingDropDownList som laddar nya rullgardinsmenyer, utan synlig postback, med nya val utifrån vad du valt i de tidigare menyerna; ett ganska vanligt scenario i olika typer av webbformulär. Just CascadingDropDownList hittar du också bland de exempelkontroller som medföljer verktygslådan tillsammans med ytterligare några stycken, bland annat min personliga favorit PopupControl som poppar upp ett litet "fönster" i anslutning till ett element, t.ex. med en asp:calendar-kontroll för att åstadkomma en så kallad datumväljare ("date picker").

Microsofts förhoppning är att Atlas Control Toolkit ska få utvecklare både inom och utom Microsoft att utveckla hundratals, eller till och med tusentals, Atlas-kontroller. Programmets ansvarige, Shawn Burke, har målet klart för sig:

"Basically, my mission is to band together with our users (you!) and turn this
tookit into the biggest, baddest set of web client UI extensions around."

För att åstadkomma detta kommer man att sätta upp någon form av source control på Internet där alla som vill kan bidra till kontrollutvecklingen med egna kontroller, men även genom exempelvis vidareutveckling och buggfixar i befintliga kontroller. Detaljerna för hur detta kommer att fungera är inte klara ännu, men en ny version av verktygslådan och en del nya kontroller kommer nu i veckan och därefter har Burke annonserat att man kommer att ta tag i saken.

CSS-vänliga kontroller lanserade

2006-05-03T09:56:00.000+02:00

Nu har Microsoft äntligen lanserat de CSS-vänliga kontrolladaptrar jag skrev om tidigare. Förutom att du med hjälp av dessa själv kan styra vad kontrollerna i ASP.NET producerar för HTML, finns det fem CSS-vänliga exempelkontroller (Menu, TreeView, DetailsView, FormView och DataList) med i paketet du kan ladda ned här. Förutom det white paper du hittar på samma plats har Scott Guthrie som vanligt skrivit en lättillgänglig introduktion i sin blogg.

I am alive!

2006-04-26T09:39:00.000+02:00

Ledighet tillbringad i det isolerade Smedsträsk, inskolning på dagis och problem med Internet-uppkopplingen är faktorer som samverkat till att hålla mig borta från min blogg de senaste veckorna. Nu är jag dock tillbaka. En gigantisk mejl- och RSS-skörd, liksom andra praktiska bestyr förenade med återkomst till kontoret efter en tids frånvaro, återstår dock att ta itu med innan jag kommer att ha tid att skriva något.

Uppdatering: En faktor som försenat min återkomst ytterligare är att jag inte kunnat publicera nya inlägg på min blogg denna vecka på grund av problem med Blogger/Blogspot. Om du kan läsa detta verkar de problemen vara lösta nu... :-)

Bygg egna Atlas-kontroller

2006-04-05T08:36:00.000+02:00

Bertrand Le Roy på Atlas-teamet har påbörjat en serie blogginlägg om hur man skapar egna Atlas-kontroller med hjälp av den utbyggnad av JavaScript som Atlas innehåller. De kontroller han använder som exempel är de som Brad Abrams använde i sin Atlas-demonstration på Mix06. Du kan ladda ned koden för demon här.

Microsoft kartlägger hur företag fungerar

2006-04-04T21:47:00.000+02:00

Ric Merrifield på Microsoft är ansvarig för ett projekt inom Microsoft som kallas "the Motion initiative" som är sysselsatt med så kallad business capability modeling. Tillsammans med företag från olika branscher - allt från livsmedelskedjor till advokatbyråer - har Microsoft byggt upp en generell modell över alla de kompetenser eller färdigheter ("capabilities") ett företag använder för att bedriva sin verksamhet. Den mest grundläggande nivån, core capabilities, handlar om breda kategorier som "Develop product/services", "Generate demand" och "Plan and manage the enterprise". Den karta Motion tagit fram borrar sig sedan ned inom varje sådan kategori ända till vad som kallas primitiva aktiviteter, till exempel "Enter orders into production" och "Access product pipeline for availability". Om allt detta och mycket mer berättade Ric Merrifield när han besökte Sverige i slutet av förra året på Microsofts och Sundblad & Sundblads Architect Forum. I fall du inte hörde till den selekta skara som då fick chansen kan jag meddela att Robert Scoble nu gjort en mycket intressant intervju med Ric Merrifield om just Motion som finns på Channel9.

På gång för ASP.NET

2006-03-30T11:54:00.000+02:00

Scott Guthrie har börjat publicera en månatligen återkommande lista på nyheter för ASP.NET från Microsoft på sin blogg. För april innehåller den sådant som ännu en Atlas-release, ett Atlas Control Pack med bland annat cascading drop-down lists och collapsable panels, de adapteruppdateringar som gör flera web controls helt CSS-kontrollerade som jag skrev om tidigare samt en release candidate för Visual Studio 2005 Web Application Project för de som gillar projektmodellen från VS2003.

Jag bloggar från Stäket

2006-03-29T20:21:00.000+02:00

I och med detta inlägg har jag placerat min blogg i Stäket på bloggkartan.se. Det verkar som att jag är den första som registrerat denna plats som hemvist för min blogg. Det ska bli intressant att se om vi blir fler...

För dig som inte vet vad Stäket är eller var det ligger kan jag berätta att det ligger i Kallhäll i Järfälla kommun norr om centrala Stockholm. "Stäk" är ett gammalt namn för ett befäst sund med spetsade träpålar under vattnet; i detta fall Almarestäket mellan Järfälla och Upplands Bro, den enda seglingsleden till Uppsala. Just detta stäk är Sveriges mest kända, inte minst på grund av "beslutet om Stäkets rivning" från 23 november 1517 som har kallats Sveriges första riksdagsbeslut och som var upphovet till Stockholms blodbad när ärkebiskop Gustav Trolle tre år senare krävde sin hämnd; Stäket var också namnet på Trolles borg.

Mix06 - avrundning

2006-03-29T19:43:00.000+02:00

Den sista dagen på Mix06 innehöll Mix06 Chat, en chans att lunchmingla med konferensens övriga deltagare, men också med dess talare och personal. Jag talade en hel del med ett par olika personer i Atlas-teamet, framför allt med Jonathan Hawkins, nyckelperson tillika Program Manager Architect i Atlas-teamet, samt med en tjej i teamet bakom Windows Live (jag uppfattade tyvärr aldrig hennes namn). Ett par intressanta saker framkom under våra samtal:

Någon form av ramverk som gör det möjligt att själv använda gadgets på sin egen webbplats på samma sätt som på Live.com kommer att levereras i en framtida Atlas-release. Eftersom nya releaser kommer ca var sjätte vecka kan det alltså bli ganska snart.
Windows Lives svar på min kritik blir förhoppningsvis åtminstone information om hur man kommer runt problemet. Förhoppningsvis kommer de på sikt att göra alla alternativ lättillgängliga för även icke-engelska browsers/Passport-konton.
Virtual Earth kommer snart att få täckning för "northern and eastern Europe" (Tyskland hör tydligen till någon av dessa kategorier!); bildmaterialet lär redan finnas och det är bara en tidsfråga innan det blir tillgängligt.
Kartmaterialet på http://local.live.com/ är mer begränsat än det du får tillgång till själv via Virtual Earth API.
Namnet Atlas är inte en akronym utan är liksom en del andra Microsoft-kodnamn hämtat från Saturnus-trivia; Atlas är en av Saturnus månar och Cassini (den inbyggda webbservern i Visual Studio 2005) är en (del av en) NASA-farkost som skickades till planeten för snart nio år sedan.

Lång dags färd mot Stockholm

2006-03-29T11:59:00.000+02:00

Det har gått ett tag sedan mitt senaste inlägg. Orsaken till detta är min mardrömsresa hem från Las Vegas. Det började med att jag fick influensan och mådde så pass illa att jag var orolig för hur jag skulle ta mig mellan planen i Chicago. När jag äntligen vinglat fram till min flight, ett direktflyg till Stockholm med SAS, visade den sig vara inställd. Efter en lång tids illamående i en extremt långsam kö belönades jag med en matkupong på $5 (sic!) och en flygresa via Frankfurt med Air India åtskilliga timmar senare. Naturligtvis hade de sjabblat med just min bokning i Frankfurt och jag fick snällt vänta i ytterligare några timmar på ett senare plan till Stockholm. Sedan dess har jag i princip varit sängliggande. Nåväl, Mix06 var dock så intressant att jag gärna hade gjort om resan även med facit i hand.

AJAX - erfarenheter från skyttegraven

2006-03-22T16:20:00.000+01:00

Den mest lärorika sessionen jag besökt hittills är Scott Isaacs "Lessons from the Trenches: Engineering Great AJAX Experiences". Scott Isaacs var chefarkitekten bakom Live.com och har samlat på sig en hel del erfarenheter om de hinder och fallgropar man måste se upp med när man kodar en AJAX-applikation. Alla som tänkt använda ATLAS/AJAX på allvar bör gå gå igenom hans slides från denna session och se den live när alla sessioner görs tillgängliga på http://www.mix06.com/ om en månad. Scotts blogg innehåller också en hel del nyttiga erfarenheter.

Mix06 Sandbox

2006-03-21T22:35:00.000+01:00

Jag tillbringade några timmar i Mix06 Sandbox under söndagen; spelade lite X-box 360, kollade in olika Origami-prototyper, tittade på Windows Presentation Foundation och experimenterade med de olika laborationerna som finns installerade på de olika stationerna här. Det kändes ganska lyxigt att ha personer som Bertrand Le Roy och Brad Abrams från ATLAS-teamet sittande bredvid sig beredda att svara på frågor om de olika laborationerna och andra ATLAS-relaterade spörsmål. En av de mest intressanta laborationerna var faktiskt Windows Vista Sidebar. Microsoft har verkligen gjort det otroligt enkelt att skapa egna gadgets för Sidebar. Du behöver egentligen bara använda HTML för att skapa en enkel gadget och sedan placera den i rätt katalog i operativsystemet så är det klart.

Jag har sett att flera av laborationerna, liksom ett antal presentationer, nu finns tillgängliga för nedladdning på https://content.mix06.com/content/sessions.aspx. Tyvärr går många laborationer inte att köra utan tillgång till filer som inte är inkluderade i de nedladdningsbara filerna, men laborationsmanualerna kan ändå vara intressanta.

Windows Live som plattform

2006-03-20T23:18:00.000+01:00

Gårdagens session "The Windows Live Platform: Build Applications That Have Access to 400 Million Address Books, and 13 Billion Contacts!" handlade om Windows Live som plattform eller hur vi som utvecklare kan använda Microsofts öppna API:er för att utnyttja Microsofts Windows Live Platform i våra egna applikationer. Exempel på de tjänster som är tillgängliga är MSN Search, Virtual Earth och MSN Messenger. Med MSN Search Web Services kan du till exempel bygga en söktjänst för din egen sajt som använder MSN Search bakom kulisserna men visar sökresultatet på din egen sajt precis som du vill ha det.

Microsoft visade en hel del ögongodis de skapat som exempel på hur tjänsterna kan kombineras, bl.a. en applikation som via Messenger visade var demokillens kontakter befinner sig på en karta från Virtual Earth liveuppdaterad var 30 sekunder med AJAX-teknik utifrån GPS-signaler på deras mobiltelefoner. Med några enkla steg skapade han sedan ett möte på ett café på kartan varpå vägbeskrivningar automatiskt skickades ut till alla deltagande kontakter utifrån deras respektive positioner.

En mer jordnära och nyttig tillämpning som demonstrerades var en Messenger-applikation som ger dig möjlighet att låta en annan person köra felsökning på din dator om du till exempel vill hjälpa din mamma med datorproblem.

Ett tredje exempel kan du själv testa genom att lägga till mix06info@hotmail.com som kontakt i Messenger och sedan skicka meddelandet "menu" till din nya kontakt. Du kommunicerar då med en Bot som kan ge dig information om Mix06. Testa till exempel "activities" genom att skriva detta, eller genom att välja det menyalternativet efter att ha skrivit "menu", och välj till exempel en restaurang på The Strip för att få upp ett Messenger Activity-fönster med en karta från Virtual Earth som visar restaurangen.

I går lanserade Microsoft också en ny ingång på MSDN med mer information om det här: Windows Live Developer Center.