Embracing HTTP in the .Net – Glenn Block
Det har efterfrågats en närmare kontakt med http i WCF det finns nu att ladda ner på http://wcf.codplex.com Det man får är bla en stark typning i accessen till http stacken. Något som jag kanske inte dirket känt ett behov av, än…

Men det som också erbjuds i och med det är att man kan koppla på processors på den inkommande ellet utgående http strömmen. I och med det så kan man utan att ändra på en befintlig metod, som tex returnerar en IEnumerable, erbuda olika content types att efterfrågas tex json eller odata. Du gör inte detta på din metod utan konfigurerar detta på applikationsnivå.

Android outside a phone – Chris Hughes
Jag hade hoppas på några coola demos. Men tyvärr hade blivit av med sina prylar (inte här i Sverige) så det blev det inte. Utan presentationen var tekniktung på lågnivå blan komponenter och C kod. Men tydligt blev att Android är lättare och betydligt billigare att använda för att styra diverse devices. Kul var det när Chris berättade om att han hade laddat in Android på en iPhone 3G och kopplat den till en dammsugare. Han kunde nu schemalägga städningen. Dammsugaren hade hela planlösningen klart för sig. Men framför allt så kunde dammsugaren jaga katten

Unleash Your Domain – Greg Young
Greg berättade om deras applikation som kör över 10 00 transaktioner över en rik modell. Och nyckeln är att dem använder sig av state transitions. Det handlar också om en CQRS modell där för att förenkla det hela Commands och Query har varsin modell. Query delen använder sig av en databas i första normalform. Medans Commands delen använder en databas i tredje eller fjärde normalformen. Klart spännande och man får läsa på mer… Bla här kan man läsa mer http://elegantcode.com/2009/11/11/cqrs-la-greg-young/ och hur mycket som helst ska finnas här http://cqrsinfo.com/

Making Java and .Net play well together – Ted Neward
Ted pratade om varför detta kan behövas och han presenterade ett antal olika metoder beroende på vilka krav man har på snabbhet tex. Spontant kan man tänka sig saker som att använda en databas för att flytta information eller BizTalk och MQSeries (om man nu har dem produkterna). Men det går också att lösa out-of process med tex sockets eller RPC och web services. Det finns även lösningar för In-process med div verktyg tex IKVM och JNBridge.

//Mattias

Det är en SharePoint 2010 sandboxed solution som tillhandahåller ett prydligt interface för att se burndown, planera sprints och storyboard där man via dran’n'dropp kan starta stories, sätta de som completed osv.

Det finns en trialversion att ladda ner, produkten kostar $150 för en sitecollection-licens.

Eric Evans om 2015

Torsdagen har varit mycket inspirerande. Den startade med en keynote av Ralph Johnson (en av Gang of Four) som satte mönster i objektorienterad design på kartan. Ralph diskuterade hur utveckling skiljer sig åt när en programvara skall leva länge kontra dö snabbt. Skillnaderna är stora. En levande programvara behöver underhållas med varsam hand för att kommande generationer av utvecklare skall kunna arbeta vidare.

Kevlin Henney (delförfattare till Pattern Oriented Software Architecture-serien av böcker) diskuterade mönster, och hur viktigt det är att känna till konsekvenserna av att applicera ett mönster. Särskilt de negativa konsekvenserna. Singleton är förutom ett designmönster även en whiskysort, och enligt Kevlin är spriten att föredra framför designmönstret när man designar system…

Eric Evans (Domain Driven Design) höll två mycket intressanta föredrag, dels om framtiden (What will not change by 2015) så som han såg den, dels om hur man kan arbeta strukturerat med DDD i en Agil uvecklingsmiljö (Folding design into an Aglie Process). Den sistnämnda presentationen var av mycket hög kaliber, med bra tips om vilka signaler man kan lyssna efter när det är dags att ta ett steg tillbaka för att arbeta fram en bättre design. Presentationen filmades, så jag hoppas den kommer upp på nätet så alla intresserade kan ta del av den.

Mer från QCon kommer!

/Emil

Lean-utveckling handlar i mångt och mycket om göra lagom mycket arkitektur ”up front”, att ta svåra beslut sent, bara utföra arbete som addera värde mm. Detta i kombination med DCI där man tydligt separerar Data (domän) från Context (use cases) och Interaction (Roller) ger en kraftfull mix av användarupplevelse och tillräckligt kraftfull arkitektur för utveckling. Jim Coplien engagerade och underhöll under hela dagen.

Brian Sletten visade hur REST/ROA ger oss möjligheter att arbeta med vår data på helt nya sätt. Dessutom snabbt ( datan kan göras cachebar). Och enkelt (web-baserade protokoll för integration). Den semantiska webben är på gång (igen), den här gången med ROA och REST som drivkrafter. Brian imponerade med demonstrationer av enkelhet och kraftfullhet i Restlets och Netkernel. Mycket av detta finns att läsa om i Roy Fieldings avhandling från 2000: Architectural Styles and Design of Network-based Software Architectures.

Mer från QCon kommer!

/Emil & Stefan

Team som förlitar sig på manuella tester inser snart att det är svårt att köra korta sprintar där det krävs omfattande manuella tester i varje sprint. Teamet kommer också att inse att om man inte tar tag i problemet lär situationen bli värre i nästa sprint, och i nästa…

Mike Cohn skriver om detta i sin blog och kallar det för projektets ”Manaul Test Technical Debt”.  Projektet har en sk teknisk skuld, d.v.s det finns en kostnad relaterad till att inte göra sig av med de manuella testerna. Lösningen är att automatisera testerna, men detta kan vara en minst sagt omfattande uppgift om man sedan länge har kört manuella tester.

Team i denna situation kan enligt Mike Cohn hantera problemet i tre steg:

1. Stop bleeding
2. Stay current
3. Catch up

Det första steget går ut på att få kontroll över situationen och se till att man kan behålla sprintlängden och samtidigt genomföra testerna inom sprinten. Börja med att identifiera de tester som tar längst tid och är lättast att automatisera. Fundera även på om det finns andra testaktiviteter som tar lång tid och går att automatisera, till exempel installation i testmiljö eller konfigurering av testdata.

I denna fas bör teamet även definiera en teststrategi om det inte redan finns en sådan. Syftet med en teststrategi är att göra ett antal antaganden om vilken typ av tester man ska ha och hur man ska exekvera dem. Målet är att säkerställa en önskad kvalitetsnivå i systemet och samtidigt minimera den tid det tar att testa systemet.

När teamet har effektiviserat de manuella testerna och börjat automatisera vissa enkla tester, är det dax att gå vidare till nästa steg. För närvarande inför vi nya manuella tester i varje sprint, men vi klarar av att köra dessa inom sprinten eftersom vi har effektiviserat testprocessen och automatiserat de tester som tar längst tid. Nästa steg är att skriva automatiserade tester för all ny funktionalitet som levereras i sprinten. När man gör detta ökar inte den tekniska skulden längre, men den minskar inte heller.

Till slut kan teamet gå in i den sista fasen och det är att börja automatisera de återstående testerna. Börja att automatisera de tester som ger störst nytta i förhållande till den tid det tar. Följande bild speglar omfattningen av att automatisera olika typer av tester.

Källa: Acceptance test engineering guide

Enhetstester syftar till att verifiera en begränsad och isolerad kodlogik, där testet ersätter ”externa” beroenden som till exempel SharePoint eller en databas. Enhetstester skrivs av utvecklare och körs i ett testramverk, som till exempel Microsoft Visual Studio Team System eller NUnit. Men det krävs en hel del att införa enhetstester i ett befintligt system, och det beror dels på systemets arkitektur men även den kompetens och motivation som finns inom teamet.

Integrationstester är programmatiska tester som skrivs av utvecklare eller testare, men som till skillnad från enhetstester inte körs isolerade. Syftet med integrationstester är att verifiera att integrationen mellan olika lager och komponenter fungerar. Jämfört med enhetstester är omfattningen något mindre men och andra sidan ökar komplexiteten i testerna eftersom vi måste återställa tillståndet i applikationen efter varje test.

Acceptanstester (även systemtester) representerar ett realistiskt användarscenario i applikationen som helhet. Dessa tester verifierar att applikationen fungerar enligt användarens krav och går ut på att testa systemets användbarhet och funktionalitet. Acceptanstesterna kan automatiseras genom att programmatiskt simulera ett användarscenario. Det finns en uppsjö av verktyg för att göra detta, till exempel Microsoft Visual Studio Team System Webtest eller open-source verktyget Selenium.

I ett befintligt system är det sannolikt enklast att automatisera systemtesterna. Integrationstester och enhetstester kräver båda att systemet följer designmönster som gör det enkelt att skriva programmatiska tester. En viktig princip är att affärslogiken är separerad från UI och infrastrukturrelaterat kod och att man använder standardiserade UI-komponenter och ramverksbaserade lösningar för persistens (OR-mapper), chachning, loggning, validering etc. Teamet kan då fokusera på att skriva tester för en begränsad del av applikationen, och den mest väsentliga delen, nämligen hjärtat i systemet, affärslagret.

Men du bör inte enbart förlita dig till systemtester eftersom det är svårt att skriva tester för alla möjliga scenarier på denna nivå. Det kräver att varje metod och komponent testas var för sig. Enhetstester i kombination med integrationstester, är i längden det mest kostnadseffektiva sättet att verifiera systemet och identifiera eventuella buggar.

Varför kommer jag på mina bästa idéer när jag tvättar håret? Varför störs jag av att arbeta i kontorslandskap? Hur kan det vara helt okey att leka med leksaker på jobbet?
Det här inlägget kommer inte att handla om några plugins till din utvecklingsmiljö eller liknande, utan om mycket enklare saker än så.
Nedan följer cirka 13 lösryckta tips plus 1 visdomsord på temat hur man blir en mer produktiv utvecklare!

1) Visste du att man i princip bara använder vänster hjärnhalva när man programmerar ensam? Parprogrammerar man däremot finns där ju en ”kartläsare” vid din sida som använder sin högra hjärnhalva för att orientera er. Det är alltså först då en hel hjärna arbetar med problemet!

2) Vill du arbeta mer med din högra, kreativa och intuitiva hjärnhalva behöver vänster hjärnhalva distraktion, så att den högra kan arbeta ostört. Ta därför exempelvis med din favoritgummianka till jobbet och placera den på eller i närheten av skärmen. När du sedan behöver hjälp med att lösa ett problem,  förklara det för din anka och se om du inte kommer på en lösning bara genom att ställa frågan högt. (Förvänta dig dock inte att ankan har några svar…)
Ett annat alternativ är att låta händerna leka med en leksak eller kub som då distraherar vänster hjärnhalva på samma sätt . Det är alltså av samma anledning jag kommer på nya idéer eller löser problem när jag tvättar håret. (Ibland kan dock håret bli tvättat både 2 och 3 gånger, vilket inte krävs för min urtunnade kalufs…)

3) Ha alltid ett liten anteckningsbok till hands och skriv direkt ner när du får en idé till lösning. En analog variant ex. av typen Moleskine rekommenderas framför en digital variant i det här fallet.

4) Om du inte redan gör det, testa att strukturera din tankar med hjälp av ”Mind mapping”.

5) När man sitter djupt koncentrerad och lyckats komma in i ”zonen” och har sådär riktigt gott flyt i det man gör och just då blir avbruten, tar det normalt mellan 15-20 minuter(!) tills man återfår koncentrationen. Se därför att eliminera alla distraktioner i din omgivande miljö! (Ni som har irriterande kollegor får dock inte ta detta för bokstavligt…)

6) Som PC-användare är man nästan per definition  ”Mac-hatare”, men man börjar ju bli lite nyfiken.  Folk som gillar Mac gör det dels på grund av att den har ett tyst operativsystem utan alla varningsrutor. Till skillnad från Microsofts diton som uppför sig som 3-åringar med någon form av bokstavskombination. Om man inte är redo att ta steget över till den fruktiga sidan, så kan man alltid använda ett program för att få tyst på sitt Microsoft-OS, som exempelvis Tweak UI eller Jedi Contentrate.

7) Skaffa dig en bra stol och dubbla skärmar. Ett företag, där säljarna har bättre datorer än utvecklarna, har så att säga inte alla indianer i kanoten.

8 ) Agila utvecklare måste ha tillgång till ”war rooms”. Står det inget ledigt? Träng ihop 2 säljare i ett gemensamt rum och ta det. De ska ju vara ute och sälja ändå och har mindre behov än er utvecklare.

9) Se till att ha en inspirerande omgivning när du arbetar. ”Pimpa” den om så krävs!

10) Använd hellre IM-verktyg som kommunikationsmedel än e-post. Det förstnämnda fungerar mycket bättre för ändamålet och är mindre distraherande.

Avslutningsvis ska jag vara aningen mer tekniknära:

11) Livet är för kort för att använda ett dåligt versionshanteringssystem. Byt om det inte håller!

12) Använd automatiseringar, integrera ständigt, skripta allting, timeboxa uppgifterna och analysera ROI.

13) Använd verktyg som verkligen underlättar ditt arbete, som t.ex. SubVersion och CruiseControl.

+1) Kom dock ihåg att utveckling handlar mer om kommunikation än verktyg!

—
Jag lyssnade under Scandinavian Developer Conference våren 2008 till den alltid lika underhållande föredragshållaren Neal Ford, som hade svar på frågor som jag inte visste jag hade! Neal har inspirerat mig till detta inlägg.

I ett agilt projekt: 

• Testar alla team-medlemmar och bidrar till testarbetet.
• Är Testprocessen lättförstådd.
• Är dokumentationen lätt att underhålla.
• Testar man inte sin egen kod.
• Minimerar man dokumentationen, eftersom utvecklare inte gillar dokumentation.
• Får man utvecklare att gilla testning.
• Förbättrar man utvecklarnas förmågor inom testning.
• Definerar man uppgifter i iterationen som innebär att ta fram testskript/testfall…
• … och man definierar även uppgifter att sedan testa dessa.

Vidare är det en bra idé att lägga till en kolumn med statusen ”Att verifiera” mellan kolumnera för ”Pågår” och ”Klart” på sin ”stand up dashboard”. Viktigt är också att så långt det är möjligt skripta sina testfall.

Ett nytt begrepp för mig var ”Developer Exploraty Testing”, som i korthet innebär  att man genomför korta testsessioner flera gånger under sprinten. Hela teamet testar samtidigt det som utvecklats inom iterationen under 1 timme utan avbrott. Testning bör ske i par och resultatet är en enkel rapport, som innehåller testobjekt, utfall, noteringar, ev. buggar, funna problem, etc.
Rapporten ligger sedan till grund för att uppdatera tillvägagångsätten,  testskript, teststatistik, etc.

Att testa i par är något som jag tror mycket på. Erfarenheten visar att mer buggar hittas, team-medlemmarna blir mer entuastiska och risken att man testar sin egen kod blir uppenbart mindre. Vad gäller regressionstester är det dags att tänka om, för inte är omtestning av ett gammalt testfall särskilt pålitligt efter ett tag? Fokusera istället på att testa av den verkliga funktionaliteten på ett konstruktivt sätt!

Hemligheten med agil testning är med andra ord att testa ofta ofta och göra det tillsammans. Detta gör att buggar hittas i ett tidigt skede, blir billigare att åtgärda och så blir utvecklarna betydligt bättre utvecklare genom att bli bättre testare!

Några grundprinciper för XP är att förbättra kommunikationen, sträva efter enkelhet, ge feedback och att alltid fortsätta framåt med mod.
Målet ska alltid vara att sträva efter att skapa något mindre extremt än man hade tidigare.

Upprätta en inception sprint (sprint 0 även kallad), där man fångar kraven på en högre nivå. Låt utvecklarna ta fram grova estimat och använd som underlag för planeringen. Sätt upp förutsättningar för att kunna övervaka projektet utifrån data från det verkliga arbetet och följ upp gjorda estimat med utfallet.

Var inte rädd för att ändra åtagandet i kommande sprint om det visat sig vara övermäktigt att leverera enligt tidigare åttaganden. Estimera om dina user storys om estimatet inte verkar stämma.

Använd klara, tydliga och avgränsade user stories, ha mindsetet att det endast finns klara (100%) eller ej klara (0%) user stories.

Flytta runt på personer om så är behövligt. Låt folk mingla och lära av varandra.

Skapa ”spikes”, dvs. små utredningar huruvida det går att lösa ett problem eller framtida krav på det sätt som man väntar sig.

Håll alltid reda på projektets ”truck number”, dvs. hur många oumbärliga projektmedlemmar som måste ”gå åt” för att projektet inte skulle kunna fortsätta.

Skapa inga svulstiga ramverk (frame works). Det bästa ”designverktyget” är en white board tillsammans med en digitalkamera, så att man kan ta en bild av det man ritat och kommmit fram till.

Parprogrammera! Det kostar 15% mer, men koden innehåller å andra sidan 15% färre buggar.

Testa att ping-pong-programmera, dvs. man skriver koden växelvis och får på så sätt större förståelse och kunskap av det som utvecklats.

Får ni någon gång möjlighet att lyssna till Neal Ford, gör det! En mycket kompetent och fantastiskt rolig föreläsare.

Det är Typemock som intervjuar Andy under SPC09.

Precis som smeder för i världen gjorde verktyg, så gör även vi som utvecklar mjukvara det. Skillnaden är bara att våra verktyg inte görs av metall utan av 1:or och 0:or. Smederna satte stor ära i sin yrkesskicklighet och ägnade ofta ett helt liv till att förfina sin yrkesskicklighet. Det borde även vi göra oavsett om vi jobbar som programmerare, arkitekter eller med kravhantering. Vi borde ta varje tillfälle som ges att träna och lära oss av varandra.

Detta är just vad som är innebörden i ”Manifesto for Software Craftsmaship”.
http://manifesto.softwarecraftsmanship.org/

En man som tagit fasta på detta är Cory Haines. Genom att resa runt i USA och parprogrammera med många olika personer på olika företag vill han utvecklas både som yrkesman och människa. Läs hans intressanta historia här:
http://www.coreyhaines.com/

Här är några tips på hur du kan utveckla din yrkesskicklighet:

• Övning och åter övning med code katas & dojos.
• Studera kod från mästare (t.ex Fitnesse eller JRuby).
• Glöm aldrig att vara noggran (mitt eget tips).
• Parprogrammering och partestning.
• Var alltid nyfiken och öppen för nya ideer.

Alla som kan musik verkar vara överens om att Stradivarius var en mästare på sitt yrke (att göra fioler). Men han misslyckades med något väldigt viktigt. Han misslyckade nämligen med att överföra sin kunskap till någon som kunde ta över och fortsätta förfina hantverket. Gör inte om hans misstag, se till att dagligen dela med dig av din kunskap!

/Patrik