Presseomtale og usergroup i Odense

by DotNetNerd 30. May 2008 16:39

Presseomtale 

Så nåede vi til den tid på året hvor der blev offentliggjort årsresultat, og pressen var ikke lang tid om at skrive om hvor godt det er gået det seneste år - som det kan ses på TV2fyn, Bureaubiz og fyens.dk.

Update: også børsen, erhvervsbladet og computerworld har nu bragt artikler om årets resultat :-) 


Det har også været et spændende og hektisk første år - men det er også sådan jeg helst vil have det :) Det ser heldigvis ud til der fortsat er masser af spændende opgaver og udfordringer fremover, så vi kan vidst godt tillade os a være lidt glade.

"Its a nerd!" Onug blev født!

Torsdag var jeg på hotel Radisson Sas til Microsoft Community arrangement hvor hovedformålet var at få startet en .NET usergroup i Odense. Opbakningen til initiativet var fantastisk, og især det at der var en flok fra Anug der var kommet forbi for at hjælpe os igang var helt fantastisk. Idag (fredag) fik jeg så luftet det for min chef, og nu ser det ud til at vi bliver sponsorer for gruppen, og han var bestemt positiv over for muligheden for at vi kan benytte vores lokaler. Det er jo altid fedt at møde nogle ligesindede ildsjæle, så jeg glæder mig meget til at se hvordan det skrider frem.

 

Tags:

MIX Essentials

by DotNetNerd 22. May 2008 20:49

Arrangementet 

Onsdag inden jeg fik set Manchester United blive kronet som europas konger, var jeg til MIX Essentials i Cinemaxx i København. Vi tog afsted 4 mand høj, eller to mandlige udviklere og to kvindlige grafikere for at være helt præcis, for at lære lidt mere om Silverlight, og søge inspiration til hvordan vi kan benytte det i vores virksomhed. Uden at jeg gik derfra med hænderne over hovedet, synes jeg det var et udemærket arrangement. Niveauet var måske lidt lavere end forventet og der var knap så mange rigtige eksempler som vi kunne have ønsket os, men vi fik da set nogle bud på hvad Silverlight kan bruges til. Mere vigtigt for mig ihvertfald var at vi fik nogle links og navnene på nogle tools sådan at jeg har noget mere at gå videre med.

Links til inspiration

En af de ting jeg ikke selv havde hørt så meget til var deepzoom og dertil værktøjet deepzoom composer, der er i beta og kan hentes direkte hos Microsoft. Deepzoom giver som navnet antydet mulighed for at man kan lave virkelig store billeder i virkelig høj kvalitet, som downloades delvist til klienten sådan at der kun sendes de detaljer der er nødvendige i forhold til det gældende zoom niveau. Et fedt eksempel på dette og hvad det kan bruges til kan ses på hardrockcafe.com under memorabelia.

Af tools der blev fremvist synes jeg især KAXAML ser lækkert ud. Det er et lille letvægts værktøj til at arbejde med XAML i et splitview. Helt sikkert et tool jeg selv skal lege lidt med fremover :) Et andet tool der så spændende ud er Silverlight Spy der er til at udforske hvordan Silverlight applikationer er skrevet. Og som med alle andre teknologier er der naturligvis også en WPF Profiler, som nok skal vise sig uundværlig på et tidspunkt, som den slags tools ofte viser sig at gøre.

Sidst i den mere futuristiske afdeling så og hørte vi lidt mere til surface som mange umiddelbart forbinder med "a big ass table". Naturligvis er perspektivet i teknologien meget mere og andet end den prototype som det her bord er - men som så tit før ser den almindelige forbruger ikke længere end på det der er lige foran dem. Jeg tror imidlertid nok teknologien skal vinde frem, og håber da også selv en dag at komme til at lave en surface baseret løsning.

Tags: ,

Test driven development – my two cents.

by DotNetNerd 11. May 2008 13:07

Test driven development – my two cents.

Unit testing er en metode til at teste at en individuel enhed kildekode fungerer korrekt.  Egentlig har unit testing været brugt i flere årtier, men begrebet har den seneste tid udviklet sig til lige at være et buzzword der er oppe i tiden – især som metodik i form af Test Driven Development. TDD bliver der blogget enormt meget om for tiden – og netop derfor vil jeg ikke kaste mig ud i at forklare hvad det er, men lader det være en forudsætning for at læse videre.

Udbredelsen af TDD/unit testing er en stor del af grundlaget for at Microsoft har kastet sig over at lave MVC frameworket, som et alternativ til den klassiske måde at udvikle ASP.NET applikationer på.

Rob Conery der står bag SubSonic, og nu er ansat hos Microsoft er for tiden i gang med en serie på sin blog som han kalder MVC storefront, hvor han går efter at blive klogere på både MVC og TDD. En sjov detalje han har bemærket er at alle i miljøet snakker om ”at hvis man nu er purist skulle man gøre sådan og sådan”, men han har umiddelbart ikke kunne finde nogen der direkte er purister inden for TDD.

Personligt kan jeg godt se anvendeligheden i TDD, men jeg mener helt klart at der er alt for meget hype om det, og at det bestemt ikke er alting det er velegnet til. Min holdning skyldes helt enkelt to ting; for det første at man ofte ikke har en god nok beskrivelse af hvad man skal udvikle til at man kan skrive en rigtigt god unit test, og for det andet at det ikke altid er noget godt kvalitetsmål. Med det mener jeg at det ikke er alting man kan teste ved hjælp af unit tests, både fordi eksempelvis usability slet ikke er noget mål for en unit test, men også fordi omkostningerne ved at skrive og vedligeholde tests kan være større end gevinsten. Dette er i nogen grad en pointe ”Joel on software” også har fremført, blandt andet ved en tale på Yale.

Jeg laver selv en del applikationer, hvor beskrivelserne er sparsomme, og udviklingen derfor ikke kan undgå at blive ”trial and error” baseret. Ikke forstået som i at der er masser af ”fejl” som sådan i koden (selvfølgelig er der også det), men fordi kundens ønsker ændrer sig markant i løbet af processen. Teoretikeren vil nok sige at så er analysen af projektet ikke god nok, en pointe der ikke går helt tabt på mig, men der er mange kunder hvor det simpelthen ikke er muligt i praksis. Let the religious battle between theory and pragma begin!

Min anden pointe med at det ikke er alting der lader sig unit teste, er selvfølgelig også et spørgsmål om vilje. Brugerflader og sprocs er vanskelige at teste, og selvom man gør sig en masse anstrengelser for at lave unit tests af disse ting er værdien mindre - i forhold til at kunne teste ”rene funktioner”, med kendt input og output. En sidste observation jeg har gjort mig, er at fejl oftere skyldes integrationsproblemer end direkte logiske fejl – og i systemer hvor det er tilfældet er integrationstests i virkeligheden mere formålstjenlige.

Selvom jeg måske nu lyder meget skeptisk, synes jeg at unit tests og TDD er rigtigt godt, til de ting det rent faktisk er opfundet til. Min indsigelse er blot imod den megen hype der er, da heller ikke det er nogen Silver bullet, og jeg føler at anvendeligheden af unit tests har det med at blive overdrevet.

Frameworks og tools – de små måske vigtige forskelle.

De fleste jeg har snakket med der har arbejdet med unit testing kender NUnit frameworket, som nok er det mest udbredte framework til unit testing i .NET. Frameworket er oprindelig portet fra JUnit og har efterhånden en del år på bagen.

Der findes imidlertid også to andre udbredte open source  alternativer som er MbUnit og XUnit – forskellene imellem de tre frameworks er relativt små, men som man siger ”god is in the details”.

MbUnit omtales som NUnit på crack, og er et framework der er udviklet til at være mere udvidelsesvenligt end NUnit er. Det er i dag nok det mest advancerede unit testing framework og giver blandt andet mulighed for at man via attributter beskriver data der skal passes til en testmetode, og derved kan den samme metode kaldes flere gange hvor forskellige grænseværdier testes.

[RowTest]
[Row("Christian", "123")]
[Row("Christian", "", ExpectedException = typeof(InvalidUserException))]
[Row("", "123", ExpectedException = typeof(InvalidUserException))]
[Row("Christian", "qwerty", ExpectedException = typeof(InvalidUserException))] 
public void CheckUserLogins(string name, string password)

Det har desuden også en feature til at rulle database ændringer tilbage ved hjælp af attributterne SqlRestoreInfoAttribute, RollBack og RestoreDatabaseFirst.

XUnit findes på codeplex, og det er udviklet med henblik på at skulle passe bedre ind i .NET miljøet, samtidig med der er ryddet op i attributter og assertions med henblik på at få pænere testkode. Jeg kan personligt virkelig godt lide at det gør brug af generics, og at det giver mulighed for at lave en slags aspect oriented programming.

Generics bruges blandt andet til fixture setup, sådan at man ved at bruge IUseFixture<T> kan passe klasser til ens testmetoder, som man så kan arbejde med.

public class MyTests : IUseFixture<MyFixture>, IDisposable
{    
    public void SetFixture(MyFixture data)    
    {                
        data.SomeMethod();    
    }
}

Aspect oriented programming fungerer ved at man laver ens egne attributter ved f.eks. at extende BeforeAfterTestAttribute, som blot er at overskrive et par metoder.

public class PrepreDatabaseAttribute : BeforeAfterTestAttribute
{    
    public override void Before(MethodInfo methodUnderTest)    
    {        
        // Do your pre-test stuff    
    }    
    public override void After(MethodInfo methodUnderTest)    
    {        
        // Do your post-test stuff    
    }
}

Udover et decideret testframework skal man også bruge et tool til at udføre ens tests og give overblik over hvad der går godt og hvad der fejler – de berømte grønne lamper man nyder at se lyse når man benytter TDD. NUnit har den fordel at der følger et lille separat tool med der kan lige præcis det, og som virker ganske fint til de flestes behov. Til XUnit er der et lignende tool under udvikling, men det er stadig eksperimentalt og virker ikke just som et færdigt tool endnu.

Alle 3 frameworks kan imidlertid også bruges sammen med TestDriven.NET og ReSharper , som begge er bedre bud hvis man vil have en ordentlig brugsoplevelse.

 TestDriven.NET er et add-in til Visual Studio, som giver mulighed for afvikling af unit tests, og er det tool flertallet bruger. Jeg må dog erkende at jeg synes TestDriven.NET er relativt dyrt, taget i betragtning af at det startede som et gratis værktøj og i bund og grund stadig er et simpelt add-in.

Resharper er også et Visual Studio add-in som man kan skaffe til rundt regnet samme pris som TestDriven.NET, men man får bare meget mere med i pakken, da det blandt andet også tilbyder hjælp til refactoring, formattering og kode analyse. Som det fremgår er jeg selv faldet lidt for ReSharper, selvom jeg var lidt skuffet over at det endnu ikke er klar i en .NET 3.5 udgave, så kodeanalysen fejler hårdt på LINQ queries o.lign. En ny version målrettet .NET 3.5 skulle dog være på trapperne, så jeg må bare leve med at slå kodeanalyse fra indtil da.

Test af sprocs – der hvor det bliver mere vanskeligt.

Når jeg nu tidligere har nævnt at jeg mener sprocs er vanskelige at teste, skylder jeg også at beskrive hvordan man kan gøre det - og uddybe hvad jeg mener med at værdien i mine øjne er mindre end ved test af mere isolerede funktioner.

Jeg læste i går en ganske god artikel i MSDN magazine omkring brugen af LINQ to SQL til test af sprocs. Der var egentlig ikke et perspektiv der i første gang havde slået mig, men det er egentlig klart at LINQ to SQL er godt til at teste sprocs på meget lettere vis end det var muligt i tiden pre-LINQ. Helt enkelt består sproc tests af.

·         Klargøring af database, så den er i en velkendt tilstand.

·         Afvikling af sproc.

·         Test af databasens tilstand er som ønsket.

De tre trin lyder simple nok, man har naturligvis en række komplikationer i forhold til det her med databasens tilstand. Det letteste er sandsynligvis at arbejde med en tom kopi af databasen, som gerne er separat fra ens anden test/udviklings database der typisk indeholder en røvfuld ”real world” data. Ved hjælp af LINQ kan man så faktisk med meget få linjer kode slette alle data i en tabel, og indsætte de data man ønsker som grundlag for testen.

Ligeledes kan man i LINQ afvikle den sproc der skal testes, og så er der egentlig ”bare” tilbage at teste databasens tilstand efterfølgende. Et godt tip fra artiklen er at hente alt data i en tabel, hashe det ved hjælp af eksempelvis en MD5 hash. Resultatet kan så meget enkelt sammenlignes med en hash som man udregner ved udformning af testen – noget der kan være en kende besværligt, da det at tage hashen første gang man afvikler koden kun beviser at resultatet er det samme ved efterfølgende afvikling og ikke nødvendigvis om det er korrekt.

Få overblik med Unit testing af sprocs

En anden måde at bruge unit tests på i forbindelse med sprocs, som jeg selv har været med til at implementere er at skrive en parser der undersøger hvilke sprocs man kalder fra sin kode og sammenligne med de sprocs der rent faktisk findes i databasen. Selvom det ikke er nogen test af funktionaliteten som sådan, kan det på store projekter bruges til at teste om de sprocs man kalder findes og omvendt om man har sprocs der ikke længere bliver brugt.

Lidt i samme boldgade kan man skrive en unit test der læser ens sprocs ud, og gemmer dem i databasen igen - giver dette en exception er det en god indikation af at sproc’en er knækket. Igen er det ikke nogen gylden løsning da man ikke finder logiske fejl og ikke engang alle slags fejl på den måde. Det er imidlertid et simpelt værktøj, som har sin berettigelse i at det kan give overblik og finde alvorlige problemer med meget simple midler.

Tags: ,

Who am I?

My name is Christian Holm Diget, and I work as an independent consultant, in Denmark, where I write code, give advice on architecture and help with training. On the side I get to do a bit of speaking and help with miscellaneous community events.

Some of my primary focus areas are code quality, programming languages and using new technologies to provide value.

Microsoft Certified Professional Developer

Microsoft Most Valuable Professional

Month List