View Full Version : [CICLO 18] Storia 1
Sorpresa sorpresa, si ricomincia :D
Nuovo ciclo della durata di due settimane, da oggi 21 aprile fino a domenica 4 maggio, come di consueto... ma con due piccole novità:
1. Quando ci si prenota per un task, bisogna SEMPRE specificare il tempo in cui si ritiene di completarlo.
2. Allo scadere del tempo, il task viene riassegnato.
In questo modo evitiamo gli stalli in cui eravamo caduti durante gli ultimi cicli prima dello stop.
Storia: Il sistema di input dei tasti deve essere disaccoppiato dalle griglie. Inoltre, nel menu iniziale deve essere nuovamente possibile selezionare la voce Advanced Mode (da sostituire con una voce Netplay).
Punti cardine da tenere a mente durante i lavori:
* E' possibile prenotare un task SOLO dopo aver indicato il tempo entro cui lo si porterà a termine. Allo scadere dello stesso, se il task non dovesse essere stato completato, sarà nuovamente possibile prenotarlo. -- NEW --
* Mai fare a gara a chi finisce il task per primo, meglio procedere con calma, altrimenti perderemo molto più tempo in seguito
* Evitiamo di complicarci la vita, esiste di certo una soluzione più semplice di quella che abbiamo pensato di implementare
* MAI aggiungere elementi non richiesti esplicitamente dai task: se mai serviranno, se ne parlerà nelle prossime storie
* Comunichiamo il più possibile, se qualcosa nelle specifiche non è chiaro discutiamone tutti i dettagli fino ad eliminare ogni dubbio, anche il più insignificante
* Postare sempre la test list PRIMA di mettere mano al codice
Task 18.1: Disaccoppiare InputReaction da GridController
Task 18.2: Riabilitare l'item Advanced Mode - Vicius + m.distrutti (COMPLETATO)
Task 18.3: Rinominare Advanced Mode in NetPlay - m.distrutti + Jocchan (COMPLETATO)
Per non dimenticare:
http://i32.tinypic.com/w6r4lx.gif
jappilas
21-04-2008, 15:25
IMHO una cosa yagni è proprio "disaccoppiare l' inputreactor dalla griglia"... l' InputReactor non è vincolato alla tastiera, contiene i riferimenti a una serie di handler per gli eventi (che attualmente provengono dalla tastiera ma di cui potrebbero aversi anche altre fonti), handler che hanno effettivo bisogno di operare sulla griglia
imho potebbe bastare introdurre una nuova event source, dei nuovi opcode di Event.Code ed eventuali nuovi handler per il gioco via rete lasciando l' input reactor come è ora, e affrontare per primo il task di studiare il protocollo di comunicazione tra le due griglie, e identificare stati ed eventi da gestire
IMHO una cosa yagni è proprio "disaccoppiare l' inputreactor dalla griglia"...
Jappi, questo non e' YAGNI, questo e' un requisito del Customer. Il Customer ha a disposizione tot task in questo ciclo e li alloca come gli pare a lui secondo la sua logica. Noi implementiamo scrivendo il codice piu' semplice possibile per soddisfare i suoi requisiti.
Se vuole l'input disaccoppiato, noi glielo disaccoppiamo.
jappilas
21-04-2008, 16:22
Jappi, questo non e' YAGNI, questo e' un requisito del Customer <...>
Se vuole l'input disaccoppiato, noi glielo disaccoppiamo.lo so ... ma quello che volevo dire è che l' InputReactor in pratica lo è già, perchè non contiene alcun riferimento nè a Grid, nè a GridController - riferimenti invece presenti negli EventHandler, ma in questo caso mi sembra inevitabile visto quello che questi devono fare...
è però presente un accesso diretto da parte del GridController all' InputReactor per il setting degli handler ( in addGridInputHandlers ), e questa interazione in effetti potrebbe essere ridotta (eliminata del tutto forse no, perchè input reactor e serie degli handler sono istanziati e privati per il singolo playfield, quindi il singolo GridController) con una soluzione come il creare il set di handler e passarli all' input reactor in modo atomico
lo so ...
Jappi, in questo thread mi dici quale task prendi e quanto tempo impieghi. Per le discussioni apri un altro topic.
jappilas
21-04-2008, 18:06
a parte il primo mi sembrano task di bassa difficoltà, adatti a qualcuno relativamente poco esperto ( magari come mini - pair introduttivi), prima di prenderne uno attenderei per vedere se qualcun altro fosse interessato ;)
Alè!!! In realtà mi aspettavo il post ieri mattina :P
Io sono disponibile a fare il task 18.1 in Pair con Jappi.
Ora i punti sono due:
- dobbiamo coordinarci un attimo sui tempi
- il customer può specificare meglio il task?! :D
Alè!!! In realtà mi aspettavo il post ieri mattina :P
Io sono disponibile a fare il task 18.1 in Pair con Jappi.
Ora i punti sono due:
- dobbiamo coordinarci un attimo sui tempi
- il customer può specificare meglio il task?! :D
Tempi? I sottotask dovete produrli voi, il Customer specifica la Storia.
Fammi una lista di sottotask e relativi test.
Tempi? I sottotask dovete produrli voi, il Customer specifica la Storia.
Fammi una lista di sottotask e relativi test.
Mi sono spiegato male: i tempi erano tra me e Jappi... ovvero quando abbiamo orari compatibili :D :D
Per i sottotask e test, prima devo finire la rapida review del codice ;)
Mi sono spiegato male: i tempi erano tra me e Jappi... ovvero quando abbiamo orari compatibili :D :D
Per i sottotask e test, prima devo finire la rapida review del codice ;)
Mi serve il numero di giorni entro il quale pensate di finire il task, altrimenti non viene assegnato.
Vorrei prenotarmi per il 18.2 ma ho un dubbio. Una volta riabilitato il versus mode nel menu se questo viene selezionato e si preme invio il gioco cosa deve fare? Per ora possiamo semplicemente far partire una partita come se fosse un versus mode oppure è meglio ignorare l'utente per ora?
Per i test avrei pensato a qualcosa come questo:
public void testAdvancedModeDoesNothingWhenSelected()
{
assertEquals(MenuItem.ADVANCED_MODE.action(), MenuActionNone);
}
Dopo di che c'è da controllare che i vari next/previousItem con test come questo:
public void testVersusModeNextItemIsAdvancedMode()
{
mainMenu.selectMenuItem(MenuItem.VERSUS_MODE);
mainMenu.selectNextItem();
assertEquals(MenuItem.ADVANCED_MODE, mainMenu.getSelectedItem());
}
Dovrei finire in un oretta se mi ci metto a lavorare in serata.
A naso il 18.3 dovrebbe essere veramente bovino. Un semplice Refactor->Rename una volta aggiornate le texture.
Allora, chiarisco meglio un pò di dettagli.
Il punto del primo task è separare gli input dalle griglie: al momento con la configurazione di tasti del giocatore uno controllo quella di sinistra, e con quella del giocatore due controllo quella di destra. Bene, l'obiettivo è fare in modo che domani sia possibile - ad esempio - controllare entrambe le griglie con i tasti del giocatore 1, o solo quelli del 2, o mettere il 2 a sinistra e l'1 a destra... oppure (cosa un tantino più interessante) sfruttare come sorgente di input anche qualcos'altro :D :D :D
Per Vic: facciamo che per ora parte lo stesso il gioco normalmente, come se si scegliesse la prima opzione ;)
Per Vic: facciamo che per ora parte lo stesso il gioco normalmente, come se si scegliesse la prima opzione ;)
Ok. Tanto non ci vuole niente a cambiare il test e il codice :)
jappilas
22-04-2008, 14:39
Alè!!! In realtà mi aspettavo il post ieri mattina :P
Io sono disponibile a fare il task 18.1 in Pair con Jappi.ehm.. veramente propendevo per un pair tra qualcuno di noi e qualcuno che magari non ha ancora visto TDD in azione, ad esempio m.distrutti per dirne uno :fiufiu:
I sottotask dovete produrli voi, il Customer specifica la Storia.certo, il fatto è che per come era posto il task mi sembrava troppo generico, e puntiglioso (o forse solo stracciamaroni :D) come sono, speravo che esprimendo le mie perplessità potesse uscire un qualcosa di più specifico ;)
comunque, se può servire, avrei già guardato il codice di quella parte, e visto che in pratica il disaccoppiamento di cui sopra dovrebbe consistere:
- da una parte nel far sì che gli event handler non siano più creati direttamente dal grid controller e poi passati uno a uno all' input reactor (cosa che in pratica costituisce l' unico punto di contatto diretto tra le due classi), ma magari creati in modo atomico in una classe esterna (in modo analogo a quanto accade a livello delle mappature dei tasti, con gli EventMappings) e passati all' input reactor in un' unica chiamata (setHandlerMappings(HandlerMappings mapings) ?)
- dall' altra , nel separare i "raw events" ( attualmente i tasti premuti sulla LWJGLKeyboard, ma potenzialmente opcode ricevuti via rete ) dalla loro "funzione" (espressa da opcode generici come UP, DOWN, ENTER, BUTTON1, BLOW, QUIT, attualmente frammisti agli altri e usati come "target code" nella conversione) magari introducendo un enum a parte (Function ?)
se il coach non ha niente in contrario potreste provare a seguire questa strada ;)
Jappila il tuo task forse è un po' troppo complesso per introdurre m.distrutti al tdd. Richiede una conoscenza della nostra codebase piuttosto avanzata. Forse il mio task è più indicato. Dopo di che può provare a fare il terzo anche assieme a Jocchan.
Se quando torno a casa questa sera lo trovo online vedo se ha voglia di fare qualche commit :)
jappilas
22-04-2008, 14:55
controordine, non avevo letto il post di Jocchan ... :O
che peraltro è proprio il chiarimento in cui speravo - il discorso che facevo sopra nasceva dal fatto che partivo dal presupposto che si trattasse di una richiesta dii funzionalità a livello architetturale quando in effetti non lo era ... come sempre chiarirsi è la cosa migliore :D
Allora, chiarisco meglio un pò di dettagli.
Il punto del primo task è separare gli input dalle griglie: al momento con la configurazione di tasti del giocatore uno controllo quella di sinistra, e con quella del giocatore due controllo quella di destra.
Bene, l'obiettivo è fare in modo che domani sia possibile - ad esempio - controllare entrambe le griglie con i tasti del giocatore 1, o solo quelli del 2, o mettere il 2 a sinistra e l'1 a destra... oppure (cosa un tantino più interessante) sfruttare come sorgente di input anche qualcos'altro :D :D :Dtempo fa stavo pensando giusto a qualcosa del genere e avevo provato a implementarla come spike - quello che avevo in mente si basava su dei "profili" a livello di configurazione dei tasti, associati a due nuove entry di game config per selezionare il profilo da usare per il singolo giocatore ( quindi campo di gioco, quindi input / input reactor)
con questo sostanzialmente non si sarebbe più vincolati a due serie fissate di keycode associati a id P1.* e P2.* , ma i "profili" possono essere in numero arbitrario (da 1 a N ) ed avere il naming che si preferisce (ad esempio "keyboard 1", "joypad 1", "keyboard 2" e così via, oppure "profile 1, 2,...", o abbreviazioni ... )
se si tratta di una cosa del genere in effetti è un task semplice :)
C'è rimasto qualche task per me?? :stordita:
Questo task 18.1 è di qualcuno??
C'è rimasto qualche task per me?? :stordita:
Questo task 18.1 è di qualcuno??
Joc?
C'è rimasto qualche task per me?? :stordita:
Questo task 18.1 è di qualcuno??
Tuo (e/o di Jappi) se date una stima del tempo necessario per completarlo :)
A proposito, tecnicamente anche il task 2 ora andrebbe riassegnato... ma la stima di Vic risale a prima che si decidesse di svolgerlo in pair con m.distrutti. Quindi ne serve una nuova (anzi, serviva già da prima di iniziare a lavorarci)... occhio a questo dettaglio, mi raccomando ;)
Per semplificare le cose, facciamo che se (in situazioni simili) non viene specificata una stima il tempo viene fissato di default a due giorni, scaduti i quali il task viene sempre e comunque revertato (se incompleto) e riassegnato.
Se finiamo presto qualche altro taskettino salterà fuori in men che non si dica :D
P.S.: Dimenticavo di specificarlo, ma ovviamente cambiare la texture del menu principale è fuori task... anche perchè solo io o XAndE potremmo farlo, quindi non avrebbe senso scriverlo lì ;)
Tuo (e/o di Jappi) se date una stima del tempo necessario per completarlo :)
La stima e' obbligatoria. No stima no party e no task.
jappilas
23-04-2008, 21:40
La stima e' obbligatoria. No stima no party e no task.giusto :)
è che per quanto mi riguarda pensavo di stabilire se prendere il task ed eventualmente dare una stima di durata, una volta accertata che la mia "interpretazione" del task (di cui a qualche post fa - in pratica introdurre un nuovo Enum "function" e/o dei "profili" di tasti) fosse corretta, o non si trattasse invece di altro ;)
m.distrutti
24-04-2008, 11:12
Task 18.1: Disaccoppiare InputReaction da GridController
Task 18.2: Riabilitare l'item Advanced Mode - Vicius + m.distrutti (2 giorni, scade il 24/04)
Task 18.3: Rinominare Advanced Mode in NetPlay
vorrei prenotarmi per il 18.3 giusto per continuare a tenermi in esercizio
devo fare anche un test relativo o farlo in coppia a qualcuno ?:)
provo a dare una soluzione giusto per discuterne un attimo XD
giusto per capire se lo farei bene :
rinominare ADVANCED MODE significa rinominare la stringa passata al costruttore di menuitem o rinominare in più anche il nome della variabile?
quest'ultimo credo possa far fallire in side effect molti test (che in teoria penso siano facili da correggere)
test:
public void testAdvancedModeBeganNetPlay()
{
assertEquals("NET PLAY", MenuItem.ADVANCED_MODE.toString());
}
uhm questo però mantiene il nome della variabile
vorrei prenotarmi per il 18.3 giusto per continuare a tenermi in esercizio
devo fare anche un test relativo o farlo in coppia a qualcuno ?:)
provo a dare una soluzione giusto per discuterne un attimo XD
giusto per capire se lo farei bene :
rinominare ADVANCED MODE significa rinominare la stringa passata al costruttore di menuitem o rinominare in più anche il nome della variabile?
quest'ultimo credo possa far fallire in side effect molti test (che in teoria penso siano facili da correggere)
test:
public void testAdvancedModeBeganNetPlay()
{
assertEquals("NET PLAY", MenuItem.ADVANCED_MODE.toString());
}
uhm questo però mantiene il nome della variabile
Va cambiato anche il nome della variabile, non abbiamo più un Advanced Mode :)
Qualche volontario per il pair?
Il test per il cambiamento dubito serva se c'è già un test che controlla che il nome della variabile sia NETPLAY (tutto attaccato fa più figo): visto che ADVANCED_MODE cessa di esistere, imho basta solo verificare che NETPLAY dia il valore corretto.
Per il pair non mi propongo io perchè in questo weekend mi verrebbe difficile trovare orari ben precisi... però per una mano via msn o via forum ci sono senz'altro ;)
m.distrutti
24-04-2008, 11:31
si tratta quindi di cambiare i test già attuali
se si potrei farlo io ora prima di andare al lavoro :D
si tratta quindi di cambiare i test già attuali
se si potrei farlo io ora prima di andare al lavoro :D
Se puoi farlo rapidissimamente, allora dai... per un pair rapidissimissimo ci sto.
Addami su msn :)
si tratta quindi di cambiare i test già attuali
se si potrei farlo io ora prima di andare al lavoro :D
Esatto. Devi usare un Refactor->Rename con la variabile e cambiare la stringa nel test così fallisce. Poi aggiorni la stringa nel codice per vedere magicamente tutto tornare verde. Ricorda Red-Green-Refactor.
Per le texture poi devi aspettare i grafici :D
m.distrutti
24-04-2008, 11:40
Se puoi farlo rapidissimamente, allora dai... per un pair rapidissimissimo ci sto.
Addami su msn :)
ok :P
intanto che cerco il tuo contatto, il mio e' : ***********
Addato, ora se non vuoi valanghe di spam ti consiglio di editare il post :)
Iniziamo il pair.
Tempo: 2 giorni (lol).
Iniziamo il pair.
Tempo: 2 giorni (lol).
Va bene stare larghi ma non vi sembra di esagerare in questo caso? :asd:
Va bene stare larghi ma non vi sembra di esagerare in questo caso? :asd:
Il LOL serviva appunto per questo :D
Task completato :)
Manca solo il task 1... fatevi sotto, così chiudiamo la storia e facciamo qualcosa di molto, molto simpatico :D
P.S.: date un pò un'occhiatina al menu principale...
m.distrutti
24-04-2008, 15:18
Il LOL serviva appunto per questo :D
Task completato :)
oddio mi sto drogando :D
mi e' sempre piaciuto correggere gli errori nei miei programmi o in quelli di amici che chiedevano aiuti :Prrr:
se e' possibile cmq parteciperei mentre fate il pair del primo task che mi sembra un po più complesso, ne approfitterei per continuare a capire meglio la code base
ma allora sto 8.1 chi lo fa? :stordita:
ma allora sto 8.1 chi lo fa? :stordita:
Abbiamo un volontario! :D :D :D
Abbiamo un volontario! :D :D :D
ma allora bisogna farlo in pair? vorrei solo capire in che modo si vuole assegnare i mapping alle due griglie.....per quanto mi riguarda l'idea di jappilas non è male..
Non si deve fare per forza in pair.
Sia Jappi che Bonfo si erano proposti per farlo in pair, ma nessuno ha prenotato il task, quindi è liberissimo.
L'obiettivo è semplicemente separare gli input dalle griglie, in modo che - se domani volessimo, e in effetti lo vogliamo - potremmo cambiare la sorgente di input in un lampo.
MasterDany
04-05-2008, 14:02
se c'è qualcosa di facile me lo fate fare? :)
se c'è qualcosa di facile me lo fate fare? :)
Quale parte di "No" non ti e' ancora chiara?
Quale parte di "No" non ti e' ancora chiara?
Come sa essere cattivo fek non ci riesce nessuno! :D :D
MasterDany
08-05-2008, 15:11
Quale parte di "No" non ti e' ancora chiara?
se mi spieghi il perchè giuro che non vi rompo più le palle.....perchè "no"?
se mi spieghi il perchè giuro che non vi rompo più le palle.....perchè "no"? perché sei volgare. ora te ne devi andare; l'hai detto eh!
MasterDany
08-05-2008, 15:26
perché sei volgare. ora te ne devi andare; l'hai detto eh!
che ho fatto di volgare^?
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.