View Full Version : [CICLO 13] Storia 1
Storia: Introduzione delle pietre, un nuovo tipo di pezzo definito da un colore (come per le gemme), da un punteggio nullo e da un numero, scelto con un valore tra 5 e 1, a seconda della riga (dal basso verso l’alto) in cui le stesse verranno depositate, seguendo lo schema in basso.
Tale numero sarà mostrato nella png usata dalla pietra in questione, ed il suo valore diminuirà di 1 ogni volta che una coppia viene droppata dal giocatore. Quando questo arriverà a zero, la pietra in questione si trasformerà in una gemma del colore corrispondente.
Ogni volta che il giocatore droppa una coppia di gemme, e prima che la coppia successiva inizi a cadere, un numero di pietre pari al valore del contatore situato sotto la propria area di gioco, e di colore scelto casualmente, verrà fatto cadere (a velocità accelerata) nella sua schermata, da sinistra verso destra, ed eventualmente su più strati in verticale. Al termine di questa operazione, il contatore verrà riportato a zero, e le gemme torneranno a cadere.
Schema per le pietre
Righe -> Valore
13, 12 -> 5
11, 10 -> 4
9, 8, 7 -> 3
6, 5, 4 -> 2
3, 2, 1, 0 -> 1
Punti cardine da tenere a mente durante i lavori:
* 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 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
Questo è un ciclo tosto che ci porterà ad avere la first playable che rilasceremo alla fine del prossimo ciclo dopo un po' di bugfix e refactoring.
Task:
13.1.1: Ufo13: completato
Aggiungere a GemType 5 nuovi tipo di Stone ognuno dei quali deve essere legato
ad un tipo di gemma normale. Le pietre avranno punteggio zero e non potranno
essere cancellate ne dalle flashing gem ne dai bauli. Le gemme non hanno animazione
Durante la caduta deve essere mostrato solo il primo frame presente nella texture.
13.1.2: Ufo13 + Bonfo: completato
Cambiare il codice che crea le stone in modo che il frame da mostrare durante la
caduta sia dipendente dalla riga in cui è previsto che la pietra andra a collidere.
Per sapere quale frame usare seguite la tabella:
Riga Frame
13-12 2
11-10 3
9-7 4
6-4 5
3-0 6
13.1.3: thebol: 3 giorni
Ogni volta che un nuova gemspair viene fatta collidere completamente si deve
aumentare il numero del frame da visualizzare di tutte le pietre presenti al
interno della griglia. Se una pietra è già arrivata al frame numero 6 allora la
si deve togliere dalla griglia sostituendola con una gemma dello stesso colore
nella stessa posizione.
13.1.4: (possibilmente in pair)
Ogni volta che si sta per creare una nuova gemspair si deve sempre controllare
se ci sono delle incoming stone. Se queste sono presenti si deve inserire nella
griglia un numero di pietre pari a questo numero. Si inserisce una pietra per
colonna partendo dalla prima a sinistra. Se si raggiunge l'ultima colonna a destra
si deve ritornare nella prima colonna e ripartire finché il numero di pietre non
raggiunge zero. Durante l'inserimento delle la griglia deve avere la gravità settata
al massimo.
ciao ;)
Ne voglio 1 !!!! :boxe:
Il problema è che fino a giovedì non posso proprio...e poi sabato e domenica non ci sono. :(
Tenetemi un posticino :flower:
C'è qualche task obbligatorio in PAIR ???
Prendo il task 1
Assegnato. Quanti giorni ?
ciao ;)
C'è qualche task obbligatorio in PAIR ???
L'ultimo vorrei fosse fatto in pair. Se però non si offre nessuno potete farlo anche da soli.
ciao ;)
Assegnato. Quanti giorni ?
ciao ;)
2 :)
Test List:
- Il punteggio delle Stone vale 0.
- Una Stone non viene cancellata ne da Baule dello stesso tipo, ne da Flashing Gem.
Intanto comincio con questi
Ho appena fatto update e ho visto che sono state modificate le PNG delle stones...perchè??? Mentre cadono quale frame facciamo vedere???
....mi devo essere perso qualcosa :stordita:
Ho appena fatto update e ho visto che sono state modificate le PNG delle stones...perchè??? Mentre cadono quale frame facciamo vedere???
....mi devo essere perso qualcosa :stordita:
Le modifiche alle png le ho fatte stamattina io, e questo perchè avere un numero che compare all'improvviso quando le pietre toccano terra non è il massimo della vita.
Quindi, meglio assegnare la png giusta fin da subito, ed inoltre questo ci fa guadagnare un altro frame, utilizzabile per l'animazione dello "sgretolamento" (che implementeremo in seguito) ;)
Jocchan...sempre puntuale :D
Ottima motivazione, ma ora si complica un po' il codice....ovvero dobbiamo prima della caduta sapere già dove si fermerà la pietra. :(
Invece prima la facevamo cadere e poi quando si fermava scoprivamo la posizione e assegnavamo il frame ;)
Jocchan...sempre puntuale :D
Ottima motivazione, ma ora si complica un po' il codice....ovvero dobbiamo prima della caduta sapere già dove si fermerà la pietra. :(
Invece prima la facevamo cadere e poi quando si fermava scoprivamo la posizione e assegnavamo il frame ;)
So bene che in questo modo, inevitabilmente, il codice verrà su leggermente più complesso, ma c'è da dire che il vantaggio in termini visivi è notevole, e che in ogni caso, in confronto a buona parte dei task svolti finora, non si tratta di un'aggiunta troppo difficile, nè troppo onerosa in termini di tempo ;)
Ok...immaginavo avessi già fatto tutti i conti di "fattibilità" :D :D
Ho un po' rimaneggiato GemType. Incominciava a non essere più molto ordinata.
I costruttori incominciavano ad non essere più razionali..venivano su un po' come i funghi. (C'era addirittura un createChest che creava solamente Flashing gem !!! :O )
Ecco le modifiche. :sofico:
1) COSTRUTTORE UNICO
private GemType(String name, int score, ItemType itemType, GemType baseType)
{
this.name = name;
this.score = score;
this.itemType = itemType;
if(baseType==null)
{
this.baseType = this;
}
else
{
this.baseType=baseType;
}
}
2) COSTRUTTORI per le varie GEMME
private static GemType createGem(String name, int score)
{
return new GemType(name, score, ItemType.GEM, null);
}
private static GemType createFlash(String name)
{
return new GemType(name, 0, ItemType.FLASH, null);
}
private static GemType createChest(String name, GemType baseType)
{
return new GemType(name, 0, ItemType.CHEST, baseType);
}
bonfo non ha senso quel costruttore... erano meglio 2...
dovrei committare GemType in serata...
bonfo non ha senso quel costruttore... erano meglio 2...
Sono arrivato tardi...
Comunque Ufo i costruttori non erano 2 ma almeno 3 o 4.
Poi mi spiegheresti l'errore che ho fatto??? :mbe:
Grazie
CIAO :D:D
EDIT: ho visto ora come l'hai modificato.
Ho capito cosa intendvi...sono d'accordissimo su come l'hai fatto. ;)
Hai diviso il costruttore per le gemme senza legami e quelle con legami. :D
Prima però c'era molta più confusione sui costruttori. C'erano 3 o 4 costruttori tutti con parametri diversi e addirittura un createChest() con solo la signature diversa per creare le flashing gem.
Ora così mi sembra molto più ordinato ;)
Sono arrivato tardi...
Comunque Ufo i costruttori non erano 2 ma almeno 3 o 4.
Poi mi spiegheresti l'errore che ho fatto??? :mbe:
Grazie
CIAO :D:D
EDIT: ho visto ora come l'hai modificato.
Ho capito cosa intendvi...sono d'accordissimo su come l'hai fatto. ;)
Hai diviso il costruttore per le gemme senza legami e quelle con legami. :D
Prima però c'era molta più confusione sui costruttori. C'erano 3 o 4 costruttori tutti con parametri diversi e addirittura un createChest() con solo la signature diversa per creare le flashing gem.
Ora così mi sembra molto più ordinato ;)
Sì era confuso ed infatti prima di iniziare il task avevo un po' snellito... Comunque GemType ha bisogno di ulteriore refactoring... Vedrò cosa fare i prossimi giorni :P
L'ultimo vorrei fosse fatto in pair. Se però non si offre nessuno potete farlo anche da soli.
ciao ;)
Diciamo pero' che se non si offre nessuno per farlo in pair vengo dritto dritto dalla Sillicon Valley a tagliarvi le ditine. Fatemi contento, fatelo in pair e possibilmente anche il task 3 :)
Siamo vicinissimi alla first playable, dateci dentro che poi la strada e' tutta in discesa.
Diciamo pero' che se non si offre nessuno per farlo in pair vengo dritto dritto dalla Sillicon Valley a tagliarvi le ditine. Fatemi contento, fatelo in pair e possibilmente anche il task 3 :)
Siamo vicinissimi alla first playable, dateci dentro che poi la strada e' tutta in discesa.
Fek è nervoso perché fra un po' deve fare la sua presentazione al GDC. Meglio non contraddirlo. :D
ciao ;)
Siccome vedo che nessuno si fa sotto....prendo il task 2
Inizio domani sera (come già detto fino a domani dovrei studiare come un pazzo...e invece posto sul forum :D)
Tempo previsto: 4 giorni (ovvero massimo lunedì sera ;) )
P.S.: se qualcuno è già pronot per farlo sin da oggi e non riesce a resistere...no problem!!
Basta che me ne lasciate uno dei 2 in pair ;)
Siccome vedo che nessuno si fa sotto....prendo il task 2
Inizio domani sera (come già detto fino a domani dovrei studiare come un pazzo...e invece posto sul forum :D)
Tempo previsto: 4 giorni (ovvero massimo lunedì sera ;) )
P.S.: se qualcuno è già pronot per farlo sin da oggi e non riesce a resistere...no problem!!
Basta che me ne lasciate uno dei 2 in pair ;)
Tutto tuo :)
ciao ;)
Durante la caduta deve essere mostrato solo il primo frame presente nella texture.
Ufo ma lo hai fatto?? .... non lo trovo :cry:
Che cosa?
Ovviamente è implicito dato che è presente solo un frame :)
eeehhhh??? :wtf:
Come è implicito?? Una gemma ha 6 frame e durante la caduta effettua l'animazione con quei 6 frame.
Quindi quando crei una gemma, di qualunque tipo, fai si che durante la caduta sia presente una animazione.
Oppure non ho capito niente io???
Bonfo il task 2 posso prenderlo io se vuoi dato che ho molto tempo libero in questi giorni :P
eeehhhh??? :wtf:
Come è implicito?? Una gemma ha 6 frame e durante la caduta effettua l'animazione con quei 6 frame.
Quindi quando crei una gemma, di qualunque tipo, fai si che durante la caduta sia presente una animazione.
Oppure non ho capito niente io???
Ma ora controllo comunque una gemma di tipo Stone dovrebbe avere solo 1 frame ora come ora :)
Ma ora controllo comunque una gemma di tipo Stone dovrebbe avere solo 1 frame ora come ora :)
No...purtroppo il codice mi sembra dire il contrario.
Ma poi...l'hai testato??? :Prrr: :rotfl:
Comunque per il task non ci sono problemi...ripeto...basta che me ne lasciate uno !!!! :Perfido:
Fammi sapere cosa decidi ;)
Cacchio.... :muro:
Ho fatto il test e porca miseria, come al solito :D, avevi ragione tu Ufo!!!
Ho fatto confusione tra il create di GemFactory e il create di Gem!!!
Chissà dove avevo la testa quando ci ho guardato :fagiano:
No...purtroppo il codice mi sembra dire il contrario.
Ma poi...l'hai testato??? :Prrr: :rotfl:
Ora guardo e vediamo. Se serve aggiungo un test altrimenti se non serve niente.
Per i task stai tranquillo che prima finiamo la storia prima inizia il ciclo successivo = altri task. Non si può aspettare tutti quelli che vogliono un task e rallentare il lavoro dell'intero progetto :)
Bonfo il task 2 posso prenderlo io se vuoi dato che ho molto tempo libero in questi giorni :P
Ora non fare l'ingordo :p
Se rimane qualcosa ti facciamo fare il bis altrimenti prima ci sono gli altri.
ciao ;)
Ora non fare l'ingordo :p
Se rimane qualcosa ti facciamo fare il bis altrimenti prima ci sono gli altri.
ciao ;)
Ah già... mi sembrava che il secondo task fosse "bloccante" per il resto dei task.
Se nessuno ha niente in contrario prendo il task 3.
Non è ingordigia ma mi sembra che gli appelli di Fek & Jocchan fossero chiari a riguardo... Insomma dobbiamo andare più veloci ed essendo mancato per un mese mi sento in dovere di recuperare :)
Bonfo: guarda meglio il codice perchè a me questo test passa:
public void testStoneHasOneFrame()
{
Gem stone = createGem(GemType.DIAMOND_STONE);
assertEquals(1, stone.getNumberOfFrames());
}
Ah già... mi sembrava che il secondo task fosse "bloccante" per il resto dei task.
Se nessuno ha niente in contrario prendo il task 3.
Non è ingordigia ma mi sembra che gli appelli di Fek & Jocchan fossero chiari a riguardo... Insomma dobbiamo andare più veloci ed essendo mancato per un mese mi sento in dovere di recuperare
Se cominciamo a correre rischiamo di cadere. :)
Vi va di farlo in pair qui sul forum visto che il task interessa ad entrambi?
ciao ;)
Sì...Ufo hai ragione!! L'ho pure scritto io un paio di post fa ;)
Se cominciamo a correre rischiamo di cadere. :)
Vi va di farlo in pair qui sul forum visto che il task interessa ad entrambi?
ciao ;)
Siamo un team ed abbiamo un obiettivo: portare il progetto a termine.
Dobbiamo essere produttivi e questo significa sfruttare al meglio le risorse. Un mese fa non avevo tempo e ne avevano altri. Ora io ho tempo ed altri potrebbero non averne. Il bello del nostro modo di lavorare è che "chi può lavora".
Per il pair... Per me va bene ma Bonfo non può iniziare prima di domani. Questo significa un giorno in cui il progetto non va avanti se nessuno si offre ora per altri task :)
Ok...vada per il pair!!!
Tanto finchè non finisco non riesco mica a studiare ;)
UFO ha accettato. Iniziamo subito :D
Ok...vada per il pair!!!
Tanto finchè non finisco non riesco mica a studiare ;)
Bene allora cominciate appena potete.
ciao ;)
Ok...vada per il pair!!!
Tanto finchè non finisco non riesco mica a studiare ;)
Ok :)
Siamo un team ed abbiamo un obiettivo: portare il progetto a termine.
Dobbiamo essere produttivi e questo significa sfruttare al meglio le risorse. Un mese fa non avevo tempo e ne avevano altri. Ora io ho tempo ed altri potrebbero non averne. Il bello del nostro modo di lavorare è che "chi può lavora".
Non abbiamo il consiglio di amministrazione della società sotto casa che ci intima di rilasciare il prodotto domani. Diamond è un progetto amatoriale che portiamo avanti nel tempo libero anche se lo rilasciamo due gironi dopo non succede niente :)
Comunque visto che sei cosi pieno di energie lancia cobertura e controlla se ci sono buchi e mancano dei test nel codice, fai tutti i refactoring che ti vengono in mente.
ciao ;)
Non abbiamo il consiglio di amministrazione della società sotto casa che ci intima di rilasciare il prodotto domani. Diamond è un progetto amatoriale che portiamo avanti nel tempo libero anche se lo rilasciamo due gironi dopo non succede niente :)
Comunque visto che sei cosi pieno di energie lancia cobertura e controlla se ci sono buchi e mancano dei test nel codice, fai tutti i refactoring che ti vengono in mente.
ciao ;)
Spesso viene ripetuto che i task vengono prima :)
Riguardo cobertura se capisco come si lancia lo faccio volentieri :)
Riguardo il CdA non c'entra molto il discorso. Comunque meglio non andare OT va :)
Non abbiamo il consiglio di amministrazione della società sotto casa che ci intima di rilasciare il prodotto domani. Diamond è un progetto amatoriale che portiamo avanti nel tempo libero anche se lo rilasciamo due gironi dopo non succede niente :)
E' vero che non abbiamo il CdA, pero' e' anche vero che proprio perche' un progetto didattico vorrei far assomigliare lo sviluppo il piu' possibile a cio' che si incontra in un progetto reale, problematiche incluse. Passata la First Playable daremo date precise per la Alpha, la Beta e la Gold e quelle date saranno fisse e immutabili. Cio' che mutera' per raggiungere le date sara' l'elenco delle feature che implementeremo: qualora ci accorgessimo che la nostra Velocita' non ci permettera' di implementare tutto cio' che vogliamo entro una data stabilita, taglieremo delle feature dalla lista in ordine di priorita'.
Detto questo, preferiamo che nessuno prenda piu' di un task a Ciclo, a meno che i task non riescano ad essere assegnati. Chi ha gia' un task e tempo a disposizione si puo' dedicare al refactoring che a questo stadio di sviluppo e' forse piu' fondamentale dei task stessi, per mantenere la nostra produttivita' alta.
Spesso viene ripetuto che i task vengono prima :)
Riguardo cobertura se capisco come si lancia lo faccio volentieri :)
I task vengono prima degli Spike, ma gia' da qualche Ciclo voglio che prima di iniziare il proprio task si faccia refactoring del codice sul quale si deve lavorare. E finito il task uno sguardo a cobertura per infoltire a nostra rete di test. Abbiamo di recente avuto qualche problema con test mancanti e bug inseriti da alcuni refactoring che ci hanno rallentato.
^TiGeRShArK^
22-03-2006, 20:01
io x ora sono out... :(
oltre al lavoro ke spesso e volentieri dura fino alle 7 in questi giorni devo pure studiare x un concorso finkè vado a letto...:muro:
voglio morire... :cry:
torno a studiare va... :sob:
task 13.1.2 completato. :yeah:
Ci sarebbe un refactoring finale realtivo al task, ma che il checkstyle mi blocca, quindi non è stato ancora committato
postato anche il refactoring...task completato...completamente :rotfl: :rotfl:
Una cosa "importante" che abbiamo fatto. Abbiamo reso pubblico setCurrentFrame()
Forse non è belissimo. Forse ci vorrebbe un meteodo che mascheri questa invocazione per mantenere il metodo setCurrentFrame() privato.
Finiamo la storia poi vediamo se ci vuole un refactoring ;)
Non si è prenotato nessuno per i task 3 e 4?????
io prendo il 3(ci avevo pensato ieri sera ma poi mi ero scordato di postare :asd: )
tempo stimato 2/3 giorni
io prendo il 3(ci avevo pensato ieri sera ma poi mi ero scordato di postare :asd: )
tempo stimato 2/3 giorni
Assegnato. Buon lavoro.
ciao ;)
prima domanda:
il ciclo di aggionamento stone e trasformazione in gemme deve essere fatto prima delle crush o dopo?
prima domanda:
il ciclo di aggionamento stone e trasformazione in gemme deve essere fatto prima delle crush o dopo?
Dopo :)
Questa deve essere l'ultima cosa da fare prima di far cadere una nuova coppia ;)
con un delay, fra l'ultima crush e la successiva insertGem?
con un delay, fra l'ultima crush e la successiva insertGem?
Esatto, appena prima del delay già esistente, così l'utente ha il tempo di accorgersi dei cambiamenti ;)
ho un problema nel creare la gemma dalla stone.
gamFactory è contenuta solo in gemQueue(che non espone nessun getter), a sua volta contenuta in gridController(che non espone nessun getter di gemQueue).
il mio punto di partenza teorico era grid, ma potrei spostarlo in gridController(dovrei rendere visibile il metodo forEachGem di grid pero) e fare in modo che sia gridController che passi la gemFactory a queue(il gemGenerator) quando la interroga.
oppure faccio gemFactory singletone e risolvo in 2 minuti pero rischio l'ira di fek(una classe che crea gemme singletone non la vedo poi cosi male.. :fiufiu: )
Non rischiare l'ira di Fek !!! :ops2:
Comunque anche a me piace poco il singleton in questo caso.
Fai "salire" GemFactory e passala come parametro a GemQueue, sempre che i parametri non siano già troppi.
Per me è la soluzione più pulita ;)
TheBol per come la vedo io puoi anche spostare la creazione di una Stone da un'altra parte... Effettivamente la GemFactory crea elementi di genere differente :)
TheBol per come la vedo io puoi anche spostare la creazione di una Stone da un'altra parte... Effettivamente la GemFactory crea elementi di genere differente :)
il prob e che non devo creare stone, ma delle gemme vere e proprie!
beccatevi i test per forEachGem
public void testForEachGem()
{
Grid grid = Grid.createForTesting();
Gem gem = null;
GemAction gemActionTest = new GemAction(){
public void applyOn(Gem gem) {
gem.stop();
};
};
for(int i = grid.getNumberOfRows() - 1; i >= 0; i--)
{
for(int k = grid.getNumberOfColumns()- 1; k >= 0; k--)
{
gem = createGem(DIAMOND);
gem.setCellPosition(i,k);
grid.addGemToGrid(gem);
}
}
for(int i = grid.getNumberOfRows() - 1; i >= 0; i--)
{
for(int k = grid.getNumberOfColumns()- 1; k >= 0; k--)
{
assertTrue(gem.isFalling());
}
}
grid.forEachGem(gemActionTest);
for(int i = grid.getNumberOfRows() - 1; i >= 0; i--)
{
for(int k = grid.getNumberOfColumns()- 1; k >= 0; k--)
{
assertFalse(gem.isFalling());
}
}
}
public void testForEachGemNull(){
Grid grid = Grid.createForTesting();
GemAction gemActionTest = new GemAction(){
public void applyOn(Gem gem) {
gem.stop();
};
};
try
{
grid.forEachGem(gemActionTest);
}
catch(NullPointerException e)
{
fail("the forEachGem call action for null gem");
}
}
oppure faccio gemFactory singletone e risolvo in 2 minuti
E provaci se hai il coraggio :p
e un casino tirare fuori il gemFactory...
fra l'altro questa classe fa 2 cose, crea gemme, e le crea in maniera random.
Secondo me la cosa piu semplice sarebbe tirare fuori la logica di creazione pura delle gemme e metterla in un singletone.
Secondo me la cosa piu semplice sarebbe tirare fuori la logica di creazione pura delle gemme e metterla in un singletone.
Se ti sente fek ti mangia :D
Edit: ti ha già sentito...sei fritto...
A questo punto credo che sia il caso di dividere GemFactory da RandomGemFactory...il legame che ci dovrebbe essere fra le due potrebbe essere la derivazione, ma GemFactory potrebbe anche essere un semplice membro di RandomGemFectory...
Non ci sono problemi ad istanziare un nuovo RandomGemFactory per generare le stone in locale, al momento in cui ci servono (basterebbe cambiare il seme o passargli lo stesso RandomGenerator)...
Piccola domandina...
Nel task 4 viene detto di inserire le stone, ma non viene detto di che tipo.
Ovvero ogni volta che si effettua un ciclo di incoming-stone queste devono essere:
- scelta casualmente?
- tutte dello stesso tipo?
- secondo un pattern particolare?
- tutte dello stesso tipo del crush che le ha generate??
(E' la versione più impensabile che mi è venuta in mente :D )
Grazie Jocchan per la risposta che mi darai ;)
Per ora, va bene generarle casualmente (come specificato nella storia... dite che devo preparare lo sbucciaginocchia per chi non la legge? :D ).
Una sorta di pattern lo introdurremo nel prossimo ciclo :)
OOOPS !!! :ops:
Avevo riletto solo il task...non mi sono riletto pure la storia :(
Mi perdoni vero .. :ave:
:D
Jocch posa lo sbucciaginocchia...
... ma lo tiene a portata di mano, non si sa mai :stordita:
;)
Manca il task in pair. Chi si propone?
Io mi propongo. Puoi chiarire il tipo di stone?
Mi sa che Jocch ha ripreso in mano lo sbucciaginocchia !!!
:rotfl: :rotfl: :rotfl: :rotfl:
@Ufo : stone casuali
Ok Ufo...mi ripropongo pure io :D
Sono fuori..as usually. :(
Quindi appena arrivo a casa, primo pomeriggio, ti contato per partire... ;)
...sempre che non arrivi qualcuno che non ha ancora fatto un task prima di me :D
redcloud
30-03-2006, 20:28
Non ho capito se c'è qualcuno che si sta occupando del task 13.1.4
Magari potrei affiancarmi a qualcuno giusto per entrare nell'ottica.
Bonfo, vuoi provare a farlo tu il task con RedCloud?
P.S.: mi addi su MSN? Non ho il tuo contatto... il mio lo trovi nel thread apposito qui in basso ;)
fatto il task 3 e committato(l'incremento della stone viene fatto 300ms(insertNewGemdelay) prima dell'inserimento della nuova gemsPair)
Thebol, per favore, puoi revertare e rifare il task? :)
Capisco che magari non hai molto tempo ma il codice è stato committato in fretta: La build era rossa ed in più erano presenti test che non testavano adeguatamente. Ora li ho corretti ma mi sento più tranquillo se il task viene rifatto :p
Per favore non usare "i" e "k" nei contatori ma usa qualcosa di più leggibile :)
Si riesce mica ad evitare anche il riferimento a Config in Grid?
Thebol, per favore, puoi revertare e rifare il task? :)
Capisco che magari non hai molto tempo ma il codice è stato committato in fretta: La build era rossa ed in più erano presenti test che non testavano adeguatamente. Ora li ho corretti ma mi sento più tranquillo se il task viene rifatto :p
Per favore non usare "i" e "k" nei contatori ma usa qualcosa di più leggibile :)
Buona idea. Abbiamo visto spesso come fare il revert di un task e implementarlo nuovamente abbia dato moltissimi vantaggi e portato ad una versione piu' chiara e facile da mantenere.
Il punto che vorrei stressare e' che la prima versione del codice di cui viene fatto il revert non e' un errore. Anzi, e' la base fondamentale dalla quale partire per l'implementazione ancora piu' semplice. Questo e' il concetto alla base delle pratiche di refactoring.
thebol te ne occupi tu allora?
Thebol, per favore, puoi revertare e rifare il task? :)
Capisco che magari non hai molto tempo ma il codice è stato committato in fretta: La build era rossa ed in più erano presenti test che non testavano adeguatamente. Ora li ho corretti ma mi sento più tranquillo se il task viene rifatto :p
Per favore non usare "i" e "k" nei contatori ma usa qualcosa di più leggibile :)
la build era rossa perche usavo junit di eclipse invece di quello di ant...non pensavo che le classi locali facessero casino
le i e le k erano nei test, non nel codice pensavo ci potessero stare.
sul revert, secondo me non ha senso, o almeno...
i test incasinati erano quelli sul forEachGem(codice che non ho toccato, l'ho solo reso pubblic) che avevo fatto 3 giorni fa in fretta cosi per provare e poi non ho piu guardato. il resto io non lo butterei via.
altra cosa, nel fare il task ho notato che la creazione delle gemme è un po incasinata(si divide fra Gem e gemFactory). Imho sarebbe utile fare una classe che crea gemme di vario tipo (o fare dei metodi statici a Gem...) e lasciare a GemFactory solo la gestione della creazione random di gemme(passerei l'eventuale gemCreator al metodo extract per esempio)
Direi di aspettare il refactoring sulla gerarchia delle gemme per fare quello che dici, anche perchè cambiarà un po' tutto...
altra cosa, nel fare il task ho notato che la creazione delle gemme è un po incasinata(si divide fra Gem e gemFactory). Imho sarebbe utile fare una classe che crea gemme di vario tipo (o fare dei metodi statici a Gem...) e lasciare a GemFactory solo la gestione della creazione random di gemme(passerei l'eventuale gemCreator al metodo extract per esempio)
Sì meglio semplificare quella parte :)
Puoi fare del refactoring?
Ufo13: ma non c'è l'altro refactoring da fare ? Aggiungere codice a Gem mi sembra sprecato adesso... Senza contare che dopo dovremo comunque modificare GemFactory...
Ufo13: ma non c'è l'altro refactoring da fare ? Aggiungere codice a Gem mi sembra sprecato adesso... Senza contare che dopo dovremo comunque modificare GemFactory...
Ovviamente non sto parlando di aggiungere codice in Gem o quant'altro ma se facendo del refactoring sparisce il riferimento a Config in Grid è meglio.
Inoltre è vero che c'è della duplicazione nella creazione in Gem ed in GemFactory.
Hai perfettamente ragione, c'è anche altro refactoring da fare, questo non vuol dire che questo non sia da fare! Se lui ha un'idea (che non sia stravolgente) per una piccola semplificazione secondo me può essere applicata!
thebol: I test documentano il codice e devono essere comprensibili.
Mettere "row" e "column" al posto di i e k non ti costa niente e rende il codice migliore :)
Ufo13: ma non c'è l'altro refactoring da fare ? Aggiungere codice a Gem mi sembra sprecato adesso... Senza contare che dopo dovremo comunque modificare GemFactory...
dei metodi static in gem era un opzione, la soluzione piu pulita è una creatorGem o qualcosa di simile
thebol: I test documentano il codice e devono essere comprensibili.
Mettere "row" e "column" al posto di i e k non ti costa niente e rende il codice migliore :)
E se vedo i e k al posto di row e column vi faccio volare le ossicine delle ditine :D
Ragazzi, e' importantissimo dare nomi significativi a varabili, campi e metodi. C'e' Eclipse che fa refactoring per noi, ci vuole un secondo, migliora la vita a tutti. Ne vale la pena.
Direi di aspettare il refactoring sulla gerarchia delle gemme per fare quello che dici, anche perchè cambiarà un po' tutto...
non avevo letto questo post..
in effetti ci sono molti refactoring in giro, e continuare a sviluppare immaginando "stravolgimenti" non è il massimo. imho se la prima playable e molto vicina (come sembra) e non la si vuole posticipare sarebbe meglio posticipare i refactoring a dopo la playable. Mi rendo conto pero che questo puo voler dire aggiungere roba da rafactorizzare
non avevo letto questo post..
in effetti ci sono molti refactoring in giro, e continuare a sviluppare immaginando "stravolgimenti" non è il massimo. imho se la prima playable e molto vicina (come sembra) e non la si vuole posticipare sarebbe meglio posticipare i refactoring a dopo la playable. Mi rendo conto pero che questo puo voler dire aggiungere roba da rafactorizzare
Ok, risolvo io la questione. YAGNI. Faremo il refactoring di cionci, ma adesso facciamo tutti i refactoring necessari per semplificare il codice, cosa che semplifichera' la vita anche a cionci nel momento in cui inserira' la gerarchia.
Quindi direi di proseguire con l'eliminazione del codice duplicato nella creazione delle gemme.
Per altro, eliminare il codice duplicato e' sempre la nostra prima priorita'. Se c'e' del codice duplicato lo si elimina sempre subito, non si aspetta.
Inoltre, se ci sono dei refactoring da fare prima della FP, preferisco posticipare la FP e fare i refactoring subito, di modo da non accumulare debiti nel codice per il futuro. Alla lunga fa' risparmiare tempo. Quindi sotto col refactoring :)
E se vedo i e k al posto di row e column vi faccio volare le ossicine delle ditine :D
Ragazzi, e' importantissimo dare nomi significativi a varabili, campi e metodi. C'e' Eclipse che fa refactoring per noi, ci vuole un secondo, migliora la vita a tutti. Ne vale la pena.
erano dei test sperimentali(cercavo un modo per testare un metodo divenuto pubblico) e mi sono dimenticato poi di ridarci un occhio :mc:
per quanto riguarda il codice duplicato ok, fra l'altro ho una mezza idea di come togliere config da grid(lo passo cmq nel costruttore, ma poi non lo salvo come propieta)
erano dei test sperimentali(cercavo un modo per testare un metodo divenuto pubblico) e mi sono dimenticato poi di ridarci un occhio :mc:
per quanto riguarda il codice duplicato ok, fra l'altro ho una mezza idea di come togliere config da grid(lo passo cmq nel costruttore, ma poi non lo salvo come propieta)
Non devi giustificarti :)
Proprio perche' facciamo refactoring di continuo, non e' un problema fare commit di codice non perfetto, basta aggiustarlo appena se ne vede la possibilita'.
Il ciclo termina dopodomani, e manca il task 4. Al momento è una nostra priorità.
sono riuscito a togliere il riferimento a config in grid, e ho aggiunto come parametro al costruttore di gridController config al posto di newGemDelay.
Fra l'altro ora sarebbe molto semplice portare updateStoneAction all'interno di grid, in modo che tutte le action usate da forEachGem() siano in grid(e forEachGem puo ridiventare private).
lo sposto?
Bonfo, vuoi provare a farlo tu il task con RedCloud?
Ragazzi che giorni infernali :coffee: :coffee:
Non sapete quanto vorrei essere stato più presente...soprattutto con tutto il fervore di refactoring che c'è in giro. Tra la gerarchia "di cionci" e il porting SDL mi sa che in un paio di settimane non si riconoscerà più il codice. :D
In ogni caso rispondo all'appello: il task 4 è da fare. :O
Io nel week-end dovrei esserci abbastanza in casa per lavorare tranquillamente. :sofico:
Se RedCloud c'è partiamo, altrimenti chi si offre mi trova pronto ;)
erano dei test sperimentali(cercavo un modo per testare un metodo divenuto pubblico) e mi sono dimenticato poi di ridarci un occhio :mc:
per quanto riguarda il codice duplicato ok, fra l'altro ho una mezza idea di come togliere config da grid(lo passo cmq nel costruttore, ma poi non lo salvo come propieta)
Inoltre i test andavano fatti così:
grid.getGemAt(i, k);
// codice che testa
Mancava la getGemAt e quindi testavi sempre sulla stessa gemma... Il commit era stato fatto senza una buona revisione del codice!
Per favore puoi rivedere tutto appena possibile?
Inoltre i test andavano fatti così:
grid.getGemAt(i, k);
// codice che testa
Mancava la getGemAt e quindi testavi sempre sulla stessa gemma... Il commit era stato fatto senza una buona revisione del codice!
Per favore puoi rivedere tutto appena possibile?
questo e stato colpa del fatto che quel metodo non è stato scritto in TDD(il metodo l'ho solo reso pubblico e non ho pouto fare i test rosso->verde, rosso->verde). Ora il metodo forEachGem si potebbe anche rendere private senza problemi, ma per usi futuri(e anche attuali, in CrushByFlashAction) lo terrei pubblico.
cmq ora ci do un occhiata
questo e stato colpa del fatto che quel metodo non è stato scritto in TDD(il metodo l'ho solo reso pubblico e non ho pouto fare i test rosso->verde, rosso->verde). Ora il metodo forEachGem si potebbe anche rendere private senza problemi, ma per usi futuri(e anche attuali, in CrushByFlashAction) lo terrei pubblico.
cmq ora ci do un occhiata
Perfetto, grazie :)
Se ci sono problemi anch'io sono online e sto aggiornando il codice.
A che punto siamo con il task 4? Non voglio far innervosire Jocchan :D
A che punto siamo con il task 4? Non voglio far innervosire Jocchan :D
Ho contattato RedCloud. :D
Lo facciamo io e lui insieme...purtroppo domani pomeriggio. :eh:
Task 4 rinviato al ciclo successivo.
Ho finito il refactoring in PlayField riguardante updateWarningBox().
Ho spostato molti test di TestWarningBox in TestIncomingStones.
Ok, risolvo io la questione. YAGNI. Faremo il refactoring di cionci, ma adesso facciamo tutti i refactoring necessari per semplificare il codice, cosa che semplifichera' la vita anche a cionci nel momento in cui inserira' la gerarchia.
miiiih....credete che me lo faccia tutto da solo questo refactoring :D
Io direi di organizzarsi...
Visto che la storia è conclusa (anche se purtroppo con un rinvio), che ne dite se cominciamo a parlare di questo refactoring ? Magari in un nuovo thread...
miiiih....credete che me lo faccia tutto da solo questo refactoring :D
Io direi di organizzarsi...
Visto che la storia è conclusa (anche se purtroppo con un rinvio), che ne dite se cominciamo a parlare di questo refactoring ? Magari in un nuovo thread...
Ok, apri pure il nuovo thread. Ce ne possiamo occupare assieme.
Non sono contento che il task sia stato spostato al prossimo Ciclo. Possiamo chiudere e spostare questo topic ora?
Io mi proporrei di concludere il task 4.
Oggi alle 17:30 / 18:00 sono disponibile .... forse anche prima.
Ora siccome questo task è fuori tempo massimo, faccio una proposta. :rolleyes:
Se qualcuno è disponibile al pair...subito.
Se non c'è nessuno potrei farlo io ma con l'appoggio del team. Ovvero contiunuo il thread aperto postando tutto ciò che faccio .... in modo che chi passa possa partecipare al volo. ;)
Attendo una risposta dai "capi" :D :D
Io mi proporrei di concludere il task 4.
Oggi alle 17:30 / 18:00 sono disponibile .... forse anche prima.
Ora siccome questo task è fuori tempo massimo, faccio una proposta. :rolleyes:
Se qualcuno è disponibile al pair...subito.
Se non c'è nessuno potrei farlo io ma con l'appoggio del team. Ovvero contiunuo il thread aperto postando tutto ciò che faccio .... in modo che chi passa possa partecipare al volo. ;)
Attendo una risposta dai "capi" :D :D
Il ciclo è chiuso, ci sono 4 bei nuovi task nel nuovo ciclo :)
Infatti..ho letto adesso ;)
Il task è stato aggiunto alla nuova storia. :D
Allora vado subito a prenotarmi per un task ;) :Prrr:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.