Jag väntar förväntansfullt på min nya telefon som förhoppningsvis dyker upp runt månadsskiftet augusti september.

Varför skall man använda Inversion of Control i sin kod? Precis som Jeffery Palermo skriver på sin blogg Inversion of Control is NOT about testability så handlar Inversion of Control inte om testbarhet utan att man vill inte skapa kopplingar mellan konkreta klasser utan mellan en klass och ett kontrakt(interface) för en annan.

Vinsterna med att använda Inversion of Control är många och testbarheten är en av dessa men bör inte vara det ända syftet.

En av den största anledningen till att jag gillar Inversion of Control är att man kan tillämpa en av Lean Software Developments sju principer Decide as late as possible. Genom att bara koppla sig till ett kontrakt så behöver man inte bestämma sig hur man skall implementera kontraktet förän det är absolut nödvändigt. Man kan till och med ändra på implementationen i efterhand utan att påverka kopplingen mellan klasserna. Jag använder detta ofta genom att göra en mycket enkel och snabb konkret implementation av ett kontrakt för att senare gå tillbaka och förbättra implementationen när det behövs.

Ett av mina favoritexempel på detta tillvägagångssätt var när vi var i processen att bygga en WindowsForms klient som skulle kommunicera med en applikationsserver. Vi hade delar av applikationsservern på plats men inte hela infrastrukturen för att kommunicera över nätverket. För att utvecklaren av WindowsForms applikationen inte skulle behöva vänta på att infrastrukturen var på plats så definerade vi kontrakten som fanns mellan klienten och servern. Servern implementerade kontraktet och klienten använde sig direkt av serverkoden under större delen av utvecklingen. När sedan infrastrukturen för kommunikationen på servern vara på plats så implementerade vi proxy klasser med samma kontrakt men som använde sig av kommunikationsinfrastrukturen. Klient koden behövde inte ändras utan endast en inställning som talade om vilket konkret implementation av kontraktet som skulle användas och vips så blev klienten en tunn klient som kommunicerade med WebServices istället för att vara direktkopplad till databas m.m. på klientsidan.

Jag har nu anmält mig till 2xSundblads certifieringsprogram för Certifierad Mjukvaruarkitekt med specialinriktning Microsoft-teknologier.

Förhoppningsvis så kommer jag att vara en Certifierad Mjukvaruarkitekt under första delen av 2009.

Efter att provat fram och tillbaka en hel del under sommaren så har jag kommit fram till att det inte var någon bra idé att använda de manuella testerna som grund för FIT tester.

Detta beror på att de manuella testerna i Visual Studio använder sig av sk. "Archived Web Page". En Archived Web Page är en html sida innehåller bakar in bilder m.m. som sidan innehåller i html:en. Detta gör att FIT har problem att parsa html koden.

Min tanke är nu att bygga en wrapper runt FIT/FITNesse testrunner som skall underlätta att skapa generiska tester i Visual Studio som använder vanliga HTML sidor, alternativt en URL till en FITNesse wiki som underlag. Wrappern skall förhoppningsvis minska antalet parametrar som måste matas in för varje FIT test så det inte blir för mycket jobb att underhålla testerna i Visual Studio.

Jag har under en längre tid funderat på hur man skall kunna jobba med FIT tester eller likande tester i Visual Studio Team System och i Team Foundation Servers automatiska tester.

Min första fundering var att skapa Generic Tests som kör FITNesses test runner mot vår FITNesse wiki. Detta skulle funka men skulle innebära att man skulle behöva skapa ett Generic test i Visual Studio för varje FITNesse test alt. varje test suite. Känns som det skulle bli krångligt att administrera eftersom det kanske ändringar på Wikin och man glömmer att uppdatera de generiska testerna

Min andra fundering blev då att skapa en egen testtyp i Visual Studio där man skapar en HTML fil för varje FIT test med en egen filändelse. Nackdelen är att det inte är så väl dokumenterat hur man skall göra detta i SDK:n och det skulle innebär underhåll av koden för denna nya testtyp. I mina undersökningar om hur jag skulle kunna göra detta så slog det mig, manuella tester är ju HTML dokument! Här av mitt förslag till lösning.

När ett nytt test skall skrivas för en befintlig funktion, eller alldra helst innan en ny funktions skall utvecklas, skapa ett manuellt test.

Skriv testet som ett normalt manuellt test fall med beskrivande text och steg för hur man genomför testet. Kriterier för hur man bedömer om testet är gick rätt eller fel måste finnas med.

Nu kan det manuella testet börja användas som en del av testprocessen och testresultaten kan lagras i Team Foundation Server för rapportering m.m.

När man sedan vill omvandla detta manuella test till ett FIT test som kan köras automatiskt så börjar man att skriva om det manuella testet och lägger in sk. FIT tabeller istället för text i steg form.

Utvecklarna skapar sedan FIT fixturer för tabellerna som är skrivna i det manuella testet om det inte redan finns FIT fixturer som kan användas.

Sedan skapar man ett Generic test som använder test runnern för FIT och pekar den mot filen för det manuella testet.

Nu har man både ett manuellt test som man kan köra om man önskar samt man har ett FIT test som man kan köra ett i taget eller som en del av det automatiska bygget.

Den största nackdelen med denna lösning är att det inte på något enkelt sätt går att visa resultatsidorna för de tester som går fel utan att skriva en egen wrapper runt test runnern för FIT.

Den andra nackdelen jag har sett är att Word som är default editorn för de manuella testerna genererar HTML som inte är så bra tillsammans med FIT.

Jag skall fortsätta att forska mer på detta ämne och återkommer om jag gör framsteg.

Jag har under en längre tid varit ganska intresserad av att använda en ORM produkt när jag utvecklar applikationer. Tyvärr har jag ännu inte tagit mig tid att sätta mig in i någon produkt och använt den i något projekt. Jag lockas dock mer och mer av idén ju mer jag jobbar med rika domän modeller. Databasen känns liksom endast som ett sätt att persistera mina objekt och inte längre som kärnan i applikationen. Detta har bara förstärkts efterhand som jag skriver mer och mer unittester. Jag jobbar ännu inte test-first men försöker skriva så mycket tester som möjligt i direkt samband med att jag skriver koden

Jag har dessutom aldrig har haft något större intresse av SQL. Det har oftast fallit mig mer naturligt att lägga mer av affärslogiken i kod än i SP, triggers m.m.

Jag har inte riktigt kännt mig 100% på att använda open source produkter som nHibernate och de kommersiella produkterna har oftast inte varit i den prisklass att mina kunder har varit intresserade. Men nu när Microsoft jobbar med sitt Entity Framework så kan det bli enklare att motivera för kunderna.

Även om jag tycker att Entity Framework i version 1 inte är vad jag söker eftersom affärsobjekten måste implementera diverse interface som binder dom till infrastrukturen, så tror jag att det kan vara en bra början för applikationer som idag är hårt kopplade till databasen. Sk. "Form over data" applikationer tror jag skulle passa utmärkt för att använda Entity Framework v1.

För applikationer med mer rika domän modeller så skulle jag nog välja nHibernate eller vänta på version 2 av Entity Framework.

Jag tror att det har blivit dags för mig att försöka använda en ORM lösning i något av mina kommande projekt under hösten för att prova om det funkar i praktiken för mig.

Jag surfade förbi denna länken om Windows Mobile 7 To Focus On Touch and Motion Gestures.

Jag har ingen aning om det ligger någon sanning bakom detta men intressant läsning oavsett.

Windows-Mobile-7-Overview by blognc on Zooomr

Johan Lindfors skriver om kvalitet och undrar om man som kund skall ställa krav på olika mättal som "code coverage" och "maintainability index" i sina mjukvaruprojekt.

Jag menar att det är kontra produktivt att ställa upp denna typ av krav. Mary och Tom Poppendieck skriver i sin bok Implementing Lean Software Development From Concept to Cash att:

"Det man mäter det får man" (min fria översättning)

En av grundpelarna i Lean Software Development är:

Optimize the Whole

Kombinerar man ihop dessa så menar jag att det man skall mäta istället för "code coverage" och "maintainability index" så bör man mäta levererad kundnytta/affärsvärde.

Mättal som "code coverage", "maintainability index", "cyclomatic complexity" kan man dock följa upp under projektets gång och använda som ett diskussionsunderlag för att driva utvecklingen mot en bättre design och bättre coverage av koden för unit-, integration- och acceptans-tester. Problemet är dock att bara för att man t.ex. har en hög coverage så innebär det inte att man har unit tester som testar tänkta funktionaliteten. När jag kör kodanalys på delar av vår kod så kan kod som är två skiktad och som är mycket svår att testa få ett högre "maintainability index" än vår vältestade och välstrukturerade kod. Är man då som kund inte insatt i att detta kan uppstå så är det lätt att man får en felaktig uppfattning om vad som är bra och dålig kod.

Min slutsats: Skall man mäta så är det levererat affärsvärde per iteration som är intressant.

The Net Objectives Pattern Repository är ett mycket bra patterns repository som är skapat och underhållet av Net Objectives.

Hit kommer jag att länka när det gäller patterns.

Ja, inte som man hade tänkt sig direkt! Jag kom inte änns till start!

Tyvärr fick jag problem med sätet(baken) under min resa till Tech Ed 2008. För mycket sittande eller värmen kanske. Problemen försvann i torsdags men jag vågade inte chansa och cykla ändå eftersom jag troligen skulle ha minst 12 timmar på cykeln denna gången pga. min dåliga form.

Det gick desto bättre för Hans-Peter som jag skulle ha cyklat med. 9:22 är en kanon tid!

Grattis!

En ny bok har adderats till Matin Fowlers Signature Series som verkar intressant för mig som är en sopa på HTML: Refactoring HTML: Improving the Design of Existing Web Applications

Efter ca två och ett halvt år på Valtech så har jag nu valt att prova mina vingar hos Concordia Bus IT som IT Affärsarkitekt. Jag har under mina dryga två år för det mesta jobbat hos Concordia Bus IT som systemutvecklare/systemarkitekt. I denna nya rollen kommer jag att flytta in mer i affärsutvecklingssidan och arkitektrollen för ConcordiaBus egenutvecklade system för koncernbolagen.

Samtidigt som jag ser fram emot de nya utmaningarna på Concordia Bus IT så är det tråkigt att lämna ett så spännande och utvecklande företag som Valtech. Jag tror att jag har utvecklats mer de åren jag har jobbat på Valtech än de ca 9 åren innan som jag har jobbat med systemutveckling. Team känslan och den otroliga kompetens som finns hos medarbeterna är otrolig! Jag rekommenderar verkligen Valtech som arbetsgivare, speciellt för dig som är intresserad av Agile systemutveckling.

Min sista arbetsdag på Valtech är den 29 augusti.

Jag kan väl sammanfatta mitt Tech Ed 2008 Developer i Orland som en givande konferens. Inte så mycket nyheter men destå mer matnyttig information om nyvarande produkter och tekniker.

Det jag tyckte var det coolaste på konferensen var helt klart Visual Studio Team System for Architechts med bl.a. Layer Diagram delen.

Sessionerna om Visual Studio Team System i huvudtaget var nog de sessionerna jag fick ut mest av. Sessionerna kring Sync Framework var också givande eftersom jag just nu titta på hur vi kan använda det i en kommande lösning.

Diskussionerna med de olika talarna efter sessionerna och i korridorerna var också mycket givande.

Att sedan familjen var på plats och vår lilla mini semester gjode ju saken inte desto sämre. Jättehärligt att kunna komma hem till fru och barn på kvällen.

Allt som allt toppen bra. Hoppas få åka nästa år igen.

Speaker(s): Roy Osherove

Tyvärr missade jag större delen av denna sessionen för jag var tvungen att åka till hotellet.

Roy är alltid bra och delarna jag hörde i slutet om TDD var givande och inte minst hans avslutande sång :-)

Speaker(s): Brian Noyes

En intressant session om Windows Workflow

Speaker(s): Richard Campbell, Kent Alstad

Att en lösning är skalbar betyder inte att prestandan är bra, bättre skalbarhet betyder oftast att prestandan för en enskild webbsida blir sämre.

Skalning handlar om att det skall inte blir dyrare per ny användare ju mer ett system växer samt att man skall minska skillnaden mellan sämsta och bästa prestandan för en webbsida i sin lösning.

Strategier för skalning:

• Specialisering - dela upp applikationen i olika delar så att man kan addera resurser till de delar som behöver mer resurser eller de delar som är viktigast för din lösning.
• Distribuering - öka antal resurser som hanterar problemet

Man kan välja den ena eller den andra men oftast är det bästa att göra båda.

Specialisering

Bryt ner applikationen i olika beståndsdelar som t.ex. sök och köp så att dessa kan skalas separat. Lägg statiskt material på dedicerade delar då dessa oftast kan skala väldigt mycket med lite resurser(att ha ASP:NET installerat på IIS försämrar IIS prestanda för bilder m.m. avsevärt).

Tänk på att om man cachar stora datamängder så gör en dubbelkoll innan man hämtar från databasen så att man inte har flera trådar som hämtar samma data.

        If cacheObject Is Nothing Then
            SyncLock lock
                If cacheObject Is Nothing Then
                    cacheObject = getfromdb()
                End If
            End SyncLock
        End If

Använder man en lastbalanserare testa alltid och se vad som händer om man kopplar ur en server.

Använder man sticky sessions så betyder det att om man förlorar en server så förlorar man alla användarnas sessioner på den servern. Försök att undvika sticky session utan använd någon form av session server eller distribuerad sessionhantering.

Skallning i dataaccess lagret kan göras med bland annat:

• uppdelning av data – data som inte ändras läggs i separata tabeller
• dela upp läs och skriv – ha separata databasservrar för att läsa och skriva.

En mycket bra session.

Speaker(s): Udi Dahan

Udi´s föreläsning om hur man kan bygga skalbara webblösningar med asynkron arkitektur var en intressant föreläsning även om jag tycker han främst hade ett brandtal varför asynkorna lösningar var så mycket bättre än synkrona lösningar istället för kontret visa hur man skulle implementera en asynkron webb arkitektur. Hade sessionen varit dubbel så lång så kanske han hade hunnit kommit in på hur man faktiskt skulle bygga sin webbarkitektur på en asynkron arkitektur.

Grundidén som ha framför i alla fall var att man skulle sätta upp sin webblösning så att när en användare efterfrågade en viss resurs(visst innehåll) så skall ett meddelande skickas till det underliggande affärslagret som i sin tur skickar ut ett svar till samtliga servrar som är intresserad av svaret genom en pub/sub lösning. De som är intresserade skulle sedan cacha detta svaret lokalt. Användaren som efterfrågar resursen får vänta på lämpligt sätt på att resursen skall bli tillgänglig för att sedan visa den samma. Det Udi inte gick in på var hur detta väntandet skulle gå till. Jag ställde dock frågan till honom efter sessionen och han ansåg att AJAX var den bästa lösningen idag om man inte byggde en anpassad vänta mekanism med hjälp av http redirect t.ex.

Hans lösning låter ju ganska enkel och kan säkert vara en bra model om man bygger sin arkitektur på denna modellen från början.

Jag kommer definitivt titta mer på detta själv och kanske kan det bli en del i en framtida lösning.

Brian Harry visade upp "Rosario" versionen av Team System for Architects på Keyniten här på Tech Ed i tisdag. Han har nu skrivet en blogg post om detta.

Bilden här visar det sk Layer diagram och används för att modulera en applikations lager samt möjliggör validering att ens klasser håller sig till denna modellen. I "Rosario" planerar man till och med att kan skall kunna ha en Check in Policy som hindrar dig att checka in om din kod inte följer den modullerade arkitekturen. Mycket coolt och användbart tycker jag.

Några andra delar som jag har sett på i "Rosario" här på Tech Ed är:

• Sekvensdiagram som kopplas kan kopplas mot modellerade klasser eller mot den konkreta implementationen. Genom att synka modellen mot koden så hålls diagrammen uppdaterade.
• Use case diagram. Vanliga uscase diagram i Uml men med möjligheten att koppla dessa use cases till Work Items vilket gör att man sedan kan koppla Use caset mot koden som associeras med Work Item. Om man sedan associerar sin unittester och övriga tester i TFS med samma Work Items så kan man se vilken funktionalitet som har tester samt om något test skulle fallera vilket use case i förlängningen som har defekter. Coolt!
• Activity diagram. Har inte sett något speciellt med detta än men bra att ha ur ett modelleringsperspektiv
• Logical Class diagram. Klassdiagram för modellering som sedan kan kopplas mot konkret implementation.

Brian visade också lite verktyg för att visa beroenden som verkade vara tagna från NDepend som också kan vara otroligt användbara.

Jag hoppas bara Microsoft gör så att alla dessa modeller går att åtminstånde läsas av alla team medlemmar oavsett vilken version av Visual Studio man har.

Eftersom jag är väldigt intresserad av test så har jag också för en del disussioner med folk från utvecklingsteamet för Test editionen av "Rosario". Dom har nämt sådant som att dom jobbar på verktyg för funktionstester som skall kunna spela in GUI händelser som sedan kan spelas upp igen som egna automatiska tester eller som en snabbspola funktion för manuella tester. Dom pratar också om att det kommer verktyg som inte kräver Visual Studio för att kunna göra olika typer av tester för att minska bariären för testerna att komma igång.

Jag ser verkligen fram emot "Rosario" men det lär väl ta minst något år till innan det är dags för lansering.

Speaker(s): James Newkirk

En mycket bra session. Mycket PPT men med bra innehåll.

TODO: Gör en sammanfattning från PPT