View Full Version : [CICLO 2] Storia 1
Nuova storia e nuovi task a seguire...
Storia:
Il diamante deve essere ridotto a 32x32, e devono essere ignorati i movimenti verso l'alto (diagonali alto-sx ed alto-dx incluse). Inoltre, l'area di gioco deve essere ristretta ad un rettangolo di 256x448 pixel, nelle collisioni con i bordi sinistro e destro non devono essere riprodotti suoni, ed occorre fare in modo che le collisioni con gli stessi arrestino il movimento orizzontale del diamante (per non farlo uscire dall'area), ma non quello verticale di caduta (continuo, presente anche senza la pressione del tasto giù).
Riservato per la divisione in task.
Task:
3.1 ridurre GEM_SIZE fino a 32px (DanieleC88: completato)
3.2 impedire spostamenti verso l'alto degli sprite tramite tastiera.
(comprese le diagonali) (^TiGeRShArK^: completato)
3.3 limitare gli spostamenti degli sprite ad un'area dello schermo.
usare come esempio 256x448 pixel (71104: completato)
3.4 riprodurre il suono solo quando il diamante collide con il bordo
inferiore. (^TiGeRShArK^: completato)
3.5 Aggiungere un movimento continuo verso il basso di qualche pixel
al diamante che si deve fermare solo in caso di collisione col bordo
inferiore. (cisc: completato)
A breve anche i test.
ciao ;)
Ora sul repository ci sono pure i test per i vari task. Per adesso sono commentati nelle varie classi. Per trovarli vi basta cercare "/** Task".
ciao ;)
^TiGeRShArK^
07-10-2005, 16:57
vorrei prenotarmi x il task 3.2....tempo stimato: 2 giorni
vorrei prenotarmi x il task 3.2....tempo stimato: 2 giorni
aggiundicato.
ciao ;)
^TiGeRShArK^
07-10-2005, 18:10
ehmmmm....
era un pochino troppo facile questo task...
l'ho completato e ho dovuto semplicemente togliere if(input.isKeyDown()) dalla classe sprite....
e togliere i commenti dalla classe TestGemMove....
posso fare qualkos'altro???? :cry:
già alla prima storia aveva fatto praticamente tutto cesare... voglio scrivere un pò di codiceeee!!! :cry:
boh..
intanto tolgo qualche duplicazione da quella classe di test e committo... :nono:
io mi prenoterei per il 3.3 (tempo stimato 1 giorno); l'area a cui va limitato il movimento è arbitraria?
Proponiti per un altro ;)
Proponiti per un altro ;) perché scusa... :confused:
perché scusa... :confused:
Ooops non ho visto il tuo post, la mia frase era per tigershark ^^'''''
Dicevo di proporsi lui stesso per un altro task, visto che ha già completato il suo ;)
io mi prenoterei per il 3.3 (tempo stimato 1 giorno); l'area a cui va limitato il movimento è arbitraria?
Leggi i test. Li c'è tutta l'interfaccia da implementare. Attento che il 3.3 è il piu tosto. Si devono modificare un sacco di cose. Sei sicuro di volere solo 1 giorni di tempo ?
ciao ;)
ehmmmm....
era un pochino troppo facile questo task...
l'ho completato e ho dovuto semplicemente togliere if(input.isKeyDown()) dalla classe sprite....
e togliere i commenti dalla classe TestGemMove....
posso fare qualkos'altro???? :cry:
già alla prima storia aveva fatto praticamente tutto cesare... voglio scrivere un pò di codiceeee!!! :cry:
boh..
intanto tolgo qualche duplicazione da quella classe di test e committo... :nono:
Visto che sei in zona prova a risolvere il 3.4 :D
ciao ;)
Leggi i test. Li c'è tutta l'interfaccia da implementare. Attento che il 3.3 è il piu tosto. Si devono modificare un sacco di cose. Sei sicuro di volere solo 1 giorni di tempo ?
ciao ;) facciamo 2? :stordita: 3??? :stordita:
EDIT: vabbè 2 dai :mbe:
intanto cmq mi rispondete alla mia ultima domanda nel 3d dei problemi? devo capirlo!! :help:
^TiGeRShArK^
07-10-2005, 18:40
Visto che sei in zona prova a risolvere il 3.4 :D
ciao ;)
ok proviamo ;)
facciamo 2? :stordita: 3??? :stordita:
EDIT: vabbè 2 dai :mbe:
intanto cmq mi rispondete alla mia ultima domanda nel 3d dei problemi? devo capirlo!! :help:
Vada per 2 allora.
Premi F5 :D
ciao ;)
eliminare questo post prego :stordita:
vorrei prenotarmi per il 3.5, il test relativo è testGravity(), vero?
l'ho finito, ho modificato il test perchè sembra che JUnit non conosca assertNotEquals, lo so che dovevo aspettare la conferma dell'avvenuta assegnazione del task, ma era semplice e ci potevo lavorare stasera, Vicius, se mi dai l'ok faccio il commit
vabbè, io il commit lo faccio, poi se c'è qualcosa che non va, torniamo indietro magari;)
Hai fatto benissimo :D
Quel assertNotEquals non so come mi sia finito nei sorgenti. Giuro :fiufiu:
ciao ;)
VICIUS, nei test della classe Extents hai usato un costruttore non definito per un oggetto Gem che usa un nuovo parametro Extents; ho definito il costruttore ma non è che tante volte manca un parametro Config? :confused:
ce lo metto?
VICIUS, nei test della classe Extents hai usato un costruttore non definito per un oggetto Gem che usa un nuovo parametro Extents; ho definito il costruttore ma non è che tante volte manca un parametro Config? :confused:
ce lo metto?
Il test che ha scritto Vicius richiede un costruttore con parametro di tipo Config?
Il test che ha scritto Vicius richiede un costruttore con parametro di tipo Config? no, solo Extent, ma io quando inizializzo Gem devo chiamare un costruttore di una super-class; mi sa che un parametro Config ce lo devo mettere per forza perché Sprite lo vuole in tutte le versioni e non lo gestisce (credo) se è null.
no, solo Extent, ma io quando inizializzo Gem devo chiamare un costruttore di una super-class; mi sa che un parametro Config ce lo devo mettere per forza perché Sprite lo vuole in tutte le versioni e non lo gestisce (credo) se è null.
Tu devi solo scrivere quello che richiede il test e nient'altro.
Se il test richiede di passare solo Extents, fai quello.
Se Sprite richiede un Config, devi guardare il codice e probabilmente dovrai fare del refactoring affinche' anche Sprite accetti un Extents.
Il modo piu' sicuro per procedere e' aggiungere un test che richieda un costruttore di Sprite che accetti un Extents e poi proseguire di li' con l'implementazione. A quel punto puoi cambiare uno per volta tutti i test che accettano Config e fargli accettare Extents, controllando ogni volta che tutti i test passino.
Quando hai finito, puoi eliminare il costruttore che accetta Config e tenere solo quello che accetta Extents. Poi passi l'Extents da Gem a Sprite ed il gioco e' fatto.
Il trucco qui e' di fare un passo per volta, avendo sempre i test sul verde quando fai refactoring, cambiando solo pochissimo codice ad ogni passo e continuando a testare.
Se provi a fare tutto il refactoring in un colpo solo, prevedo che sarai costretto a debuggare, e passerai molto tempo con test che falliscono o che non compilano. Alla fine impiegherai piu' tempo che facendo un passo per volta e andando sul sicuro.
RaouL_BennetH
08-10-2005, 00:00
perdonate l'intromissione ma per la prima volta ho lanciato JUnit da eclipse e volevo chiedervi:
è normale che riporta una marea di failure? (compila ma è luce rossa?)
perdonate l'intromissione ma per la prima volta ho lanciato JUnit da eclipse e volevo chiedervi:
è normale che riporta una marea di failure? (compila ma è luce rossa?)
è successo anche a me; no, non è normale, probabilmente devi impostare bene il java.library.path (cavolo, come sto diventando esperto, sono COMMOSSO :cry: :D)
per impostarlo vai sulla finestrona delle configurazioni di Run o Debug e nella configurazione di JUnit vai su arguments; poi tra gli argomenti della VM scrivi: -Djava.library.path=lib/win32
RaouL_BennetH
08-10-2005, 00:05
è successo anche a me; no, non è normale, probabilmente devi impostare bene il java.library.path (cavolo, come sto diventando esperto, sono COMMOSSO :cry: :D)
per impostarlo vai sulla finestrona delle configurazioni di Run o Debug e nella configurazione di JUnit vai su arguments; poi tra gli argomenti della VM scrivi: -Djava.library.path=lib/win32
Bene,mi ci metto domani allora,sono davvero a pezzi stasera @@.
P.S.:mi sa che sul mio linux "win32" fa incacchiare il sistema :D
^TiGeRShArK^
08-10-2005, 00:13
perdonate l'intromissione ma per la prima volta ho lanciato JUnit da eclipse e volevo chiedervi:
è normale che riporta una marea di failure? (compila ma è luce rossa?)
rifai l'update...
ti conviene..
non vorrei ke tu abbia bekkato la versione incasinata del repository..
ora funge tutto..
RaouL_BennetH
08-10-2005, 00:17
rifai l'update...
ti conviene..
non vorrei ke tu abbia bekkato la versione incasinata del repository..
ora funge tutto..
l'update l'ho fatto proprio pochi secondi fa,e se faccio partire l'applicazione mi funziona.Solo se provo a lanciare JUnit mi da na marea di errori.
Bene,mi ci metto domani allora,sono davvero a pezzi stasera @@.
P.S.:mi sa che sul mio linux "win32" fa incacchiare il sistema :D ah e che ne sapevo :D
allora anziché win32 semplicemente metti linux: -Djava.library.path=lib/linux
dovrebbe essere così se nn sbaglio...
ciao :)
^TiGeRShArK^
08-10-2005, 00:25
allora devi settare quel maledetta java.property..
(ma solo a me funge tutto senza settarlo??? :confused: )
no, solo Extent, ma io quando inizializzo Gem devo chiamare un costruttore di una super-class; mi sa che un parametro Config ce lo devo mettere per forza perché Sprite lo vuole in tutte le versioni e non lo gestisce (credo) se è null.
Non avevo pensato a config quando ho scritto il test. Puoi tranquillamente aggiunger un uovo parametro al costruttore. Visto che ci sei modifica anche createGemForTesting e usa quello nel test.
ciao ;)
Non avevo pensato a config quando ho scritto il test. Puoi tranquillamente aggiunger un uovo parametro al costruttore. Visto che ci sei modifica anche createGemForTesting e usa quello nel test.
ciao ;)
Config e Extents comunicano la stessa informazione ma con significato leggermente diverso. E' una duplicazione. O uno o l'altro.
Config e Extents comunicano la stessa informazione ma con significato leggermente diverso. E' una duplicazione. O uno o l'altro.
Se non ho capito male Config potrebbe in un futuro portare anche altre informazioni. Il problema è che ora non ci serve a niente. Come ha fatto a finire nei sorgenti.?
Io per ora sposterei tutto il codice di Config da qualche parte dove non possa fare male.
ciao ;)
:cry:
Ma Extents chi l'ha fatto ?
:cry:
Ma Extents chi l'ha fatto ?
lo sto facendo io... ^^
perciò allora che devo, fare, cerco di togliere Config dai costruttori di Sprite?
inoltre in Sprite ho aggunto un membro privato di tipo Extents che viene ricevuto dal costruttore e che può anche essere null (in tal caso lo sprite non ha extents e non vengono fatti controlli sul movimento); dite che va bene?
altra cosa, VICIUS: il significato dei parametri del costruttore di Extents sarebbe (nell'ordine) left, top, width, height, ho interpretato bene?
lo sto facendo io... ^^
perciò allora che devo, fare, cerco di togliere Config dai costruttori di Sprite?
Procedi pure. Tanto per ora Config non ti serve a niente.
inoltre in Sprite ho aggunto un membro privato di tipo Extents che viene ricevuto dal costruttore e che può anche essere null (in tal caso lo sprite non ha extents e non vengono fatti controlli sul movimento); dite che va bene?
Per l'implementazione hai carta bianca. Pero cerca di attenerti ai test. Evitare di fare il controllo se è null un campo non è richiesto quindi non lo devi implemetnare.
ciao ;)
ragazzi, Config non è inutile in realtà perché Sprite, Texture e altre classi la usano per leggere le dimensioni del display, secondo me *non va* tolta, e anzi sapete una cosa? mi sa che la metto pure nel costruttore di Extents visto che le dimensioni del display mi servono per convertire le coordinate...
^TiGeRShArK^
08-10-2005, 15:54
completato e committato anke il task 3.4...
ovviamente il test TestCollision però non passa perchè 71104 dovrebbe aggiungere nel codice del controllo delle collisioni il controllo in base all'Extent attuale... x il resto la build è verde (a parte qualke minor correction ke 71104 deve fare nel suo codice ke non passa le strette maglie del controllo sintattiko d fek :Prrr: )
[...] a parte qualke minor correction ke 71104 deve fare nel suo codice ke non passa le strette maglie del controllo sintattiko d fek :Prrr: )
Ma come. Ha fatto un commit senza controlalre con ant check !! :nonsifa:
ciao ;)
ragazzi, Config non è inutile in realtà perché Sprite, Texture e altre classi la usano per leggere le dimensioni del display, secondo me *non va* tolta, e anzi sapete una cosa? mi sa che la metto pure nel costruttore di Extents visto che le dimensioni del display mi servono per convertire le coordinate...
Config nel costruttore di Sprite l'abbiamo aggiunto io e DanieleC88 per conoscere le dimensioni dello schermo come parete di collisioni, in parole povere, se riduci lo spazio in cui il diamante può muoversi tramite Extents, Config non server più...
Config nel costruttore di Sprite l'abbiamo aggiunto io e DanieleC88 per conoscere le dimensioni dello schermo come parete di collisioni, in parole povere, se riduci lo spazio in cui il diamante può muoversi tramite Extents, Config non server più... perfetto, allora li tolgo tutti e poi faccio anche ant check (scusate, non sapevo manco che fosse ant :D)
C'è anche un test che fallisce. Si tratta di testCollisionBottom. Chi ha fatto un commit prima di controllare i test? Di chi è la colpa su dai che non vi faccio niente... io :D
ciao ;)
io ho controllato ed era tutto verde... ehm, Danilo...? :D
cmq il mio commit era la revision 232 se non erro.
comunque ragazzi lasciatevi dire che con le coordinate dell'asse Y avete fatto un discreto casino... O_O
dovrò cambiare un bel po' di cose...
intanto ditemi una cosa: qual è di preciso il significato dei membri widthCollision e heightCollision?
io ho controllato ed era tutto verde... ehm, Danilo...? :D
ma chi è Danilo!!!
cmq il mio commit era la revision 232 se non erro.
comunque ragazzi lasciatevi dire che con le coordinate dell'asse Y avete fatto un discreto casino... O_O
dovrò cambiare un bel po' di cose...
spiegati meglio, qual'è il casino di cui parli?
intanto ditemi una cosa: qual è di preciso il significato dei membri widthCollision e heightCollision?
widthCollision e heightCollision sono le dimensioni dello Sprite che non variano con il pulsing e che quindi possono essere controllati nelle collisioni senza che venga introdotto il bug segnalato da cionci, al momento il codice in Sprite non va bene perchè le variabili in questione vengono aggiornate insieme a width e heigth, ma nelle mie modifiche di ieri avevo corretto questo problema, adesso le mie modifiche le ha Vicius:D
ma chi è Danilo!!! TigerShark :D
spiegati meglio, qual'è il casino di cui parli? a parte un errore trovato da Danilo (top e bottom scambiati), qui si fa molta confusione con l'orientamento dell'asse Y...
widthCollision e heightCollision sono le dimensioni dello Sprite che non variano con il pulsing e che quindi possono essere controllati nelle collisioni senza che venga introdotto il bug segnalato da cionci, al momento il codice in Sprite non va bene perchè le variabili in questione vengono aggiornate insieme a width e heigth, ma nelle mie modifiche di ieri avevo corretto questo problema, adesso le mie modifiche le ha Vicius:D capisco; cerco di aggiornare pure io; se necessario farò una mostruosa opera di merge :|
:help:
GROAR MA CHI E' STATO a fare le funzioni per testare le collisioni con le pareti?!?!?!!? :bsod: :bsod: :banned:
sentite, visto che devo anche eliminare Config e le dimensioni del display, io qua tolgo tutte ste collisioni del cavolo, lascio solo le collisioni con l'Extent e riproduco il suono per quello inferiore... se poi ho fatto casino si torna indietro, amen.
^TiGeRShArK^
08-10-2005, 18:53
boh..
mel lo kiedevo pure io...
infatti le ho dovute correggere che top e bottom erano invertite perchè erano state fatte pensando che l'origine delle coordinate fosse in alto a sinistra...
comunque con le modifiche che ho fatto dovrebbero andare...
basta ke le modifichi per aggiungere il controllo da extent anzichè nei margini dello schermo..
penso ti convenga inserire getLimitX e getLimitY da Extent in modo da effettuare il confronto in base a questi valori...
cmq sia vi prego di non committare nulla finché non ho sistemato un po' di cose, sto facendo un poderoso refactoring (tranquillo fek, lo faccio passo passo :D non committo nulla finché non ho tutti i test verdi e il programma funzionante ;))
ragazzi, ho trovato un altro punto su cui si è fatta un po' di confusione: il significato della posizione di uno sprite; l'hot spot per così dire dello sprite va considerato il punto centrale, quello in alto a sinistra o quello in basso a sinistra? per ora io ho messo quello centrale (nella maggior parte del codice veniva interpretato così) ma se devo cambiare non c'è problema, devo modificare solo un paio di cose in Extent e Sprite.
EDIT: vorrei un'altra conferma per questo punto perché i test delle collisioni falliscono: devo correggerli ma prima voglio la conferma. VIIIIICIUUUUUSSSSS???
non c'entra nulla coi problemi che ho adesso, ma propongo di spostare il metodo reactToInput in Gem; per ora è in Sprite e non mi sembra concettualmente corretto (non tutti gli sprites che useremo dovranno rispondere all'input dell'utente, senza contare che altri tipi diversi da Gem derivati da Sprite reagiranno in maniera diversa); ci metto un TODO?
ragazzi, ho trovato un altro punto su cui si è fatta un po' di confusione: il significato della posizione di uno sprite; l'hot spot per così dire dello sprite va considerato il punto centrale, quello in alto a sinistra o quello in basso a sinistra? per ora io ho messo quello centrale (nella maggior parte del codice veniva interpretato così) ma se devo cambiare non c'è problema, devo modificare solo un paio di cose in Extent e Sprite.
EDIT: vorrei un'altra conferma per questo punto perché i test delle collisioni falliscono: devo correggerli ma prima voglio la conferma. VIIIIICIUUUUUSSSSS???
Nel resto del codice viene interpretato cosi per via del fatto che gli sprite sono disegnati con due triangoli. Questi sono, secondo me, quei tipi di dettagli sulla implementazione che è meglio nascondere. Quindi io preferirei in alto a destra, anche perché mi viene più naturale pensare con quel tipo di coordinate.
ciao ;)
non c'entra nulla coi problemi che ho adesso, ma propongo di spostare il metodo reactToInput in Gem; per ora è in Sprite e non mi sembra concettualmente corretto (non tutti gli sprites che useremo dovranno rispondere all'input dell'utente, senza contare che altri tipi diversi da Gem derivati da Sprite reagiranno in maniera diversa); ci metto un TODO?
Era un idea che era venuta pure a me. Per ora mettici un TODO. Una volta finiti i task ci mettiamo e li sistemiamo tutti prima di cominciare la prossima storia.
ciao ;)
Nel resto del codice viene interpretato cosi per via del fatto che gli sprite sono disegnati con due triangoli. Questi sono, secondo me, quei tipi di dettagli sulla implementazione che è meglio nascondere. Quindi io preferirei in alto a destra, anche perché mi viene più naturale pensare con quel tipo di coordinate.
in alto a destra? :mbe: non volevi dire forse sinistra? :mbe:
comunque siccome l'asse delle Y è orientato verso l'alto in questo caso io l'hot spot lo metterei piuttosto in basso a sinistra; comunque per ora lascio al centro e attendo il parere di fek (potrebbe essere necessario modificare anche alcuni test delle collisioni oltre a Extent e Sprite).
in alto a destra? :mbe: non volevi dire forse sinistra? :mbe:
uh? ah! si a sinistra :stordita:
ciao ;)
finalmente ce l'ho fatta: tra problemi nel codice da sistemare e antipatia naturale tra me e SVN stavo uscendo pazzo (intendo dire peggio di come sono :|)
cisc: abbiamo perso il tuo task (il 3.5) :D
l'errore è stato mio, ti prego di perdonarmi: :( ho fatto casino sul mio pc col merge (lo ammetto!!! :cry: ); comunque volendo vedere il lato positivo delle cose:
1) 4 task su 5 sono completi e funzionanti (test completamente verdi)
2) nel programma sono state sistemate numerose incoerenze e un errore madornale (grazie TigerShark :))
3) l'unica una piccola incoerenza rimasta è completamente "sotto controllo" (a seconda del parere di fek possiamo aggiornare rapidamente il codice e renderlo perfetto)
4) il task 3.5 immagino che ce l'avrai ancora sul tuo pc, ma ad ogni modo penso che varrà la pena di rifarlo perché sono cambiati alcuni metodi in Sprite (ed è stato anche aggiunto un bel TODO che cambierà molte cose)
se vuoi il tuo task posso rifarlo io, visto che si è perso per causa mia, anche perché ho finito il mio con un giorno di anticipo quindi ho un altro giorno di tempo :p
detto questo dopo che sarà stato ripristinato il task 3.5 io mi proporrei per spostare reactToInput da Sprite a Gem :)
PS: spero di aver fatto tutto bene con SubVersion: dall'ultimo update di prova che ho fatto (senza errori) ho importato il progetto in Eclipse, i test erano tutti verdi e il programma funzionava; insomma non dovrei proprio aver rotto la build :D
comunque se ci sono problemi avvisatemi che sul mio pc ho ben due copie funzionanti dei sorgenti :D
DanieleC88
09-10-2005, 08:19
GROAR MA CHI E' STATO a fare le funzioni per testare le collisioni con le pareti?!?!?!!? :bsod: :bsod: :banned:
Parli di testCollision.java?
...sono stato io... :cry: :cry: :cry: :cry: :cry:
Cosa avevano di così tragico?
4) il task 3.5 immagino che ce l'avrai ancora sul tuo pc, ma ad ogni modo penso che varrà la pena di rifarlo perché sono cambiati alcuni metodi in Sprite (ed è stato anche aggiunto un bel TODO che cambierà molte cose)
Il task di cisc ce l'ho pure io nei miei sorgenti in locale. Se non vedo nessun commit da parte di qualcuno per quel task lo metto su io questa sera.
ciao ;)
BlueDragon
09-10-2005, 13:04
Il programma gira che è una bellezza ed è sempre più bello, però la build poco fa era rotta!
Facendo girare l'Ant Build fallivano numerosi check di stile e mancava un new Audio() al test di GemWithExtens, che lo faceva fallire perché senza Audio non funge il sound.
Ho aggiunto l'Audio al test e modificato alcune piccole cose in Gem e Sprite affinché lo stile fosse soddisfatto (ho tolto le protected, dando loro un metodo di accesso ed ho messo una variabile di appoggio in un paio di metodi poiché lo stile non voleva che ai parametri dei metodi fossero assegnati nuovi valori).
Build apposto ora, occhio ad usare l'Ant build per il controllo di stile prima di committare.. :)
vermanete non l'ho usata perché ancora non la so usare... :cry:
credevo fosse un "optional" il check con ant, non pensavo che la build si considerasse rotta anche a causa di ant...
per lanciare la build di ant, devi cliccare col mouse destro su build.xml, poi fai run as, ant build e parte, però devi importare Junit in windows->preferences->ant->runtime devi andare in Classpath->Gobal Entries e aggiungere la libreria
BlueDragon
09-10-2005, 15:24
Beh, Ant fa almeno 3 cose:
controlla lo stile, compila, lancia i test.
E' possibile compilare e lanciare i test anche senza Ant, quindi se uno compila e lancia i test e va tutto bene, potrebbe considerare Ant una cosa in più per lo stile...
La cosa strana però è che ti risultavano verdi tutti i test, mentre invece lanciando Ant a me dava errore...giustamente perché l'Audio non era inizializzato.
Come avevi lanciato i test?
Cmq per usare Ant fai clickdestro sul file build.xml che sta subito nella directory principale e poi fai Run As -> "Ant Build".
Potrebbe dirti che manca qualcosa...io ho risolto andando su Run As -> "Ant Build..." (la seconda opzione), poi nel tab Classpath clicca su User Entries nell'albero degli import e poi fai Add JARs sulla destra e scegli di aggiungere dalla directory lib sotto Diamonds il file junit.jar.
Con quello dovrebbe funzionare...(se ti da lo stesso problema che avevo io).
Buona build! :)
Beh, Ant fa almeno 3 cose:
controlla lo stile, compila, lancia i test.
E' possibile compilare e lanciare i test anche senza Ant, quindi se uno compila e lancia i test e va tutto bene, potrebbe considerare Ant una cosa in più per lo stile...
La cosa strana però è che ti risultavano verdi tutti i test, mentre invece lanciando Ant a me dava errore...giustamente perché l'Audio non era inizializzato.
Come avevi lanciato i test? anziché usare la normale configurazione per avviare come "Java Application" avevo fatto una nuova copnfigurazione per JUnit: i test li faceva tutti (e ci metteva pure tanto) ed erano tutti verdi... :|
Cmq per usare Ant fai clickdestro sul file build.xml che sta subito nella directory principale e poi fai Run As -> "Ant Build".
Potrebbe dirti che manca qualcosa...io ho risolto andando su Run As -> "Ant Build..." (la seconda opzione), poi nel tab Classpath clicca su User Entries nell'albero degli import e poi fai Add JARs sulla destra e scegli di aggiungere dalla directory lib sotto Diamonds il file junit.jar.
Con quello dovrebbe funzionare...(se ti da lo stesso problema che avevo io).
Buona build! :)
ti ringrazio proverò :)
Ok. Tutti i task sono completati. Build pulita e i test danno luce verde. La storia si puo dire finita. Complimenti a tutti. :D
ciao ;)
Benissimo.
E' necessario qualche refactoring o passiamo direttamente alla seconda storia?
^TiGeRShArK^
10-10-2005, 08:28
Benissimo.
E' necessario qualche refactoring o passiamo direttamente alla seconda storia?
penso ke il refactoring debba essere fatto sempre e comunque quando incontriamo una parte di codice ke "puzza" durante lo sviluppo del gioco, quindi non deve essere legato ad una particolare storia, ma è trasversale a tutte le storie :p
Certo ke alla fine di una storia e prima di iniziarne un'altra è + semplice fare il refactoring dato ke "in teoria" non ci dovrebbero essere altri commit...a meno ke due persone diverse non si mettono a fare refactoring sulla stessa area di codice... è lì nascerà un conflitto.....
ho detto una kazzata o siete d'accordo??? :stordita:
penso ke il refactoring debba essere fatto sempre e comunque quando incontriamo una parte di codice ke "puzza" durante lo sviluppo del gioco, quindi non deve essere legato ad una particolare storia, ma è trasversale a tutte le storie :p
Certo ke alla fine di una storia e prima di iniziarne un'altra è + semplice fare il refactoring dato ke "in teoria" non ci dovrebbero essere altri commit...a meno ke due persone diverse non si mettono a fare refactoring sulla stessa area di codice... è lì nascerà un conflitto.....
ho detto una kazzata o siete d'accordo??? :stordita:
E' ovvio che debba essere fatto sempre, però è sicuramente più efficiente (oltre che semplice) farlo al termine di una storia, prima di iniziare la successiva.
direi che col refactoring per adesso può bastare: guardate il log di SubVersion... :p :p :p
andiamo alla seconda storia, dai!! :D
cdimauro
10-10-2005, 14:02
Ma bravi: manco il fine settimana e avete già fatto fuori questo ciclo della seconda storia, lasciandomi a bocca asciutta. :)
Complimentoni! :) :) :)
Un bel po di refactoring l'ho gia fatto io. Questa sera vedo di pubblicare task e test per la prossima storia.
ciao ;)
Ma bravi: manco il fine settimana e avete già fatto fuori questo ciclo della seconda storia, lasciandomi a bocca asciutta. :)
Complimentoni! :) :) :)
Avrai modo di rifarti con la prossima storia ;)
arrivo io e tutto va più veloce :D
certo, in effetti devo proprio dire che se non ci fossi stato io che bla bla bla con la mia impeccabile esperienza e la mia sconfinata capacità bla bla bla :O che ho risolto il task assegnatomi molto prima della scadenza del tempo stimato (nonostante i numerosi problemi di cui soffriva il codice, ma qui più che questa faccina :O dovrei fare quest'altra :muro: ) questa storia avrebbe tirato per le lunghe, insomma come dico sempre, e chi mi conosce lo sa (Alberto, atleta-campione), sono proprio un mostro della programmazione MWHAUWHAUWHAUWAHUWAHUWAHUWAHUWAHUWAHUWA
+1 :|
Storia finita.
Potere chiudere il topic?
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.