kata
Tonino Lucca
http://www.vimeo.com/16177730
Sono 10 minuti.
Commenti benvenuti.
Ciao ciao.
T
Andrea Francia
1) :-)
Molto carini gli effetti di dissolvenza.
2) :-)
Molto carina la musica
3) :-(
All'inizio mi sono confuso un po'.
Mi ha confuso il fatto che vim fosse diviso in due finestre che
puntavano a porzioni diverse dello stesso file.
Mi aspettavo invece di trovare fin da subito una finestra per i test e
una per il codice.
Ho dovuto mettere in pausa per cercare di capire cosa fosse e il fatto
che il file si chiamasse genericamente Module1.fs non mi ha aiutato.
4)
Dato che non conosco F# ho fatto fatica a capire cosa fosse il test e
cosa fosse il codice.
Forse sarebbe stato per me piu' chiaro se avessi cominciato con un
test shouldPass, in questo modo avrei capito come interpretare i
messaggi di output.
5)
Sarebbe fico se riuscissi a far vedere i keystroke che usi.
6)
Sai che in vim esiste il comando "q:"? Forse potrebbe tornarti utili
per usare il completamento automatico quando invochi le sostituzioni
(s/prima/dopo).
7)
Il syntax highlight non funziona molto bene sembra.
8)
Non conosco F# e quindi non ho capito il codice. Quindi non so se in
alcuni punti sei stato avaro di caratteri per gli identificatori e se
dipenda dal linguaggio. Per esempio, cosa vuol dire H::T?
9)
Non mi piace vedere usare convenzioni diverse per nomi diversi:
camelCase per positionalMatch e tutto minuscolo per
nonpositionalmatch.
Non mi e' chiaro perche' non usi la stessa convenzione sui metodi:
"match" e' un verbo (imperativo) mentre positionalMatch e
nonPositionalMatch non lo sono. A me piace che gli identificatori
associati ad azioni siano dei verbi.
10)
Non mi piace l'uso del shouldBe, non mi sembra che sia usato in modo
che suona bene.
Un conto e' usarlo cosi:
1.should.be(equalTo("2")
o cosi:
assertThat 1 shouldBe "2"
Se invece ad usarlo cosi' la lettura mi sembra compromessa:
shouldBe 1 2
Al massimo si potrebbe cambiare in
theyShouldBeEqual 1 2
Anche se penso che il buon vecchio
assertEquals 1 2
sia piu' leggibile.
11)
Non mi piace che i nomi dei test non descrivano il comportamento sotto test.
Per esempio, invece di '''no matches" io avrei scritto:
"on no matches should return empty string"
o piu' semplicemente:
"no matches --> empty string"
12)
Bello che hai messo in piedi un sistema che automaticamente avvia i
test ad ogni salvataggio.
Conclusione)
I miei complimenti per aver imparato questo linguaggio e per aver
risolto il problema in soli 10 minuti.
2010/10/27 Tonino Lucca <ton...@gmail.com>:
> --
> Hai ricevuto questo messaggio perché sei iscritto al gruppo
> "milano-codingdojo" di Google Gruppi.
> Per postare messaggi in questo gruppo, invia un'email a
> milano-c...@googlegroups.com.
> Per annullare l'iscrizione a questo gruppo, invia un'email a
> milano-codingd...@googlegroups.com.
> Per ulteriori opzioni, visita il gruppo all'indirizzo
> http://groups.google.com/group/milano-codingdojo?hl=it.
>
--
Andrea Francia
Tonino Lucca
Bravo Tonino!
1) :-)
Molto carini gli effetti di dissolvenza.
2) :-)
Molto carina la musica
3) :-(
All'inizio mi sono confuso un po'.
Mi ha confuso il fatto che vim fosse diviso in due finestre che
puntavano a porzioni diverse dello stesso file.
Mi aspettavo invece di trovare fin da subito una finestra per i test e
una per il codice.
Ho dovuto mettere in pausa per cercare di capire cosa fosse e il fatto
che il file si chiamasse genericamente Module1.fs non mi ha aiutato.
(sotto il sistema di build continuo c'e' una solution di vs2010)
ma questa non e' una buona scusa :D
4)
Dato che non conosco F# ho fatto fatica a capire cosa fosse il test e
cosa fosse il codice.
Forse sarebbe stato per me piu' chiaro se avessi cominciato con un
test shouldPass, in questo modo avrei capito come interpretare i
messaggi di output.
per i test ho scritto un piccolo wrapper che mi consentisse di non usare direttamente le liste nei
test, e di poter scrivere scrivere "xxxx" anziché ['x';'x';'x';'x'].
Quindi un test del tipo AssertEquals(['m'] , guess ['y'; 'x';'x';'x'] ['r';'g';'b';'y'] ) diventa:
shouldBe "m" guess "yxxx" "rgby"
5)
Sarebbe fico se riuscissi a far vedere i keystroke che usi.
6)
Sai che in vim esiste il comando "q:"? Forse potrebbe tornarti utili
per usare il completamento automatico quando invochi le sostituzioni
(s/prima/dopo).
7)
Il syntax highlight non funziona molto bene sembra.
8)
Non conosco F# e quindi non ho capito il codice. Quindi non so se in
alcuni punti sei stato avaro di caratteri per gli identificatori e se
dipenda dal linguaggio. Per esempio, cosa vuol dire H::T?
Testa e coda di una lista.
9)
Non mi piace vedere usare convenzioni diverse per nomi diversi:
camelCase per positionalMatch e tutto minuscolo per
nonpositionalmatch.
Non mi e' chiaro perche' non usi la stessa convenzione sui metodi:
"match" e' un verbo (imperativo) mentre positionalMatch e
nonPositionalMatch non lo sono. A me piace che gli identificatori
associati ad azioni siano dei verbi.
Ok.
10)
Non mi piace l'uso del shouldBe, non mi sembra che sia usato in modo
che suona bene.
Un conto e' usarlo cosi:
1.should.be(equalTo("2")
o cosi:
assertThat 1 shouldBe "2"
Se invece ad usarlo cosi' la lettura mi sembra compromessa:
shouldBe 1 2
Al massimo si potrebbe cambiare in
theyShouldBeEqual 1 2
Anche se penso che il buon vecchio
assertEquals 1 2
sia piu' leggibile.
Ok, non mi ricordo esattamente perche' ho scelto il nome shouldBe. Forse e' stato
pensando che cosi' mi sarei risparmiato di doverlo scrivere nei nomi dei test test (punto 11).
Mah... una scusa debole forse. Non saprei.
11)
Non mi piace che i nomi dei test non descrivano il comportamento sotto test.
Per esempio, invece di '''no matches" io avrei scritto:
"on no matches should return empty string"
o piu' semplicemente:
"no matches --> empty string"
12)
Bello che hai messo in piedi un sistema che automaticamente avvia i
test ad ogni salvataggio.
Il sistema l'ho preso da un progetto di google (autobuild) (modificando poi il
file di build stesso)
Praticamente il sistema usa nant + msbuild (e volendo anche growl, che pero' era spento).
Un po' pesantino magari (infatti il build non e' proprio velocissimo).
Conclusione)
I miei complimenti per aver imparato questo linguaggio e per aver
risolto il problema in soli 10 minuti.
Grazie :)
Ciao.
T.
Matteo Vaccari
4)
Dato che non conosco F# ho fatto fatica a capire cosa fosse il test e
cosa fosse il codice.
Ciao Tonino,
una piccola idea: potresti forse scrivere una piccola guida a questo kata che spiega quel minimo di sintassi F# che permetta a qualcuno che non ne sa nulla di seguire meglio quello che fai...
Matteo
Tonino Lucca
Qui avevo scritto qualcosa
http://tonyxzt.blogspot.com/2010/10/codebreaker-in-f.html
Se poi qualcuno fosse _particolarmente interessato/a_ a migliori approfondimenti,
mi mandi una mail, specificando se secondo lui/lei e' opportuno:
a) un post piu' chiaro/esauriente
b) una versione con commento audio/sottotitolato
c) altro...
Grazie, ciao.
T.