[CICLO 18] Storia 1

[Jocchan]

Sorpresa sorpresa, si ricomincia
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

[Jocchan]

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)

[fek]

Per non dimenticare:

[jappilas]

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

[fek]

Originariamente inviato da jappilas

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]

Originariamente inviato da fek

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

[fek]

Originariamente inviato da jappilas

lo so ...

Jappi, in questo thread mi dici quale task prendi e quanto tempo impieghi. Per le discussioni apri un altro topic.

[jappilas]

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

[Bonfo]

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?!

[fek]

Originariamente inviato da Bonfo

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?!

Tempi? I sottotask dovete produrli voi, il Customer specifica la Storia.
Fammi una lista di sottotask e relativi test.

[Bonfo]

Originariamente inviato da fek

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

Per i sottotask e test, prima devo finire la rapida review del codice

[fek]

Originariamente inviato da Bonfo

Mi sono spiegato male: i tempi erano tra me e Jappi... ovvero quando abbiamo orari compatibili

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.

[VICIUS]

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.

[Jocchan]

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

Per Vic: facciamo che per ora parte lo stesso il gioco normalmente, come se si scegliesse la prima opzione

[VICIUS]

Originariamente inviato da Jocchan

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]

Originariamente inviato da Bonfo

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

Originariamente inviato da fek

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 ) 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

[VICIUS]

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]

controordine, non avevo letto il post di Jocchan ...
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

Originariamente inviato da Jocchan

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

tempo 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

[Bonfo]

C'è rimasto qualche task per me??
Questo task 18.1 è di qualcuno??

[fek]

Originariamente inviato da Bonfo

C'è rimasto qualche task per me??
Questo task 18.1 è di qualcuno??

Joc?