Inte mycket OOP i titlarna för årets föredrag.
Tänker på detta när jag lyssnar på ”Event Sourcing explained” med Rickard Öberg.
Känns som Rickard har kämpat många år med att komma runt Javas modell av objektorientering.
http://www.qi4j.org/ är ett ganska kraftfullt försök till utbrytning som han måste lagt ner en väldig massa tid på.
Eventsourcing, som dagens dragning handlar om, går ut på att bygga applikationen runt en sekvens av händelser som man sparar i en event-logg.
Inte mycket OO i den skissen.
Jag får mer vibbar till gamla tiders sekventiella kommandoprogram.
Och skälet, om jag förstår det rätt, är att det är svårt att ändra (eller få flexibilitet) i en domänmodell modellerad som javaklasser.
Så då är det enklare att säga: Här är alla händelser, gör vad du vill med dem, bygg din egen modell som passar dina syften.
Det ger total flexibilitet och dessutom enkel interoperabilitet, eftersom eventloggen kan publiceras som en atom-feed t.ex.
Och det blir också relativt enkelt att hålla alla system med duplicerad data i synk eftersom alla event finns sparade och kan spelas upp om och om igen, bara varje system håller koll på när det senast hämtada information från loggen.
Undrar bara varför Rickard inte hoppat över till något annat språk. Måste vara nån slags kärlek.

Talare: Dan North, keynote

Ett återkommande ämne oavsett spår tycks vara ovisshet och osäkerhet. I dagens keynote fördjupar dig Dan inom ämnet och uppmanar oss att prata mer om magkänslan och det vi känner oss osäkra kring.

Han menar på att ”Fear leeds to risk” och ”Process leads to hate”. Ett vanligt problem är att om det inte finns utrymme och går att hantera ovisshet så väljer man som person och team hellre att misslyckas. Det kan man styra över.

Budskapet är att vi ska försöka att förstå osäkerheten, vad består magont av och hur sannolikt är det att det inträffar?

Vi bör omfamna osäkerheten kring olika områden:

* Scope
* Teknik
* Ansträngning

Det går att göra val utifrån en modell för osäkerhet
* options have value, att ta ett beslut har ett värde i sig självt
* options expire, beroende på när jag gör valet får det olika effekter
* commit deliberately

Det går inte att förutse allt och osäkerhet är naturligt. Vi behöver bara bli bättre på att prata om det.

Note to self: Just nu är jag osäker på om alla som inte var där och som läser det här förstår vad jag menar. Vad är sannolikheten för det?

”Never commit early unless you know why and expect the unexpectable”

Det grymma med att vara på en bred utvecklarkonferens som Øredev är ju att det är lätt att gå lite utanför den vanliga fåran, där man brukar vara.

Jag har gått på några UX presentationer idag som varit rätt bra. Om man ska vara riktigt generös med tolkningen av användare så var jag på en igår också på temat ”API the hidden UI”. Tanken är att den som kommer använda ditt API också är någon form av användare, en stor skillnad är dock att ett GUI kan ändras efter att det börjat användas, ett API kan däremot inte ändras utan att saker verkligen går sönder för användare. I princip kan man säga (ok, lite hårddraget) att man bara har en chans att göra API:t rätt. När det publicerats är det användarna som äger det. Inte själva implementationen, men du kan inte ändra hur som helst längre.

Flera av lärdomarna där har jag hört upprepas idag på mer traditionella UX presentationer t ex:

• När man får förfrågningar om nya funktioner får man det oftast i form av ett halvfärdigt lösningsförslag. Försök att fokusera på det underliggande problemet istället. En princip som kan användas är att det inte ska bli bättre bara för en användare utan för många. Beställaren ska kunna motivera varför, för vilka den löser vilket problem.
• Använd konventioner som är utbredda. Analogt med att användare spenderar mest tid på andra webbplatser än din egen, så spenderar API-användare mest tid med andra API:er än ditt. Ett exempel är att en relation mellan brukar benämnas parent-child. Om man i sitt API kallar det för father kommer det bli förvirrande.

Jeff Patton presenterade två klassiska ”failure modes” när man utvecklar och jobbar (mindre bra) med UX:

1. Man antar att ”om jag gillar det så kommer användarna också göra det”
2. Man frågar användare direkt vad de vill ha och ger användare skulden om det inte blir bra.

Keynote Alexis Ohanian
Gårdagens keynote handlade åter igen om det heta ämnet User Expirience och tänket ”Users Come First”

Idag står Agile, Test och UX på min agenda. Jag tänker också utmana mig inom något område som jag inte har kunskap om. Exakt vad har jag inte kommit fram till ännu då det finns så många spännande spår. Dags att pringa vidare…..

Det märks att javascript sakta börjar lämna sitt gamla rykte bakom sig. Fyra av sex föreläsningar på Web-spåret var rena javascript-kodorgier.

1. Javascript effects, Seb Lee-Delisle, http://sebleedelisle.com/

Killen är otroligt begåvad och med självsäkerhet och kvicka fingrar bränner han av en livekodnings-sejour där han skapar ett animerat träd på en html5-canvas med hjälp av lite javascript och lyckas få med objekt-orientering, funktionella delar, rekursion, global versus lokal data och naturligtvis closures.

Efter det får vi alla koppla upp våra iPhones mot hans dator, via en html5 webbsida med websockets, och sedan börjar han projicera rörliga bilder i lokalen genom att varje telefon får representera EN pixel av filmen som servern sänder. Seb har många ideer…

Kolla på youtube, t.ex. http://www.youtube.com/watch?v=UCuVjPpExoQ och missa för allt i världen inte http://creativejs.com/ om du har lite tid över att leka.

2. Sproutcore, Yehuda Katz

Javascript-ramverk som ska hjälpa oss strukturera klientsidan av webbapplikationer finns det många av. Vilket ska man välja?

Sproutcore  är väl en av finalisterna. Varför det är så lyckas Yehuda visa på ett ganska övertygande sätt.

Ett sätt att få överblick är att kolla in TodoMVC där en och samma webbapplikation finns skriven i en rad av de populäraste ramverken.

3. Test-driven Javascript, Christian Johansen

Norrmannen höjer ribban ytterligare och kör TDD-utveckling live, från början till slut, alla 50 minuterna, de sista fem är gastkramande spännande. Ska han hinna färdigställa hela appen och få det avslutande funktionstestet att gå igenom?

Naturligvis gör han det, och slår därmed till och med den exelenta Brighton-bon Seb Lee-Delisle på fingrarna med sin fingerfärdighet.

Otroligt inspirerande att se TDD i javascript genomförd med sådan självklarhet.

4. Node.js – A practical introduction, Felix Geisendörfer

För er som prenumererat på podcasten nodeup är det här inget nytt namn. När man lyssnar på nodeup kan man dock få en känsla av att ha tagit ett sömnpiller (eller att grabbarna i podcasten har tagit ett par…) när nördigheten passerar ytterligare en gräns man fem minuter tidigare trodde var opasserbar.

Men av detta märks noll och intet när Felix ska berätta för oss vad node.js är för en varelse. Tvärtom får jag nästan en känsla av att han knappt tar sig tid att andas, så oerhört mycket har han att förmedla. Entusiasmen går inte att ta fel på, inte heller kunnandet.

Inte ens hans lätta tyskbrytning spelar någon roll, ett fenomen som annars kan göra vilken föreläsning som helst dubbelt krävande.

Kolla in http://nodejs.org/ och http://www.youtube.com/watch?v=g29PemqW7lQ.

Under onsdagen var jag på ett par bra dragningar om REST (REpresentational State Transfer) som är det sätt som ”alla” bygger sina API:er på idag. Eller åtminstone påstår att man bygger sina API:er på. Nåväl jag ska inte orera om missuppfattningar om REST.

Vad jag dock kan konstatera är att ett centralt begrepp, som jag knappast sett ”in the wild” är HATEOAS (Hypermedia As The Engine Of Application State). Jim Webber förklarar dock föredömligt pedagogiskt vad det handlar om. Utgående från det självklara i hur vi som människor genom vår browser navigerar genom ett checkout-flöde på typ amazon. När vi börjar vår utcheckning gör vi det genom att följa en hyperlänk. Vi vet i det läget inte vart vi senare kommer navigera, men vi får hjälp från applikationen genom att vi förses med länkar genom t ex anchor-taggar eller form targets som för oss människor (förhoppningsvis) har en uppenbar semantik. Typ vi ser våra varor och när vi klickar på knappen ”betala” förväntar vi oss att komma till en sida där vi… betalar. Inget konstigt – HATEOAS. Samma tankesätt kan generaliseras till att även omfatta maskin-till-maskin kommunikation, där dock länkarnas semantiska innebörd måste formaliseras.

En annan sak som Jim Webber uppenbarligen brinner för är att omfamna HTTP som det applikationsprotokoll det faktiskt är. Mer specifikt ett applikationsprotokoll inom domänen att skyffla runt dokument på internet.

Det vi gör när vi då navigerar mellan dessa resurser som pekas ut av länkar är att vi skickar och tar emot dokument. Allt som verkligen händer med våra domänobjekt är sidoeffekter av att dokumenten skyfflas runt. Det behöver INTE råda en ett-till-ett relation mellan resurser och domänobjekt!

Ian Robinson pratar senare om Test-Driven Rest. Inte helt förvånande använder han i mycket samma analogier som Jim Webber (de har skrivit boken Rest in Practice tillsammans).

Ian har dock en kort lista på saker som kan vara bra att testa isolerat när man testar sitt REST API:

• Att HTTP interaktionen går som den ska. Att man får rätt responskoder och headers etc.

• Att interaktionen med underliggande domänrepresentationer sker som den ska.
• Att rätt responser ges på rätt format.
• Och att hypermedia dyker upp som det ska, ledtrådar till vad som kan göras härnäst.

Talare: David Evans (Quality testing agile coach)

I sitt arbete som Quality testing agile coach har David uppmärksammat mönster som visar på att man får utmaningar med testning i stora företag där man har problem i orgnisationen och på avdelningar. Ett sätt att skapa bra förutsättningar för att arbeta med testning är en bra miljö och kultur för att hantera när fel uppstår och att det är något positivt som går att hantera och lösa.

* Granska utifrån olika perspektiv – explore
* Prova nya saker – utmana oss
* Lär från misstag – lärande

Varför ska man testa?
* Genomgång av ”The agile testing quadrants” (Brian Marick diagram)
* Hitta testerna som supportar teamets arbetssätt
* Mer testing förbättrar inte kvaliteten. Man måste förstå vad som inträffat och agera på den informationen. Ta hand om problemet och skapa en plan för det man finner i sina tester.
* Testa på rätt nivå.

Tips på vägen
* Vad behöver vi skriva och vad ska vi bygga för att kunna testa. TDD
* Lär dig det som är användbart
* En felrapport är bara en uppfattning, stakeholders tar beslut och prioriterar.
* En defekt är ett tecken på att det inte finns ett test.
* End to end testing är överskattat.
* Varning: TDD gör utvecklingen mer långsam! Tänk på att hastigheten inte är det viktiga, det är vad vi fyller den.
* Alla kan testa, testare är våra vänner
* Det viktiga är hur vi gör våra tester, inte hur vi är som testare.

Jag tycker vi har många bra idéer om hur vi kan väva in testning i teamen och vår utvecklingsprocess. Vi fortsätter prova nya sätt och utmanar oss inom området och det lär vi oss mycket på.

”Testing is never finished, it is only ever stopped”

Talare: Chris Pattersson

Chris satte fokus på grundläggande processer och verktyg utan någon större djupdykning och analys av ämnet. Frågan var, hur ska man tänka i utvecklingsprocessen?

Vi fick en övergripande genomgång av grunderna för design, process, genomförande, underhåll och verktyg. Ledorden var mockups, automatiserade tester och automatiserad deployment.

• Enkla Mockups med fokus på idén och design av funktionaliuteten inte grafiken.
• Avoid abstraction – undvik förvirring och fokusera på rätt saker
• Names matters – sätt namn som alla förstår på classer, metoder och argument. minimera dokumentationen
• Composition – skapa återanvändbara komponenter
• Reuse – hög kvalitet gör att vi kan återanvända komponeneter
• Measurement – mät, logga och analysera
• Automatiserade tester
• Autodeployment till dev
• Lär dig olika språk
• Utbilda andra

Talare: Michael Nygard

Michael berättar om flera projekt där han varit delaktig både som applikationsutvecklare och systemarkitekt i ett operationsteam och där man stött på stora problem som utmanat organisationen och avdelningarnas samarbeten. Han berättar om fördelarna och vikten av att arbeta närmare varandra i vardagen. Att tillsammans nå över gränserna är nyckeln i stora organisationer.

 Att tänka på i samarbetet
– Extra hw löser ofta inte problemet(prestanda), spara kostnader
– Kombinera kunskap om utveckling, backend och operation
– Prata ett konkret språk: nätverk, protokoll, paket, xml, etc. samarbeta över gränserna och delad förståelse för problemet

 Organization Design
Designa organisationen på samma sätt som ett system. Det skapar en syn och process för hur man arbetar i framtiden med förvaltningen. Vi bygger samtidigt organisationen som ska underhålla applikationen. Det arbetet görs inte i en sprint, det är en Marathon…

Jag tänker Superteamet, gör ni också det? Vi samarbetar, hittar, visualiserar, analyserar och hantera problem och buggar på olika sätt och nivåer utifrån flera kompetenser.

Finns det fler sätt vi kan arbeta närmare varandra på i Superteamet? Kanske ha en gemensam backlog och mer delaktighet i alla ärenden så att vi får förutsättningar att arbeta mer tillsammans med samma saker?

Michel reflekterade också över vad gick rätt i projekten även där projekten havererat. Punkterna nedan är från Michel men sammanfattar Superteamet på ett mycket bra sätt.

– Vi använder Kanban för hantering av incidenter, det ökar transparensen
– Vi delar information, verktyg och kunskap
– Vi hanterar snabba förändringar
– Vi gör heroiska insatser – utsätter oss för stora utmaningar dagligen

”Dev + Ops = DevOps (IT operations och application developer in collaboration)”