[CICLO 17] Storia 1

[Jocchan]

Storia di refactoring:
- Completare il refactoring di BigGem, uniformando le interfacce di Droppable e BigGem. Cell deve diventare una Region, ovvero un gruppo di celle rettangolari. Un diamante e' una Region 1x1: Bonfo + Ufo13
- Consolidare le responsabilita' di Dynamite al momento sparse in piu' classi: thebol + Jappilas + ...
- Testare il codice di input: cdimauro: completato

La storia è già divisa in task: fatevi sotto!

[Bonfo]

Siccome siamo in ballo...continuiamo a ballare.
Io e Ufo andiamo avanti con il refactoring di BigGem.

[VICIUS]

Originariamente inviato da Bonfo

Siccome siamo in ballo...continuiamo a ballare.
Io e Ufo andiamo avanti con il refactoring di BigGem.

Una stima sul tempo necessario per completare il refactoring?

ciao

[VICIUS]

Visto che ci siamo anche gli altri due task sarebbe meglio farli in pair. Quindi fatevi avanti.

Per il terzo task sarebbe utile rifattorizzare keymapping in modo da caricare i tasti da un file di configurazione come GameConfig (quindi uso della classe properties) in modo da poter cambiare i tasti agilmente e usare un file standard per i test.

ciao

[cdimauro]

Per il terzo task ci potrei pensare io e qualcun altro. Tempo previsto: 2 giorni per rifattorizzare qualcosina e uno per aggiornare i test.

Un paio di domande:
- per la configurazione dei tasti posso usare sempre GameConfig oppure un altro file (o due: uno il mapping di ogni giocatore);
- con uso della classe properties cosa intendi?

Comunque la mia idea è di sganciare KeyMappings dalla particolare implementazione della tastiera, rendendola quindi un elemento a sé stante, facendo sì che la tastiera diventi un semplice dispositivo di input che trasli già al suo interno i codici "raw" della tastiera sui relativi Event "standard" di Diamonds, per poi notificare questo evento ai listener a essa legati.

Sarà poi la routine di notify del listener a traslare, tramite il keymapping che usa e relative impostazioni del file di configurazione, l'evento della pressione di un particolare tasto in quello di Event.UP, Event.DOWN, Event.BUTTON1, ecc.

[VICIUS]

Originariamente inviato da cdimauro

Per il terzo task ci potrei pensare io e qualcun altro. Tempo previsto: 2 giorni per rifattorizzare qualcosina e uno per aggiornare i test.

Un paio di domande:
- per la configurazione dei tasti posso usare sempre GameConfig oppure un altro file (o due: uno il mapping di ogni giocatore);

Secondo me ci conviene usare un file separato. GameConfig in questo momento contiene proprietà che sicuramente non saranno modificabili dall'utente finale. Per il parsing potete usare sempre Config anche se probabilmente dovrete aggiungere una getString.

Originariamente inviato da cdimauro

- con uso della classe properties cosa intendi?

Era solo per evitare di ritrovarmi con un file .xml nel repository

ciao

[fek]

Originariamente inviato da VICIUS

Secondo me ci conviene usare un file separato. GameConfig in questo momento contiene proprietà che sicuramente non saranno modificabili dall'utente finale. Per il parsing potete usare sempre Config anche se probabilmente dovrete aggiungere una getString.

Anche secondo me andrebbe usato un file differente e la classe Config per leggerlo.

[cdimauro]

Originariamente inviato da VICIUS

Secondo me ci conviene usare un file separato. GameConfig in questo momento contiene proprietà che sicuramente non saranno modificabili dall'utente finale. Per il parsing potete usare sempre Config anche se probabilmente dovrete aggiungere una getString.

OK, quindi vada per un file contenente le configurazioni dei tasti di entrambi i giocatori

Era solo per evitare di ritrovarmi con un file .xml nel repository

Ehm, scusa la mia ignoranza, ma non ho ancora capito cosa intendi per "uso della classe properties".

Oggi sono un po' intronato.

EDIT: Ho appena visto config e ho capito cosa volevi dire. Oggi non è proprio giornata.

Comunque ho già rifattorizzato un po' di roba, semplificando KeyboardInterface, eliminato KeyMappings e facendola diventare una classe a sé stante, che non dipende dall'implementazione della tastiera.

Inoltre la traslazione dell'evento (usando il mapping apposito) adesso avviene in notifyEvent. Di conseguenza cambia anche il modo di usare questo metodo.

A motivo di ciò, ho dovuto cambiare un bel po' di test che usavano input senza impostare alcun KeyMapping, oppure che passavano a notifyEvent direttamente l'evento processato (es: al posto di Event.LEFT adesso si deve passare Event.KEY_LEFT).

[thebol]

scrivendo un file di properties secondo lo standard prop = value, e facendolo parsare dalla classe java properties, ottieni un oggetto su cui facendo getProperties(prop) restitusice value.

cmq è utilizzata anche nella gestione del file di config(classe Config).

[Bonfo]

Originariamente inviato da VICIUS

Una stima sul tempo necessario per completare il refactoring?

ciao

Allora...adesso parlo senza aver sentito Ufo.
La situazione è "grave"...ovvero ogni volta che cerchiamo di mettere mano a qualcosa va ad impattare su gran parte del codice, richiedendo sempre la presenza di refactoring che non siamo ancora riusciti a fare.
Insomma ...una cane che si morde la coda

In ogni caso stiamo cercando i punti di attacco.
Se tutto va come prevediamo ci troveremo alla fine con il codice praticamente "nuovo".

Quindi i tempi sono lunghi...anche perchè biosgna mettere le mani in un sacco di posti (Grid, Action, State, tutti i Droppable, Sprite, Cell e via così...praticamente tutto )

[VICIUS]

Originariamente inviato da Bonfo

Allora...adesso parlo senza aver sentito Ufo.
La situazione è "grave"...ovvero ogni volta che cerchiamo di mettere mano a qualcosa va ad impattare su gran parte del codice, richiedendo sempre la presenza di refactoring che non siamo ancora riusciti a fare.
Insomma ...una cane che si morde la coda

In ogni caso stiamo cercando i punti di attacco.
Se tutto va come prevediamo ci troveremo alla fine con il codice praticamente "nuovo".

Quindi i tempi sono lunghi...anche perchè biosgna mettere le mani in un sacco di posti (Grid, Action, State, tutti i Droppable, Sprite, Cell e via così...praticamente tutto )

Ok. Allora andate piano, scrivete un sacco di test e lanciate ant fino a consumare il tasto di eclipse
Se avete bisogno di consigli e idee nuove io sono sempre disponibile di sera.

ciao

[jappilas]

esaminando il comportamento attuale (di fino a ieri sera, cioe' ) della dynamite, mi veniva un dubbio: attualmente il candelotto viene rimosso all' evento di BLOW.released ma la griglia aggiornata alla fine del "turno" (se il tasto viene rilasciato durante il gioco, statisticamente capitera' con maggiore probabilita' durante la caduta della gempair, quindi nel gemPairOnControlState)

il comportamento del cadelotto deve verificarsi (cancellazione + caduta della/e droppable che la sovrastano, per ora, animazione + cancellazione + caduta, nella storia successiva) appena si rilascia il tasto o si ha il timeout , anche se nel frattempo c e' una gempair in gioco che sta cadendo?

Forse bisognera' aggiungere allo stato il controllo e la gestione della dynamite, o uno stato apposito (la mai idea e' di trattare anche la dynamite analogamente al crushState per far cadere le droppable) parlandone con vic e' emerso che a seconda dei casi "potrebbe" rendersi necessario o consigliabile rivedere gli state, quindi e' necessario chiarire

[fek]

Originariamente inviato da VICIUS

Ok. Allora andate piano, scrivete un sacco di test e lanciate ant fino a consumare il tasto di eclipse
Se avete bisogno di consigli e idee nuove io sono sempre disponibile di sera.

ciao

Ed e' proprio il fatto che toccando qualcosa si va ad inficiare molto codice il motivo per il quale e' assolutamente necessaria questa fase di refactoring. Cercate di mantenere ogni classe il piu' possibile coesa e indipendente dal resto del sistema: vi accorgete della coesione guardando i test della classe. Se i test non richiedono tanti altri oggetti per funzionare, vuol dire che la classe e' molto coesa ed e' un ottimo segno.

Forza ragazzi che il lavoro che state facendo e' importantissimo. Vedrete che appena iniziate a svolgere i primi nodi il resto del codice andra' a posto da solo. L'importante come dice Vic e' procedere passettino per passettino, e scrivere tanti test che vi proteggono dai problemi.

[fek]

Un ultimo consiglio: fate commit spesso e volentieri, cosi' permettete agl'altri che lavorano di sincronizzarsi al refactoring, ed evitate noiosi merge.

Inoltre mettersi in testa di fare commit spesso vi aiuta a sforzarvi di rendere ogni passo del refactoring molto breve, quindi meno rischi di fare casini. E piu' tranquillita' per voi. E' una lotta

[cdimauro]

'na parola. Con le grosse rifattorizzazioni che ho fatto mi succedeva spesso e volentieri che, dopo una modifica, saltavano fuori degli errori in altre classi. Corretto un errore, se ne saltava fuori un altro a esso legato, e così via, modello catena di Sant'Antonio.

Ho vissuto con l'incubo di effettuare merge chilometrici in questi momenti.

Per fortuna che modifiche così pesanti non si fanno tutti i giorni.

[Ufo13]

Allora... Il refactoring di BigGem con Cell procede... Qualcuno riesce a darmi una mano?

Vi posto la BigGem refattorizzata, la build è rossa e non capisco perchè

[cdimauro]

Per favore, NON committate in questo momento: ho per le mani una rifattorizzazione piuttosto pesante, e non vorrei che si creassero casini!!!

[cdimauro]

Commit effettuato. Adesso Diamonds è event-based.

[Bonfo]

Originariamente inviato da Ufo13

Allora... Il refactoring di BigGem con Cell procede... Qualcuno riesce a darmi una mano?

Vi posto la BigGem refattorizzata, la build è rossa e non capisco perchè

Ho visto qualcosa di strano...perchp in addColumn e addRow le gem sono dichiarate FINAL ??

[Ufo13]

Originariamente inviato da Bonfo

Ho visto qualcosa di strano...perchp in addColumn e addRow le gem sono dichiarate FINAL ??

Non mi risulta :o