R: Re: [novara-xpug:680] feedback

[new...@libero.it]

Acc, oggi libero fa i capricci...

Ok, allego la soluzione mia e di Alberto ma è veramente tremenda(gameOfLife.zip)

n.b. non ho fatto nessuna modifica rispetto a quella di giovedì sera, e si vede :)

ne ho fatta poi una seconda cercando di farmi guidare più dai test (newGameOfLife.zip)

non sono completamente soddisfatto, ci sono un sacco di refactoring che vorrei apportare ma in questa maniera sono riuscito a fare "emergere" classi che con la prima implementazione non avevo visto...

Il prossimo incontro è fissato per Giovedì questo (16/2/2011) l'idea era di fare un altro kata, Alberto se non ricordo male ha proposto il Minesweeper http://codingdojo.org/cgi-bin/wiki.pl?KataMinesweeper

che credo possa andare bene, mi sembra abbastanza semplice e potrebbe permetterci di concentrarci maggiormente sui passi del tdd piuttosto che al raggiungimento a tutti i costi della soluzione.

E poi magari all'incontro successivo potremmo dedicare una serata al Refactoring, che ne dite !?

P.S.

mi è piaciuta _molto_ l'idea delle faccine con una frase sintetica a fianco!!!

le mie sono questa:

:) = problema risolto - questo da molta carica

:| = ho sofferto la pressione del tempo (3 pomodori) per scarsa conoscenza linguaggio e problema...

:( = ci siamo fatti guidare troppo poco dai test

----Messaggio originale----
Da: alex...@gmail.com
Data: 11/02/2012 17.05
A: <novar...@googlegroups.com>
Ogg: Re: [novara-xpug:680] feedback

Concordo con te Giuseppe. Nel team formato da Sergio e me invece dei test ad un certo punto ce ne siamo totalmente dimenticati (ahi ahi ahi...) e abbiamo focalizzato la nostra attenzione sulla risoluzione del problema del controllo delle celle adiacenti (con una serie di if annidati -> barbari ma funzionanti) che non abbiamo avuto il tempo di rimuovere con un bel refactoring finale. La cosa interessante è che poi abbiamo costruito i vari test e funzionavano al primo colpo con l'implementazione fatta, quindi alla fine siamo riusciti a rispettare tutte le specifiche del Kata (anche se forse non quelle dell'XP :D).
Forse (parlo da parte mia), con il fatto di essere abituato a focalizzarmi sull'algoritmo di risoluzione e cercare di ottimizzarlo, ho finito per coinvolgere anche Sergio che sicuramente ha uno stile di coding più evoluto del mio e più rispettoso delle tecniche XP. Dovrò migliorare tanto in questo aspetto e cercare di farmi guidare di più dai test.

Ad esempio nel Kata Bwling sono riuscito a farmi guidare di più dai test perchè non conoscevo bene il sistema di punteggio del bowling, mentre il Game Of Life fin dal primo istante me lo sono immaginato come una matrice in cui la chiave di soluzione è il conteggio delle celle vive intorno ad una cella X e dopo 2 anni di algoritmi con matrici in Università per me è stato spontaneo codificare subito la soluzione che avevo già in testa, forse finendo per costringere il mio socio a seguire la mia strada di soluzione e non credo che in un pair programming sia una cosa buona.
A questo proposito sarei curioso di sapere un'impressione da parte tua, Sergio.

Quindi a mio modo di vedere, facendo una retrospettiva su Giovedì direi:
:) = Kata funzionante
:| = codice che funziona, ma che non è definibile elegante come soluzione
:( = la soluzione non è stata ottenuta partendo dai test, ma concentrandosi sul puro algoritmo

--
_____________________
http://groups.google.com/group/admins-gallug?hl=it
 
GalLUG - Galliate LUG & Novara XPug
Circolo ANSPI B.Quagliotti – CF 01103280036
Viale Quagliotti, 1 - Galliate (NO)
Tel/Fax: 0321.806832 - in...@gallug.it - www.gallug.it
_____________________
Per mandare una mail al gruppo: novar...@googlegroups.com
Per disiscriverti mail vuota a: novara-xpug...@googlegroups.com

 

[Alex Gotev]

Ecco anche la soluzione che ho rivisitato di quella che abbiamo fatto con Sergio in allegato. Nei test ora ci sono anche i pattern più famosi del Game Of Life. Tutto funziona. Ho visto che si poteva creare una classe per ogni cella, ma alla fine non vedo di che utilità possa essere in questo caso se non che genera overhead. Se vogliamo poi realizzare il Game of Life con celle esagonali allora il discorso cambia. Ho creato un'intefaccia comune per implementare i pattern di test e ogni pattern è implementato in una sua classe. Se ne possono aggiungere di nuovi. SIcuramente ci sarà ancora da migliorare, aspetto i vostri feedback!

Alex

[Alex Gotev]

Sono andato avanti nel refactoring e sopresa sorpresa...mi sono smentito! La classe Cella è venuta fuori nel bel mezzo del refactoring! Come la vecchia pubblicità della Barilla: "E' la pasta che te lo chiede!", qui è successa la stessa cosa: "E' il codice che te lo chiede!". In allegato il progetto modificato.

Il changelog del codice rispetto alla mail precedente:

• Nuovi test aggiunti, da cui deriva tutto il resto qui sotto
  
• Classe Cella emersa dal design. Il controllo della sopravvivenza generazionale è ora interno a ciascuna cella, aprendo nuove possibiltà nella creazione di griglie di diverso tipo. In questo modo nel passaggio da una generazione all'altra non serve più creare una griglia temporanea, ma vengono eseguite due passate sulla griglia originale: la prima passata rileva per ogni cella quanti vicini vivi ci sono e la seconda passata effettua il passaggio alla successiva generazione. Così ci dovrebbe essere eno spreco di memoria, specie se volessi fare una griglia di 1 milione x 1 milione. Look at the code for more info.
  
• Override del metodo toString della classe Griglia, per poterla stampare ben formattata semplicemente
• Aggiunta di un contatore generazionale alla classe Griglia che si auto incrementa ad ogni avanzamento
  
• Refactoring dei parametri dell'interfaccia per i pattern (e conseguente refactoring in cascata). Per chi ha visto il codice precedente, ora non serve più passare il parametro che indica quante generazioni sono state fatte.
• Refactoring dei pattern test (ora è possibile testare anche la periodicità dei pattern Blinker e Beacon)
  

[news75]

Il giorno mar, 14/02/2012 alle 11.57 +0100, Alex Gotev ha scritto:
> Sono andato avanti nel refactoring e sopresa sorpresa...mi sono
> smentito! La classe Cella è venuta fuori nel bel mezzo del
> refactoring!

In effetti con Cella le regole sono più leggibili.
Una cosa che cosi a "sentimento" non mi piace proprio è
l'inizializzazione nel costruttore...

g.

[Alex Gotev]

Tu avresti messo un metodo specifico da richiamare per l'inizializzazione? C'è qualche cosa in particolare che non ti fa piacere l'inizializzazione nel costruttore? Io ho sempre fatto così finora, ma magari c'è un modo migliore. Ora sto andando avanti nel refactoring e ho definito una classe astratta GameOfLifeGriglia, così poi faccio il passo successivo e implemento la classe GrigliaEsagonale (quella "normale" ora l'ho chiamata GrigliaQuadrata che eredita quella astratta) e riutilizzo tutte le classi di test che ho fatto anche per il nuovo tipo. Ho spostato anche il controllo delle celle vicine vive all'interno della singola cella, che ora ha un ArrayList di celle in cui memorizza tutte le celle vicine e quindi non si dovrà più impazzire con gli indici, ma con un semplice for ciclo l'elenco e verifico quali celle sono vive. Apporto ancora un altro po' di modifiche e posto anche la soluzione con queste ultime modifiche. Intando se hai suggerimenti o critiche dimmi pure così miglioro il codice.

Alex
 

[Alex Gotev]

Ecco l'ultima versione modificata del GameOfLife che ho realizzato, con l'aggiunta di una semplice interfaccia grafica Swing che ho realizzato con NetBeans. Per provare il tutto, compilate e fate partire la classe principale "GameOfLifeGUI.java". Nello ZIP c'è l'intera cartella del progetto NetBeans in cui ho importato i package e le classi che ho realizzato in Eclipse.