Återkoppling från en Coding Dojo

Posted on 2012-02-07 by Fredrik Wendt

Det är otroligt kul och inspirerande att se Coding Dojos tas emot så väl ute bland de företag jag besöker. Att det är väl mottaget bland utvecklare är uppenbart och kan bl a förklaras med “Code wins arguments”. I “gamla” inkörda team där diskussioner gått i stå och nötts länge kan helt plötsligt helt ny dynamik uppstå. De “gamla” argumenten som gått fram och tillbaka men bara varit abstrakta och teoretiska skall helt plötsligt omsättas i kod, med/inför kollegorna och “helt plötsligt” går det från abstrakt till konkret och inte bara fåtalet engagerar sig och har en uppfattning, utan flertalet.

De Coding Dojos jag driver hos kunder är just detta – praktiska övningar med ett mål eller en poäng. Ingen föreläsningsserie man sitter och nickar igenom och sedan släpper vind för våg. Med riktiga övningar, där alla deltar och skriver kod själva ökar deltagandet, engagemanget och det kritiska granskandet.

Eftersom det ofta uppstår diskussioner med uttryck som “jag brukar göra såhär”, “oj, så har jag aldrig gjort, eller tänkt” så är det viktigt att det inte finns lönesättande chef(er) på plats. Om deltagarna är rädda för att säga fel och börjar väga sin ord så försvinner en stor poäng med dojon. Jag försöker få alla att vara spontana med hur de tänker, att exponera hur de jobbar utanför dojon så att de kan få konstruktiv feedback på sitt arbetssätt. Lönesättande chef och/eller beställer behöver givetvis återkoppling också. Här följer ett exempel från förra veckan.

Hej Kund!

Efter lite hackiga, trevande steg med första övningen tyckte jag mig se en enorm skillnad till tillfälle två. Det märks att flera utvecklare försökt sig på det vi övade i vardagen! Jag tror mig se att så gott som alla utvecklare har fått en ny infallsvinkel till hur de ser på sin kodskrivning och den synen utvecklade vi med en mer realistisk övning ihop med mockning. Det var mycket bra frågor som dök upp, vilket tyder på att de är engagerade, intresserade, verkligen försöker anamma en annan kodordning och har en sund kritisk inställning till vad de gör själva (det är ju inte jag som skriver koden under övningen – jag bara guidar och ger tips)!

Övning 1:

Vi tog en enkel basövning (String calculator).
Vi introducerade red-green-refactor, Arrange/Act/Assert, bottom-up.
Vi tog baby steps bokstavligen med 1 minut som tidkrav att gå från röd till grön.
Vi såg triangulering som ett sätt att driva fram funktionalitet.
Grå zon: “täcker testen all funktionalitet? om inte, har vi använt test-driven utveckling?”

Övning 2:

Vi tog in en ny, ganska stor uppgift som är mycket mer realistisk (tagen från produktionskod).
Vi lade på ett nytt moment/tanke i form av en “testbacklog”. (Verkade vara en ny idé – diskuterade VAB-scenariot och vikten av att kunna dela kod ofta.)
Vi lade på mockning med Mockito. (En del var redan bekanta med Mockito.)
Grå zon: “ett par antydningar till att ändra kod utan att testen uttrycker den funktionella ändringen i koden”.
Vi refaktorerade kod lite oortodoxt (utan test, utan undo/bortkommentering).

Det var mycket motiverande för min del att se utvecklingen i teamet, det var en helt annan “mognad” i TDD-tänket och ett bra driv/bra dialoger. Parprogrammeringen såg bitvis fullständigt klanderfri ut – mycket kul att se! Nästan all kod drevs fram från test (två, tre tillfällen fanns antydan till att skriva kod som inte var testdriven/täckt av test).

Utvärderingen i slutet bjöd mer på kod- och designdiskussioner (jag vill aldrig avbryta sådant) så vi hann inte “utvärdera” så mycket, men på tavlan skrev jag upp:

+ bra frågor
+ bra övning
! refactoring gjorde koden mycket mer läsbar
! smidigt med @Mock
? Använda TestNG nästa gång

Mitt förslag är att vi nästa gång utvecklar i flera par parallellt (en dator per par med Eclipse är vad som behövs), lägger på Clean Code-aspekter och använder samma uppgift och ser hur vi kan få koden att se ut på olika sätt.

Squeed bjuder på mat och kompetens till CV:t

Posted on 2011-11-15 by Fredrik Wendt

Att behärska testdriven utveckling (TDD) och clean code, och att kunna skriva med det i CV:t och visa på praktiska kunskaper – det ökar krasst anställningsbarheten på de flesta studenter (och redan anställda) med en rejäl faktor. En tydlig “anledning” till att företag ute på marknaden köper in Coding Dojo-hjälp från Squeed är just att för få utvecklare faktiskt vet hur man skriver kod som blir möjlig att underhålla och leva med. Kass kod = kasst projekt och ännu sämre kod = ännu sämre möjlighet att rädda projekten. En annan faktor är givetvis det ännu mer kortsiktiga i att buggar som upptäcks tidigt är många gånger billigare att upptäcka och rätta än de som upptäcks senare i kedjan. Att ha utvecklare som jobbar testdrivet är helt enkelt ett sätt att få ned totalkostnaden.

Att kunna skriva bra kod är alltså alltför sällsynt och därför väldigt attraktivt. Detta tycker vi på Squeed är hemskt synd. För att motverka detta anordnar vi bl a Javaforum och nforum (nästa gång 24 november), håller i den öppna Coding Dojon JDojo@Gbg utöver att vi givetvis erbjuder professionell hjälp (konsulting).

Nyligen besökte vi dessutom DatE-IT och låter nu 16 studenter få ta del av detta kompetenspaket (plus mat). Utöver detta har Squeed också försökt få in fler kvalitativa utvecklare på banan genom att gå som lärare på KYH:s Agile Web Developer-utbildning och lägga grunden för deras utveckling.

Bidra till communityn?

Ja, vi tror att vi bidrar till branschen och communityn i Göteborg på detta sätt. Vi tror att det är ett sätt inte bara stötta de enskilda individer som går/får utbildning, utan även att det höjer ribban i branschen. Om du har idéer på andra saker vi kan eller bör göra tas detta emot med varm hand.

Kata: Authentication Filter in Java EE

Posted on 2011-09-21 by Fredrik Wendt

This is an exercise I’ve used to demonstrate how awkward unit testing can be if you can’t use a mocking framework. It’s an almost real work life situation (disclaimer: you should perhaps use container based authentication and JAAS) where we’re using API:s in a Java EE Server, adding two collaborators and then writing the logic combining it all.

No group has (yet) completed the entire task within 90 minutes – you might want to start/focus on using one collaborator only (I suggest the LDAP collaborator).

Originally posted on codingdojo.org.

When cleaning up a folder at work, I found this old document – it’s some form of a logical flow chart of the filter to write.

Here we go …

Background

In this Kata, your a programmer at ABC Corp and you’re making a new web app from scratch. After the head architect started working on this, it’s now up to you to make sure these tasks are completed:

allow authentication using request parameters
all authentication/login attempts should be verified agains LDAP
successful logins should be recorded in the single sign on registry

However, you’re not the only programmer (team) adressing this web app, so the LDAP is written by another team and what you have right now is this interface:

 public interface LdapAuthenticationGateway {
   boolean credentialsAreValid(String userName, String password);
 }

and the single sign on registry is also written by another team, leaving you with this interface:

 public interface SingleSignOnRegistry {
   boolean tokenIsValid(String token);
   String registerNewSession(String userName);
   void endSession(String token);
 }

Your job basically is to write one or more javax.servlet.Filter that handles incoming requests and act according to whether there’s a cookie with a SSO token, username+password parameters etc.

It’s assumed that there’s some form of DependencyInjection framework in place – to get a handle to the SingleSignOnRegistry or the LdapAuthenticationGateway, you’ll simply have to provide something like:

 public void setSingleSignOnRegistry(SingleSignOnRegistry registry) {
   ...
 }

About this kata

This “real life” scenario has been used to demonstrate how mocking (using Mockito) can be useful. We’ve combined it with BDD and JDojo@Gbg will try to practice TDD using this kata (without mocking) next time around.

(“Real life” is quoted – proper JEE authentication should be tied into the container etc etc … The point with this exercise is that it’s fairly easy to explain how it should work and what needs to be done here with “real” Java EE API:s, and then focus on the “How to develop” aspect (TDD), but also to show/talk about the difference between mocking and stubbing.)

Squeed Team Blog

Tag Archives: jdojo@gbg