Dagens workshop, Specifications by Examples, med Gojko Adzic, gav bland annat denna output där Gojkos modell visar vart problemområden finns i utvecklingsprojekt idag. De färgade prickarna är Valtechs anställdas bedömning om vilka områden som är de mest utmanande.

Genom våra smartphones går det idag snabbt att uppdatera status på Twitter, Facebook och ladda upp bilder och vi gör det närsom.  När vi står på bussen, drar barnvagnen från förskolan och när vi sitter på en restaurang vill vi checka in fort för att visa vart vi är. Även vårt ökade resande skapar krav på snabba upplägg till sociala medier, det blir ett måste för att kunna agera på nätet när du befinner dig utomlands utan att bli ruinerad på datatrafikräkningen efteråt.

Smartphones har möjliggjort snabb tillgänglighet för oss att nå sociala medier. Detta ställer också krav tillbaka på de sociala medierna att de kan ta vara på informationen i våra smartphones. Trenden visar på att om vi inte kan nå social media snabbt från våra smartphones kommer det att sluta användas.

Jag tror vi kommer att se mer av behovet att snabba på vårt sociala liv på nätet.  Inga fler album och sorteringar utan allt i ett flöde, inga mer aktiva check-ins utan automatiska positioneringar, kortare blogginlägg, mer ögonblicksbilder och videofilmer där du i filmen berättar vad som händer istället för att skriva det. Vi kommer vilja ha våra nyheter snabbare omkring oss och Siri kommer att bli en del i att snabbt hantera din smartphone. Att ställa krav på våra smartphones innebär krav på hur snabbt mobilen fungerar men också hur fort nätet ger oss den information vi vill ha.

Bakslaget

Men när kommer bakslaget? När börjar vi tänka efter vad vi faktiskt delar och vem som ser det? Är dina blogginlägg caschade för all evighet, är dina tweets lagrade och retweetade i all oändlighet och har dina bilder spritts runt om på nätet? När kommer vi lessna på att alltid vara tillgängliga och att dela med oss av allt. Kommer den vardagen att komma, där vi kämpar emot de sociala medierna och dess förmåga att suga oss in i beroende och att öppet visa hur vi lever våra liv. När sociala medier bli snabbare och mer tillgängliga kommer vi då istället att kämpa emot?

Under ett föredrag på Jfokus första konferensdag pratade Greg Young om “Command Query Responsibility Segregation” eller CQRS och varför det passade så bra för en kund som jobbar med datorhandel på börser. CQRS är ju en gammal idé från Bertrand Meyer och här används den för att inte bara dela upp enskilda funktioner i läs och skriv, utan hela system.

Det går ut på att helt separera skrivningar från läsningar på arkitekturell nivå. Skrivningar lägger dessutom bara till data till en log av händelser och ändrar aldrig data. För finansbranchen är det naturligtvis viktigt att ha en log som är garanterat korrekt men jag fann optimeringsmöjligheterna mycket mer intressanta.

Att ha en databas man bara skriver till gör modelleringen av datamodellen betydligt enklare. Är det en relationsdatabas behöver man t ex inte göra avkall på tredje normalform. Vad som passar bättre är kanske en dokumentdatabas så att händelsetyper kan variera enklare. Vi kommer inte att behöva göra sökningar i realtid vilket avdramatiserar valet fantastiskt mycket.

Formellt är nu tillståndet i vårt systemet definierat av alla händelser som inkommit. I praktiken behöver vi ett annat sätt att komma åt tillståndet. Vi kan inte för varje sökning summera alla händelser. Tanken är i stället att vi har en annan databas som vi optimerar för de läsningar vi behöver kunna göra. En databas där vi löpande aggregerar händelser till den struktur vi har behov av.

Denna andra databas är alltså bara en optimering och innehåller inte “sanningen”. Vi kan ändra på optimeringen senare utan att vara rädda för att förlora någon information. Vi kan ha olika databaser för olika sökningar. Vi kan dubbellagra information bäst vi gitter.

De allra flesta system hanterar dessutom mångdubbelt fler läsningar än skrivningar så databasen vi har för sökningar kan vi distribuera över världen samtidigt som skrivdatabasen kan ligga på en mer kontrollerad central plats.

Ref: http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/

I år var första året jag deltog på JFokus som moderator, dvs jag presenterade presentatörerna. Förutom att en av talarna inte hade med sig egen dator och min inte ville visa någon bild på projektorn till en början så gick allt bra.

Först ut på morgonen var Greg Luck från Terracotta, grundaren av Ehcache-projektet. Med den bakgrunden var det ganska givet att han skulle prata om just caching. Alla som någon jobb arbetat med en större webbapp vet hur viktigt det är, men av någon anledning är det inte lika vanligt i enterpriseapplikationer. Greg pratade om den nya cachestandarden för Java javax.cache som defineras i JSR-107. Som man märker på det låga numret har den här JSR-en funnits ganska länge. Under ett par år var den helt död men nu är man 90% klar. Greg är co-lead för projektet. Tanken är att ha ett generiskt interface och sen kunna byta ut cacheimplementationen under. Basfunktionaliteten måste vara med men det finns en del saker som är optional, tex distribuerade cacher. JSR-107 kommer vara en del av nästa Java EE standard men går även att använda med Java SE. Utvecklingen sker på github vilket gör det lätta att se hur arbetet framskrider och att delta.

Dagen fortsatte med Angelika Langer, oberoende konsult med lång erfarenhet av Java och C++. Hon pratade om lambdas i Java 8 och även del andra nya funktioner. Det är verkligen på tiden att Java får riktiga lambdas/closures, alla som programmerat Ruby eller JavaScript (eller något annat språk, det är väl i princip bara Java som inte har closuses än) vet hur kraftfullt det kan vara. Angelika pratade också om en utökning av interfaces som gör det möjligt att ha en default-implementation. Alltså interfaces med implementation, vilket innebär att vi nu har mixins i Java. Eftersom interface inte kan innehålla data så är det inte samma sak som multipelt arv. För mig som mest varit i Ruby-land de senaste åren gjorde det genast Java mycket mer intressant. Tyvärr är releasedatum av Java 8 någon gång 2013.

Sist ut innan lunch var Java Rock Star Cliff Click från Azul Systems en JVM-leverantör. Han pratade om benchmarks av JVM. Först handlade det om micro-benchmark och saker man behöver se upp för som kan ge felaktiga resultat. T ex hotspot-kompilatorn och inlineade metoder eller GC. Sedan pratade han om macro-benchmarks, dvs de standard benchmarks som används av industrin. Där visade på hur de oftast mäter orimliga saker och hur lätt det är att gamea reglerna för att få de resultat man vill ha som leverantör. Presentationen var helt klart underhållande, men inte så releveant för det jag arbetar med dagligen. Eftersom 80-90% av användarens väntetid sker på frontend kan man ju också fråga sig hur viktigt det är med optimering på serversidan när det gäller webbappar. Visst hjälper benchmarks dig att kunna skala backend, men det är ändå användarnas upplevelse som är det viktigaste.

Inom Java har inte alltid webbramverken satt utvecklare och webben i fokus. Play! framework gör verkligen det och det är nog en av anledningarna till det starkt växande intresse vi märker. Det var en fullsatt Hands-on lab på Jfokus som jag höll. Det var en längre introduktion, men vi har dessutom ordnat kortare introduktioner och startat igång team med ramverket med gott resultat. Det är lekande lätt Efter succén med 1.x är det nu spännande med vad som händer med 2.0 releasen, så missa inte Peter Hiltons presentation på Jfokus idag eller Scala meetup imorgon. Det finns även minst två andra presentationer om denna innovativa och produktiva utvecklingsmiljö på Jfokus (av Ward och Raible) så om du jobbar med webb och Java bör du sätta dig in i Play!

Vi hade det stora nöjet att ha Brian Riddle från TV4 hos oss för ett lunchseminarium kring continious integration. Brian är en mycket erfaren utvecklare inom java och ruby, med över tio års erfarenhet av systemutveckling i mediavärlden.

Brian tar med oss på en resa och berättar hur TV4 gick från att 2008 arbeta ostrukturerat med tester och driftsättningar till att idag använda Jenkins för att test och driftsättning av alla större system. Från noll processer eller praxis till strukturerade utvecklingsmiljöer och tydliga rutiner vid lanseringar.

• Hur ser verksamhetens marknad ut, kunder och konkurrenssituation?
• Vad är det som gör att vissa företag och organisationer lyckas bättre än andra?
• Vad händer med företagskulturen när medarbetarna själva är med och producerar innehållet?
• Hur samlar vi verksamheten runt dessa frågor och hur får vi alla i verksamheten att gemensamt engagera sig?

Kanske inte de vanligaste och första frågeställningarna som dyker upp när man tänker på ett intranätprojekt. Fokus är såklart beroende på hur man ser på ett intranät och vilket syfte det skall fylla, informationskanal eller en kommunikationskanal med arbetsverktyg och processtöd ?

Sociala intranät en fråga om kultur

Sociala intranät har etablerat sig som begrepp, en naturlig utveckling med tanke på hur de sociala medierna utvecklats och ökat i betydelse. Exempel på organisationer som använder sociala medier i verksamheten är; UD för informations- och kunskapsspridning. UD får ca 5-6000 unika frågor från journalister varje år här spelar sociala medier en nyckelroll i informationsspridningen. Ett annat exempel är ComHem som öppnat upp Twitter för kundtjänstfrågor. Vi är idag vana att arbeta med “sociala funktioner” i många olika sammanhang och att föra in denna typ av funktionalitet i ett intranät är en naturlig utveckling.

För de allra flesta betyder socialt intranät att man öppnat upp sitt intranät för kommentarer, diskussionsgrupper, wikis, personliga sidor eller bloggfunktioner. Syftet med ett socialt intranät är att skapa större dynamik genom att öppna upp för delaktighet och erfarenhetsutbyte i verksamheten.

Frågan är bara, tror vi att alla börjar kommentera, starta diskussionsgrupper, delta i wikis, använda sin personliga sida eller för den delen blogga bara för att man skapar möjligheten? Eller är införande av ett socialt intranät mer en fråga om synsätt och kultur snarare än teknik och funktion? Att göra ROI (Return On Investment) på sociala media-investeringar är svårt och antagligen lika svårt på sociala intranät. Lyckas man inte införa de förändringar som krävs för att alla i verksamheten skall använda de sociala funktionerna på intranätet, så kommer man inte kunna räkna hem investeringen oavsett teknisk lösning. Här gäller det att göra medarbetarna delaktiga i projektet och att de känner att dom får vara med och påverka och utveckla intranätet utifrån sina egna drivkrafter, behov och vad de behöver för sitt dagliga arbete.

Lika mycket användbarhetsprojekt som teknikprojekt

Att skapa en kultur och ett synsätt i en verksamhet som genomsyrar öppenhet, delaktighet och prestigelöshet är nödvändigt om man skall lyckas med implementering av sociala intranät. Det sociala intranätet blir verksamhetens tvärfunktionella och gemensamma plattform. För att göra det sociala intranätet än mer tillgängligt bör man också se över mobilanpassning av intranätet, för att möjliggöra ex. tidsrapportering via mobilen, åtkomst till adressboken eller nyttja kraften i de sociala funktionerna.

På samma sätt som sociala medier, medvetet eller omedvetet, påverkat dels vårt sätt att kommunicera och agera, men också vilka krav och förväntningar vi har i olika situationer. På samma sätt kan ett socialt intranät förändra och påverka arbetssätt, kommunikation, innovation, verksamhetsutveckling. Men det kräver en balans i implementering mellan synsätt och kultur samt funktion och teknik. Det är lika mycket ett användbarhetsprojekt som det är ett teknikprojekt.

Tvärfunktionella team minskar risker och ökar effektivitet

Genom att arbeta lättrörligt och med tvärfunktionella utvecklingsteam skapar man effektivitet i arbetet, kvalitetssäkring genom löpande delleveranser och avstämningar samt med användbarhet i fokus. På samma sätt bör man organisera den referensgrupp som skall representera verksamheten och vara kravställare i projektet.

Implementeringen av ett socialt intranät innebär utveckling från en informationskanal till en kommunikationskanal, ett interaktivt och dynamiskt arbetsverktyg med processtöd.

Hur implementerar vi användningen?

Börja med de delar som har låg tröskel och där användaren direkt ser nyttan av att engagera sig i olika sammanhang. Vad det är för typ av funktioner eller sammanhang kan bara medarbetare svara för själv, vilket innebär att det är av största vikt att de själva är med och skapar förutsättningarna för det nya intranätet.

Ett exempel på funktionalitet kan vara att skapa ett enkelt och intuitivt stöd för utvecklingssamtal där alla medarbetare går in och aktivt förbereda sig inför samtalet. Viktigt att tänka på oavsett vad man börjar med är att skapa ett intuitivt och enkelt stöd som skapar värde och upplevs som ett lyft för användarna.

Vilken betydelse har ett intranät?

Återgår till frågeställningen i rubriken ”vilken betydelse har ett intranät?”. Svaret är såklart att det beror på hur man ser på sitt intranät, handlar det om en informationskanal eller en kommunikationskanal, ett arbetsverktyg och processtöd som stödjer ett tvärfunktionell och ”socialt” synsätt?

Om du är nyfiken på hur vi på Valtech arbetar med vårt intranät är du välkomna att höra av dig.

För några år sedan pågick en diskussion bland de som tidigt tagit till sig agila metoder: vad skulle “agile” översättas till på svenska? Många kände att “agil” var svårt att förklara för folk och mest gav associationer till hundar som hoppar genom ringar. Det fanns en hel del röster, inklusive min egen, som föredrog att kalla det vi höll på med för “lättrörliga metoder”.

Med facit i hand vet vi att det gick rätt bra att etablera “agil” i svenskan, idag har de flesta som sysslar med systemutveckling hört talas om agila metoder och Scrum, som är den agila metod som de flesta använder. Däremot är det enligt min erfarenhet få agila team som är vad jag skulle kalla lättrörliga.

Jag har ingen entydig definition av vad lättrörlig betyder, men för enkelhets skull kan vi anta ett team med följande egenskaper som alla möjliggör hantering av förändring:

• Kan releasa till produktion minst en gång i veckan.
• Har en deployprocess som tar mindre än en halvtimme, gärna mindre än fem minuter.
• Har en täckande automatiserad testsvit.

Många som läser ovanstående lista säger säkert att “man behöver inte allt det där för att vara agil”. Vilket på sätt och vis är min poäng. Agil som ordet tolkas av den överväldigande majoriteten idag handlar om en projektledningsmetod – något som främst handlar om sociala och organisationella förändringar. Vi inför ståuppmöten, vi delar in projektet i sprintar och konverterar kravspecen till en backlog.

Däremot hoppar vi oftast över det som XP definierade som en av fyra grundvärderingar: enkelhet. Det är enkelhet som gör att vi kan releasa ofta. Det är enkelhet som gör att deployment går snabbt. Det är enkelhet som gör att vi överhuvudtaget kan skriva automatiska tester för systemet vi skapar. Det är det som skiljer ett lättrörligt projekt från en agil SAP-implementation.

De tidiga Scrumförespråkarna visste detta. I den första boken om Scrum skriver Jeff Sutherland:

The key to entering a hyper productive state was not just the Scrum organizational pattern. We did constant component testing of topic areas, integration of packages, and refactoring of selected parts of the system. These activities have become key features of XP.

Idag ser de flesta Scrumprojekt helt annorlunda ut. Det är därför dags att acceptera den glidning i betydelse som ordet “agil” haft, och skilja den från “lättrörlig”, även om de från början beskrev samma sak. Och när ni utvärderar er agila satsning och tycker att det inte var så stor skillnad mot tidigare så kanske ni skall ta nästa steg och satsa på att bli lättrörliga också?

1 Följsam design (responsive design)

Följsam design slog igenom stort i höstas och är redan en etablerad trend. 2012 blir året då beställare och kunder börjar använda ordet. Du behöver inte längre sälja in den extra kostnaden. Responsiv design är också den viktigaste tekniken som kommer ta oss tillbaka till ursprunget; webben som kittet mellan mobil och desktop och som minskar gapet mellan olika sammanhang.

Vi kommer också börja se mycket bättre exempel på följsam design, både när det gäller prestanda, kreativitet och innehåll. Principen progressiv förbättring kommer vidga sig och även innefatta innehåll, vilket ytterligare kommer sätta fokus på innehållsstrategi.

När vi närmar oss slutet av året har “följsam design” försvunnit som begrepp och ingår snarare (precis som “tillgänglighet” och “seo” numera gör) i kundens förväntningar på god gränssnittsutveckling.

2 Snabbhet

Fler och fler designers kommer lära sig publiceringsverktyg, ramverk, gränssnittsutveckling och prototypverktyg och använda dem kreativt för att öka elegans, följsamhet, effektivitet och snabbhet.

2012 blir året då vi bygger, testar, utvärderar, bygger, testar och utvärderar. Och bygger. Vi hänger med utvecklare. Som Sarah B. Nelson på Tapir & Tine skrev: “At Lean Startup day at SXSW, guess who wasn’t part of the conversation? Yup, designers”.

I år börjar vi inte från första början i designprocesser, vi dokumenterar allt mindre, vi föreslår inte dyra förstudier. Vi experimenterar, undviker perfektionism, prototypar och blir ännu mer lättrörliga.

3 Mobile first

2012 blir året då vi som designers och konceptutvecklare, på riktigt, utgår från hur innehåll och funktioner kommer användas i mobilen. Vi bygger en kärna utan fluff och irrelevant innehåll som sedan anpassas efter enhetsanvändning. Varför? Mobilanvänding är snart viktigare än desktopanvänding. Mobilen kräver enkelhet.

Vill du vara förberedd på de mobila möjlighetena och den mobila tillväxten (vem vill inte det?) måste du helt enkelt fokusera och välja bort. Vilket i sin tur innebär fantastiska innovationsmöjligheter.

4 Anpassad typografi

Numera står inte längre kriget mellan Times New Roman och Arial. Tjänster som Google Web Fonts, TypeKit och FontDeck gör det möjligt att använda många fler typsnitt till en rimlig kostnad. Speciellt inom bloggosfären är det här redan en hyfsad etablerad trend. Vi kommer se den på allt större webbar 2012.

5 Långa vyer

Ok, det viktigaste måste såklart fortfarande vara högst upp på sidan. Men 2012 kommer designers i högre grad utnyttja möjligheten till att designa längre sidor.

Användaren vinner på färre omladdningar samtidigt som den ökade användningen av touchgränssnitt gör det lättare att scrolla. Och Facebook- och Twitterdesignkonventionen med automatisk laddning av nya objekt kommer hjälpa till att förpassa pagineringen till dess rättmätiga plats – ett sista vilorum.

Facit: Experter på konverteringsoptimering har länge känt till att långa sidor presterar bättre än korta, förutsatt att användaren vet att de kan skrolla.

6 Vektorgrafik

Speciellt i USA har vi under 2011 sett stora maskotar hjälpa till med estetik för att bygga upplevelse och i sin tur varumärke. MailChimp, Firefox och Silverback har alla briljerat med lyckade exempel på webbmaskotar. Läcker vektorgrafik hjälper till att skapa surrealistiska och lättviktiga miljöer som vanliga realistiska fotografier har svårt att uppnå.

7 Avancerade webbappar för mobil och läsplattor

Ok, den här är väl för 2013 men vi är generösa idag. I slutet av 2012 blir W3C:s Device API färdigt och vi kommer se ett snabbt stöd i WebKit och Firefox. Nu får vi tillgång till enheters kameror, kalendrar, bilder, batteritid etc och kan skapa riktigt avancerade webbappar med HTML, CSS och JavaScript.

En webb på riktigt.

Den 3:e december höll vi vårt andra Coderetreat på Valtech. Den här gången var det en del av ett globalt event, under samma dygn hölls det Coderetreat i 90 städer på alla jordens bebodda kontinenter. Över 2200 utvecklare deltog och det var en hel del kända namn, bl a deltog Martin Fowler i Melbourne, och retreaten i Miami faciliterades av Michael Feathers. Corey Haines, en av skaparna av Coderetreat, faciliterade ett retreat i Australien och flög sedan tillbaka i tiden, över datumlinjen, till Hawaii och faciliterade ännu ett retreat. För att främja coderetreats och samla ihop befintlig kunskap har Corey satt upp coderetreat.org. Där finns information om hur ett retreat fungerar, information och övningstips till facilitatorer samt en mängd bloggposter från tidigare events.

Precis som förra gången så var det Emily Bache som faciliterade i Stockholm. Vi var ungefär lika många, runt 40 stycken. Det var kul att se att många som var med förra gången ville vara med igen. Efter feedback från förra gången hade vi lagt ut lappar märkta med programmeringsspråk på borden för att göra det lättare att hitta någon att parprogrammera med. Det var kul att det kom folk från flera olika utvecklarcommunities såsom JavaScript, .NET, Ruby, Java, Scala, Clojure.

I borta änden av rummet har vi en TV på väggen. Vi kopplade in laptop till den och startade en Google Hangout med Coderetreat i Umeå. Det var även en del andra städer som gick med under dagen. Vi hann inte direkt kommunicera så mycket med varanda, men det ökade ändå känslan av ett globalt event. Innan dagen hade vi kontaktat några andra städer som vi skulle Skypea med under dagen. Tyvärr hade vi (eller de) problem med sin uppkoppling så det blev aldrig av.

Dagen bestod av 5 stycken 45-minuters iterationer där vi hela tiden arbetade med att lösa Conway’s Game of Life. Du kan läsa mer om formatet i blogposten om vårt första coderetreat.

Efter sista iterationen samlades vi till ett retrospektiv. Vi utgick från frågorna

• Vad lärde du dig idag?
• Vad överaskade dig?
• Vad kommer du göra annorlunda på måndag (på jobbet)?
• Vad insåg du att du borde bli bättre på?

Här är några (osorterade) kommentarer från retrospektivet

• Dagen var utmanande, roligt!
• Bra att pendla mellan att lyfta blicken, och att jobba med fokus på riktigt låg nivå i små, små steg.
• Kul att träffa nya duktiga människaor, även från andra communities.
• Jag borde ha följt iterationens utmaning striktare.
• Det kändes annorlunda att jobba outside-in.
• Inspirerande att det finns så mycket bra folk!
• Det är svårt att ändra vanor, de sitter djupt.
• TDD på mikronivå leder lätt till yagni, fokus på fel/onödiga saker.
• Det är bra att alternera mellan BDD och TDD.
• Har blivit bättre på att bryta ut komplexitet i mindre moduler för att få dem mer testbara.
• Denna gång var det mindre fokus hos de deltagande på att testa nya språk, gav ett bättre fokus.
• Lärt sig att snabbare slänga bort sådant som inte är en del av lösningen/på väg åt fel håll.
• Positivt att de flesta jobbar med TDD till vardags.
• Det är bra med guiding tests för att hitta riktningen.
• Det var lite si och så med parprogrammeringsetiketten, viktigt att byta förare ofta.
• Jag ska jobba mer funktionellt i fortsättningen.
• Det finns alltid ett bättre sätt att göra något.
• Det var överraskande att det blir mycket lättare att se vad som ska brytas ut i egna enheter när man parprogrammerar.
• Det var svårt att tänka funktionellt i stället för objektorienterat.
• Jag ska bli bättre på datastrukturer och grunderna i datalogi.
• Vilken skillnad det blir om man går ifrån antaganden och lyfter blicken.
• Det är viktigt att man skapar ett gemensamt språk, så att begrepp betyder samma sak för bägge i ett par.
• Den här gången arbetade jag bara i språk jag redan kan, det ledde till mer fokus på TDD.
• Jag blev överraskad av att “mute session” (inte prata, bara kommunicera med kod/tester) blev så produktiv.
• Kul att alla är så öppna, gör att man känner sig välkommen.
• Jag ska bli bättre på baby steps, att göra så lite som möjligt i varje steg.
• Jag upptäckte att det är bra att ha helhetsbild, men bara lösa en liten del av problemet i taget.
• Det var bra att öva på TDD även om jag jobbar med det varje dag.
• Det var lärorikt med miniretrospektiv efter varje iteration.
• Det var kul att se lösningar i andra språk än mitt vanliga.
• Jag ska öva mer på att ta riktigt små steg.
• Jag lärde mig jättemycket från den jag parprogrammerade med.
• Nu har jag sett TDD på riktigt, det är inte som TDD som jag har trott och arbetat med.
• Kul att parprogrammera med någon jag inte känner.
• Jag har blivit bättre på TDD.

Själv är jag väldigt nöjd med dagen. Det var kul att vara en del av ett globalt event, även om det var en hel del extrajobb och koordination med de andra städerna innan. Veckan innan skickades ungefär 1000 mail på maillistan för arrangörer!  De två saker jag själv tyckte var mest positivt med dagen var dels att träffa så många duktiga utvecklare som jobbar med TDD varje dag, och dels att det blev mycket starkare fokus på att förbättra sitt hantverk än förra gången då många fokuserade på att prova nya språk. En utmattande, men väldigt inspirerande dag!

Nästa gång kommer vi att köra Legacy Code Retreat. Ett format framtaget av J.B. Rainsberger. Datum TBD.

Andra blogposter om dagen:
Hardy Ferentschik
Valtech UK Visst har de snyggt tema på sin blog? =)