Man sitter runt ett bord och parprogrammerar skulle man kunna säga.
Syftet är att lära sig TDD och utbyta programmeringserfarenheter genom
att lösa ett enkelt problem, t.ex. poängberäkning i bowling eller
minesweep. Två vid tangentbordet hela tiden sedan roterar man en
person efter varje lyckat test, i alla fall när vi kört ping-pong- metoden.
> Sorry, http://codingdojo.org/ > Man sitter runt ett bord och parprogrammerar skulle man kunna säga. Syftet
> är att lära sig TDD och utbyta programmeringserfarenheter genom att lösa ett
> enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två vid
> tangentbordet hela tiden sedan roterar man en person efter varje lyckat
> test, i alla fall när vi kört ping-pong-metoden.
> Joakim
> On 19 okt 2009, at 11.00, Emil Cardell wrote:
> Dagens noob fråga.Men exakt vad görs på en coding dojo?
> Exempel på vad ni gjorde förra gången?
Man sitter runt ett bord och parprogrammerar skulle man kunna säga. Syftet är att lära sig TDD och utbyta programmeringserfarenheter genom att lösa ett enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två vid tangentbordet hela tiden sedan roterar man en person efter varje lyckat test, i alla fall när vi kört ping-pong-metoden.
Joakim
On 19 okt 2009, at 11.00, Emil Cardell wrote:
Dagens noob fråga.
Men exakt vad görs på en coding dojo?
Exempel på vad ni gjorde förra gången?
Sedan efter ett tag blir alla trötta för att ingen fattar hur man räknar
poäng i bowling, det är då "return 300;" kommer fram! (eller hur var det
Håkan?)
Den 19 oktober 2009 11.12 skrev Joakim Sundén <joakim.sun...@gmail.com>:
> Sorry, http://codingdojo.org/ > Man sitter runt ett bord och parprogrammerar skulle man kunna säga. Syftet
> är att lära sig TDD och utbyta programmeringserfarenheter genom att lösa ett
> enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två vid
> tangentbordet hela tiden sedan roterar man en person efter varje lyckat
> test, i alla fall när vi kört ping-pong-metoden.
> Joakim
> On 19 okt 2009, at 11.00, Emil Cardell wrote:
> Dagens noob fråga.Men exakt vad görs på en coding dojo?
> Exempel på vad ni gjorde förra gången?
On Oct 19, 2009 12:32 p.m., "Anders Jönsson" <joensson.and...@gmail.com> wrote:
Sedan efter ett tag blir alla trötta för att ingen fattar hur man räknar poäng i bowling, det är då "return 300;" kommer fram! (eller hur var det Håkan?)
Den 19 oktober 2009 11.12 skrev Joakim Sundén <joakim.sun...@gmail.com>:
> Sedan efter ett tag blir alla trötta för att ingen fattar hur man räknar
> poäng i bowling, det är då "return 300;" kommer fram! (eller hur var det
> Håkan?)
> Den 19 oktober 2009 11.12 skrev Joakim Sundén <joakim.sun...@gmail.com>:
> Sorry, http://codingdojo.org/ >> Man sitter runt ett bord och parprogrammerar skulle man kunna säga. Syftet
>> är att lära sig TDD och utbyta programmeringserfarenheter genom att lösa ett
>> enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två vid
>> tangentbordet hela tiden sedan roterar man en person efter varje lyckat
>> test, i alla fall när vi kört ping-pong-metoden.
>> Joakim
>> On 19 okt 2009, at 11.00, Emil Cardell wrote:
>> Dagens noob fråga.Men exakt vad görs på en coding dojo?
>> Exempel på vad ni gjorde förra gången?
Cristian,
Du har löst problemet, så jag tror inte att det finns ett behov av att köra någon Coding Dojo. :)
Men om vi gör detta ändå, ska man ta några vapen med sig? Kommer vi att brottas med varandra, eller bara med kod?
Mvh,
Tibi
From: sweden-altnet@googlegroups.com [mailto:sweden-altnet@googlegroups.com] On Behalf Of Cristian Libardo
Sent: Monday, October 19, 2009 12:56 PM
To: sweden-altnet@googlegroups.com
Subject: Re: Coding Dojo
Jag är på.
if user = me:
return 300
2009/10/19 Anders Jönsson <joensson.and...@gmail.com<mailto:joensson.and...@gmail.com>>
Sedan efter ett tag blir alla trötta för att ingen fattar hur man räknar poäng i bowling, det är då "return 300;" kommer fram! (eller hur var det Håkan?)
Den 19 oktober 2009 11.12 skrev Joakim Sundén <joakim.sun...@gmail.com<mailto:joakim.sun...@gmail.com>>:
Man sitter runt ett bord och parprogrammerar skulle man kunna säga. Syftet är att lära sig TDD och utbyta programmeringserfarenheter genom att lösa ett enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två vid tangentbordet hela tiden sedan roterar man en person efter varje lyckat test, i alla fall när vi kört ping-pong-metoden.
Joakim
On 19 okt 2009, at 11.00, Emil Cardell wrote:
Dagens noob fråga.
Men exakt vad görs på en coding dojo?
Exempel på vad ni gjorde förra gången?
Ett alternativ som kanske skulle kunna vara intressant någon gång är en så
kallad Performance Kata. Dvs där en person kodar en kata live framför alla
andra, och sedan diskuterar man det hela efteråt. Ett kul exempel kan ni se
på själva, där Corey Haines BDD:ar fram en string templater inför Orlando
Ruby Users Group:
http://blog.envylabs.com/2009/08/corey-haines-performance-kata/
Någon som vågar göra något sådant? Man kan till och med köra både dojo och
performance kata på samma möte t.ex.
Har aldrig hört det namnet tidigare, det brukar ju kallas "prepared
kata", men Jocke Holm gjorde en sådan med bowling game på Avega för
drygt två år sedan. Det känns mer relevant när en person vill lära ut
något eller visa en ny metod, t.ex. en BDD-smak eller TDD för en grupp
nybörjare. Någon som är sugen på att visa BDD med Ruby och RSpec kanske?
> Ett alternativ som kanske skulle kunna vara intressant någon gång är
> en så kallad Performance Kata. Dvs där en person kodar en kata live
> framför alla andra, och sedan diskuterar man det hela efteråt. Ett
> kul exempel kan ni se på själva, där Corey Haines BDD:ar fram en
> string templater inför Orlando Ruby Users Group: http://blog.envylabs.com/2009/08/corey-haines-performance-kata/
> Någon som vågar göra något sådant? Man kan till och med köra både
> dojo och performance kata på samma möte t.ex.
Visst, och det kan väl alltid vara relevant för oss som grupp? T.ex. att
slaviskt följa en kata såsom Robert C. Martin beskrivit den, för att
därigenom få en känsla för hur en av TDD-världens stora skulle ha attackerat
ett problem, och därefter diskutera vad som var bra och mindre bra i hans
särskilda TDD-"smak". För det behövs inget så exotiskt som rspec och BDD,
utan vanlig C# och NUnit räcker.
> Har aldrig hört det namnet tidigare, det brukar ju kallas "prepared kata",
> men Jocke Holm gjorde en sådan med bowling game på Avega för drygt två år
> sedan. Det känns mer relevant när en person vill lära ut något eller visa en
> ny metod, t.ex. en BDD-smak eller TDD för en grupp nybörjare. Någon som är
> sugen på att visa BDD med Ruby och RSpec kanske?
> Joakim
> On 19 okt 2009, at 13.49, Peter Hultgren wrote:
> Hej gott folk!
> Ett alternativ som kanske skulle kunna vara intressant någon gång är en så
> kallad Performance Kata. Dvs där en person kodar en kata live framför alla
> andra, och sedan diskuterar man det hela efteråt. Ett kul exempel kan ni se
> på själva, där Corey Haines BDD:ar fram en string templater inför Orlando
> Ruby Users Group:
> http://blog.envylabs.com/2009/08/corey-haines-performance-kata/
> Någon som vågar göra något sådant? Man kan till och med köra både dojo och
> performance kata på samma möte t.ex.
jag är på, fast skulle vara kul att prova ett annat format än vad vi gjort
tidigare, tex Hultgrens förslag eller att alla tar med sig datorer och löser
samma uppgifter varefter vi diskuterar de olika lösningarna.
/Torkel
2009/10/19 Peter Hultgren <peter.micros...@gmail.com>
> Visst, och det kan väl alltid vara relevant för oss som grupp? T.ex. att
> slaviskt följa en kata såsom Robert C. Martin beskrivit den, för att
> därigenom få en känsla för hur en av TDD-världens stora skulle ha attackerat
> ett problem, och därefter diskutera vad som var bra och mindre bra i hans
> särskilda TDD-"smak". För det behövs inget så exotiskt som rspec och BDD,
> utan vanlig C# och NUnit räcker.
>> Har aldrig hört det namnet tidigare, det brukar ju kallas "prepared kata",
>> men Jocke Holm gjorde en sådan med bowling game på Avega för drygt två år
>> sedan. Det känns mer relevant när en person vill lära ut något eller visa en
>> ny metod, t.ex. en BDD-smak eller TDD för en grupp nybörjare. Någon som är
>> sugen på att visa BDD med Ruby och RSpec kanske?
>> Joakim
>> On 19 okt 2009, at 13.49, Peter Hultgren wrote:
>> Hej gott folk!
>> Ett alternativ som kanske skulle kunna vara intressant någon gång är en så
>> kallad Performance Kata. Dvs där en person kodar en kata live framför alla
>> andra, och sedan diskuterar man det hela efteråt. Ett kul exempel kan ni se
>> på själva, där Corey Haines BDD:ar fram en string templater inför Orlando
>> Ruby Users Group:
>> http://blog.envylabs.com/2009/08/corey-haines-performance-kata/
>> Någon som vågar göra något sådant? Man kan till och med köra både dojo och
>> performance kata på samma möte t.ex.
> jag är på, fast skulle vara kul att prova ett annat format än vad vi gjort
> tidigare, tex Hultgrens förslag eller att alla tar med sig datorer och löser
> samma uppgifter varefter vi diskuterar de olika lösningarna.
> /Torkel
> 2009/10/19 Peter Hultgren <peter.micros...@gmail.com>
> Visst, och det kan väl alltid vara relevant för oss som grupp? T.ex. att
>> slaviskt följa en kata såsom Robert C. Martin beskrivit den, för att
>> därigenom få en känsla för hur en av TDD-världens stora skulle ha attackerat
>> ett problem, och därefter diskutera vad som var bra och mindre bra i hans
>> särskilda TDD-"smak". För det behövs inget så exotiskt som rspec och BDD,
>> utan vanlig C# och NUnit räcker.
>>> Har aldrig hört det namnet tidigare, det brukar ju kallas "prepared
>>> kata", men Jocke Holm gjorde en sådan med bowling game på Avega för drygt
>>> två år sedan. Det känns mer relevant när en person vill lära ut något eller
>>> visa en ny metod, t.ex. en BDD-smak eller TDD för en grupp nybörjare. Någon
>>> som är sugen på att visa BDD med Ruby och RSpec kanske?
>>> Joakim
>>> On 19 okt 2009, at 13.49, Peter Hultgren wrote:
>>> Hej gott folk!
>>> Ett alternativ som kanske skulle kunna vara intressant någon gång är en
>>> så kallad Performance Kata. Dvs där en person kodar en kata live framför
>>> alla andra, och sedan diskuterar man det hela efteråt. Ett kul exempel kan
>>> ni se på själva, där Corey Haines BDD:ar fram en string templater inför
>>> Orlando Ruby Users Group:
>>> http://blog.envylabs.com/2009/08/corey-haines-performance-kata/
>>> Någon som vågar göra något sådant? Man kan till och med köra både dojo
>>> och performance kata på samma möte t.ex.
Om man vill piffa till lösningen lite kan jag rekommendera att använda
"Object Calisthenics". Ger IMO en annan upplevelse av dojon med mindre fokus
på TDD och mer fokus på OO design. På gott och ont. Försöker fortafarnde
hitta en balans mellan de två.
> Sorry, http://codingdojo.org/ > Man sitter runt ett bord och parprogrammerar skulle man kunna säga. Syftet
> är att lära sig TDD och utbyta programmeringserfarenheter genom att lösa ett
> enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två vid
> tangentbordet hela tiden sedan roterar man en person efter varje lyckat
> test, i alla fall när vi kört ping-pong-metoden.
> Joakim
> On 19 okt 2009, at 11.00, Emil Cardell wrote:
> Dagens noob fråga. Men exakt vad görs på en coding dojo?
> Exempel på vad ni gjorde förra gången?
Den intressantaste delen av en Kata tycker jag är när de inledande testen är
skrivna och det blir dags för den första ordentliga refaktoriseringen (typ
efter nån timma eller två). Det är då de mest givande diskutionerna infinner
sig.
Kan vi inte hoppa till det steget direkt om någon redan från början tar med
sig en bunt rutten legacy code som vi kan refakorisera och designa om? Då
kan vi diskutera god design, clean code och DDD redan från början. Och
slippa den första transportsträckan.
/Carl
2009/10/19 Emil Gustafsson <e...@cellfish.se>
> Om man vill piffa till lösningen lite kan jag rekommendera att använda
> "Object Calisthenics". Ger IMO en annan upplevelse av dojon med mindre fokus
> på TDD och mer fokus på OO design. På gott och ont. Försöker fortafarnde
> hitta en balans mellan de två.
>> Sorry, http://codingdojo.org/ >> Man sitter runt ett bord och parprogrammerar skulle man kunna säga. Syftet
>> är att lära sig TDD och utbyta programmeringserfarenheter genom att lösa ett
>> enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två vid
>> tangentbordet hela tiden sedan roterar man en person efter varje lyckat
>> test, i alla fall när vi kört ping-pong-metoden.
>> Joakim
>> On 19 okt 2009, at 11.00, Emil Cardell wrote:
>> Dagens noob fråga. Men exakt vad görs på en coding dojo?
>> Exempel på vad ni gjorde förra gången?
Absolut, och därav skrev jag att det ger en annan erfarenhet än den
klassiska dojon som är väldigt TDD fokuserad. Och jag skulle aldrig köra
Calisthenics med en grupp som testar coding dojos för första gången. Jag gav
det bara som ett exempel på något man kanske vill överväga att testa. Min
erfarenhet säger att när man kört en dojo med ungefär samma folk en handfull
gånger så vill de flesta testa något nytt (och inte bara en ny kata).
Calisthenics kan då vara en frisk fläkt. "Samma" erfarenhet säger även att
gruppen kommer sakna den mer basic TDD upplevelsen som är typisk för en
dojo... :-)
Ang. att plocka in rutten kod att fixa. En bra idé. Själv har jag bara
testat att ta kod från en tidigare dojo session och sedan applicera
calisthenicsreglerna på den koden. Enkelt eftersom ingen "äger koden" och
det är från en sådan session som önskan att köra en dojo där man applicerade
calisthenics reglerna från början kom.
> Den intressantaste delen av en Kata tycker jag är när de inledande
> testen är skrivna och det blir dags för den första ordentliga
> refaktoriseringen (typ efter nån timma eller två). Det är då de mest givande
> diskutionerna infinner sig.
> Kan vi inte hoppa till det steget direkt om någon redan från början tar med
> sig en bunt rutten legacy code som vi kan refakorisera och designa om? Då
> kan vi diskutera god design, clean code och DDD redan från början. Och
> slippa den första transportsträckan.
> /Carl
> 2009/10/19 Emil Gustafsson <e...@cellfish.se>
>> Om man vill piffa till lösningen lite kan jag rekommendera att använda
>> "Object Calisthenics". Ger IMO en annan upplevelse av dojon med mindre fokus
>> på TDD och mer fokus på OO design. På gott och ont. Försöker fortafarnde
>> hitta en balans mellan de två.
>>> Sorry, http://codingdojo.org/ >>> Man sitter runt ett bord och parprogrammerar skulle man kunna säga.
>>> Syftet är att lära sig TDD och utbyta programmeringserfarenheter genom att
>>> lösa ett enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två
>>> vid tangentbordet hela tiden sedan roterar man en person efter varje lyckat
>>> test, i alla fall när vi kört ping-pong-metoden.
>>> Joakim
>>> On 19 okt 2009, at 11.00, Emil Cardell wrote:
>>> Dagens noob fråga. Men exakt vad görs på en coding dojo?
>>> Exempel på vad ni gjorde förra gången?
Vi får väl låta deltagarna avgöra vad det blir. Och om någon träder
fram och vill köra en prepared kata får det erbjudandet ligga med i
potten också. Blir det många deltagare kan vi köra flera parallellt! :-)
Jag tycker personligen Emils calisthenics-idé låter bra, jag och Peter
har pratat om det tidigare och även experimenterat lite själva. Det är
inte helt lätt att ens förstå hur man ska följa alla reglerna måste
jag säga. Emil kanske har några tips? Förutom de man kan läsa på din
blogg förstås...
Någon som vill agera värd eller ska vi vara på Avega igen? :-)
> Den intressantaste delen av en Kata tycker jag är när de inledande
> testen är skrivna och det blir dags för den första ordentliga
> refaktoriseringen (typ efter nån timma eller två). Det är då de mest
> givande diskutionerna infinner sig.
> Kan vi inte hoppa till det steget direkt om någon redan från början
> tar med sig en bunt rutten legacy code som vi kan refakorisera och
> designa om? Då kan vi diskutera god design, clean code och DDD redan
> från början. Och slippa den första transportsträckan.
> /Carl
> 2009/10/19 Emil Gustafsson <e...@cellfish.se>
> Om man vill piffa till lösningen lite kan jag rekommendera att
> använda "Object Calisthenics". Ger IMO en annan upplevelse av dojon
> med mindre fokus på TDD och mer fokus på OO design. På gott och ont.
> Försöker fortafarnde hitta en balans mellan de två.
> Man sitter runt ett bord och parprogrammerar skulle man kunna säga.
> Syftet är att lära sig TDD och utbyta programmeringserfarenheter
> genom att lösa ett enkelt problem, t.ex. poängberäkning i bowling
> eller minesweep. Två vid tangentbordet hela tiden sedan roterar man
> en person efter varje lyckat test, i alla fall när vi kört ping-pong- > metoden.
> Joakim
> On 19 okt 2009, at 11.00, Emil Cardell wrote:
>> Dagens noob fråga.
>> Men exakt vad görs på en coding dojo?
>> Exempel på vad ni gjorde förra gången?
De praktiska tipsen kring calisthenics är väl att komma ihåg att reglerna
inte är där för att man skall koda runt dem, de är där för att man genom att
följa reglerna tvingas in i "bra" mönster. För en djupare förståelse kan jag
rekommendera boken där de beskrivs (*The ThoughtWorks Anthology*). Finns ett
draft till artikeln på internet som inte är uppdaterat så läs boken
istället. Men visst är det så att alla regler inte är jätte tydliga. Men
snabbkursen är:
1. "One level of indentetion" - ger enkla metoder utan krånglig logik eller
nästlade loopar.
2. "Don't use else" - tanken är att använda polymorphism istället för
if/else eller switchar
3. "Wrap primitive types" - Gäller för argument. Ett argument som är en int
är inte en int. det är en storlek, pengar etc. I praktiken måste man ju
bryta mot denna regel i det publika API:et (ex en sträng om du kör
minesweeper)
4. "Use one dot per line" - Inga "tåg" av anrop. Varje objekt skall bara
anropa metoder på sig själv eller på sina vänner. Aldrig på sina vänners,
vänner (ex: a.b() är ok, men inte a.b().c(). Du skall inte heller "lura
systemet" genom att göra B b =a.b(); b.c();
5. "Don't abbreviate" - detta är den konstigaste slogan eftersom
förklaringen är att inga kall/metod namn skall innehålla förkortningar (så
långt inget konstigt), men regeln säger även att inga klass/metodnamn skall
vara mer än två ord långt. Detta hjälper dig skapa object och metoder som
bara gör en sak.
6. "Keep entities small" - max 50 rader per klass och max 10 klasser per
namespace. Ännu en sak för att hjälpa dig skapa enkla klasser som bara har
ett enda syfte. Observera att det finns ingen gräns på metoder (mer än regel
1).
7. "No more than 2 member variables in each class" - Ännu en regel för att
skapa enkla klasser. Målet är att varje metod i en klass skall jobba på alla
medlemsvariabler.
8. "First class collections" - undantaget från regel 7 säger att
kollektioner får bara ha en enda medlemsvariabel.
9. "Don't use getters/setters/properties" - helt klart den svåraste regeln
tycker jag. Syftet är att använda ett "tell, don't ask" mönster i koden. Dvs
tala om vad objekten skall göra med sitt data istf att fråga om dess data.
Ett annat praktiskt tips som underlättar en dojo är att tillåta generic
collections så länge man bara gör "foreach" på dem. Jag har valt att tolka
användandet av Length/Size eller []-operatorn som brott mot regel 9. Kreativ
namngivning från "GetSize" till "CalculateSize" är inte heller OK såvida
inte "CalculateSize" gör någon intressant uträkning.
Om ni väljer calisthenics så är jag mycket intresserad av att höra hur det
går...
----------------------------------------------------
blog: http://blogs.msdn.com/cellfish
> Vi får väl låta deltagarna avgöra vad det blir. Och om någon träder fram
> och vill köra en prepared kata får det erbjudandet ligga med i potten också.
> Blir det många deltagare kan vi köra flera parallellt! :-)
> Jag tycker personligen Emils calisthenics-idé låter bra, jag och Peter har
> pratat om det tidigare och även experimenterat lite själva. Det är inte helt
> lätt att ens förstå hur man ska följa alla reglerna måste jag säga. Emil
> kanske har några tips? Förutom de man kan läsa på din blogg förstås...
> Någon som vill agera värd eller ska vi vara på Avega igen? :-)
> Den intressantaste delen av en Kata tycker jag är när de inledande
> testen är skrivna och det blir dags för den första ordentliga
> refaktoriseringen (typ efter nån timma eller två). Det är då de mest givande
> diskutionerna infinner sig.
> Kan vi inte hoppa till det steget direkt om någon redan från början tar med
> sig en bunt rutten legacy code som vi kan refakorisera och designa om? Då
> kan vi diskutera god design, clean code och DDD redan från början. Och
> slippa den första transportsträckan.
> /Carl
> 2009/10/19 Emil Gustafsson <e...@cellfish.se>
>> Om man vill piffa till lösningen lite kan jag rekommendera att använda
>> "Object Calisthenics". Ger IMO en annan upplevelse av dojon med mindre fokus
>> på TDD och mer fokus på OO design. På gott och ont. Försöker fortafarnde
>> hitta en balans mellan de två.
>>> Sorry, http://codingdojo.org/ >>> Man sitter runt ett bord och parprogrammerar skulle man kunna säga.
>>> Syftet är att lära sig TDD och utbyta programmeringserfarenheter genom att
>>> lösa ett enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två
>>> vid tangentbordet hela tiden sedan roterar man en person efter varje lyckat
>>> test, i alla fall när vi kört ping-pong-metoden.
>>> Joakim
>>> On 19 okt 2009, at 11.00, Emil Cardell wrote:
>>> Dagens noob fråga. Men exakt vad görs på en coding dojo?
>>> Exempel på vad ni gjorde förra gången?
> De praktiska tipsen kring calisthenics är väl att komma ihåg att reglerna
> inte är där för att man skall koda runt dem, de är där för att man genom att
> följa reglerna tvingas in i "bra" mönster. För en djupare förståelse kan jag
> rekommendera boken där de beskrivs (*The ThoughtWorks Anthology*). Finns ett
> draft till artikeln på internet som inte är uppdaterat så läs boken
> istället. Men visst är det så att alla regler inte är jätte tydliga. Men
> snabbkursen är:
> 1. "One level of indentetion" - ger enkla metoder utan krånglig logik eller
> nästlade loopar.
> 2. "Don't use else" - tanken är att använda polymorphism istället för
> if/else eller switchar
> 3. "Wrap primitive types" - Gäller för argument. Ett argument som är en int
> är inte en int. det är en storlek, pengar etc. I praktiken måste man ju
> bryta mot denna regel i det publika API:et (ex en sträng om du kör
> minesweeper)
> 4. "Use one dot per line" - Inga "tåg" av anrop. Varje objekt skall bara
> anropa metoder på sig själv eller på sina vänner. Aldrig på sina vänners,
> vänner (ex: a.b() är ok, men inte a.b().c(). Du skall inte heller "lura
> systemet" genom att göra B b =a.b(); b.c();
> 5. "Don't abbreviate" - detta är den konstigaste slogan eftersom
> förklaringen är att inga kall/metod namn skall innehålla förkortningar (så
> långt inget konstigt), men regeln säger även att inga klass/metodnamn skall
> vara mer än två ord långt. Detta hjälper dig skapa object och metoder som
> bara gör en sak.
> 6. "Keep entities small" - max 50 rader per klass och max 10 klasser per
> namespace. Ännu en sak för att hjälpa dig skapa enkla klasser som bara har
> ett enda syfte. Observera att det finns ingen gräns på metoder (mer än regel
> 1).
> 7. "No more than 2 member variables in each class" - Ännu en regel för att
> skapa enkla klasser. Målet är att varje metod i en klass skall jobba på alla
> medlemsvariabler.
> 8. "First class collections" - undantaget från regel 7 säger att
> kollektioner får bara ha en enda medlemsvariabel.
> 9. "Don't use getters/setters/properties" - helt klart den svåraste regeln
> tycker jag. Syftet är att använda ett "tell, don't ask" mönster i koden. Dvs
> tala om vad objekten skall göra med sitt data istf att fråga om dess data.
> Ett annat praktiskt tips som underlättar en dojo är att tillåta generic
> collections så länge man bara gör "foreach" på dem. Jag har valt att tolka
> användandet av Length/Size eller []-operatorn som brott mot regel 9. Kreativ
> namngivning från "GetSize" till "CalculateSize" är inte heller OK såvida
> inte "CalculateSize" gör någon intressant uträkning.
> Om ni väljer calisthenics så är jag mycket intresserad av att höra hur det
> går...
> ----------------------------------------------------
> blog:http://blogs.msdn.com/cellfish
> > Vi får väl låta deltagarna avgöra vad det blir. Och om någon träder fram
> > och vill köra en prepared kata får det erbjudandet ligga med i potten också.
> > Blir det många deltagare kan vi köra flera parallellt! :-)
> > Jag tycker personligen Emils calisthenics-idé låter bra, jag och Peter har
> > pratat om det tidigare och även experimenterat lite själva. Det är inte helt
> > lätt att ens förstå hur man ska följa alla reglerna måste jag säga. Emil
> > kanske har några tips? Förutom de man kan läsa på din blogg förstås...
> > Någon som vill agera värd eller ska vi vara på Avega igen? :-)
> > Den intressantaste delen av en Kata tycker jag är när de inledande
> > testen är skrivna och det blir dags för den första ordentliga
> > refaktoriseringen (typ efter nån timma eller två). Det är då de mest givande
> > diskutionerna infinner sig.
> > Kan vi inte hoppa till det steget direkt om någon redan från början tar med
> > sig en bunt rutten legacy code som vi kan refakorisera och designa om? Då
> > kan vi diskutera god design, clean code och DDD redan från början. Och
> > slippa den första transportsträckan.
> > /Carl
> > 2009/10/19 Emil Gustafsson <e...@cellfish.se>
> >> Om man vill piffa till lösningen lite kan jag rekommendera att använda
> >> "Object Calisthenics". Ger IMO en annan upplevelse av dojon med mindre fokus
> >> på TDD och mer fokus på OO design. På gott och ont. Försöker fortafarnde
> >> hitta en balans mellan de två.
> >>> Sorry,http://codingdojo.org/ > >>> Man sitter runt ett bord och parprogrammerar skulle man kunna säga.
> >>> Syftet är att lära sig TDD och utbyta programmeringserfarenheter genom att
> >>> lösa ett enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två
> >>> vid tangentbordet hela tiden sedan roterar man en person efter varje lyckat
> >>> test, i alla fall när vi kört ping-pong-metoden.
> >>> Joakim
> >>> On 19 okt 2009, at 11.00, Emil Cardell wrote:
> >>> Dagens noob fråga. Men exakt vad görs på en coding dojo?
> >>> Exempel på vad ni gjorde förra gången?
> Jag är gärna på, verkar coolt med calisthenics, kata och coding
> dojo :)
> Har inte kört något av detta, men jag är villig och lära av proffsen.
> /marqus
> On 20 Okt, 17:24, Emil Gustafsson <e...@cellfish.se> wrote:
> > De praktiska tipsen kring calisthenics är väl att komma ihåg att reglerna
> > inte är där för att man skall koda runt dem, de är där för att man genom att
> > följa reglerna tvingas in i "bra" mönster. För en djupare förståelse kan jag
> > rekommendera boken där de beskrivs (*The ThoughtWorks Anthology*). Finns ett
> > draft till artikeln på internet som inte är uppdaterat så läs boken
> > istället. Men visst är det så att alla regler inte är jätte tydliga. Men
> > snabbkursen är:
> > 1. "One level of indentetion" - ger enkla metoder utan krånglig logik eller
> > nästlade loopar.
> > 2. "Don't use else" - tanken är att använda polymorphism istället för
> > if/else eller switchar
> > 3. "Wrap primitive types" - Gäller för argument. Ett argument som är en int
> > är inte en int. det är en storlek, pengar etc. I praktiken måste man ju
> > bryta mot denna regel i det publika API:et (ex en sträng om du kör
> > minesweeper)
> > 4. "Use one dot per line" - Inga "tåg" av anrop. Varje objekt skall bara
> > anropa metoder på sig själv eller på sina vänner. Aldrig på sina vänners,
> > vänner (ex: a.b() är ok, men inte a.b().c(). Du skall inte heller "lura
> > systemet" genom att göra B b =a.b(); b.c();
> > 5. "Don't abbreviate" - detta är den konstigaste slogan eftersom
> > förklaringen är att inga kall/metod namn skall innehålla förkortningar (så
> > långt inget konstigt), men regeln säger även att inga klass/metodnamn skall
> > vara mer än två ord långt. Detta hjälper dig skapa object och metoder som
> > bara gör en sak.
> > 6. "Keep entities small" - max 50 rader per klass och max 10 klasser per
> > namespace. Ännu en sak för att hjälpa dig skapa enkla klasser som bara har
> > ett enda syfte. Observera att det finns ingen gräns på metoder (mer än regel
> > 1).
> > 7. "No more than 2 member variables in each class" - Ännu en regel för att
> > skapa enkla klasser. Målet är att varje metod i en klass skall jobba på alla
> > medlemsvariabler.
> > 8. "First class collections" - undantaget från regel 7 säger att
> > kollektioner får bara ha en enda medlemsvariabel.
> > 9. "Don't use getters/setters/properties" - helt klart den svåraste regeln
> > tycker jag. Syftet är att använda ett "tell, don't ask" mönster i koden. Dvs
> > tala om vad objekten skall göra med sitt data istf att fråga om dess data.
> > Ett annat praktiskt tips som underlättar en dojo är att tillåta generic
> > collections så länge man bara gör "foreach" på dem. Jag har valt att tolka
> > användandet av Length/Size eller []-operatorn som brott mot regel 9. Kreativ
> > namngivning från "GetSize" till "CalculateSize" är inte heller OK såvida
> > inte "CalculateSize" gör någon intressant uträkning.
> > Om ni väljer calisthenics så är jag mycket intresserad av att höra hur det
> > går...
> > ----------------------------------------------------
> > blog:http://blogs.msdn.com/cellfish
> > > Vi får väl låta deltagarna avgöra vad det blir. Och om någon träder fram
> > > och vill köra en prepared kata får det erbjudandet ligga med i potten också.
> > > Blir det många deltagare kan vi köra flera parallellt! :-)
> > > Jag tycker personligen Emils calisthenics-idé låter bra, jag och Peter har
> > > pratat om det tidigare och även experimenterat lite själva. Det är inte helt
> > > lätt att ens förstå hur man ska följa alla reglerna måste jag säga. Emil
> > > kanske har några tips? Förutom de man kan läsa på din blogg förstås...
> > > Någon som vill agera värd eller ska vi vara på Avega igen? :-)
> > > Den intressantaste delen av en Kata tycker jag är när de inledande
> > > testen är skrivna och det blir dags för den första ordentliga
> > > refaktoriseringen (typ efter nån timma eller två). Det är då de mest givande
> > > diskutionerna infinner sig.
> > > Kan vi inte hoppa till det steget direkt om någon redan från början tar med
> > > sig en bunt rutten legacy code som vi kan refakorisera och designa om? Då
> > > kan vi diskutera god design, clean code och DDD redan från början. Och
> > > slippa den första transportsträckan.
> > >> Om man vill piffa till lösningen lite kan jag rekommendera att använda
> > >> "Object Calisthenics". Ger IMO en annan upplevelse av dojon med mindre fokus
> > >> på TDD och mer fokus på OO design. På gott och ont. Försöker fortafarnde
> > >> hitta en balans mellan de två.
> > >>> Sorry,http://codingdojo.org/ > > >>> Man sitter runt ett bord och parprogrammerar skulle man kunna säga.
> > >>> Syftet är att lära sig TDD och utbyta programmeringserfarenheter genom att
> > >>> lösa ett enkelt problem, t.ex. poängberäkning i bowling eller minesweep. Två
> > >>> vid tangentbordet hela tiden sedan roterar man en person efter varje lyckat
> > >>> test, i alla fall när vi kört ping-pong-metoden.
> > >>> Joakim
> > >>> On 19 okt 2009, at 11.00, Emil Cardell wrote:
> > >>> Dagens noob fråga. Men exakt vad görs på en coding dojo?
> > >>> Exempel på vad ni gjorde förra gången?
> Instämmer. Jag håller på att hämta in på TDD, DDD and what not. Är
> mycket intresserad av att hänga med på en dojo.
> Förresten är jag ny här i gruppen: hej, hej till alla.
> /Johan
> On 20 Okt, 19:32, Marqus Landin <marqus.lan...@bolditsolutions.se>
> wrote:
> > Jag är gärna på, verkar coolt med calisthenics, kata och coding
> > dojo :)
> > Har inte kört något av detta, men jag är villig och lära av proffsen.
> > /marqus
> > On 20 Okt, 17:24, Emil Gustafsson <e...@cellfish.se> wrote:
> > > De praktiska tipsen kring calisthenics är väl att komma ihåg att
> reglerna
> > > inte är där för att man skall koda runt dem, de är där för att man
> genom att
> > > följa reglerna tvingas in i "bra" mönster. För en djupare förståelse
> kan jag
> > > rekommendera boken där de beskrivs (*The ThoughtWorks Anthology*).
> Finns ett
> > > draft till artikeln på internet som inte är uppdaterat så läs boken
> > > istället. Men visst är det så att alla regler inte är jätte tydliga.
> Men
> > > snabbkursen är:
> > > 1. "One level of indentetion" - ger enkla metoder utan krånglig logik
> eller
> > > nästlade loopar.
> > > 2. "Don't use else" - tanken är att använda polymorphism istället för
> > > if/else eller switchar
> > > 3. "Wrap primitive types" - Gäller för argument. Ett argument som är en
> int
> > > är inte en int. det är en storlek, pengar etc. I praktiken måste man ju
> > > bryta mot denna regel i det publika API:et (ex en sträng om du kör
> > > minesweeper)
> > > 4. "Use one dot per line" - Inga "tåg" av anrop. Varje objekt skall
> bara
> > > anropa metoder på sig själv eller på sina vänner. Aldrig på sina
> vänners,
> > > vänner (ex: a.b() är ok, men inte a.b().c(). Du skall inte heller "lura
> > > systemet" genom att göra B b =a.b(); b.c();
> > > 5. "Don't abbreviate" - detta är den konstigaste slogan eftersom
> > > förklaringen är att inga kall/metod namn skall innehålla förkortningar
> (så
> > > långt inget konstigt), men regeln säger även att inga klass/metodnamn
> skall
> > > vara mer än två ord långt. Detta hjälper dig skapa object och metoder
> som
> > > bara gör en sak.
> > > 6. "Keep entities small" - max 50 rader per klass och max 10 klasser
> per
> > > namespace. Ännu en sak för att hjälpa dig skapa enkla klasser som bara
> har
> > > ett enda syfte. Observera att det finns ingen gräns på metoder (mer än
> regel
> > > 1).
> > > 7. "No more than 2 member variables in each class" - Ännu en regel för
> att
> > > skapa enkla klasser. Målet är att varje metod i en klass skall jobba på
> alla
> > > medlemsvariabler.
> > > 8. "First class collections" - undantaget från regel 7 säger att
> > > kollektioner får bara ha en enda medlemsvariabel.
> > > 9. "Don't use getters/setters/properties" - helt klart den svåraste
> regeln
> > > tycker jag. Syftet är att använda ett "tell, don't ask" mönster i
> koden. Dvs
> > > tala om vad objekten skall göra med sitt data istf att fråga om dess
> data.
> > > Ett annat praktiskt tips som underlättar en dojo är att tillåta generic
> > > collections så länge man bara gör "foreach" på dem. Jag har valt att
> tolka
> > > användandet av Length/Size eller []-operatorn som brott mot regel 9.
> Kreativ
> > > namngivning från "GetSize" till "CalculateSize" är inte heller OK
> såvida
> > > inte "CalculateSize" gör någon intressant uträkning.
> > > Om ni väljer calisthenics så är jag mycket intresserad av att höra hur
> det
> > > går...
> > > ----------------------------------------------------
> > > blog:http://blogs.msdn.com/cellfish
> > > > Vi får väl låta deltagarna avgöra vad det blir. Och om någon träder
> fram
> > > > och vill köra en prepared kata får det erbjudandet ligga med i potten
> också.
> > > > Blir det många deltagare kan vi köra flera parallellt! :-)
> > > > Jag tycker personligen Emils calisthenics-idé låter bra, jag och
> Peter har
> > > > pratat om det tidigare och även experimenterat lite själva. Det är
> inte helt
> > > > lätt att ens förstå hur man ska följa alla reglerna måste jag säga.
> Emil
> > > > kanske har några tips? Förutom de man kan läsa på din blogg
> förstås...
> > > > Någon som vill agera värd eller ska vi vara på Avega igen? :-)
> > > > On 20 okt 2009, at 00.04, Carl Kenne wrote:
> > > > Den intressantaste delen av en Kata tycker jag är när de inledande
> > > > testen är skrivna och det blir dags för den första ordentliga
> > > > refaktoriseringen (typ efter nån timma eller två). Det är då de mest
> givande
> > > > diskutionerna infinner sig.
> > > > Kan vi inte hoppa till det steget direkt om någon redan från början
> tar med
> > > > sig en bunt rutten legacy code som vi kan refakorisera och designa
> om? Då
> > > > kan vi diskutera god design, clean code och DDD redan från början.
> Och
> > > > slippa den första transportsträckan.
> > > >> Om man vill piffa till lösningen lite kan jag rekommendera att
> använda
> > > >> "Object Calisthenics". Ger IMO en annan upplevelse av dojon med
> mindre fokus
> > > >> på TDD och mer fokus på OO design. På gott och ont. Försöker
> fortafarnde
> > > >> hitta en balans mellan de två.
> > > >>> Sorry,http://codingdojo.org/ > > > >>> Man sitter runt ett bord och parprogrammerar skulle man kunna säga.
> > > >>> Syftet är att lära sig TDD och utbyta programmeringserfarenheter
> genom att
> > > >>> lösa ett enkelt problem, t.ex. poängberäkning i bowling eller
> minesweep. Två
> > > >>> vid tangentbordet hela tiden sedan roterar man en person efter
> varje lyckat
> > > >>> test, i alla fall när vi kört ping-pong-metoden.
> > > >>> Joakim
> > > >>> On 19 okt 2009, at 11.00, Emil Cardell wrote:
> > > >>> Dagens noob fråga. Men exakt vad görs på en coding dojo?
> > > >>> Exempel på vad ni gjorde förra gången?
> Jag är på!
> Dock behöver jag veta när och var för att veta hur det skall säljas in
> hemma.
> /Morten
> On 19 Okt, 10:40, Joakim Sundén <joakim.sun...@gmail.com> wrote:
> > Tjena!
> > Börjar det inte bli dags att köra en Coding Dojo snart? Eller har vi
> > tröttnat på det? :-)
> Jag är på!
> Dock behöver jag veta när och var för att veta hur det skall säljas in
> hemma.
> /Morten
> On 19 Okt, 10:40, Joakim Sundén <joakim.sun...@gmail.com> wrote:
> > Tjena!
> > Börjar det inte bli dags att köra en Coding Dojo snart? Eller har vi
> > tröttnat på det? :-)
|
