View Full Version : [CICLO 9] Storia 1
Storia: Introduzione del tipo di pezzo "baule" (con numero di colori equivalente a quello delle gemme e punteggio nullo). Quando il baule collide con il fondo o si ferma su una gemma (o agglomerato), tutte le gemme (e/o gli agglomerati) di colore uguale al baule, adiacenti ad esso ed adiacenti tra loro in una delle quattro direzioni principali, spariscono, incrementando il punteggio di un valore pari a quello della somma dei singoli punteggi, e lo spazio lasciato libero viene coperto dalle gemme sovrastanti (gli agglomerati, essendo il legame irreversibile, scenderanno SOLO se non ci saranno gemme al di sotto di tutta la loro larghezza).
Per chiarirci le idee, definiamo questo meccanismo "cancellazione", ed ogni volta che parleremo di cancellazione ci riferiremo a tutto il processo nella sua interezza.
La collisione gemma-baule deve essere rilevata anche in senso inverso: se una gemma, quando si ferma, collide con un baule in una delle quattro direzioni principali, si innesca ugualmente il meccanismo di cancellazione sopra descritto. Questo può innescare delle reazioni a catena (chain).
Fin quando ci sono cancellazioni in corso, non devono cadere altre gemme.
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
N.B.:
- I bauli non sono gemme, quindi non devono concorrere nella formazione di agglomerati
- Due bauli uguali, se collidono, si eliminano a vicenda (insieme alle altre gemme di uguale colore adiacenti)
- Non deve mai essere creata una coppia di bauli uguali
Task: Tutti in pair-programming
9.1.1: 71104 + ^TiGeRShArK^:
Aggiungere il supporto per 5 nuovi tipi di gemme "Baule". Le gemme di tipo baule possono essere di 5 colori, uno per ogni tipo di gemma già presente. Modificare quindi RandomGemGenerator perché possa creare questo tipo di gemme con una probabilità più bassa rispetto alle altre. Modificare anche BagOfGem in modo che il punteggio dei "bauli" sia pari a 0.
9.1.2:
Ogni volta che entrambe le gemme di una gemspair si sono fermate grid deve controllare se ci sono dei bauli presenti all'Interno della griglia. Per ognuno di questi bauli deve controllare se esistono gemme o agglomerati dello stesso colore con almeno un lato a contatto col baule. Se ve ne sono allora queste gemme e agglomerati devono essere cancellate dalla griglia. Se queste gemme sono a loro volta a contatto con altre gemme dello stesso colore allora devono essere cancellate anche queste.
9.1.3: Bonfo + cisc:
Se dopo la cancellazione delle gemme o agglomerati vengono a formarsi degli spazi vuoti, e sopra a questi ci sono delle gemme o agglomerati, queste lacune devono essere riempite con le gemme che li sovrastano. Gli agglomerati devono spostarsi verticalmente di un numero di celle che permetta di spostare tutti i membri che formano le loro basi dello stesso numero di righe. Se questo non è possibile allora devono rimanere immobili. Se almeno una gemma è stata spostata allora grid deve rieseguire il controllo per vedere se è possibile cancellare altre gemme.
9.1.4: Ufo13 + ??:
Spostare il calcolo del punteggio dal momento in cui le gemme vengono create nella griglia a quello in cui queste vengono cancellate.
9.1.5:
Impedire la creazione della nuova gemspair finché il processo di cancellazione e spostamento dei task 2 e 3 non è completamente terminato.
ciao ;)
Le png dei bauli son già pronte?
prendo il 9.1.4, 2 giorni dopo la fine del 9.1.2
Bellissimi il 9.1.2 e il 9.1.3 ....!!!
Io ne prendo uno dei due....e se uqlcuno lo vuol fare con me mi fa solo piacere ;)
Siccome mi sembrano tutto tranne che banali mi terrei coi tempi larghi !!!
Bonfo, che ne dici di un bel pair programming con uno de due? ( tanto so sicuro che adesso esce fek o vic che ci dice che uno dei due va fatto in pair:D:D)
Le png le preparo stamattina (scusatemi ma 'sto periodo è un inferno).
I task 2 e 3 immagino saranno solo in pair programming, ma aspettate la conferma di Fek e/o Vicius.
9.1.1 io!!! :D
ora provo a sviluppare qualche test...
ma i test per RandomGenerator non esistono? :confused:
ma i test per RandomGenerator non esistono? :confused:
Non è facile testare la randomizzazione...
Comunque credo che cionci avesse testato qualcosa... Usa la funzione di ricerca (mi pare ctrl+shift+g) per vedere chi chiama il metodo selezionato.
Non è facile testare la randomizzazione... mock, mock, mock!! :D
ora cerco, se i test non ci sono li aggiungo io :Prrr:
mock, mock, mock!! :D
ora cerco, se i test non ci sono li aggiungo io :Prrr:
hmmmmm non intendevo quel genere di problema... Il task è tuo cmq :)
DanieleC88
24-01-2006, 10:40
Wow, storie toste, queste. Peccato che sono senza Eclipse e Java al momento, devo provare a reinstallarli, anche se non ho ancora recuperato la Debian, posso fare qualcosina qui dalla Knoppix. :)
Ma lo so tanto che con voi non c'è scampo, nel frattempo che io cerco di reinstallare il necessario voi avete già prenotato e finito tutto! :D
Ok cisc....io prefereisco il 9.1.3, ma sono pronto a contrattare per il 9.1.2 ;)
E' bene pèrò dirti quando nun ci sono... :( ...e quando ci sono :D
Ti mando un pm.
Ciao
Visto che i task sono solo cinque ma tutti piuttosto complessi, fateli tutti in pair per favore. E mi raccomando la test list prima di iniziare.
^TiGeRShArK^
24-01-2006, 10:53
io mi prenderei quello dei due che mi lasciate...
miii che siete cannibali però! :Prrr:
EDIT:
visto il post di fek, 71104 che ne diresti di un bel pair x il task 1? :D
eh volentieri, ma c'è un problema: i test per il primo task non ci sono, è tutto untested e testare comporta un overhead che non vale la pena; fek, puoi vedere tu stesso per favore? io per adesso ho fatto uno spike modificando in questo modo il metodo RandomGenerator.extract:
public int extract(int gems)
{
if (rand.nextInt(100) >= 70)
{
return rand.nextInt(gems);
}
else
{
return gems;
}
}
e aggiungendo una linea in GemType:
public static final GemType EMERALD = new GemType("emerald", 40);
public static final GemType RUBY = new GemType("ruby", 50);
public static final GemType SAPPHIRE = new GemType("sapphire", 60);
public static final GemType TOPAZ = new GemType("topaz", 80);
public static final GemType DIAMOND = new GemType("diamond", 100);
public static final GemType TRUNK = new GemType("trunk", 0);
e anche altre due in BagOfGems:
private void createMapOfGemsWithoutBonus()
{
numberOfGems = new HashMap<GemType, Integer>();
numberOfGems.put(EMERALD, 0);
numberOfGems.put(RUBY, 0);
numberOfGems.put(SAPPHIRE, 0);
numberOfGems.put(TOPAZ, 0);
numberOfGems.put(DIAMOND, 0);
numberOfGems.put(TRUNK, 0);
};
private void createMapOfGemsWithBonus()
{
numberOfGemsWithBonus = new HashMap<GemType, Integer>();
numberOfGemsWithBonus.put(EMERALD, 0);
numberOfGemsWithBonus.put(RUBY, 0);
numberOfGemsWithBonus.put(SAPPHIRE, 0);
numberOfGemsWithBonus.put(TOPAZ, 0);
numberOfGemsWithBonus.put(DIAMOND, 0);
numberOfGemsWithBonus.put(TRUNK, 0);
}
tutto senza test perché i test di quel codice non so se vale la pena di farli; il task sarebbe finito così, ma non ho ancora committato nulla ovviamente.
per quanto riguarda un pair per me va benissimo :D
mi prenoto per il secondo task in pair.
tutto senza test perché i test di quel codice non so se vale la pena di farli; il task sarebbe finito così, ma non ho ancora committato nulla ovviamente.
per quanto riguarda un pair per me va benissimo :D
mi prenoto per il secondo task in pair.
Ma in questo modo come fai a distinguere tra i bauli dei vari colori?
Il codice per caricare le png in Gem lo hai gia scritto ?
ciao ;)
Ho committato i bauli.
Il formato è lo stesso delle gemme (incluso il riflesso animato e l'illuminazione).
In seguito vedremo di creare un'animazione per la loro apertura, e di animare anche i riflessi dei gemmoni ;)
Ma in questo modo come fai a distinguere tra i bauli dei vari colori?
to', è vero ^^
troppa assenza da Diamonds mi ha fatto male T_T
Il codice per caricare le png in Gem lo hai gia scritto ?
si, è implicito: una volta aggiunto il tipo a GemType, la GemFactory ha la possibilità di caricarlo dal nome del file specificato (io avevo temporaneamente messo "trunk"), e se non lo trova carica il diamante di default: infatti avviando il gioco da me al posto dei bauli mi carica tutti diamanti standard (quelli bianchi).
eh volentieri, ma c'è un problema: i test per il primo task non ci sono, è tutto untested e testare comporta un overhead che non vale la pena; fek, puoi vedere tu stesso per favore?
Chi dove cosa come quando? Revert. Test list prima e poi i test e poi il codice. Se c'e' qualcosa di non testato, prima lo si testa e poi si prosegue. Testare vale sempre la pena, mentre non testare potrebbe portare a grosse pene (soprattutto alle ossicine dei ditini :D).
si, è implicito: una volta aggiunto il tipo a GemType, la GemFactory ha la possibilità di caricarlo dal nome del file specificato (io avevo temporaneamente messo "trunk"), e se non lo trova carica il diamante di default: infatti avviando il gioco da me al posto dei bauli mi carica tutti diamanti standard (quelli bianchi).
Piccola nota. Per la gestione delle condizioni di errore applichiamo la filosofia "Die very painfully". Tradotto: niente workaround ad una situazione d'errore nella code base. Se la png non c'e' non carichi una png di default, ma fai esplodere il gioco e uscire con fischi e fuochi d'artificio :)
La test list dov'e'? Il fatto che non possa seguire questo ciclo e il prossimo come vorrei non significa che potete gettare al vento le pratiche. Anzi, anche perche' Vicius e' molto piu' cattivo di me ;)
^TiGeRShArK^
24-01-2006, 11:32
Piccola nota. Per la gestione delle condizioni di errore applichiamo la filosofia "Die very painfully". Tradotto: niente workaround ad una situazione d'errore nella code base. Se la png non c'e' non carichi una png di default, ma fai esplodere il gioco e uscire con fischi e fuochi d'artificio :)
La test list dov'e'? Il fatto che non possa seguire questo ciclo e il prossimo come vorrei non significa che potete gettare al vento le pratiche. Anzi, anche perche' Vicius e' molto piu' cattivo di me ;)
e il file con i fischi e i fuochi d'artificio è committato sul repository??? :sofico:
Anzi, anche perche' Vicius e' molto piu' cattivo di me ;)
:angel:
Poi in BagOfGems non serve mica contenere i trunk o sbaglio? Tanto valgono 0!
e il file con i fischi e i fuochi d'artificio è committato sul repository??? :sofico:
:rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl:
la filosofia "Die very painfully"...ma dove le trovi tutte queste citazioni poetiche :D :D :p
mock, mock, mock!! :D
ora cerco, se i test non ci sono li aggiungo io :Prrr:
C'è già un mock... C'era un test che controllava la sequenza di gemme estratte impostando i numeri da estrarre in MockRandomGenerator... Mi sembrava che fosse in TestGemQueue...
IMHO non è RandomGenerator (che è un semplice RandomGenerator) a dover essere modificato per il task 1, ma è GemFactory...
Modificare GemFactory per gestire i bauli è semplice...estraete un numero in %... Se è inferiore a una certa percentuale (che so 90%) viene generata una gemma, altrimenti un baule...
Piuttosto...chi ha inserito codice non testato in Rectangle ?
I toString() e resizeToContain non sono testati in TestRectangle...
Inoltre a che serve convertire a stringa il rettangolo ?!?? E che vuol dire resizeToContain ????
Non so chi ha aggiunto il toString ma credo serva per gli AssertEquals per mostrare l'errore quando gli oggetti non sono uguali.
Il resizeToContain penso sia stato aggiunto durante il pair tra me e fek... Bisogna aggiungere il test allora... Comunque forse è indirettamente testato da BigGem... Ora non posso guardarci :p
Sì, indirittamente è testato da BigGem, ma non tutto, una condizione non è testata... Mentre toString non è testata per niente...
Bene... Meglio aggiungere i test al più presto :p
Piuttosto...chi ha inserito codice non testato in Rectangle ?
I toString() e resizeToContain non sono testati in TestRectangle...
Inoltre a che serve convertire a stringa il rettangolo ?!?? E che vuol dire resizeToContain ????
Firuli' firula'... :D
Sono stato io, ho coperto quei metodi con i test di BigGem, ma avrei dovuto scrivere dei test espliciti. Errore mio. Mi autospezzo le ditine.
toString mi serviva affiche' JUnit mi mostrasse le coordinate del rettangolo in un test fallito. resizeToContain() cambia la dimensione del rettangolo per contenere un punto che gli viene passato. Lo copro io con un test esplicito.
fek c'è un problema.... Il resizeToContain ipotizza che top e bottom siano capovolti... Cioè top() ha valore minore di bottom()...
Solo in grid questo caso si presenta... Io lo sposterei dentro BigGem...
Hmmm forse si presenta pure sullo schermo... se non sbaglio in OpenGL l'origine è in alto a sinistra... Vabè fai tu :p
Hmmm... fammici pensare :)
DanieleC88
24-01-2006, 14:44
se non sbaglio in OpenGL l'origine è in alto a sinistra...
Se non ricordo male l'origine è in basso a sinistra. Se si passa un'altezza negativa a glOrtho invece l'origine si sposta in alto a sinistra. Giusto?
AAAAAAAAAAAAAAARRRRRRRRGHH COSASTATEFACENDO!!!!
vi siete già scordati tutti le pene che abbiamo subito alla seconda storia a causa dell'origine???? :D
L'ORIGINE E' IN ALTO A SINISTRA, ce l'abbiamo messo apposta per uniformarci allo standard, e io l'ho anche scritto nel thread Diamonds Knowledge (che adesso non aggiorno più perché le caratteristiche cambiavano troppo in fretta).
tant'è vero che in Grid la riga 0 è quella in alto, e Grid quando calcola le coordinate delle caselle da disegnare non fa nessuna inversione dell'asse verticale... ;)
Chi dove cosa come quando? Revert. Test list prima e poi i test e poi il codice. tranquillo, come ho già detto (solo che tu non leggi mai :D) non ho fatto nessun commit: era solo uno spike :)
Se c'e' qualcosa di non testato, prima lo si testa e poi si prosegue. Testare vale sempre la pena, mentre non testare potrebbe portare a grosse pene (soprattutto alle ossicine dei ditini :D). domanda, dobbiamo testare RandomGenerator creando un mock della classe Random di Java? RandomGenerator non è testato perché non ne vale la pena: infatti si tratta di una classe estremamente semplice (due metodi di complessità 1 per adesso, uno dei quali passerà forse a complessità 3) e testarla significa introdurre un'interfaccia implementata da due classi, la prima deve incapsulare Random e la seconda deve essere il mock. non credo sia indispensabile farlo, il tutto sarebbe non troppo utile ai fini del TDD e risulterebbe inutile dal punto di vista funzionale.
71104: leggimi ogni tanto ;) RandomGeneretor è testato e c'è già anche il mock :)
Tu nond evi modificare RandomGenerator, ma GemFactory...
Piccola nota. Per la gestione delle condizioni di errore applichiamo la filosofia "Die very painfully". Tradotto: niente workaround ad una situazione d'errore nella code base. Se la png non c'e' non carichi una png di default, ma fai esplodere il gioco e uscire con fischi e fuochi d'artificio :) sono d'accordissimo; ribadiscilo a chi ha scritto questo codice: :)
if(firstExtraction)
{
randomIndex = randomGenerator.extract(gemTypes.length);
firstExtraction = false;
firstRandomGemIndex = gemTypes.length;
secondRandomGemIndex = gemTypes.length;
}
else
{
randomIndex = randomGenerator.extract(gemTypes.length - 1);
}
if(randomIndex >= secondRandomGemIndex)
{
randomIndex = (randomIndex + 1) % gemTypes.length;
}
secondRandomGemIndex = firstRandomGemIndex;
firstRandomGemIndex = randomIndex;
La test list dov'e'? Il fatto che non possa seguire questo ciclo e il prossimo come vorrei non significa che potete gettare al vento le pratiche. Anzi, anche perche' Vicius e' molto piu' cattivo di me ;) aspetta aspetta, che cionci mi sembra che abbia dato un suggerimento che fa al caso mio: mi permetterà forse di proseguire nel mio task lavandomi le mani di Randomgenerator e del fatto che è scoperta :Prrr: :Prrr: :D
71104: leggimi ogni tanto ;) e un momento, ci sarei arrivato :D
RandomGeneretor è testato e c'è già anche il mock :) ho fatto una ricerca da Eclipse: mi dice che non viene usato nei test (ho cercato tutti i riferimenti al costruttore di RandomGenerator e me li trova solo in GemFactory); il mock c'è, ma essendo il mock di RandomGenerator stessa, non servirà certo a testare RandomGenerator :D
Tu nond evi modificare RandomGenerator, ma GemFactory... ok, vedrò come posso fare; il task richiedeva di modificare RandomGenerator e io non guardo il codice da un paio di settimane e non so quasi più come funziona, percui sono caduto in errore ^^
sono d'accordissimo; ribadiscilo a chi ha scritto questo codice: :)
L'ho scritto io :|
aspetta aspetta, che cionci mi sembra che abbia dato un suggerimento che fa al caso mio: mi permetterà forse di proseguire nel mio task lavandomi le mani di Randomgenerator e del fatto che è scoperta :Prrr: :Prrr: :D
PRIMA LA TESTLIST! :D:D:D
sono d'accordissimo; ribadiscilo a chi ha scritto questo codice: :)
L'ho scritto io quel codice ed è completamente testato...non capisco quale problema ci sia nella riga che hai evidenziato...
Il codice era inizialmente stato scritto test driven a partire dai test di TestGemFactory...
Inizialmente Jocchan mi aveva chiesto di rendere l'ultima gemma uscita impossibile da estrarre... Cosa che è stata fatta... Poi quando venivano create due gemme alla volta (per gemspair) mi ha chiesto che si tenessero in considerazioen le ultime due gemme estratte e fare in modo che la gemma estratta fosse diversa dalla penultima...
RandomGenerator è come la classe Timer...non lo puoi testare... Il mock è stato creato appositamente per testare le classi come GemFactory che usano il random generator...
Tu devi modificare GemFactory...se il task dice RandomGenerator allora correggete il task ;)
L'ho scritto io :|
No...l'ho scritto io :cry: :cry:
ok, vedrò come posso fare; il task richiedeva di modificare RandomGenerator e io non guardo il codice da un paio di settimane e non so quasi più come funziona, percui sono caduto in errore ^^
Guarda che quelle classi stanno lì da mesi :sofico:
L'ho scritto io :| :|
PRIMA LA TESTLIST! :D:D:D ok ok ^^
allora, direi che per i test bisogna fare essenzialmente due cose:
1) replicare in TestGemFactory tutto ciò che c'è per testare gli altri tipi di gemme; in altre parole:
- testare che la factory crei il tipo di baule richiesto (metodo create)
- testare tramite il mock che l'estrazione di gemme casuali funzioni anche per i bauli
2) testare che la creazione dei bauli avvenga con una frequenza minore di quella delle gemme normali (nello spike avevo messo 70% di probabilità per le gemme normali e 30% per i bauli; cionci suggeriva 90% e 10%, ad ogni modo il valore lo metto in Config e Jocchan lo setta come più gli piace).
ora penso come fare i test; il primo punto è banale, il secondo lo è decisamente meno... ^^'
L'ho scritto io quel codice ed è completamente testato...non capisco quale problema ci sia nella riga che hai evidenziato... prima mi occupo del mio task, poi proverò a scrivere un test per evidenziarti il problema :)
a proposito VICIUS, penso che il catcher delle eccezioni a monte (quello che crea la segnalazione errori) vada aggiornato:
1) se possibile deve inviarci la mail :)
2) deve gestire a parte le eccezioni tipo TextureNotFound e simili: se un file non viene trovato il problema non è bug del programma (come il messaggio di errore lascia credere) ma un problema di installazione, e secondo me il messaggio d'errore deve essere diverso...
3) non so quanto vada bene il nome del driver della scheda grafica da inserire nella segnalazione errori: su questo mio PC (che ha una scheda grafica abbastanza schifosa, di quelle Intel integrate nella scheda mamma) il nome del driver non solo non mi dice il nome del modello, ma contiene addirittura il nome del mio utente!!! O_o'
un utente che subisce un crash potrebbe non volerci inviare la segnalazione per motivi di privacy...
il secondo lo è decisamente meno... ^^'
Invece è banale...visto che i numeri che il mock estre glieli passi te...
Anzi...ora rivedendo il codice mi è venuto da rifatactorizzarlo...
prima mi occupo del mio task, poi proverò a scrivere un test per evidenziarti il problema :)
No, davvero...spiegamelo... Fammi capire cosa intendi e dove secondo te può esserci il problema...
PS: ho modificato GemFactory...non mi piaceva così :) Comunque la riga che hai evidenziato c'è ancora...
:|
ok ok ^^
allora, direi che per i test bisogna fare essenzialmente due cose:
1) replicare in TestGemFactory tutto ciò che c'è per testare gli altri tipi di gemme; in altre parole:
- testare che la factory crei il tipo di baule richiesto (metodo create)
- testare tramite il mock che l'estrazione di gemme casuali funzioni anche per i bauli
2) testare che la creazione dei bauli avvenga con una frequenza minore di quella delle gemme normali (nello spike avevo messo 70% di probabilità per le gemme normali e 30% per i bauli; cionci suggeriva 90% e 10%, ad ogni modo il valore lo metto in Config e Jocchan lo setta come più gli piace).
ora penso come fare i test; il primo punto è banale, il secondo lo è decisamente meno... ^^'
Perfetto. Solo una piccola nota: metti il valore come intero che rappresenta la percentuale. Evitiamo i floating point.
hmmmm non capisco una cosa... Perchè il baule è una Gem?
71104 non dimenticare i test dove provi una combinazione di 4x4 bauli che non formino una BigGem :D
P.S. in effetti capisco che Trunk possiede praticamente tutti i comportamenti di Gem... Effettivamente ci può anche stare ma occhio ai ruoli diversi di tali oggetti...
Caspita!!!!
Ha ragione Ufo.... :mano: ....un baule non è una gemma!!! :nonsifa:
Se mai sono entrambi dei "Droppable" !!! :sofico:
Qui ci vedo perfettamente una interfaccia e un bel refactoring... ;)
hmmmm no beh solo interfaccia vuol dire duplicare codice a gogo imho...
Meglio definire due dettagli:
- due bauli uguali che collidono tra loro si cancellano a vicenda
- non deve mai essere creata una coppia di bauli uguali
hmmmm no beh solo interfaccia vuol dire duplicare codice a gogo imho...
Effettivamente c'e' molto codice in comune fra Gem e Trunk e non possiamo lasciarci scappare questo segnale.
In questi casi io di solito seguo questo schema decisionale:
1) Posso fattorizzare il comportamento comune in una classe che poi uso all'interno delle due classi o piu' classi? (Composition).
2) Ha senso estrarre un concetto comune fra le due o piu' classi tali che ogni classe sia modellabile rispetto a questo concetto con una relazione "e' un'"? (Inheritance).
Valuto sempre prima 1) e poi 2).
In questo caso 1) porterebbe ad alcune complicazioni perche' sia Trunk sia Gem devono far parte in qualche modo della griglia: ne uscirebbe che Grid dovrebbe tenere conto delle Gem e dei Trunk in gioco e poi anche dei nuovi oggetti contenuti in Gem e Trunk e inserirli nella griglia.
L'opzione 2) mi sembra in questa situazione piu' naturale, un concetto che espone un'interfaccia Droppable, che possiamo chiamare DroppableObject magari. Gem "e' un" DroppableObject, Trunk "e' un" DroppableObject. E direi dei fermarsi qui per ora.
Dunque, io direi di iniziare a implementare Trunk nella maniera piu' semplice possibile al momento, magari derivandolo provvisoriamente da Gem, di modo da riuscira a scriverlo velocemente. Poi guardarei l'implementazione, e se ' il caso applicherei un "Extract Superclass" a Gem e isolerei il comportamento comune. Vediamo che cosa ne esce. Se non va, siamo sempre pronti a rifattorizzare in un'altra direzione.
hmmmm no beh solo interfaccia vuol dire duplicare codice a gogo imho...
:wtf: :wtf: ...non ho capito!?!
In realtà dove fino ad adesso si è usata una gem si usa un Droppable. Poi è ovvio che ci saranno differenze tra bauli e gemme e quindi in certi punti del codice, con un piccolo cast, si mette tutto a posto.
Non vedo dove si replichi il codice. Anzi...ideona :idea:
AbstractDroppableObject implements Droppable
Possiamo mettere lì tutto il codice da non replicare e poi:
Gem extends AbstractDroppableObject implements Droppable
Box extends AbstractDroppableObject implements Droppable
...che ne dite ;)
P.S.:come lo chiamiamo sto baule: Box o Trunk ???
In realtà dove fino ad adesso si è usata una gem si usa un Droppable. Poi è ovvio che ci saranno differenze tra bauli e gemme e quindi in certi punti del codice, con un piccolo cast, si mette tutto a posto.
Tu prova a risolvere le differenze con un cast e di' addio alle tue ditine :D
Bhè..lsenza leggere ho fatto la stessa pensata di Fek. :D
Allora non sono proprio pirla :sofico: :sborone: ...
Tu prova a risolvere le differenze con un cast e di' addio alle tue ditine :D
Mi spiego meglio: si usa a bomba il polimorfismo e poi quando abbiamo bisogno di una gemma utilizziamo una gemma e non un droppable...mi sono fatto capire o no?? :mbe:
...e poi i o ci tengo alle mie ditine :ave:
Mi spiego meglio: si usa a bomba il polimorfismo e poi quando abbiamo bisogno di una gemma utilizziamo una gemma e non un droppable...mi sono fatto capire o no?? :mbe:
Assolutamente no :)
Se passiamo ad un'interfaccia Droppable, allora Grid avra' solo visione di questa e di nient'altro. Non conoscera' ne' Gem ne' Trunk, ma le differenze di comportamento saranno delegate alle diverse implementazioni delle interfacce.
Questo in teoria, ma la pratica ci dice che ancora non sappiamo se riusciremo a fare questo giochino e non vogliamo forzarlo dall'alto sul codice. Quindi per noi questo e' solo il mondo ideale al quale vogliamo tendere. Nel frattempo siamo nel mondo reale e quello che faremo sara' implementare Trunk nel modo piu' semplice possibile e poi vedere se riusciamo a tirare fuori naturalmente il concetto di cui sopra e se semplifica ulteriormente la soluzione.
:wtf: :wtf: ...non ho capito!?!
Se implementi un'interfaccia e basta devi portare il codice dei movimenti sia dentro gem sia dentro trunk... Con la abstract risolvi il problema.
L'idea di fek è quella più semplice per portare il task ma ricordiamo di testare BigGem con i trunk...
D'accordissimo....siamo Xp e non model-driven.
Quello che volevo dire io, purtroppo non ancora conoscendo pienamente il codice, che nel caso in una classe si debba usare una Gemma, tale classe X non userà un droppable ma una Gem, avendo così conoscenza dei metodi propri di Gem e non di Droppable.
Ho detto giusto o una cavolata? :help:
@Ufo: sì...ho capito mentre scrivevo :bimbo: ...infatti mi è venuta in mente la classe astratta. :P
Azz...che bello... Dopo bisognerebbe anche cambiare GemsPair in DroppableObjectsPair :eek:
Comunque quella della derivazione è sicuramente la soluzione più logica... Però verrebbe davvero una bella architettura... Gli handler e grid lavorerebbero su DroppableObjects..
D'accordissimo....siamo Xp e non model-driven.
Quello che volevo dire io, purtroppo non ancora conoscendo pienamente il codice, che nel caso in una classe si debba usare una Gemma, tale classe X non userà un droppable ma una Gem, avendo così conoscenza dei metodi propri di Gem e non di Droppable.
Ho detto giusto o una cavolata? :help:
Non ho capito quello che hai scritto... Provo ad interpretare e a rispondere...
Quello che viene spesso detto è che il passaggio è CODICE->DESIGN quindi facendo come ha detto Fek intanto scrivi il codice e poi vedi se puoi tirare su un design pattern...
Dopo avrebbe senso rendere BigGem un DroppableObject ? Visto che dopo dovrà cadere come gli altri oggetti, certo non si dovrà mai muovere con i tasti o pulsare...questo di fatto lo renderebbe un oggetto "solido"...
Dopo avrebbe senso rendere BigGem un DroppableObject ? Visto che dopo dovrà cadere come gli altri oggetti, certo non si dovrà mai muovere con i tasti o pulsare...questo di fatto lo renderebbe un oggetto "solido"...
Dipende cosa intendiamo per droppable... Io lo stavo intendendo come oggetto controllato dal giocatore (quindi oggetto di gemsPair, controllabile etc).
Per quanto riguarda l'effetto caduta dopo cancellazione... Piuttosto utilizzare un'interfaccia separata? Tipo FallingItemInterface...
Bhè...dipende cosa si fattorizza in DroppableObject...siu potrebbe addirittura ereditare da DroppableObject la classe MovableDroppableObject....
....ma a questo punto Fek ci spacca a tutti le ditine e ci gioca a shangahi!!!
Come ha detto lui siamo Xp e quindi aspettiamo di fare il codice...il più semplice possibile...poi facendo refactoring vediamo se esce da sola questa gerarchia....anche se a me piace tanto :D
Dopo avrebbe senso rendere BigGem un DroppableObject ? Visto che dopo dovrà cadere come gli altri oggetti, certo non si dovrà mai muovere con i tasti o pulsare...questo di fatto lo renderebbe un oggetto "solido"...
Vediamo. Ha delle controindicazione solo per il fatto che BigGem occupa piu' di una casella, ma potrebbe essere una buona soluzione. Ancora non saprei.
^TiGeRShArK^
24-01-2006, 21:17
non entro nella disputa...
ma xkè nn chiamarla "Chest" la classe???
mi pare piu' appropriato....:mbe:
ma xkè nn chiamarla "Chest" la classe???
mi pare piu' appropriato....:mbe:
Concordo...
salve a tutti, scusate se il task l'ho finito oggi ma ieri a un certo punto me ne sono dovuto andare. allora, vi espongo un "report" del mio commit: :p
per prima cosa i test di GemFactory stavano diventando assai confusi (qualche decina asserzioni divise in solo due funzioni di test :muro: ) percui una delle due funzioni (la seconda per l'esattezza) l'ho divisa in 3 funzioni (testRandomGemSequence, testRandomGemDifferentFromPrevious, e testRandomgemDifferentFromTwoPrevious) e poi ho aggiunto un test per il mio task (testBoxExtraction). inoltre ho anche semplificato il metodo createRandomGem con due evidenti miglioramenti:
1) prima il funzionamento non era per nulla chiaro, adesso il codice si autoesplica perfettamente
2) ho eliminato una variabile membro di GemFactory, i test passano tutti e il programma funziona ancora
poi ho letto ciò che avete scritto qui sul forum e avete ragione: siccome per ora i pezzi del baule li ho considerati normali gemme, il programma quando vede che si è formato un rettangolo prova a cercare la texture dell'agglomerato, e ovviamente non la trova, quindi lancia l'eccezione.
ergo adesso serve un bel megarefactoring :)
adesso mi leggerò attentamente la soluzione finale per cui avete optato, poi dopo pranzo proverò a cimentarmici.
ah a proposito, cionci la linea che avevo evidenziato p ancora presenta ma adesso non da' più problemi, comunque per capire qual era prima il problema basta che leggi quello che abbiamo scritto io e fek: dopo che fek mi ha fatto notare che il comportamento del programma in un certo caso non rispettava una filosofia che dobbiamo adottare ("die very painfully") ho fatto apposta un debug per vedere qual era il codice che provocava il caricamento del diamante quando il tipo di gemma richiesta non esisteva, e la linea mi era sembrata proprio essere quella...
ho fatto apposta un debug per vedere qual era il codice che provocava il caricamento del diamante quando il tipo di gemma richiesta non esisteva, e la linea mi era sembrata proprio essere quella...
Impossibile...come fa ad esserci un tipo non esistente nel vettore se io estraggo casualmente una posizione da quel vettore ? Per quella funzione non ci sono parametri...estrae esclusivamente un elemento casuale dal vettore quindi non gli puoi passare un tipo di gemma non esistente...
Ora è comunque identico a prima...ho solo spostato qualche inizializzazione e aggiunto l'intero "module" che prende valori diversi a seconda che sia la prima estrazione o una successiva (prima facevo due chiamate distinti a seconda del ramo del dell'if)...
Semmai è la Gem.create che deve fallire se il tipo di gemma passato non esiste...
ergo adesso serve un bel megarefactoring :)
adesso mi leggerò attentamente la soluzione finale per cui avete optato, poi dopo pranzo proverò a cimentarmici.
Megarefactoring? Non capisco... Basta scrivere un test che lancia l'eccezione e fare in modo che passi... Che refactoring avresti in mente di fare? Secondo me basta aggiungere un metodo isBox dentro Gem che se è di uno dei tipi Box ritorna true...
A quel punto modifichi createNewBigGems di conseguenza :)
p.s. anzi ancora meglio secondo me è aggiungere isBox dentro GemType... Poi fai tu...
Io direi di risolvere il task nella maniera più semplice possibile...poi vedimao dopo in fase di refactoring...
...anche se questo "bug" è "causato" dalle specifiche date...quindi io aspetterei di sentire come deve comportarsi il sistema in questo caso. :D
Altra cosa...?? Ma il 9.1.2 non c'è nessuno che lo fa??
Non so se si può avendone già uno assegnato...ma se nessuno la fa attendo qualcuno che mi contatti per farlo... :sofico:
il sistema deve comportarsi non lanciando l'eccezione e gestendo la situazione correttamente :D
Correttamente che vuol dire?? Ovvero cosa deve succedere se ci sono 4 o più bauli uguali che formano un agglomerato??
Tu stai supponendo un bel:"niente"...e molto probabilmente ai ragione!!! Ma nessuno lo ha mai detto.
...sto facendo il pignolo?? :mbe:
Non deve succedere niente perchè se dovesse succedere qualcosa le specifiche lo direbbero :)
Una cosa è certa: un'eccezione non va generata.
71104: l'algoritmo così come è stato modificato non ha una probabilità uniforme
Ti spiego:
Elementi estratti: a=2 b=3
Estrazione su 5 elementi: con l'algoritmo che hai impementato te la probabilità è 3/5 di estrarre l'elemento 4 !!!
Inoltre non avresti dovuto mettere i bauli nel vettore insieme alle gemme...questo perchè se deve uscire una gemma e le precedenti uscite sono 3 e 4, hai una probabilità 2 su 5 che esca un baule !!! Infatti se escono 3 o 4 esce il primo baule ;)
Altra cosa, io controllavo solo il valore del penultimo valore estratto per permettere l'estrazione di due gemme uguali...che ora non avviene ;)
Suggerimento...il test dell'estrazione delle gemme che c'era già su TestGemFactory ti sarebbe dovuto servire come riprova per mentere identico il funzionamento del tuo algoritmo per le gemme (sarebbe bastato intercalare un "1" fra i valori da estrarre in modo da obbligare GemFactory ad estrarre una gemma)...
71104: l'algoritmo così come è stato modificato non ha una probabilità uniforme
Ti spiego:
Elementi estratti: a=2 b=3
Estrazione su 5 elementi: con l'algoritmo che hai impementato te la probabilità è 3/5 di estrarre l'elemento 4 !!!
Inoltre non avresti dovuto mettere i bauli nel vettore insieme alle gemme...questo perchè se deve uscire una gemma e le precedenti uscite sono 3 e 4, hai una probabilità 2 su 5 che esca un baule !!! Infatti se escono 3 o 4 esce il primo baule ;)
Altra cosa, io controllavo solo il valore del penultimo valore estratto per permettere l'estrazione di due gemme uguali...che ora non avviene ;)
Suggerimento...il test dell'estrazione delle gemme che c'era già su TestGemFactory ti sarebbe dovuto servire come riprova per mentere identico il funzionamento del tuo algoritmo per le gemme (sarebbe bastato intercalare un "1" fra i valori da estrarre in modo da obbligare GemFactory ad estrarre una gemma)...
Stavo in effetti osservando il codice della factory con una certa perplessità...
Ma come si fa a testare la probabilità di uscita?
Altra cosa, io controllavo solo il valore del penultimo valore estratto per permettere l'estrazione di due gemme uguali...che ora non avviene ;) ah ecco, infatti c'era qualcosa che non mi tornava... :mbe:
quindi quell'algoritmo può diventare ancora più semplice :p
correggo subito.
il discorso della probabilità però non l'ho capito... non mi sembra così elevata la probabilità che esca un baule anziché una gemma; da me ho fatto un test: ho riempito l'intera griglia, e sono usciti 22 bauli e 90 gemme, quindi effettivamente c'è qualche sproporzione ma non così elevata come dici...
Credo che sia alquanto impossibile...però sentiamo fek...magari ha a disposizione un MockInfiniteTime o MockInfiniteLoop :D
Credo che sia alquanto impossibile...però sentiamo fek...magari ha a disposizione un MockInfiniteTime o MockInfiniteLoop :D
Scrivi un mock che estrare 1000 gemme in una sequenza riproducibile con le probabilita' che vuoi tu :)
il discorso della probabilità però non l'ho capito... non mi sembra così elevata la probabilità che esca un baule anziché una gemma; da me ho fatto un test: ho riempito l'intera griglia, e sono usciti 22 bauli e 90 gemme, quindi effettivamente c'è qualche sproporzione ma non così elevata come dici...
Non dico che sia elevata...dico solo che non è il 10% ;)
La robabilità che esca un baule è 1/10, più la probabilità che esca un 4 quando l'ultima o la penultima gemma uscita è 4, più la probabilità che esca 3 quando la penultima e l'ultima gemma uscita sono 3 e 4 (e viceversa)...
Con un rapido calcolo: 1/10 + 2*(1/10 * 1/10) + 2 * (1/10 * 1/10 * 1/10)
All'incirca, dovrebbe essere del 12,2%...
Scrivi un mock che estrare 1000 gemme in una sequenza riproducibile con le probabilita' che vuoi tu :)
Mmmmhhh...allora speri nella legge dei grandi numeri ?!?!? Lo sai che sarebbe un test che potrebbe fallire randomicamente ? Nel vero senso della parola...
La legge di Murphy docet :) :sofico:
Non dico che sia elevata...dico solo che non è il 10% ;)
La robabilità che esca un baule è 1/10, più la probabilità che esca un 4 quando l'ultima o la penultima gemma uscita è 4, più la probabilità che esca 3 quando la penultima e l'ultima gemma uscita sono 3 e 4 (e viceversa)...
Con un rapido calcolo: 1/10 + 2*(1/10 * 1/10) + 2 * (1/10 * 1/10 * 1/10)
All'incirca, dovrebbe essere del 12,2%... sisi, hai ragione, guardando il codice ho capito anche io adesso l'errore: sia quando esce una gemma che quando esce un baule può capitare che l'ìndice debba essere incrementato perché questi corrisponde alla gemma o al baule estratto/a due volte fa; ed incrementando l'indice può accadere che l'indice estratto non sia più una gemma, ma un baule, o viceversa, e siccome la probabilità che esca una gemma è più elevata, è altrettanto elevata la probabilità che sia una gemma a diventare un baule e non il viceversa... giusto? :)
adesso provo a correggere...
Giusto...comunque c'è anche l'altro fatto...quando assegno la probabilità zero (una gemma non deve uscire) ad un elemento, l'estrazione casuale la devo fare fra N elementi meno uno ;)
Ti consiglio di spezzare le estrazioni (e anche i vettori) !!!
Anche perchè gli algoritmi devono essere diversi...quello delle gemme deve restare identico a come l'avevo fatto io (a meno che non mi sia perso qualcosa) e tenere conto della penultima gemma uscita, mentre quello per i bauli deve tenere conto solo dell'ultimo baule uscito (non ci devono essere bauli identici nella stessa coppia)...
Non dico che sia elevata...dico solo che non è il 10% ;)
La probabilità che esca un baule è 1/10, più la probabilità che esca un 4 quando l'ultima o la penultima gemma uscita è 4, più la probabilità che esca 3 quando la penultima e l'ultima gemma uscita sono 3 e 4 (e viceversa)...
Ho sbagliato !!!
Mi sono scordato di considerare la probabilità che esca una gemma :D
Giusto...comunque c'è anche l'altro fatto...quando assegno la probabilità zero (una gemma non deve uscire) ad un elemento, l'estrazione casuale la devo fare fra N elementi meno uno ;)
Ti consiglio di spezzare le estrazioni (e anche i vettori) !!!
Anche perchè gli algoritmi devono essere diversi...quello delle gemme deve restare identico a come l'avevo fatto io (a meno che non mi sia perso qualcosa) e tenere conto della penultima gemma uscita, mentre quello per i bauli deve tenere conto solo dell'ultimo baule uscito (non ci devono essere bauli identici nella stessa coppia)... giusto... senti, ho fatto una correzione invertendo semplicemente l'ordine dei due if nell'algoritmo di estrazione in GemFactory (in tal modo la probabilità che esca un baule è più corretta: ho rifatto il test e sono usciti 6 bauli e 98 gemme, a occhio va meglio) e ho eliminato quel test che avevo erroneamente creato per testare che una gemma estratta fosse diversa dalla precedente; ho committato il tutto ma adesso devo proprio uscire, tornerò tra una mezz'ora.
tu puoi dividere i due array per gemme e bauli? poi quando torno sistemerò l'ultima cosa che hai detto (i bauli devono essere diversi solo dal precedente, mentre le gemme devono essere diverse da quelle uscite due volte prima).
Purtroppo non posso occuparmene... C'è da mettere mano ai test... Io ti consiglio di ripartire da zero con le modifiche (PS firstExtraction aveva il suo "perchè" ;))...
71104 scusami se non mi faccio gli affari miei ma questo task dovresti farlo in pair con ^TigerShark^ perchè non aspetti lui?
71104: puoi fare il revert del tuo codice e aspettare Tiger e fare il task in pair per favore?
mi associo a Bonfo, se proprio non c'è nessuno che voglia fare il 9.1.2, dato che appunto dobbiamo aspettare che questo task sia finito, io non ho nulla da fare:D, anche stasera sarei pronto a fare qualcosa:D
^TiGeRShArK^
25-01-2006, 20:16
io mi prenderei quello dei due che mi lasciate...
miii che siete cannibali però!
EDIT:
visto il post di fek, 71104 che ne diresti di un bel pair x il task 1?
per quanto riguarda un pair per me va benissimo
mi prenoto per il secondo task in pair.
Task: Tutti in pair-programming
9.1.1: 71104 + ^TiGeRShArK^:
Aggiungere il supporto per 5 nuovi tipi di gemme "Baule". Le gemme di tipo baule possono essere di 5 colori, uno per ogni tipo di gemma già presente. Modificare quindi RandomGemGenerator perché possa creare questo tipo di gemme con una probabilità più bassa rispetto alle altre. Modificare anche BagOfGem in modo che il punteggio dei "bauli" sia pari a 0.
mi sa ke non ci siamo capiti...:mbe:
e pure stavolta alla fine resto senza task xkè domani sera non posso e poi scendo a reggio :cry:
a saperlo mi facevo il task 2.....:sob:
omg, non guardavo più la prima pagina del thread e perciò non sapevo del pair... ^^
scusate il disagio non ho aspettato TigerShark perché la mia test list era stata accettata, comunque io qualche pagina prima mi ero anche proposto per il pair del secondo task...
allora, rimetto il codice originale in GemFactory e mi organizzo con TigerShark; devo anche revertare i test?
mi sa ke non ci siamo capiti...:mbe:
e pure stavolta alla fine resto senza task xkè domani sera non posso e poi scendo a reggio :cry:
a saperlo mi facevo il task 2.....:sob: nononono scusa avevo capito male io, colpa mia che corro sempre :D
se adesso sei libero possiamo lavorare al primo task in pair anche subito :)
^TiGeRShArK^
25-01-2006, 20:18
71104 scusami se non mi faccio gli affari miei ma questo task dovresti farlo in pair con ^TigerShark^ perchè non aspetti lui?
mi sa ke non ci siamo capiti...
io prima intendevo di fare il task 1 con lui...
poi lui ha detto di fare il task 2..
e vicius ci ha assegnato il task 1 a tutti e due e me ne sono accorto solo stasera... :muro:
Meglio definire due dettagli:
- due bauli uguali che collidono tra loro si cancellano a vicenda
- non deve mai essere creata una coppia di bauli uguali
Ho letto solo ora dell'eccezione in caso di un agglomerato di gemmoni.
Meglio ribadire questi due dettagli: visto che li ho aggiunti dopo, potrebbero essere sfuggiti a qualcuno.
Inoltre, i bauli NON sono gemme, quindi non devono concorrere in nessun caso alla formazione di agglomerati. L'idea di un agglomerato di bauli, quindi, verrebbe a cadere in partenza.
Sì può considerare il task 9.1.1 copletato??
Perchè in questo caso bisogna farsi sotto con il 9.1.2...che lo vedo bello intenso!!!... e forse siamo un po' in ritardo ;)
Io domani sono messo malucchio...forse ho un paio d'ore (forse più un oretta e mezza) dalle 17/17:30 alle 19:00
Per sabato...se ne parla...è un'altra giornata pienotta :(
Comunque mi aspetto appena accendo il Pc di vedere un bel thread di pair programming sul 9.1.2 :D :D
Sì può considerare il task 9.1.1 copletato??
Perchè in questo caso bisogna farsi sotto con il 9.1.2...che lo vedo bello intenso!!!... e forse siamo un po' in ritardo ;)
Penso che questa sarà l'unica storia per questo ciclo. Sono tutti task complessi che introducono importantissimi cambiamenti nel sistema. Se finiamo prima ci concentriamo per bene sul refactoring del sistema e al testing/debuging del codice.
ciao ;)
Penso che questa sarà l'unica storia per questo ciclo. Sono tutti task complessi che introducono importantissimi cambiamenti nel sistema. Se finiamo prima ci concentriamo per bene sul refactoring del sistema e al testing/debuging del codice.
ciao ;)
Esatto. Meglio concentrarci su poche cose, ma farle per bene ;)
Mi piacerebbe partecipare a questo refactoring :cry: ma sono molto occupato :(
Task 9.1.2 nessuno si offre? Hmmm potrei offrirmi a farlo oggi in pair con qualcuno... se qualcuno si offre
Sì...mi sono accorto come questo ciclo abbia una storia molto complessa con i suoi vari task. Quello che volevo dire non è certamente un altra storia...ma che forse non riousciremo a finire i task nelle due settimane solite ;)
Ufo...alla fine oggi sono arrivato a casa ora...se ti va...sono pronto :D :D
Sì...mi sono accorto come questo ciclo abbia una storia molto complessa con i suoi vari task. Quello che volevo dire non è certamente un altra storia...ma che forse non riousciremo a finire i task nelle due settimane solite ;)
Ufo...alla fine oggi sono arrivato a casa ora...se ti va...sono pronto :D :D
Mettiamo da parte il pessimismo. E' un periodaccio per tutti, ma con un pò di impegno ce la faremo agevolmente :)
Ce la faremo !!! :sofico: :sofico:
Ragazzi, continuiamo sul nuovo forum: http://www.nsn3.net/forum/index.php?showforum=814
Per favore dateci una mano a copiare & incollare più roba possibile ;)
Io trovo che sia una decisione assurda...almeno una spiegazione sarebbe utile...e sappiamo che non è quella riportata nel nuovo forum...
Io trovo che sia una decisione assurda...almeno una spiegazione sarebbe utile...e sappiamo che non è quella riportata nel nuovo forum...
Quella non è una spiegazione, ma un elenco delle nuove possibilità aperte dall'altra soluzione. Se sembrava una giustificazione o roba simile allora vedrò di editare il post, dato che non era quello l'intento ;)
Quella non è una spiegazione, ma un elenco delle nuove possibilità aperte dall'altra soluzione. Se sembrava una giustificazione o roba simile allora vedrò di editare il post, dato che non era quello l'intento ;)
Non mi sembra che ci sia alcun vantaggio...un forum di supporto per Diamonds può benissimo esistere pur mantenendo lo sviluppo qui...
Il ciclo nove termina su NSN quindi questo non serve più. chiuso.
ciao ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.