Open Space med blixttal

På gårdagens träff testade vi OpenSpace med blixttal på 10 minuter.

Den här gången var det fem blixttal som tilläts dra ut lite på tiden. Förutom väldigt intressanta blixttal så blev det mycket bra diskussioner runt varje ämne, och vi kommer definitivt göra detta igen!

Här följer anteckningar från talen.

Smärta i enhetstesterna är symptom på sjuk design

Av: Markus Örebrand

Mer info: podcast - Sustainable TDD, avsnitt: Test reflexology
Bad Design != Good Design

Stor fixtur

Symptom: För hög koppling till beroende, high coupling.
Åtgärd: Gruppera med fasad eller aggregatrot, förenkla, bryt isär

Komplex fixtur

Symptom: Svart magi (reflection t.ex.) behövs i fixtur.
Sjukdom: Creation and usage not separated, cohesion problem.
Åtgärd: DI, ServiceLocator

Conditioning

Symptom: SUT (bil måste köra i 30 för att kunna testa varning)
Sjukdom: Business rule in wrong place, not explicit, Cohesion
Åtgärd: Make business rule explicit.

Överbeskyddande test

Symptom: Klass 50 rader, test 200 rader. Kombinationer
Sjukdom: SUT är både databas och sökmotor, SRP-violation, cohesion.
Åtgärd: Bryt isär.

Test coverage strategi - testpyramiden

Av: Jonas Andersson

Hur köteori kan eliminera planeringsbehovet

Av: Christina Skaskiw

Mer info:
The principles of product development flow, av Donald Reinertsson (motiverar Kanban ekonomiskt)
Kanban, av David Andersson

(Se även Naked Planning från Agile Toolkit Podcast)

Planering

Planering = Push, i motsats till Pull = Flow
Tar tid = waste, inte värdeskapande
Gissar
Tråkigt

Syfte: Förutsägbarhet

Kanban kan mha historik ge oss orsak till varianser
Historik är mycket mer vetenskapligt

Köteori

Start 1909 av Copenhagen telephone company
Cost of delay, i motsats till utilization, utnyttjandegrad, beläggningsgrad
Hög utilization → lite slack → längre ledtider
Ledtid (cycle time)
Ställtid
Mål: Sänk utnyttjandegraden, mer slack, mindre varians, mer förutsägbart flöde

Flow

Hur mycket blir klart / tid = flöde
Hur lång tid / grej = cycle time

Kanban i förvaltning

Av: Jonas Andersson

(Inga anteckningar)

Exception handling with ejb:s

Av: Jonas Andersson

From: http://www-106.ibm.com/developerworks/java/library/j-ejbexcept.html (En gammal goding)

 Exception handling basics

1. If you can't handle an exception, don't catch it.

2. If you catch an exception, don't swallow it.

3. Catch an exception as close as possible to its source.

4. Log an exception where you catch it, unless you plan to rethrow it.

5. Structure your methods according to how fine-grained your exception handling must be.

6. Use as many typed exceptions as you need, particularly for application exceptions.

EJB Specifics

 - Catch exceptions at EJB-boundary

   - ApplicationException

       - Caller's fault

       - No implicit rollback

       - If caught → Log at DEBUG and rethrow

   - System exception

       - Unrecoverable checked or unchecked exception.

  - Log at ERROR,  wrap in EJBException.

Checked vs Unchecked

- if there isn't anything you can do about an exception, it's a system exception

  and it should be thrown as an unchecked exception