Det tredje språket i boken Seven languages in seven weeks är Prolog och det är det första språk i boken som jag faktskt provat då det var en av programmeringskurserna på högskolan. Då tyckte jag prolog var ganska roligt.
Prolog - dag 1
Prolog är baserat på fakta och regler. Det som skiljer prolog från de tidigare språken i boken är att du inte talar om för Prolog hur dessa fakta och regler ska behandlas. Det fixar Prolog själv. Det enda du behöver göra efter ha matat Prolog med fakta och regler är att ställa frågor och Prolog svarar. För ett antal applikationer ger detta fantastiskt små och överskådliga program.
Prolog - dag 2
Dag 2 handlade mest om rekursiva anrop och listor. Att med hjälp av en rekursiv logisk regel summera ihop värdena i en array ställer begreppen lite på huvudet. Jag förstår vad som händer men jag känner att jag har en lång resa innan jag skulle komma på själv att jag skulle behandla en array på det sättet. Det ser synnerligen inneffektivt ut med alla rekursiva anrop men man har tydligen lyckats att optimera för det.
Prolog - dag 3
Prolog har några styrkor och en av de mest uppenbara visades med ett exempel av hur kort ett program blir som löser soduko. 25-30 rader med logiska regler, sedan är det bara att köra. Det är så att jag kommer på mig att undra om det inte finns prolog-motorer för java eller .net som man skulle kunna använda på de problem som man kan beskriva med logiska regler. För på rätt problem hinner du inte starta kompilatorn i Visual Studio innan Prolog har levererat en färdig applikation.
Allt är inte lätt och smidigt i Prolog men jag kan definitivt se att det finns många problem där man skulle ha mycket att vinna på att hitta en prolog-inspirerad väg till lösningen. Att inte beskriva lösningen utan att beskriva problemet är ibland mycket enklare helt enkelt.
Tyvärr är Prolog gammalt och inte speciellt utvecklat för att köras över flera trådar, flera processer etc etc. Det gör att jag känner att det här kapitlet mest har varit en teoretisk övning. En mycket intressant tankeexperiment men jag kommer nog inte att ta den vidare till någon mer användbar nivå.
lördag 30 april 2011
torsdag 21 april 2011
Seven languages in seven weeks - Io
Då var det dags för språk nummer två. Jag tror väl inte att jag klarar att hålla ett språk i veckan nu jag har det första språket som facit. Det andra språket heter Io, ett namn som gör det svårt att söka på. Io Language ger lite bättre träffar men det är ett illa valt namn.
Io - dag 1
Io är inte ett objektorienterat språk som Ruby, Java eller C# även om det finns objekt. Io är likt Javascript protoyp-baserat. I sak handlar det om att man i stället för att skriva klasser som man har som fabrik för att skapa objekt så kopierar man existerande objekt och använder dessa som mall.
Precis som med första dagen för Ruby så har vi gått igenom lite syntax. Precis som med Ruby så använder Io få paranteser och något som gör Io lite mer annorlunda syntaxmässigt är att man inte heller håller ihop objekt och egenskap med punkt. Det gör det lite svårt att läsa Io-kod för mig då jag inte riktigt lyckas lista ut om det är objekt, metod eller egenskap som jag tittar på. Något som osökt leder mig in på nästa egenskap för Io.
Allt är objekt. Man gör kort och gott inte skillnad på om det är en metod eller egenskap som du arbetar på. Kanske något förenklat man kan säga när du begär att få ett värde från en egenskap så körs det en liten metod som returnerar den egenskapen och om en metoden är en rad eller hundra som i sin tur anropar hundra andra spelar ingen roll.
Vad mer att säga från första dagen med Io. Jo, syntaxen är väldigt avskalad. Syntaxsocker existerar inte eller kommer i väldigt små mängder.
Dags för dag två.
Io - dag 2
Dag två handlade mycket om att använda de slots och även att ge en insikt i att allt som sker i Io är en form av meddelanden.
En av konsekvenserna av att Io är uppbyggt som det är ger att du kan modifiera väldigt mycket, tex är alla operatorer som ==, < etc metoder, något speciella metoder men i princip som vilken annan metod som helst.
Meddelanden tog mig en stund att förstå, jag läste sidorna både tre och fyra gånger innan jag lyckades förstå vad det var som hände. Känns ganska självklart nu så jag kanske hade en dålig dag :-). Kort och gott är i princip alla anrop i Io ett meddelande och meddelanden har en avsändare, mottagare, namn och argument. Att ha kunskapen om vem som anropar, och vad som anropades och med vilka parametrar kan ge en del spännande lösningar.
Io - dag 3
Dag 3 börjar med en diskussion om domänspecifika språk. En av uppgifterna i slutet av dagen gick ut på att man skulle ta en text-fil och mer eller mindre behanda innehållet i text-filen som kod. Samtidigt som jag blir imponerad över möjligheterna blir jag också lite rädd över om någon kommer att förstå vad som händer.
Io har precis som Ruby en method-missing metod och den erbjuder mer eller mindre samma möjligheter som i Ruby
Io har funktioner för Concurrency där jag bitvis förstår storheten men för vissa saker går den mig helt förbi. Där jag inte förstår är varför cooperativ multitasking är bra. Anledningen till att den inte är bra att utvecklaren måste komma ihåg att lägga in anrop som släpper kontrollen på lämpliga ställen. Preemtive multitasking befriar oss från den uppgiften och vi slipper bekymra oss om att vår applikation kommer att göra systemet oresponsivt. Men Io har en kooperativ modell. Syftet är kort och gott att om inte en "tråd" inte kan avbrytas när som helst så blir systemen förutsägbara då din process inte kan avbrytas hur som helst. Jag kan förstå men det känns som ett steg tillbaka.
En annan sak som har jag lite lättare att ta till mig är att man har en Actor-baserad modell för trådarna. I princip innebär det att varje tråd äger sitt eget data. Jämför man med C# eller Java så delar alla trådar i en process på samma minne och kan därmed också ställa till problem för varandra på oväntade sätt.
Efter har testat lite med Io känner jag att jag förstår Javascript bättre. Men jag kan inte säga att jag på något sätt känner mig hugad att använda språket. Den avskalade syntaxen som gör det enkelt att göra domänspecifika språk skulle kunna vara intressant men jag känner inte att jag kan komma på något projekt där Io styrkor skulle få mig att välja bort "standard"-språken.
Io - dag 1
Io är inte ett objektorienterat språk som Ruby, Java eller C# även om det finns objekt. Io är likt Javascript protoyp-baserat. I sak handlar det om att man i stället för att skriva klasser som man har som fabrik för att skapa objekt så kopierar man existerande objekt och använder dessa som mall.
Precis som med första dagen för Ruby så har vi gått igenom lite syntax. Precis som med Ruby så använder Io få paranteser och något som gör Io lite mer annorlunda syntaxmässigt är att man inte heller håller ihop objekt och egenskap med punkt. Det gör det lite svårt att läsa Io-kod för mig då jag inte riktigt lyckas lista ut om det är objekt, metod eller egenskap som jag tittar på. Något som osökt leder mig in på nästa egenskap för Io.
Allt är objekt. Man gör kort och gott inte skillnad på om det är en metod eller egenskap som du arbetar på. Kanske något förenklat man kan säga när du begär att få ett värde från en egenskap så körs det en liten metod som returnerar den egenskapen och om en metoden är en rad eller hundra som i sin tur anropar hundra andra spelar ingen roll.
Vad mer att säga från första dagen med Io. Jo, syntaxen är väldigt avskalad. Syntaxsocker existerar inte eller kommer i väldigt små mängder.
Dags för dag två.
Io - dag 2
Dag två handlade mycket om att använda de slots och även att ge en insikt i att allt som sker i Io är en form av meddelanden.
En av konsekvenserna av att Io är uppbyggt som det är ger att du kan modifiera väldigt mycket, tex är alla operatorer som ==, < etc metoder, något speciella metoder men i princip som vilken annan metod som helst.
Meddelanden tog mig en stund att förstå, jag läste sidorna både tre och fyra gånger innan jag lyckades förstå vad det var som hände. Känns ganska självklart nu så jag kanske hade en dålig dag :-). Kort och gott är i princip alla anrop i Io ett meddelande och meddelanden har en avsändare, mottagare, namn och argument. Att ha kunskapen om vem som anropar, och vad som anropades och med vilka parametrar kan ge en del spännande lösningar.
Io - dag 3
Dag 3 börjar med en diskussion om domänspecifika språk. En av uppgifterna i slutet av dagen gick ut på att man skulle ta en text-fil och mer eller mindre behanda innehållet i text-filen som kod. Samtidigt som jag blir imponerad över möjligheterna blir jag också lite rädd över om någon kommer att förstå vad som händer.
Io har precis som Ruby en method-missing metod och den erbjuder mer eller mindre samma möjligheter som i Ruby
Io har funktioner för Concurrency där jag bitvis förstår storheten men för vissa saker går den mig helt förbi. Där jag inte förstår är varför cooperativ multitasking är bra. Anledningen till att den inte är bra att utvecklaren måste komma ihåg att lägga in anrop som släpper kontrollen på lämpliga ställen. Preemtive multitasking befriar oss från den uppgiften och vi slipper bekymra oss om att vår applikation kommer att göra systemet oresponsivt. Men Io har en kooperativ modell. Syftet är kort och gott att om inte en "tråd" inte kan avbrytas när som helst så blir systemen förutsägbara då din process inte kan avbrytas hur som helst. Jag kan förstå men det känns som ett steg tillbaka.
En annan sak som har jag lite lättare att ta till mig är att man har en Actor-baserad modell för trådarna. I princip innebär det att varje tråd äger sitt eget data. Jämför man med C# eller Java så delar alla trådar i en process på samma minne och kan därmed också ställa till problem för varandra på oväntade sätt.
Efter har testat lite med Io känner jag att jag förstår Javascript bättre. Men jag kan inte säga att jag på något sätt känner mig hugad att använda språket. Den avskalade syntaxen som gör det enkelt att göra domänspecifika språk skulle kunna vara intressant men jag känner inte att jag kan komma på något projekt där Io styrkor skulle få mig att välja bort "standard"-språken.
lördag 9 april 2011
Seven languages in seven weeks - Ruby
Jag har börjat läsa Bruce Tates bok, 7 languages in 7 weeks och tänke skriva lite "dagbok" om upplevelsen.
Sju språk är ett ganska mastigt projekt att ge sig på men boken aspirerar inte på att göra dig till mästare på något sätt utan snarare att ge en översikt de olika språkens styrkor och svagheter så att man kan utvärdera vilket språk som lämpar sig för vilken uppgift.
Ruby - dag 1
Första går igen lite av den grundläggande syntaxen. Installation av Ruby var smidig och med språkreferensen på nätet så löste jag till och med extrauppgiften utan någon större utmaning. Jag hoppas att det blir lite svårare framåt, även om självförtroendet mådde bra av första dagen. Som java/C# programmerare kände jag igen mig väldigt mycket och det var bara avsaknaden av parenteser som kändes lite konstig.
Ruby - dag 2
Den andra dagen gav en betydligt större utmaning än dag ett och jag får erkänna att jag har fuskat med övningsuppgifterna. Jag får gå tillbaka och göra ett nytt försök på dem lite senare när begreppen har trillat ner lite bättre.
Dagen började lite stilla med syntax för funktioner, arrayer och hashmaps. Att hashmaps är implementerade direkt i syntax kändes lite konstigt men när jag tänker efter så är det inte ofta som jag använt något annat än standardvarianten i vare sig Java eller C# och då kanske man lika gärna kan stöjda dem direkt i syntax.
Code blocks är ett av de begrepp jag ännu inte lyckats ta till mig helt och hållet. Det kanske i viss mån kan liknas vid delegater i C#. Kort och gott kan du definiera ett block med kod som argument till en metod. Nyckelordet yield agerar som en platshållare för blocket. Lite som att skriva en Template Method.
Mixin kan liknas vid Visitor-pattern. Man implementerar en mixin genom att skriva en module. Denna modul kan sedan inkluderas i vilken klass som helst, i princip. Två vanliga mixins är enumerable och comparable som man använda i sina klasser för att iterera och jämföra.
Nu är jag lite lätt skräckslagen inför dag 3. :-)
Ruby - Dag 3
Dag tre börjar vi titta var det är som Ruby speciellt och inte bara en annan syntax. I Rubys fall är det speciella metaprogrammering. Alltså att kunna skriva kod som bygger annan kod.
Öppna klasser är något som går emot mycket av det jag lärt mig tidigare där open-closed-priciple har varit en grundsten. Att en klass i Ruby är öppen innebär att du när som helst kan definiera om hur en klass fungera. Det är bara att definiera om metoden till att göra det du vill att den ska göra just nu. Men som Bruce skriver i boken. Har du bett om en vass kniv kan du skära dig rejält. I C# är det nog närmast method extensions som till viss del utför samma funktionallitet, fast mycket mer begränsat.
En annan vanlig metaprogrammerings metod är att använda en "systemmetod" som heter method_missing. Denna metod skulle jag jämföra med en 404 i html och precis som med en 404 där du kan ha en handler som utför någon operation så kan du välja att implementera vad som ska hända när någon försöker att anropa en metod som inte finns. Detta verkar vara användbart när man har scenarion där man i java eller c# hade använt en parameter för att hantera att det finns för många varianter för att det ska gå att hantera med metoder. Kraftfullt i en del situationer kan jag tänka mig.
Det tredje begreppet är modul och jag är inte riktigt säker på vad som skiljer det från en mixin från dag två. Konceptet är att lägga till funktionalitet till sin klass.
Övningen upplevde jag som enklare än för dag 2 av någon anledning. Men nu får det gå någon dag innan jag ger mig på nästa språk, Io.
Sju språk är ett ganska mastigt projekt att ge sig på men boken aspirerar inte på att göra dig till mästare på något sätt utan snarare att ge en översikt de olika språkens styrkor och svagheter så att man kan utvärdera vilket språk som lämpar sig för vilken uppgift.
Ruby - dag 1
Första går igen lite av den grundläggande syntaxen. Installation av Ruby var smidig och med språkreferensen på nätet så löste jag till och med extrauppgiften utan någon större utmaning. Jag hoppas att det blir lite svårare framåt, även om självförtroendet mådde bra av första dagen. Som java/C# programmerare kände jag igen mig väldigt mycket och det var bara avsaknaden av parenteser som kändes lite konstig.
Ruby - dag 2
Den andra dagen gav en betydligt större utmaning än dag ett och jag får erkänna att jag har fuskat med övningsuppgifterna. Jag får gå tillbaka och göra ett nytt försök på dem lite senare när begreppen har trillat ner lite bättre.
Dagen började lite stilla med syntax för funktioner, arrayer och hashmaps. Att hashmaps är implementerade direkt i syntax kändes lite konstigt men när jag tänker efter så är det inte ofta som jag använt något annat än standardvarianten i vare sig Java eller C# och då kanske man lika gärna kan stöjda dem direkt i syntax.
Code blocks är ett av de begrepp jag ännu inte lyckats ta till mig helt och hållet. Det kanske i viss mån kan liknas vid delegater i C#. Kort och gott kan du definiera ett block med kod som argument till en metod. Nyckelordet yield agerar som en platshållare för blocket. Lite som att skriva en Template Method.
Mixin kan liknas vid Visitor-pattern. Man implementerar en mixin genom att skriva en module. Denna modul kan sedan inkluderas i vilken klass som helst, i princip. Två vanliga mixins är enumerable och comparable som man använda i sina klasser för att iterera och jämföra.
Nu är jag lite lätt skräckslagen inför dag 3. :-)
Ruby - Dag 3
Dag tre börjar vi titta var det är som Ruby speciellt och inte bara en annan syntax. I Rubys fall är det speciella metaprogrammering. Alltså att kunna skriva kod som bygger annan kod.
Öppna klasser är något som går emot mycket av det jag lärt mig tidigare där open-closed-priciple har varit en grundsten. Att en klass i Ruby är öppen innebär att du när som helst kan definiera om hur en klass fungera. Det är bara att definiera om metoden till att göra det du vill att den ska göra just nu. Men som Bruce skriver i boken. Har du bett om en vass kniv kan du skära dig rejält. I C# är det nog närmast method extensions som till viss del utför samma funktionallitet, fast mycket mer begränsat.
En annan vanlig metaprogrammerings metod är att använda en "systemmetod" som heter method_missing. Denna metod skulle jag jämföra med en 404 i html och precis som med en 404 där du kan ha en handler som utför någon operation så kan du välja att implementera vad som ska hända när någon försöker att anropa en metod som inte finns. Detta verkar vara användbart när man har scenarion där man i java eller c# hade använt en parameter för att hantera att det finns för många varianter för att det ska gå att hantera med metoder. Kraftfullt i en del situationer kan jag tänka mig.
Det tredje begreppet är modul och jag är inte riktigt säker på vad som skiljer det från en mixin från dag två. Konceptet är att lägga till funktionalitet till sin klass.
Övningen upplevde jag som enklare än för dag 2 av någon anledning. Men nu får det gå någon dag innan jag ger mig på nästa språk, Io.
onsdag 6 april 2011
SDC2011
Jag var på Swedish Developer Conference 2011 tidigare i veckan och tänkte försöka att skriva ihop en liten sammanfattning av vad jag såg. För att vi skulle få med så många som möjligt på jobbet var vi bara där på måndagen om det var på tisdagen allt roligt hände missade jag det.
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.
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.
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.
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.
Prenumerera på:
Inlägg (Atom)
Inlägg
