Jag fick ett ett uppdrag av jobbet för någon dag sedan och har funderat lite på det och tänkte att jag skulle skriva ner lite tankar runt detta så att jag kanske kan komma ihåg det. Det vi ska försöka att åstadkomma är ett gemensamt tänk runt automatiska tester på xUnit-formen.
Som de flesta som har läst lite om tester automation vet är det mycket billigare att rätta ett fel direkt än om man väntar en dag, eller en månad. Tar det tid innan man rättar felet har man hunnit glömma mycket om vad det var man skulle lösa och hur man resonerade när man skulle lösa det. Koden som blir kvar blir ett dokument på hur det är löst men säger inte så mycket om varför du valde den ena av två lösningar. Det skulle bli hela romaner i kommentarerna om man skulle få med de typen av information.
Hur drabbar detta dina tester. Jo, det ger att du vill ha snabba tester som du kan se till att de körs i samband med kompilering. Det är då du vet vad du har gjort och vad det är du har ändrat. Det finns en regel som säger att du bör kunna köra åtminstone tusen tester på en sekund för att de ska räknas som snabba. Det innebär i de allra flesta fall att dina tester inte har tid att vänta på en sql-fråga eller webbservice-anrop.
Men ibland vill man trots allt testa sina integrationer och även få en "hela vägen" känsla för att det fungerar. De snabba testerna kommer att per definition bara testa små fragment av din applikation. Många små tester kan testa hela applikationen men om du inte börjar med en strikt tdd-approch kommer det målet vara väldigt svårt att uppnå och många gånger även väldigt dyrt. Det kan alltså vara idé att ha en uppsättning med tester som där det är tillåtet att testerna får ta tid. Dessa skulle förslagsvis köras på natten i en bygg-server.
Vi har alltså behov av två testbibliotek för våra xUnit-tester. Snabba och långsamma. Jag kan dock se behov av ett tredje bibilotek med tester och det är integrationstester. Med integration i detta fall menar jag den integration som inte kan fungera likadant i utvecklar, byggmiljö som i produktionsmiljö. Saker som skulle kunna separera ett test från de andra är att ett anrop måste göras över en vpn-tunnel och att detta inte går att lösa i de långsamma testerna. Alltså att ett manuellt arbete måste utföras vilket man inte kan kräva att det görs varje natt.
Så för att summera. Jag kommer att rekomendera att vi från nästa beslutspunkt har två obligatoriska xUnit-projekt i våra lösningar och i dessa organiserar våra tester. Detta för att kunna fånga så många fel som möjligt i tidigast möjliga skede utan att för den skull offra möjligheten till att ha långsamma "täcker allt" tester där de kan vara lämpliga. Om man önskar kan man naturligtvis ha flera av varje testtyp men det är testprestanda som bestämmer i första hand.
lördag 8 oktober 2011
torsdag 12 maj 2011
Seven languages in seven weeks - Erlang
Det femte språket i boken Seven Languages in Seven weeks av Bruce Tate är Erlang. Ett språk som togs fram av Ericsson då inga andra var bra nog. Erlang har ett par designmål som skiljer det från andra språk. Det hanterar väldigt många saker parallellt. Språket är tar även ett annat grepp på felhantering som kort och gott går ut på att det är helt ok att en process dör ibland.
Erlang - dag 1
Erlang har fått en del inspiration från Prolog. Faktum är att man började med att modifiera Prolog för att få det resultat man önskade. Så mycket av syntaxen är relativt lik. Man har tuples, atoms. Men inga objekt.
Erlang är trots att det är ett högnivå-språk lämpligt att köra hårdvarunära då det finns stöd för att manipulera bits och bytes. Erlang dessutom ruskigt stora tal naturligt. Så många siffror du får plats med i minnet.
Precis som med Prolog använder man rekursiva strukturer för att lösa problem.
Erlang - dag 2
För en Java-utvecklare är annonyma funktioner inget nytt. Även om det skiljer en del mellan den objektorienterade approchen och den i Erlang. Dock blir det lite mer spännande i Erlang som som är dynamiskt typat. Funktionen du får kan ju vara vilken funktion som helst.
En styrka med annonyma funktioner är att du precis som i Ruby kan skriva en funktion som du kör på varje element i en lista och du kan enkelt återanvända dina funktioner på vilken lista som helst.
Erlang - dag 3
Dag tre går igenom de parallella verktyg som Erlang har. Principen är väldigt enkel och bygger på koncepten om Actors och Messages som vi sett tidigare. Det finns några inbyggda sätt att skapa processer och att skicka meddelanden till den kö som varje process är utrustad med. Sedan kommer processen att beta av kön ett meddelande i taget. Det är höggradigt asynkrona meddelanden som skickas så vill man åstadkomma synkrona meddelanden får man ta till lite trick, men i princip får man vänta på att man får ett asynkront meddelande tillbaka. I princip kanske man kan säga att alla applikationer man bygger i princip blir som en liten svärm med webservrar som löser var sin uppgift.
Felhantering i Erlang går i mångt och mycket ut på att låta saker dö. Tricket är att inte hantera något tillstånd. Alla funktionsanrop bär med sig all information den behöver och nästa anrop kommer, förutsatt att samma information skickas in, ge samma resultat. Poängen med detta är att det lättare att döda en process och starta den igen om något blivit sjukt än att försöka att hantera fel. Den nya processen kommer att ge samma resultat som den gamla så det är ingen som kommer att bry sig kort och gott.
Jag är lite besviken på kapitlet om Erlang. Jag känner att jag saknar kopplingen till verkligheten. Kapitlet kändes akademiskt. Jag förstår att tillstånd är något som är dåligt om man vill hantera många saker samtidigt men samtidigt så har de flesta applikationer jag träffat på små beroenden på vad klockan är, eller hur många som är inloggade. Var tar all denna information vägen i en Erlangapplikation?
Jag har en teori om den här boken. Den är inte till för att ge en översikt på ett antal språk så att man ska kunna jämföra dem och kanske välja ut ett för att lära sig "på riktigt". Bokens syfte är att lära ut funktionell programmering, men genom att sockra med Ruby som objektorienterat språk och Io som är likt javascript så märker man inte hur man sakta lär sig funktionsbaserat tänkande.
Erlang - dag 1
Erlang har fått en del inspiration från Prolog. Faktum är att man började med att modifiera Prolog för att få det resultat man önskade. Så mycket av syntaxen är relativt lik. Man har tuples, atoms. Men inga objekt.
Erlang är trots att det är ett högnivå-språk lämpligt att köra hårdvarunära då det finns stöd för att manipulera bits och bytes. Erlang dessutom ruskigt stora tal naturligt. Så många siffror du får plats med i minnet.
Precis som med Prolog använder man rekursiva strukturer för att lösa problem.
Erlang - dag 2
För en Java-utvecklare är annonyma funktioner inget nytt. Även om det skiljer en del mellan den objektorienterade approchen och den i Erlang. Dock blir det lite mer spännande i Erlang som som är dynamiskt typat. Funktionen du får kan ju vara vilken funktion som helst.
En styrka med annonyma funktioner är att du precis som i Ruby kan skriva en funktion som du kör på varje element i en lista och du kan enkelt återanvända dina funktioner på vilken lista som helst.
Erlang - dag 3
Dag tre går igenom de parallella verktyg som Erlang har. Principen är väldigt enkel och bygger på koncepten om Actors och Messages som vi sett tidigare. Det finns några inbyggda sätt att skapa processer och att skicka meddelanden till den kö som varje process är utrustad med. Sedan kommer processen att beta av kön ett meddelande i taget. Det är höggradigt asynkrona meddelanden som skickas så vill man åstadkomma synkrona meddelanden får man ta till lite trick, men i princip får man vänta på att man får ett asynkront meddelande tillbaka. I princip kanske man kan säga att alla applikationer man bygger i princip blir som en liten svärm med webservrar som löser var sin uppgift.
Felhantering i Erlang går i mångt och mycket ut på att låta saker dö. Tricket är att inte hantera något tillstånd. Alla funktionsanrop bär med sig all information den behöver och nästa anrop kommer, förutsatt att samma information skickas in, ge samma resultat. Poängen med detta är att det lättare att döda en process och starta den igen om något blivit sjukt än att försöka att hantera fel. Den nya processen kommer att ge samma resultat som den gamla så det är ingen som kommer att bry sig kort och gott.
Jag är lite besviken på kapitlet om Erlang. Jag känner att jag saknar kopplingen till verkligheten. Kapitlet kändes akademiskt. Jag förstår att tillstånd är något som är dåligt om man vill hantera många saker samtidigt men samtidigt så har de flesta applikationer jag träffat på små beroenden på vad klockan är, eller hur många som är inloggade. Var tar all denna information vägen i en Erlangapplikation?
Jag har en teori om den här boken. Den är inte till för att ge en översikt på ett antal språk så att man ska kunna jämföra dem och kanske välja ut ett för att lära sig "på riktigt". Bokens syfte är att lära ut funktionell programmering, men genom att sockra med Ruby som objektorienterat språk och Io som är likt javascript så märker man inte hur man sakta lär sig funktionsbaserat tänkande.
fredag 6 maj 2011
Seven languages in seven weeks - Scala
Dags för språk nummer fyra ur boken Seven languages in seven weeks. Nu blir det Scala. Ett språk som många ser som språket som kommer att Java som huvudspråk till JVM. En av fördelarna med Scala är att det är kompatibelt med Java. Har du 10 år av kod med dig från Java så behöver du inte börja med att skriva om den utan du kan återanvända dina favoritfunktioner från Scala.
Scala - dag 1
Första dagen med Scala var rätt trist, lite syntax varav det mesta känns igen från de flesta c-derivat. Så det var inte mycket som kändes nytt. Det som var lite intressant var att man valt att ha mixins eller moduler (ruby resp io) och för att förvirra lite kallar dem för traits. Jag hoppas på en roligare dag två :)
Scala - dag 2
Idag har vi gått igenom Scalas nyckelord var och val. Skillnaden mellan dessa är om variabeln som deklareras är mutable (kan förändras) eller inmutable (kan inte förändras). Genom att ha stora delar av sin kod inmutable kan man utradera mycket av de problem som objektorienterade språk har med parallell körning, tex över flera processorer.
En stor del av kapitlet ägnas åt Scalas collections. Dessa är i mångt och mycket också uppbygda runt inmutable objects. Tex om du lägger till ett objekt i en lista får du tillbaka en helt ny lista i stället för att behöva oroa dig för om din lista har förändrats på oväntat sätt. Jag uppfattar det som kanske något ineffektivt men förstår att vinsten kommer när man börjar arbeta med parallell bearbetning.
Scalas collections kan användas i vanliga for-loopar men tanken är att man ska använda dem funktionellt. Alltså finns det sätt att skicka in en funktion som ska köras på alla objekt tex på din lista.
Scala - dag 3
Under dag 3 visades den inbyggda xml-hanteringen där xml kan definieras som vilken variabel som helst.
Patternmatching är en funktion som lite kan jämföras med de logiska vilkoren i prolog.
Parallellism i Scala liknar till viss del den i Io då den använder actors och meddelanden.
Lite sammanfattning om Scala.
Jag uppfattar Scala som en utveckling av Java där man kunnat släppa kravet på bakåtkompabilitet som finns. Så att byta ut trådbaserad parallellsim mot actors. Införa inmutable objects och functionalism m.m. Trots allt detta nya så kan man ändå återanvända sina gamla javabibliotek. Det är ganska trevligt tycker jag.
Scala - dag 1
Första dagen med Scala var rätt trist, lite syntax varav det mesta känns igen från de flesta c-derivat. Så det var inte mycket som kändes nytt. Det som var lite intressant var att man valt att ha mixins eller moduler (ruby resp io) och för att förvirra lite kallar dem för traits. Jag hoppas på en roligare dag två :)
Scala - dag 2
Idag har vi gått igenom Scalas nyckelord var och val. Skillnaden mellan dessa är om variabeln som deklareras är mutable (kan förändras) eller inmutable (kan inte förändras). Genom att ha stora delar av sin kod inmutable kan man utradera mycket av de problem som objektorienterade språk har med parallell körning, tex över flera processorer.
En stor del av kapitlet ägnas åt Scalas collections. Dessa är i mångt och mycket också uppbygda runt inmutable objects. Tex om du lägger till ett objekt i en lista får du tillbaka en helt ny lista i stället för att behöva oroa dig för om din lista har förändrats på oväntat sätt. Jag uppfattar det som kanske något ineffektivt men förstår att vinsten kommer när man börjar arbeta med parallell bearbetning.
Scalas collections kan användas i vanliga for-loopar men tanken är att man ska använda dem funktionellt. Alltså finns det sätt att skicka in en funktion som ska köras på alla objekt tex på din lista.
Scala - dag 3
Under dag 3 visades den inbyggda xml-hanteringen där xml kan definieras som vilken variabel som helst.
Patternmatching är en funktion som lite kan jämföras med de logiska vilkoren i prolog.
Parallellism i Scala liknar till viss del den i Io då den använder actors och meddelanden.
Lite sammanfattning om Scala.
Jag uppfattar Scala som en utveckling av Java där man kunnat släppa kravet på bakåtkompabilitet som finns. Så att byta ut trådbaserad parallellsim mot actors. Införa inmutable objects och functionalism m.m. Trots allt detta nya så kan man ändå återanvända sina gamla javabibliotek. Det är ganska trevligt tycker jag.
lördag 30 april 2011
Seven languages in seven weeks - Prolog
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å.
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å.
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
