Det första som är värt att nämnas är att konferensen har vuxit en del sedan jag var där för två år sedan. Både antalet besökare, spår och dagar hade ökat. Kanske i viss mån på bekostnad av kvalitet tyvärr. Man förväntar sig trots allt ett visst mått av show. Men SDC kanske fungerar lite som plantskola för blivant stjärnor.
Som en generell notering så verkar samtliga föreläsare som jag såg förespråka TDD i en form eller annan.
Första passet:
Alistair Cockburn - On Beyond Agile: The New Face Of Software Engineering
Alistar höll i årets keynote och pratade om mjukvaruutvecklings framtid utifrån 5 delar. Tyvärr kände jag att han höll sig lite över mitt huvud så jag hade svårt att ta till mig det han sa. Det blev lite för inriktat på ledning och jag tappade intresset. Det som fastnade var runt de olika typer av spel som han menar att vi är med i. Där projektet är ett spel med tydligt slut. Jämför med tex att leda ett företag där spelet närmast går ut på att befinna sig i spelet, utan något annat mål än att befinna sig i spelet. Beroende på vilket spel man spelar så kan det ge olika resultat, tex om man spelar spelet för att befinna sig i det kanske man inte är så intresserad av att komma till avslut.
Niel Ford - Functional Thinking
Tyvärr var jag tvungen att hjälpa kollegor som inte hade förmånen under denna session så jag kände att jag missade lite men några noteringar fick jag med.
- Till skillnad från objektorienterade språk försöker man i möjligaste mån att undvika att hantera tillstånd.
- Man vill ha rena funktioner som inte har bieffekter. Om du kör funktionen på din lokala dator eller i ett kluster över 1000 processorer ska inte spela roll. Funktionen skall oavsett omständigheter ge samma resultat utifrån varje givet input.
- Resultatet i stället för stegen för att åstadkomma resultatet.
Niel hävdade också att tendensen inom programspråksutveckling går mot att implementera funktionella begrepp snarare än att vidareutveckla objektorientering.
Mini coding dojo
Detta var den session som jag valde utifrån personligt intresse. En kata, närmare bestämmt FizzBuzz. Tydligen är det en lek som man kan få göra på mattelektionerna i skolan på mellanstadiet. Man räknar 1, 2, 3, 4, 5 etc. Om det talet man ska säga är delbart med 3 så säger man inte 3 utan Fizz, om ett tal är delbart med 5 säger man Buzz, och om talet är delbart både med 3 och 5 så säger man FizzBuzz. Detta som ett exempel på hur man kan leka leken.
Det vi gjorde var att implementera en klass som fungerade som fusk för den stackars elev som är nervös för att säga fel och därmed få klasskamraternas hån.
Reglerna för katan var att det var en person som programmerarade, med en person som stöd och alla andra tittade på. Vi hade en timer som stod på 7 minuter. När klocka pep så fick den som programmerade gå och sätta sig, bisittaren fick börja programmera och en ur "publiken" fick sätta sig som bisittare. Det sättet att lösa katan skiljde sig en del från de kator jag varit med som mer har varit av typen gruppövning där alla löst samma uppgift och först efteråt jämfört lösningarna. Men det var TDD som gällde. "Publiken" fick kommentera lösningen när testerna lyste grönt.
Ivar Nilsen och Anders Karlsen - Pair programming and TDD in practice
Detta var dagens flopp för min del. För även om det var intresssant att se hur de arbetade sig fram till en lösning genom att använda TDD och parprogrammering så kände jag att jag behövde få någon form av teori för varför de gjorde som de gjorde. Kanske hänvisa till någon studie som kunde säga när man ska och när man inte ska osv. Det blev lite tradigt med 40 minuter där de står och kodar med lite enstaka kommentarer till varandra.
Jag frågade efteråt hur lång tid de hade trott att de 40 minuterna kodning hade tagit om de hade gjort den ensamma och för första gången och de uppskattade det till 6-8 timmar. Tillsammans trodde de att de hade löst det på 2-3 timmar. Något jag hade lite svårt att tro. Att koden blir bättre och har färre buggar kan jag kanske köpa in på som argument för parprogrammering men att den initiala lösningstiden skulle vara hälften låter som fantasier i mina öron.
Gojko Adzic - Winning big with specification by example
Om den förra sessionen var lågvattenmärket så var Gojko dagens höjdpunkt. Han berättade om vilka mönster han kunde utläsa efter att ha studera 50 framgångsrika agila projekt. Många av de slutsatser han kom fram till föll mig i smaken med "test som specifikation" och "frekventa tester".
En sak som jag inte tänkt så mycket på är att vi ofta slänger oss med olika uttryck på saker som är relativt lika. A-TTD och BDD tex är relativt lika och har i mångt och mycket samma mål, även om metoden är lite olika. Gojko beskrev det som det största problemet med att dra slutsatser från de 50 projekten, att se vad de faktiskt gör bakom termerna.
Kort och gott kommer jag att köpa hans bok när den kommer ut. Det var 50 minuter som skapade en hel del nyfikenhet hos mig.
Thomas Lundström - Railsify your web developmentThomas gav ett stelt och nervöst intryck. Att han hade en titel som förmodligen skrämde borde de flesta som skulle kunna vara intresserade gjorde att det var ganska tomt i lokalen. "Vad MS borde ha lärt från Ruby" kanske hade varit en bättre titel. Det var i alla fall vad det handlade om.
- BDD i kulturen. Tex har de flesta projekt körbara specifikationer. Kommer delvis från att Ruby är en dynamiskt språk så den (falska?) säkerheten som kompilatorn ger behöver säkras upp med tester i högre grad och det är något som finns i kulturen menade Thomas på.
- TDD - Även här förmodligen för att Ruby är dynamiskt. Men jag har inte sett ett exempel från MS där loggning, tester etc är en naturlig del av exemplen.
- MVC behöver kanske inte presenteras så mycket men "code behind" har en tendens att bli rätt mycket soppa i.
- Colloborative database development, varje utvecklare har en privat databas så man kan mecka runt utan att störa andra utvecklare. Har verktyg för att "merga" databaser. För .Net skulle man tex kunna använda Migrator.Net för att komma ifrån den gemensamma databasen.
- App-Private Database. Detta koncept gör att varje Ruby-app har sin egen databas och man undviker att jobba mot samma databas. Om en applikation behöver tillgång till en annan applikations databas får man bygga webservices. Idén är att göra små moduler som kan förändras oberoende av varandra. Behöver man ändra i databasen så är det bara den egna applikationen som berörs.
- RESTful -
- DevOps - beskrevs som att ta in driftavdelningen i projekten på samma sätt som man i agila team tagit in testare som en del av teamet.
- Convention over Configuration - Varför ska default-alternativ konfigureras. Syftet är att ta bort alla val som man "måste" göra för att kunna få igång applikationen. Måste man inte göra dem gör man inte fel förrän man faktiskt behöver göra något och då har man en hanterbar konfiguration att förhålla sig till.
- DRY - Don't repeat yourself....
- Scaling out - Dela inget data, inga sessioner gör att det inte spelar någon roll om applikationen körs på 1 eller 100 datorer.
- OSS - var främst riktat till .Net-utvecklarna. Don't be afraid.
- Reference management - även denna till .Nettare. NuGet eller OpenWrap för att hantera olika versioner av dll:er som behövs i applikationer.
Staffan Nöteberg - Regex
Staffan gick igenom grunden i RegEx och visade skillnaderna mellan NonDeterministiska och Deterministiska Finita Automata och vilka konsekvenser. Han visade också de tre kommandon som finns i RegEx och förklarade dessa så att de gick att förstå och vilka typer av applikationer där RegEx är lämpliga att användas.Dock förstörde han min vilja att faktiskt lära mig genom att säga att varje plattform har sin implementation av RegEx och bristen på standard är synnerligen besvärlig. Man måste i princip lära sig hur varje RegEx-kompilator fungerar och vilka vägval som de tar för att kunna förutse vilka resultat man kommer att få ut.
Till sist
Dagen avslutades med att jag fick ett sms, jag hade vunnit. Vunnit ganska stort också tycker jag. En gratis utbildning på ProgramUtvikling i Norge. Tyvärr verkar det som att de två utbildningarna som jag är mest intresserad av inte har några planerade datum så vi får se vad jag hittar på. Att lära sig TDD och A-TDD med Bob Martin himself hade varit ganska stort tycker jag... men så bra verkar det inte bli. Men jag är glad ändå!
Så på det stora hela var jag nöjd med dagen.
Inga kommentarer:
Skicka en kommentar