View Full Version : Progetto Diamonds o Diamond Crush: la rinascita
redcloud
07-03-2007, 15:47
Riprendiamo qui il discorso sulla riorganizzazione del progetto. Personalmente mi interessa riprendere l'attività per capire veramente come è strutturato un progetto simile. Nella scorsa edizione ho avuto difficoltà nel comprendere quale fosse la reale struttura del progetto. Per una persona che arriva a "gioco iniziato" può essere molto difficile allinearsi al gruppo ed è per questo motivo che in questa tornata dovremmo poter organizzare il tutto in modo più chiaro soprattutto per le nuove leve che vorranno darci una mano. Mi interessa anche passare a sourceforge perchè mette a disposizione strumenti molto utili che non mi dispiacerebbe imparare ad usare!
ostrega, non avevo pensato a una cosa però... su SourceForge mi sa che non abbiamo nessuna forma di BuildMachine :(
avevo letto di sfuggita accenni ad una Compile Farm, o qualcosa del genere, che non so se valga anche per Java... devo informarmi decentemente.
poi, per quanto riguarda il Coach: chi è disposto ad esserlo alzi la mano -- io no :|
redcloud
07-03-2007, 15:58
Io purtroppo sono il più novizio e non ho esperienza in coaching, non ci converrebbe se lo fossi io :mc:
https://sourceforge.net/forum/forum.php?forum_id=665363
ah bene, come non detto, LOL :D :D :D
Io purtroppo sono il più novizio e non ho esperienza in coaching, non ci converrebbe se lo fossi io :mc: jappilas allora? è molto portato per le decisioni di design.
per la Build Machine che si fa?
redcloud
07-03-2007, 16:04
Per me va bene.
jappilas
07-03-2007, 16:09
riprendo qui il discorso iniziato nell' altro thread :)
in sostanza avevo avviato un refactoring di alcune parti di DC con l' obiettivo di mettere le basi per funzioni a mio avviso fondamentali per considerare il gioco completo, quali:
- menu: menu iniziale e, menu secondari accessibili dalla schermata principale, nonchè menu in game (resume game/restart game/quit to main menu ) accessibile mettendo il gioco in pausa
questo ha richiesto che al termine del loop dell' oggetto GameLoop si tornasse al loop del menu, e il modo più pulito di farlo secondo me era un pattern state gestito a livello della classe principale Game
inoltre ha richiesto modifiche alla classe delle voci di menu
inoltre richiederebbe modifiche alla gestione dei layer, qualora si voglia rendere più pulito il redraw di sprites e layer nella schermata dei menu
- impostazione dei tasti dal menu opzioni: questo richiederebbe modifiche alla parte grafica del menu per visualizzare il codice dei tasti premuti e associati al tale evento per il giocatore 1 o 2
- gioco con gamepad questo richiederebbe interventi alla sezione di input dell' engine, nonchè al menu che consentirebbe di scegliere il pad come periferica per il primo o secondo giocatore
- gioco con connessione remota: questo richiederebbe oltre al protocollo di netgame funzionante, modifiche alla parte grafica del menu per impostare la modalità di gioco (connessione o in hosting) nonchè l' indirizzo remoto (introduzione dei caratteri nella schermata del menu), nonchè, magari, una schermata introduttiva del tipo "waiting for other player"
- gioco personalizzato: selezione oltre a modalità di input per i giocatori e del fondale e della musica di sottofondo: questo richiederebbe oltre all' apposita voce di menu, la gestione di layer intermedi nell' area di gioco
jappilas allora? è molto portato per le decisioni di design. design ancora ancora, coaching non garantisco ... non sono certo all' altezza di fek :stordita:
e poi non vorrei preso dalla foga, spezzare le ditine al primo che non segue le mie direttive o a cui non vada bene questa lista di obiettivi... :D
pensavo quantomeno a vicius e ufo13 :O
sono d'accordo per jappilas coach, per la build machine è un problema...se ne fa a meno?:stordita:
riprendo qui il discorso iniziato nell' altro thread :)
in sostanza avevo avviato un refactoring di alcune parti di DC con l' obiettivo di mettere le basi per funzioni a mio avviso fondamentali per considerare il gioco completo, quali:
- menu: menu iniziale e, menu secondari accessibili dalla schermata principale, nonchè menu in game (resume game/restart game/quit to main menu ) accessibile mettendo il gioco in pausa
questo ha richiesto che al termine del loop dell' oggetto GameLoop si tornasse al loop del menu, e il modo più pulito di farlo secondo me era un pattern state gestito a livello della classe principale Game
inoltre ha richiesto modifiche alla classe delle voci di menu
inoltre richiederebbe modifiche alla gestione dei layer, qualora si voglia rendere più pulito il redraw di sprites e layer nella schermata dei menu
- impostazione dei tasti dal menu opzioni: questo richiederebbe modifiche alla parte grafica del menu per visualizzare il codice dei tasti premuti e associati al tale evento per il giocatore 1 o 2
- gioco con gamepad questo richiederebbe interventi alla sezione di input dell' engine, nonchè al menu che consentirebbe di scegliere il pad come periferica per il primo o secondo giocatore
- gioco con connessione remota: questo richiederebbe oltre al protocollo di netgame funzionante, modifiche alla parte grafica del menu per impostare la modalità di gioco (connessione o in hosting) nonchè l' indirizzo remoto (introduzione dei caratteri nella schermata del menu), nonchè, magari, una schermata introduttiva del tipo "waiting for other player"
- gioco personalizzato: selezione oltre a modalità di input per i giocatori e del fondale e della musica di sottofondo: questo richiederebbe oltre all' apposita voce di menu, la gestione di layer intermedi nell' area di gioco
design ancora ancora, coaching non garantisco ... non sono certo all' altezza di fek... :stordita:
e poi non vorrei preso dalla foga, spezzare le ditine al primo che non segue le mie direttive o a cui non vada bene questa lista di obiettivi... :D
credo che queste features siano fondamentali, io darei un'occhiata anche a questo http://www.hwupgrade.it/forum/showthread.php?t=1216896
Più che altro, direi che bisogna mettere le feature in ordine di priorità: rimettere in piedi un progetto defunto è tutt'altro che semplice, ed il rischio di una ri-caduta nell'oblio è molto forte.
Quindi, prima occorre pensare alle cose più importanti e poi a tutto il resto.
Dipendesse da me, andrei con una TODO list di questo tipo:
1. riportare il codice ad uno stato riutilizzabile
2. tagliare via la modalità Advanced, non c'è il tempo per completarla
3. inserire il netplay, per dare uno scopo vero e proprio di esistere al gioco (per il multi locale c'è già la demo)
4. inserire tutti i menu, in ordine di utilità
Una volta completati questi quattro passi, si potrà pensare ad un'altra release, che potrebbe essere quella definitiva (a meno che non si voglia poi pensare ad aggiungere tutta la roba che è stata tolta, ma questo è decisamente YAGNI).
sono d'accordo per jappilas coach, per la build machine è un problema...se ne fa a meno?:stordita: ASSOLUTAMENTE NO.
ne sto discutendo giusto ora con jappilas su MSN: il clima di terrore del checkstyle e della build rossa è assolutamente indispensabile :D :D :D
hola Jocchan quanto tempo! :)
hola Jocchan quanto tempo! :)
Ciao Bertuzzo, non ti vedo su msn da una vita :D
Più che altro, direi che bisogna mettere le feature in ordine di priorità: rimettere in piedi un progetto defunto è tutt'altro che semplice, ed il rischio di una ri-caduta nell'oblio è molto forte.
Quindi, prima occorre pensare alle cose più importanti e poi a tutto il resto.
Dipendesse da me, andrei con una TODO list di questo tipo:
1. riportare il codice ad uno stato riutilizzabile
2. tagliare via la modalità Advanced, non c'è il tempo per completarla
3. inserire il netplay, per dare uno scopo vero e proprio di esistere al gioco (per il multi locale c'è già la demo)
4. inserire tutti i menu, in ordine di utilità
Una volta completati questi quattro passi, si potrà pensare ad un'altra release, che potrebbe essere quella definitiva (a meno che non si voglia poi pensare ad aggiungere tutta la roba che è stata tolta, ma questo è decisamente YAGNI).
sono d'accordo, per lo sviluppo farei una TODO list a livello di task, completa di tutte le features che si vogliono implementare, sempre con delle priorità, in modo da fare qualcosa di meno lineare, ma più flessibile
ASSOLUTAMENTE NO.
ne sto discutendo giusto ora con jappilas su MSN: il clima di terrore del checkstyle e della build rossa è assolutamente indispensabile :D :D :D
secondo me se ci sta una certa onesta mentale tra chi collabora se ne può fare a meno, basta che si stabiliscano delle regole e si rispettino
secondo me se ci sta una certa onesta mentale tra chi collabora se ne può fare a meno, basta che si stabiliscano delle regole e si rispettino no no: ribadisco il clima di terrore :P
mettila così: quando entra un nuovo membro nel team si fa molto prima a dire "guai a te se rompi la build" piuttosto che elencargli tutte le regole di buona creanza diamondcrusciana :D
la build machine è semplicemente un'automatizzazione di quella che hai chiamato onestà mentale ;)
jappilas
07-03-2007, 17:13
sono d'accordo, per lo sviluppo farei una TODO list a livello di task, completa di tutte le features che si vogliono implementare, sempre con delle priorità, in modo da fare qualcosa di meno lineare, ma più flessibileper me va bene ;)
secondo me se ci sta una certa onesta mentale tra chi collabora se ne può fare a meno, basta che si stabiliscano delle regole e si rispettinoanche quello è vero ;)
però c'è devo dire che a me per primo, ai tempi, i continui messaggi di checkstyle sono serviti per interiorizzare le linee guida da adottare nella scrittura di codice per DC...
che essendo molto diverse da quelle che dovevo ( e devo :( ) usare in altri ambiti, università o lavoro, all' inizio mi hanno richiesto sforzo notevole - nonostante mi imponessi di fare come fek mi aveva inculcato :D
ora, non è per costringere chiunque a passare attraverso le mie stesse difficoltà, (anche se penso che sarebbero maggiori per chi si sia formato da un certo tempo in un certo modo e debba riabituarsi, minori per chi su Java e DC inizi...certo, pur dovendo interiorizzare la logica degli oggetti e i pattern ) ma è per non sacrificare quella pulizia almeno esterna che il codice di DC finora vanta - come dicevo tempo fa, mi sono arrivate (ma è come se fossero arrivate a tutto il team ) mail con oltre a richieste di dettagli e chiarimenti, complimenti per la chiarezza del codice
questo mi ha fatto sentire davvero orgoglioso del progetto ed è una cosa da cui secondo me non si può prescindere ;)
guardate, non ho nulla contro la build machine, anzi, penso sia uno strumento utilissimo, sto solo dicendo che dobbiamo valutare se possiamo farne a meno e passare a sourceforge, per me se ne potrebbe fare a meno...
jappilas
07-03-2007, 17:32
è che al di là del checkstyle (che potrebbe bastare quello avviato in locale da ant, a patto che non si perda l' abitudine di provare la build prima di ogni commit - e la si inculchi a eventuali nuovi membri :D ) la build machine produceva anche gli eseguibili nativi ... ora, io non ricordo come si facesse per questi ultimi ( GCJ sulla macchina di fek ?) e attualmente non avrei idea di come fare passando a sourceforge :stordita:
Ciao a tutti.
Daniele mi ha contattato ed eccomi qui a rapporto. Ovviamente non ho fatto in tempo a leggere tutto. :D
Vado per punti in modo molto "schematico":
- sono sotto laurea, devo praticamente scrivere giorno e notte se voglio fare in tempo. Tempo disponibile 0 e non per programmare, ma poroprio per leggere il forum.
- DC è stupendo e bellissimo, sono soddisfattissimo di tutto quello fatto, ma ora è morto. In che senso: quel codice li ( cioè sia di gioco ma soprattutto dei test), ora è un vecchio malato e per curarlo bisogna fare uno sfrozo tale che si fa prima a scrivere tutto da zero consocendo già quali possono essere i tranelli del percorso Se Jocchan è in forma può sempre buttar giù un progetto nuovo ... :P
- Il TDD è pericolossisimo e una delle metodologie più difficili oltre che tremendamente efficaci. Qualunque cosa si faccia o si decida bisognerà esser cattivissimi nel rispettare le sue regole.
In conclusione non sono molto propenso a rimettere le mani a DC. è bello così.... perchè è arrivato al FP in modo fantastico e funziona benissimo e pure perchè è morto per nostri errori. Averlo li mi ricorderà sempre tutto questo: la fatica e la soddisfazione, la bellezza e gli errori da non fare ;)
In ogni caso devo aspettare il post laurea per dare una qualunque disponibilità... arrivato a quel punto mi siedo in poltrona e decido cosa fare della mia vita :sofico: :sofico:
è che al di là del checkstyle (che potrebbe bastare quello avviato in locale da ant, a patto che non si perda l' abitudine di provare la build prima di ogni commit - e la si inculchi a eventuali nuovi membri :D ) la build machine produceva anche gli eseguibili nativi ... ora, io non ricordo come si facesse per questi ultimi ( GCJ sulla macchina di fek ?) e attualmente non avrei idea di come fare passando a sourceforge :stordita: uhm, e se FreshMeat o qualche altro sito offrisse servizi del genere? comunque la Compile Farm di SF sembrava proprio essere una specie di Build Machine da quanto ho capito... però l'hanno cassata.
jappilas
07-03-2007, 18:03
Ciao a tutti.
Daniele mi ha contattato ed eccomi qui a rapporto. Ovviamente non ho fatto in tempo a leggere tutto. :D:nonsifa:
- sono sotto laurea, devo praticamente scrivere giorno e notte se voglio fare in tempo. Tempo disponibile 0 e non per programmare, ma poroprio per leggere il forum.in realtà nemmeno io ... e purtroppo non sono ancora alla tesi :(,
come dicevo prima stavo applicando idee che mi giravano in testa alla mia copia di DC, e lo posso fare un' ora o due al giorno - ma condividevo lo stato dei lavori nell' eventualità potesse interessare agli altri :p
- DC è stupendo e bellissimo, sono soddisfattissimo di tutto quello fatto, ma ora è morto. di solito un progetto si considera morto se non ci lavora o non lo usa più nessuno al mondo - ma io ci giocavo spessissimo :D
In che senso: quel codice li ( cioè sia di gioco ma soprattutto dei test), ora è un vecchio malato e per curarlo bisogna fare uno sfrozo tale che si fa prima a scrivere tutto da zero consocendo già quali possono essere i tranelli del percorso [fek mode]il codice è per definizione soggetto a essere integralmente riscritto quando non sia adeguato - il punto è trovare la voglia e il tempo per dedicarsi alla riprogettazione e riscrittura
e questo altro non è che un ulteriore problema da risolvere a mezzo progettazione e analisi nell' ambito del progetto (posto che lo si voglia portare avanti ) :)[/fek mode]
Se Jocchan è in forma può sempre buttar giù un progetto nuovo ... mi sembra di capire che anche lui è parecchio impegnato - a maggior ragione lo ringrazio della sua disponibilità di questi giorni su messenger :)
- Il TDD è pericolossisimo e una delle metodologie più difficili oltre che tremendamente efficaci. Qualunque cosa si faccia o si decida bisognerà esser cattivissimi nel rispettare le sue regole.che sia difficile ed efficace al tempo stesso se usato nel modo giusto, sono d' accordo :D
però allo stato attuale penso che noialtri (tutti programmatori che con il TDD abbiamo avuto a che fare almeno una volta) si possa a ragion veduta, "lascarlo" leggermente, a patto di non perdere mai di vista il design per requisiti :O
per inciso, il motivo per cui volevo introdurre un' interfaccia LoopInterface implementata da due oggetti GameLoop/MenuLoop era proprio , come dicevo a Federico/Ufo, porre le basi per una più semplice scrittura di test atomici sul loop primario del gioco, in quanto è da testare un' interfaccia molto più "streamlined" di prima :O
In conclusione non sono molto propenso a rimettere le mani a DC. è bello così.... perchè è arrivato al FP in modo fantastico e funziona benissimo e pure perchè è morto per nostri errori. Averlo li mi ricorderà sempre tutto questo: la fatica e la soddisfazione, la bellezza e gli errori da non fare ;)capisco il punto di vista, e vale anche per me... ma mi sono detto, la funzione di monito, anzi memento degli errori commessi in passato la svolge anche se gli metto uno splash screen (giusto non l' avevo scritto, ora è mostrato uno splash screen per due secondi - tanto ci vuole per tirare su gli oggetti gameloop e menuloop e caricare le textures) e un menu in game, e farlo non mi costa poi molto... :O
In ogni caso devo aspettare il post laurea per dare una qualunque disponibilità... arrivato a quel punto mi siedo in poltrona e decido cosa fare della mia vita :sofico: :sofico:tanti auguri per la laurea ;) :cool:
redcloud
07-03-2007, 20:39
Io prenderei in considerazione anche il fatto di fare un bel diagramma pseudo-UML, giusto per far capire a grandi linee la struttura del progetto.
il codice è per definizione soggetto a essere integralmente riscritto quando non sia adeguato
è quello che ho detto io :read: :read:
però allo stato attuale penso che noialtri (tutti programmatori che con il TDD abbiamo avuto a che fare almeno una volta) si possa a ragion veduta, "lascarlo" leggermente, a patto di non perdere mai di vista il design per requisiti :O
Non voglio esser offensivo con nessuno... ma il problema della non riuscita del progetto è proprio perchè non abbiamo sempre seguito "le regole" del TDD fino in fondo. :Prrr:
bè? ce l'abbiamo un coach si o no? VICIUS e Ufo13 che fine hanno fatto?
jappilas
08-03-2007, 17:51
è quello che ho detto io :read: :read: era per dire che - per qto mi riguarda almeno - quella della riscrittura (finanche completa o quasi) del codice, è un' eventualità messa in conto da sempre, e che sempre per quanto mi riguarda non mi affeziono mai a del codice in quanto tale (a meno che proprio non si tratti di qualcosa scritto con il massimo sforzo di pianificazione preventiva e pulizia implementativa di cui fossi capace, o di un' implementazione perfetta e referenziale di qualche design pattern)
Ma visto che il codice di DC è perfettibile per definizione, e visto che stava prendendo muffa sul mio HD, il mio hobby di questo periodo (finchè ho la possibilità di metterci un' oretta al giorno ) è buttare giù il codice che ho in testa :D
Non voglio esser offensivo con nessuno... e chi si offende? :)
anzi, se sei impegnato con la laurea (cosa che in effetti un giorno spero venga anche per me :stordita: ) ti ribadisco i miei migliori auguri con la speranza di rileggerti presto ;)
redcloud
08-03-2007, 21:22
Allora, iniziamo a mettere su il necessario? :sofico:
si, un coach tanto per cominciare... e subito a seguire un modo (se esiste) per realizzare una build machine nonostante la codebase risieda su SourceForge. dopodiché possiamo aprire il progetto.
idea :eek:
potremmo proporre a PGI-Bis il ruolo di coach... solo che bisogna prima convincerlo ad andare d'accordo col nostro modo di programmare :fagiano:
come lavora lui per noi non va assolutamente bene: tutti quei commenti nel codice rallentano i tempi di sviluppo in maniera mostruosa, non risolviamo nulla.
Pgi-Bis sente e vede tutto! Ringrazio sentitamente, lo prendo come un attestato di stima anche se suona come un "ragazzi, grattiamo il fondo del barile" :D, cortesemente rifiuto.
problema risolto, siamo senza coach e quindi DC non rinascerà mai :D :D
baci & abbracci, è stato un piacere, ci vediamo forse un giorno dal vivo, ciao a tutti :p
@PGI-Bis: per quanto mi riguarda era più verso l'attestato di stima: penso che l'80% dei tuoi post sul forum riguardino Java :D ma in effetti non ci speravo molto: sembri molto ferrato nella tua idea di programmazione (che non condivido). grazie lo stesso quantomeno per l'interessamento; ciao.
PS: ehiehiehi (da leggere con la voce di Krusty), sentite questa che m'è appena venuta in mente: siamo senza coach, cioè ci siamo SCOACHATI. MHWUAMWHAUWAMHWAUWMAHWUAMWHAUWA :rotfl: :rotfl: :rotfl:
PS: ehiehiehi (da leggere con la voce di Krusty), sentite questa che m'è appena venuta in mente: siamo senza coach, cioè ci siamo SCOACHATI. MHWUAMWHAUWAMHWAUWMAHWUAMWHAUWA :rotfl: :rotfl: :rotfl:
:rotfl: :rotfl: :rotfl:
:rotfl: :rotfl: :rotfl:
:rotfl: :rotfl: :rotfl:
:rotfl: :rotfl: :rotfl:
jappilas
09-03-2007, 18:11
problema risolto, siamo senza coach e quindi DC non rinascerà mai :D :Dio avevo proposto ufoFede e VicMirco, se sono disposti meglio, altrimenti posso provare io... ma in tal caso dovrete sopportare me e l' amico appollaiato sulle mie spalle da un po' di tempo :Obaci & abbracci, è stato un piacere, ci vediamo forse un giorno dal vivo, ciao a tutti :pse (metti caso) per un qualche motivo o lavoro vengo spedito verso il centro italia stai pur certo che l' occasione di romperti le scatole dal vivo non la perdo :D
@PGI-Bis: per quanto mi riguarda era più verso l'attestato di stima: penso che l'80% dei tuoi post sul forum riguardino Java :D ma in effetti non ci speravo molto: sembri molto ferrato nella tua idea di programmazione (che non condivido). grazie lo stesso quantomeno per l'interessamento; ciao.per me questo non vuol dire che non sia ben prezioso l' ingresso e il contributo anche di qualcuno abituato a un metodo di lavoro diverso, basta che poi si pieghi a quello che il coach impone... :D
o che ci sia un terzo che medi le divergenze struttural-concettuali... :O
PS: ehiehiehi (da leggere con la voce di Krusty), sentite questa che m'è appena venuta in mente: siamo senza coach, cioè ci siamo SCOACHATI. MHWUAMWHAUWAMHWAUWMAHWUAMWHAUWA :rotfl: :rotfl: :rotfl:OMG :rotfl:
Berto, questa è fantastica ... sai che passerà alla storia e verrà con tutta probabilità ripresa nei secoli dei secoli, sì? :D
redcloud
09-03-2007, 23:42
Japp per me va bene averti come coach :)
jappilas
10-03-2007, 00:51
Japp per me va bene averti come coach :):)
bene, allora tanto per cominciare trascrivo il piano di azione del revamping project che stavo seguendo, sotto forma di un archivio con i file che ho finora modificato / aggiunto in un archivio allegato, e le interfacce e gli enum direttamente qui
package it.diamonds;
public enum GameState
{
GAME, MENU, EXITING;
}package it.diamonds;
public interface LoopInterface
{
void enter(); //operazioni preliminari prima del ciclo principale, ad es disegno dello sfondo
void loop(); //ciclo principale, tutto quello che prima erano loop() e menuLoop()
LoopInterface updateState(); //avvicendamento tra i due oggetti
boolean isRunning(); //ritorna true finchè l' oggetto cicla in loop()
GameState getCurrentState(); //ritorna un id dello stato attuale ai fini del testing, nella forma di un valore enumerato
boolean mustLoop(); //condizione di arresto per il ciclo esterno introdotto in Game.run()
}LoopInterface è il cuore del nuovo main loop, nonchè quello che permette di avere un menu in game (in modo pulito cioè, ovvero con due oggetti ditinti che si alternano - design pattern State)
i due oggetti implementanti, cioè GameLoop e MenuLoop, sono singolarmente più piccoli della precedente versione di gameloop (anche perchè le inizializzazioni di oggetti esterni quali le voci di menu o il preload delle textures sono state decentrate in un ulteriore oggetto gamelauncher
package it.diamonds;
import it.diamonds.menu.AbstractMenu;
public interface MenuInterface
{
void startGame(); //inizio del gioco in versus mode
void exit(); //uscita da diamonds
void resumeGame(); //ripresa della partita attuale
void restartGame(); //rientro in gioco - reset della partita
void quitGame(); //cancellazione della partita attuale
void selectMenu(AbstractMenu newMenu); //selezione esterna del menu
AbstractMenu getCurrentMenu(); //verifica del menu corrente, per il testing
}questa interfaccia costituisce in pratica il controllo del ciclo del menu, per i test e per le menuactions
in effetti potrebbe essere superflua, l' idea era di forzarmi a usare solo metodi di un' interfaccia per controllare l 'oggetto menu da fuori...
File nell' archivio:
Game: nuova versione, implementa un ciclo esterno con il passaggio dal menu al gioco e viceversa
istanzia un GameLauncher e ottiene da questo l' oggetto LoopInterface iniziale per poi eseguirne i metodi enter() loop() , e updateState()
GameLoop: nuova versione, ottenuta dalla precedente per rimozione delle parti relative al menu
MenuLoop: nuova classe, implementa le parti del menu precedentemente in gameloop dedicate al menu
GameLauncher: implementa il preload delle texture e l' inizializzazione delle parti dell' environment precedentemente in gameloop, restituisce menuloop come oggetto LoopInterface iniziale
AbstractMenu: nuova classe, versione modificata del MainMenu - Abstract perchè predisposta a ospitare (staticamente, secondo lo schema usato per le MenuItem) oggetti istanze di sè stesso (l menu principale e quello in game ) ma anche oggetti istanze di classi derivate (VariantMenu) che ne ridefiniscono i metodi di selezione orizzontale
VariantMenu: classe derivata in cui a ogni voce di menu corrisponda più di uno sprite (pensavo al menu delle opzioni ad es)
MenuItem versione modificata, con delle menuitem in più per l' in game menu
soo inoltre presenti le menuaction specifiche per il menu in game...
note:
consiglio di fare un backup del proprio repository prima di provare ad aggiungere i file nell 'archivio, o di visionarli separatamente - aspetto in ogni caso commenti
(anzi in realtà aspetto test list :D)
introducendo quel codice i test sono pesantemente br()ken, motivo per cui sono al refactoring dei testcase... che dovrebbe essere completato per domani
sono a conoscenza della deroga fatta alle regole... ma queste verranno immediatamente ripristinate non appena l' auditing e il relativo testing delle classi citate non sarà completato
redcloud
10-03-2007, 23:53
Mi sembrano buone idee, questo tipo di suddivisione in interfacce credo sia importante. Sarebbe utile fare una descrizione di quali sono le parti principali di tutto il codice e di come interagiscono, almeno dei cenni. Come ci muoviamo per il repository?
jappilas
11-03-2007, 15:17
Mi sembrano buone idee, questo tipo di suddivisione in interfacce credo sia importante. :)
comunque in realtà le decisioni del coach non si discutono :O ( scherzo :D)
Sarebbe utile fare una descrizione di quali sono le parti principali di tutto il codice e di come interagiscono, almeno dei cenni. che sarà quello a cui mi dedicherò appena avrò finito con l' auditing del nuovo codice e la scrittura del nuovoTestGameLoop - a buon punto :)
notare però che appena finito questo, esco dalla modalità spike per entrare in quella normale - il che comporterà il ripristino delle metodiche regolari
anche a me va bene che jappilas faccia da coach, ma parlando di cose concrete: la build machine? che si fa? risolto quel problema potrà essere aperto un progetto su SourceForge (posso occuparmene anche io se volete, che conosco bene SF) al quale, vi ricordo, potrebbero potenzialmente partecipare non solo i membri del vecchio team (noi) ma anche altri programmatori di tutto il mondo (dopo averli inclusi nel progetto, ovvio).
proverò ad informarmi su cos'è di preciso e come si usa CruiseControl.
RaouL_BennetH
11-03-2007, 17:11
Se davvero reiniziate a lavorare su Diamond, spero che accetterete la mia collaborazione, seppur minima dato che non so programmare ma ne approfitterei per imparare da voi che siete il top. Se siete contrari, vi ricordo che la maggior parte delle idee per il gioco all'inizio furono mie idee :O ergo, non potete tenermi fuori :D
Spero invece di cuore di riuscire ad imparare davvero qualcosa di positivo da voi tutti.
RaouL.
redcloud
11-03-2007, 17:41
Ma scherzi? Datti da fare e muoviti pure! :sofico:
notizie; buone o cattive? mah, chi lo sa visto che non possiamo sapere l'esito di questo tentativo di riesumazione del progetto. certo è che se "falliamo" un'altra volta le notizie son cattive perché la cosa sarà frustrante :Prrr:
però son notizie.
ho mandato la richiesta di registrazione del progetto su SourceForge. monitorate questo URL (http://sf.net/projects/diamondcrush), perché in (penso) un paio di giorni al massimo diverrà attivo. nel frattempo chi vuole partecipare (senza impegno di continuità: non possiamo pretenderlo per un progetto che ha un piede, ma anche tutti e due, nella fossa) può registrare il suo account su SourceForge, e ce lo faccia sapere qui sul forum chè quando il progetto sarà pronto lo aggiungeremo come membro nel team.
per quanto riguarda CruiseControl: mi sono documentato sommariamente e sembra esserci tranquillamente la possibilità di creare builds e build artifacts da un repository che si trova su macchine su cui non abbiamo il controllo (cioè quelle di SourceForge). il repository ovviamente è basato su SubVersion (attualmente SourceForge li mette a disposizione entrambi: CVS e SVN), quindi chi vuole cominci ad installare un client SVN (si consiglia Subclipse, il plugin SVN per Eclipse).
per ora mi sembra tutto. ah, ho bloccato Ufo13 su MSN e mi appresto a metterlo in ignore list qui su HWU; non che questo abbia riscontri sul progetto, ma giusto per completezza.
redcloud
11-03-2007, 19:40
71104 ma che combini mai!!! Sei polemico!!! Il mio nick su sourceforge è redcloud80
71104 ma che combini mai!!! Sei polemico!!! evitiamo di insozzare il topic con gli OT :)
Il mio nick su sourceforge è redcloud80 ci hanno già accettato il progetto!! :)
http://sf.net/projects/diamondcrush
finora come membri ho aggiunto me, te, jappilas e DanieleC88. i vostri account ragazzi, i vostri account: chi ha intenzione di dare una mano (anche una tantum) si registri e ci faccia sapere!
RaouL_BennetH
12-03-2007, 10:54
finora come membri ho aggiunto me, te e jappilas. i vostri account ragazzi, i vostri account: chi ha intenzione di dare una mano (anche una tantum) si registri e ci faccia sapere!
Come ci si registra? (sorry for niubba question inside :( ) ((intendo al progetto non a sf .... ))
Come ci si registra? (sorry for niubba question inside :( ) ((intendo al progetto non a sf .... )) devi avere un account su SourceForge, a quel punto mi fai sapere il nome del tuo account e io lo aggiungo ai membri del progetto.
ragazzi, tra un po' esco ma stasera ho bisogno dell'aiuto di qualcuno che abbia la possibilità di usare un client FTP (io ho qualche problema di porte chiuse: riesco ad usare FTP per tutto tranne che per trasferire il contenuto dei files -.- ).
mi serve che qualcuno si connetta al server FTP di SourceForge e ci metta i tre files che abbiamo rilasciato per la First Playable: DC per Windows, per Linux a 32 bit, e per Linux a 64. non subito comunque, lo faremo stasera (oppure fatelo con l'aiuto di DanieleC88 se lo trovate su MSN).
qui nel frattempo avete l'elenco dei membri:
http://sourceforge.net/project/memberlist.php?group_id=191341
(spero il link funzioni anche fuori dall'account con cui ero loggato)
RaouL_BennetH
12-03-2007, 11:32
devi avere un account su SourceForge, a quel punto mi fai sapere il nome del tuo account e io lo aggiungo ai membri del progetto.
è raoul_benneth :)
ti ho aggiunto come Developer allora :)
ai developers ho dato accesso a Subversion e accesso al task manager come "technicians" (che mi pare significhi che possono svolgere i task ma non editarli, aggiungerne, ecc.)
Jocchan, registrati: non ho ancora dato a nessuno l'accesso al web space, agli screenshots, e alle project news come editor :D
ah, finora sto amministrando il progetto lavorando dall'account "diamondcrusher", quello con cui jappilas ha avviato la registrazione del progetto. l'account a71104 invece l'ho impostato come normale Developer, al pari di voi comuni mortali :p :Prrr:
RaouL_BennetH
12-03-2007, 11:41
vi ringrazio profondamente per l'occasione datami :ave:
Purtroppo io ne approfitterò per imparare qualcosa da voi più che essere un reale contributo nel programmare. Cercherò di compensare queste mie mancanze con le idee semprechè le riteniate opprtune :)
Grazie davvero :cry:
RaouL.
ho messo anche lo screenshot :D
http://sourceforge.net/project/screenshots.php?group_id=191341
praticamente ora restano sostanzialmente da fare 5 cose:
1) uppare via FTP i files della First Playable
2) trasferire sullo spazio web di SourceForge (che è virtualmente illimitato) il sito web attualmente presente all'URL www.diamondcrush.net, e mettere magari a quell'URL una pagina con uno script che redireziona subito
3) mettere il codice nel repository (questo lo deve fare jappilas)
4) uppare CruiseControl (mi devo documentare assieme ad Antares88)
5) programmare :)
vi ringrazio profondamente per l'occasione datami :ave:
Purtroppo io ne approfitterò per imparare qualcosa da voi più che essere un reale contributo nel programmare. Cercherò di compensare queste mie mancanze con le idee semprechè le riteniate opprtune :)
Grazie davvero :cry:
RaouL. ma non dire così suvvia, c'è tanta gente che è entrata in DC partendo da zero ^^
programmare in Diamond Crush è semplicissimo e velocissimo quando il resto del team lo fa bene. quindi stavolta vediamo di evitare il codice con complessità ciclomatiche troppo elevate (e per "troppo" intendo anche > 3), i design troppo complessi con mille alternative più semplici, ecc. ecc.
e soprattutto, se decideremo di continuare col TDD, facciamo test decenti, possibilmente uno per ogni istruzione significativa di codice, e possibilmente piccoli, semplici e mockati.
redcloud
12-03-2007, 12:09
ragazzi, tra un po' esco ma stasera ho bisogno dell'aiuto di qualcuno che abbia la possibilità di usare un client FTP (io ho qualche problema di porte chiuse: riesco ad usare FTP per tutto tranne che per trasferire il contenuto dei files -.- ).
mi serve che qualcuno si connetta al server FTP di SourceForge e ci metta i tre files che abbiamo rilasciato per la First Playable: DC per Windows, per Linux a 32 bit, e per Linux a 64. non subito comunque, lo faremo stasera (oppure fatelo con l'aiuto di DanieleC88 se lo trovate su MSN).
Bene bene, io ti posso dare una mano con l'ftp. Ho notato che il progetto è rilasciato con licenza BSD, come mai non GPL? Poi si dovrebbe fare una pagina da inserire nello spazio messo a disposizione da sf e che faccia il redirect al sito ufficiale diamondcrush.
jappilas
12-03-2007, 12:16
3) mettere il codice nel repository (questo lo deve fare jappilas)in realtà dovrebbe poterlo fare chiunque abbia accesso a SVN, te compreso :D
scherzi a parte, per quanto mi riguarda avrei preferito ripristinare il source tree per come lo avevamo sul server di NSN , per cui completo anche di branch e tags - mentre io dispongo del solo /trunk
inoltre la mia copia di lavoro è tutto meno che finalizzata, non mi azzarderei a committare quella ;)
Ho notato che il progetto è rilasciato con licenza BSD, come mai non GPL?perchè il progetto è nato con obiettivi più didattici che altro...
all' inizio (l' anno scorso) si era parlato addirittura di una licenza "public domain like" ..
ma quella tipo MIT - BSD dovrebbe permettere l' attibuzione della paternità del codice e di essere menzionati come autori originali di questo, se anche venisse riutilizzato per altri scopi
Antares88
12-03-2007, 18:21
Salve a tutti ! è un po che non ci si sente eh ? :D
In verità no. :P
Con vari di voi mi sento su msn, quindi come nn detto :D
@71104: mi sono iscritto a SF con nick Antares88
@tutti: se ci documentiamo su come si fa e mi date una mano, posso tenerla io una build machine. Ho il pc sempre acceso a mò di server.
@tutti^2: come facciamo per quanto riguarda il lato grafico ? manca un bel po di roba T_T
ottimo lavoro Alberto! il mio nick su sourceforge è danielesv
@Antares: effettivamente i grafici hanno sempre scarseggiato, io sono una schiappa con la grafica, se no potevo aiutare...
ottimo lavoro Alberto! il mio nick su sourceforge è danielesv aggiunti sia te che anta. anta l'ho segnato come Graphics designer e oltre allo stesso tipo di accesso dei developers gli ho dato anche accesso allo spazio web, in caso dovesse lavorare sulla grafica del sito. manca Jocchan ^^
Allora, valutiamo bene la situazione.
1. Il progetto è morto, non giriamoci intorno, e se lo vogliamo resuscitare occorrerà il massimo impegno da parte di tutti. Quindi, mi aspetto che tutte le persone presenti qui lo dimostrino con i fatti (discutere non è mai servito a niente, e le discussioni senza fine hanno solo fatto male a Diamonds).
2. Senza delle linee guida non si va da nessuna parte. Occorre sceglierle, ed a sceglierle deve essere una sola persona (chi è d'accordo è d'accordo, chi non lo è lo sarà col tempo... non dimenticatelo mai!). Una volta tracciate le linee guida bisognerà portarle avanti con convinzione.
Ragazzi, non so se ve ne siete accorti, ma siamo vicini ai QUINDICIMILA download della First Playable, cosa che - per un progetto come Diamonds - è un risultato ben più che eccellente! E se questo non basta per dare una bella iniezione di autostima a noi tutti non so cosa potrebbe farlo :D
Abbiamo fatto un ottimo lavoro, ora va completato... sarebbe un delitto non farlo (anche per ripagare le 15.000 persone che ci hanno dato la loro fiducia).
3. Dobbiamo essere professionali. Questo non significa avere deadline strette da situazione lavorativa (non che le nostre alla fin fine lo fossero, eh! In contesti lavorativi la situazione è DECISAMENTE più stringente, non dimentichiamolo :Prrr: Abbiamo tutti una vita e degli impegni :p ). Mi riferisco soprattutto a "faide interne", dissapori e inimicizie varie (mi riferisco al post di Berto poco più sopra, che sinceramente non mi ha fatto piacere leggere).
Dimentichiamocele e passiamoci TUTTI sopra, non fanno altro che danneggiare direttamente o indirettamente il progetto. Se ci teniamo, la nostra priorità deve essere Diamonds, e tutto il resto deve venire dopo.
4. Per ripartire, occorrerà fare un bel revert, ne sono sempre più convinto.
La codebase è ridotta malissimo e l'Advanced Mode è parecchio incompleto, mentre il codice della first playable era snello e sicuramente molto meglio testato. Bisogna ripartire da lì, tagliando via tutto quello che è stato fatto dopo (e magari integrare alcune cosette carine che stava facendo Jap).
Insomma, occorre seguire una scaletta di questo tipo:
- revertare alla FP
- integrare le modifiche di Jappilas
- dimenticarci completamente di Advanced Mode e Single Player: non c'è il tempo di inserirli (e nell'industry capita MOLTO più spesso di quanto pensiate, non è un caso se il 90% delle espansioni che escono per i giochi contengono un sacco di feature originariamente previste come feature di base...)
- aggiungere il netplay
- aggiungere un paio di menu e lustrini vari qui e là
- pubblicizzarci di brutto, come e più dei vecchi tempi
- goderci il download counter schizzare di brutto (insieme alla nostra autostima :ciapet: )
Per una cosa del genere, lo ripeto fino allo sfinimento, serviranno impegno e serietà da parte di tutti quanti. Se siete arrivati a leggere fin qui e desiderate continuare a partecipare, state accettando esplicitamente quanto ho scritto e vi state impegnando a dare il massimo, ed è quello che mi aspetto da tutto il team, me compreso.
Detto questo, datemi un rapido feedback e vediamo di ricominciare. Seriamente.
:Prrr:
redcloud
13-03-2007, 09:37
Dai dai che stiamo iniziando a carburare :D Quoto pienamente Jo (anche se mi piacerebbe inserire la modalità single senza IA: si gioca contro se stessi e basta, giusto per non dover giocare con due mani quando non si ha un amico a disposizione :sofico: )
Allora, valutiamo bene la situazione.
1. Il progetto è morto, non giriamoci intorno, e se lo vogliamo resuscitare occorrerà il massimo impegno da parte di tutti. Quindi, mi aspetto che tutte le persone presenti qui lo dimostrino con i fatti (discutere non è mai servito a niente, e le discussioni senza fine hanno solo fatto male a Diamonds).
2. Senza delle linee guida non si va da nessuna parte. Occorre sceglierle, ed a sceglierle deve essere una sola persona (chi è d'accordo è d'accordo, chi non lo è lo sarà col tempo... non dimenticatelo mai!). Una volta tracciate le linee guida bisognerà portarle avanti con convinzione.
Ragazzi, non so se ve ne siete accorti, ma siamo vicini ai QUINDICIMILA download della First Playable, cosa che - per un progetto come Diamonds - è un risultato ben più che eccellente! E se questo non basta per dare una bella iniezione di autostima a noi tutti non so cosa potrebbe farlo :D
Abbiamo fatto un ottimo lavoro, ora va completato... sarebbe un delitto non farlo (anche per ripagare le 15.000 persone che ci hanno dato la loro fiducia).
3. Dobbiamo essere professionali. Questo non significa avere deadline strette da situazione lavorativa (non che le nostre alla fin fine lo fossero, eh! In contesti lavorativi la situazione è DECISAMENTE più stringente, non dimentichiamolo :Prrr: Abbiamo tutti una vita e degli impegni :p ). Mi riferisco soprattutto a "faide interne", dissapori e inimicizie varie (mi riferisco al post di Berto poco più sopra, che sinceramente non mi ha fatto piacere leggere).
Dimentichiamocele e passiamoci TUTTI sopra, non fanno altro che danneggiare direttamente o indirettamente il progetto. Se ci teniamo, la nostra priorità deve essere Diamonds, e tutto il resto deve venire dopo.
4. Per ripartire, occorrerà fare un bel revert, ne sono sempre più convinto.
La codebase è ridotta malissimo e l'Advanced Mode è parecchio incompleto, mentre il codice della first playable era snello e sicuramente molto meglio testato. Bisogna ripartire da lì, tagliando via tutto quello che è stato fatto dopo (e magari integrare alcune cosette carine che stava facendo Jap).
Insomma, occorre seguire una scaletta di questo tipo:
- revertare alla FP
- integrare le modifiche di Jappilas
- dimenticarci completamente di Advanced Mode e Single Player: non c'è il tempo di inserirli (e nell'industry capita MOLTO più spesso di quanto pensiate, non è un caso se il 90% delle espansioni che escono per i giochi contengono un sacco di feature originariamente previste come feature di base...)
- aggiungere il netplay
- aggiungere un paio di menu e lustrini vari qui e là
- pubblicizzarci di brutto, come e più dei vecchi tempi
- goderci il download counter schizzare di brutto (insieme alla nostra autostima :ciapet: )
Per una cosa del genere, lo ripeto fino allo sfinimento, serviranno impegno e serietà da parte di tutti quanti. Se siete arrivati a leggere fin qui e desiderate continuare a partecipare, state accettando esplicitamente quanto ho scritto e vi state impegnando a dare il massimo, ed è quello che mi aspetto da tutto il team, me compreso.
Detto questo, datemi un rapido feedback e vediamo di ricominciare. Seriamente.
:Prrr:
Ok, è tornato il customer!!:D sono d'accordo anche a ripartire dalla FP, anche se già da allora, se non ricordo male, c'erano dei refactoring in sospeso, che non sono mai stati completati, o sbaglio? P.S: cmq, io direi che adesso l'importante sia ripartire, da qualsiasi punto
il discorso del "non c'è tempo per inserire questo&quello" al momento attuale non lo capisco visto che non abbiamo più scadenze: intanto programmiamo le cose essenziali (quelle che hai detto anche tu), poi a seconda di quanto ci mettiamo si vedrà cosa altro fare :Prrr:
in tutto il postone comunque non ho visto un piccolo dettaglio: il nome dell'account di Jocchan su SF :| :Prrr:
detto questo: che ne dite se io committassi nel repository il codice alla revision della FP, dimenticandoci così completamente di tutto ciò che è stato aggiunto (bello o brutto)? e considerando che anche quel codice conterrà alcune cose che non ci piaceranno, test fatti male, codice lungo e complicato, ecc. ecc.
il discorso del "non c'è tempo per inserire questo&quello" al momento attuale non lo capisco visto che non abbiamo più scadenze: intanto programmiamo le cose essenziali (quelle che hai detto anche tu), poi a seconda di quanto ci mettiamo si vedrà cosa altro fare :Prrr:
in tutto il postone comunque non ho visto un piccolo dettaglio: il nome dell'account di Jocchan su SF :| :Prrr:
detto questo: che ne dite se io committassi nel repository il codice alla revision della FP, dimenticandoci così completamente di tutto ciò che è stato aggiunto (bello o brutto)? e considerando che anche quel codice conterrà alcune cose che non ci piaceranno, test fatti male, codice lungo e complicato, ecc. ecc.
guarda, adesso che ci penso, dopo la first palyable furono fatti dei refactoring abbastanza sostanziosi, tipo quello sulle biggem, siamo sicuri che il codice della FP sia veramente migliore di quello che ci ritroviamo adesso?
jappilas
13-03-2007, 12:18
il discorso del "non c'è tempo per inserire questo&quello" al momento attuale non lo capisco visto che non abbiamo più scadenze:....sulle scadenze: non è vero che non ve ne siano , solo che sono abbastanza in là, cioè dicembre prossimo, il che lascia un po' di tempo affinchè il regalo per i 30 anni del sottoscritto sia pronto :D
in tutto il postone comunque non ho visto un piccolo dettaglio: il nome dell'account di Jocchan su SF :| :Prrr:davvero, Jo, iscriviti ;)
detto questo: che ne dite se io committassi nel repository il codice alla revision della FP, dimenticandoci così completamente di tutto ciò che è stato aggiunto (bello o brutto)? e considerando che anche quel codice conterrà alcune cose che non ci piaceranno, test fatti male, codice lungo e complicato, ecc. ecc.fosse per me metterei online l' ultimo source tree completo dei branch e tags - senza, ne parlavo con Jo, pare possano insorgere problemi con il versioning...
Dai dai che stiamo iniziando a carburare :D Quoto pienamente Jo (anche se mi piacerebbe inserire la modalità single senza IA: si gioca contro se stessi e basta, giusto per non dover giocare con due mani quando non si ha un amico a disposizione :sofico: )basta fare un backup di KeyConfig, ed editarlo replicando i codici dei tasti :D
certo, non si vedrà l' avversario subire la caduta delle stone, ma almeno ci si può concentrare su una sola griglia :D
guarda, adesso che ci penso, dopo la first palyable furono fatti dei refactoring abbastanza sostanziosi, tipo quello sulle biggem, siamo sicuri che il codice della FP sia veramente migliore di quello che ci ritroviamo adesso?no, migliore non lo è... per dire, io ricordo svariati bug, non ultimo quello corretto da Baol (che invito a partecipare attivamente ;)) l' autunno scorso
RaouL_BennetH
13-03-2007, 12:22
Io nel frattempo mi sto leggendo alcune delle guide proposte per il tdd. Spero solo che abbiate un pò di pazienza perchè davvero non ho idea nemmeno di come si inizia a scrivere un test. Al momento però ho già installato eclipse e sembra che l'installazione sia andata a buon fine. Se avete qualche consiglio pratico da darmi ne sarei più che contento :)
Grazie mille.
RaouL.
ok, allora mettiamo l'ultima revision e continuiamo da quella? per me va bene, purché abbiamo la possibilità di cassare tranquillamente qualsiasi test fatto male (leggasi: test non piccolo, non semplice, e/o non mockato :Prrr: ) e rifarlo in seguito -- se proprio necessario.
btw, che ne facciamo del TDD? io sarei favorevole a continuare lo sviluppo senza i test, visto che l'esperienza mi ha confermato che sono in grado di lavorare in maniera eccellente e produttiva anche senza. voi che dite? non mi interessa essere d'intralcio, percui se la maggioranza di voi vuole a tutti i costi continuare TDD mi adatterò.
btw, che ne facciamo del TDD? io sarei favorevole a continuare lo sviluppo senza i test, [...]
:mad:
jappilas
13-03-2007, 13:38
ok, allora mettiamo l'ultima revision e continuiamo da quella? per me va bene, purché abbiamo la possibilità di cassare tranquillamente qualsiasi test fatto male (leggasi: test non piccolo, non semplice, e/o non mockato :Prrr: ) e rifarlo in seguito -- se proprio necessario.molti dei test che stavo scrivendo possono non essere perfetti (soprattutto sto pensando a come riscriverli senza fare uso di casting, cosa che non ricordavo andasse evitata, mea culpa), ma questo dovrebbe essere pressochè referenziale
public void testMenuLoopFinishedOnGameRestart()
{
menuLoop.restartGame();
assertFalse("The Menu Loop must be stopped", menuLoop.isRunning());
}
btw, che ne facciamo del TDD? io sarei favorevole a continuare lo sviluppo senza i test, visto che l'esperienza mi ha confermato che sono in grado di lavorare in maniera eccellente e produttiva anche senza. che tu sia in grado di raggiungere un' ottima produttività non dubito ;)
ma è da tenere presente l' aspetto della partecipazione ai lavori di persone meno esperte e/o meno addentro all' approccio TDD ma anche solo con meno confidenza con la code base ... specialmente se abbiamo l' interesse ad attrarre la partecipazione di contributor nuovi, magari provenienti da altre parti del mondo ;)
il rischio di rompere qualcosa in modo anche "subdolo" cresce esponenzialmente, e non possiamo permetterci che questo accada ... piuttosto che rischiare di compromettere la qualità del lavoro preferisco non riprenderlo nemmeno
anche perchè, come una cosa detta da ufoFede mi ha fatto mettere a fuoco, quello che davvero "è" DC , e che conta per esso, non è tanto il giochino arcade in quanto tale, è il lavoro svolto e il modo di svolgerlo, cioè non è importante la destinazione, ma il viaggio...
voi che dite? non mi interessa essere d'intralcio, percui se la maggioranza di voi vuole a tutti i costi continuare TDD mi adatterò.ottimo :)
EDIT: ah, importante: se mi volete come coach dovrete sottostare ad alcune limitazioni ...
posto che sono il primo a dire che idee alternative su design e rifattorizzazioni sono ben accette, non accetterò atteggiamenti polemici o sarcastici, nè sul forum nè in discussioni a cui io sia partecipe
non tollererò che discussioni sulla strada da seguire degenerino con attacchi personali e si ripeta quanto successo qualche giorno fa su MSN (non starò a menzionare gli interessati perchè la mia stima verso di loro non è cambiata, ma mi è dispiaciuto parecchio assistere)
già è poco il tempo che posso dedicare giornalmente, se cose del genere accadranno abbandonerò definitivamente, ma non prima di aver spezzato ditine e braccine ...
il discorso del "non c'è tempo per inserire questo&quello" al momento attuale non lo capisco visto che non abbiamo più scadenze: intanto programmiamo le cose essenziali (quelle che hai detto anche tu), poi a seconda di quanto ci mettiamo si vedrà cosa altro fare :Prrr:
in tutto il postone comunque non ho visto un piccolo dettaglio: il nome dell'account di Jocchan su SF :| :Prrr:
detto questo: che ne dite se io committassi nel repository il codice alla revision della FP, dimenticandoci così completamente di tutto ciò che è stato aggiunto (bello o brutto)? e considerando che anche quel codice conterrà alcune cose che non ci piaceranno, test fatti male, codice lungo e complicato, ecc. ecc.
Il solo progetto senza scadenze è un progetto morto.
Te lo ricordi quell'esempio di quel picchiaduro il cui sviluppo va avanti da sì e no sei anni? Credi che ci giocheremo mai? :Prrr:
Senza scadenze non si arriva da nessuna parte: ci si può tenere larghi perchè tutti abbiamo impegni (lo facevamo già, si può fare di più), ma le deadline devono restare, altrimenti è inutile ripartire, visto che non faremmo altro che fallire clamorosamente.
Per la codebase, sinceramente dovete dirmelo voi quale delle due fosse migliore.
Io ricordo chiaramente una valanga di bug introdotti dopo la FP (alcuni pure belli grossi, tipo gemmoni che si formavano nelle caselle sbagliate). Dunque, se si fa un bel riassunto di COSA è stato rifattorizzato, si può cercare di reinserirlo pur ripartendo sempre dalla FP.
Per il fatto di iscrivermi o meno su SF, inoltre, dipende tutto da voi :D
jappilas
13-03-2007, 14:54
Quindi, mi aspetto che tutte le persone presenti qui lo dimostrino con i fatti (discutere non è mai servito a niente, e le discussioni senza fine hanno solo fatto male a Diamonds).*- vedere anche il mio post precedente ...
2. Senza delle linee guida non si va da nessuna parte. Occorre sceglierle, ed a sceglierle deve essere una sola persona (chi è d'accordo è d'accordo, chi non lo è lo sarà col tempo... non dimenticatelo mai!). Una volta tracciate le linee guida bisognerà portarle avanti con convinzione.anche per quello ero titubante ad accettare il ruolo di coach... faccio presente che l' anno scorso la mia più grande aspirazione era diventare il nuovo fek :D
Ragazzi, non so se ve ne siete accorti, ma siamo vicini ai QUINDICIMILA download della First Playable, cosa che - per un progetto come Diamonds - è un risultato ben più che eccellente! E se questo non basta per dare una bella iniezione di autostima a noi tutti non so cosa potrebbe farlo :D
Abbiamo fatto un ottimo lavoro, ora va completato... sarebbe un delitto non farlo (anche per ripagare le 15.000 persone che ci hanno dato la loro fiducia).:)
3. Dobbiamo essere professionali. Questo non significa avere deadline strette da situazione lavorativa (non che le nostre alla fin fine lo fossero, eh! In contesti lavorativi la situazione è DECISAMENTE più stringente, non dimentichiamolo :Prrr: ma al di là delle deadline (io sarei per darci delle scandenze molto in là, tipo dicembre, per lavorare con forse più calma :O )
Abbiamo tutti una vita e degli impegni :p ). Mi riferisco soprattutto a "faide interne", dissapori e inimicizie varie (mi riferisco al post di Berto poco più sopra, che sinceramente non mi ha fatto piacere leggere).
Dimentichiamocele e passiamoci TUTTI sopra, non fanno altro che danneggiare direttamente o indirettamente il progetto. Se ci teniamo, la nostra priorità deve essere Diamonds, e tutto il resto deve venire dopo.*
anche perchè ricordo il mio impegno, per chi non ci passi sopra ditine spezzate e mio abbandono :O
4. Per ripartire, occorrerà fare un bel revert, ne sono sempre più convinto.
La codebase è ridotta malissimo e l'Advanced Mode è parecchio incompleto, mentre il codice della first playable era snello e sicuramente molto meglio testato. Bisogna ripartire da lì, tagliando via tutto quello che è stato fatto dopo (e magari integrare alcune cosette carine che stava facendo Jap).io farei una cosa, le cosette carine su cui stavo lavorando, le introdurrei gradualmente testando quanto più possibile :O
ad esempio, lo splash screen... per adesso ho aggiunto al costruttore del GameLauncher qualche riga di codice presa pari pari dal metodo che preparava il background del gioco - funziona, ma non è testato
il menu in game - con annesso sistema di menu multiplo e stratificato con sprites separati, per come stavo scrivendo l' AbstractMenu può funzionare, ma non è ancora testato (ho delle test list in mente ma non sono ancora formalizzate)
in pratica ho deliberatamente derogato al TDD per valutare l' impatto di certe funzioni sulla code base, ma se il progetto riparte sono per farlo rispettare e rispettarlo per primo :O
- revertare alla FP
io reverterei alla "post _logging_ infrastructure_removal" :O
- integrare le modifiche di Jappilasvedi sopra ;)
- dimenticarci completamente di Advanced Mode e Single Player: non c'è il tempo di inserirli (e nell'industry capita MOLTO più spesso di quanto pensiate, non è un caso se il 90% delle espansioni che escono per i giochi contengono un sacco di feature originariamente previste come feature di base...)ammetto che un po' mi spiace, ricordo quanto tempo spesi a concepire l' artificial player... ;_;
ma è vero, il single player ha priorità minima (verrà forse affrontato quando tutto il resto sarà a posto)
l' advanced mode però lo lascerei come task a priorità bassa ma non nulla, senza buttarlo via , proporrei di reintrodurlo più avanti ( se avanzerà un po' di tempo) studiandone il design meglio di quanto fatto l' anno scorso
cosa fattibile anche perchè credo che più o meno tutti abbiamo in testa il codice che implementava le dinamiti, credo tutti abbiano imparato qualcosa da quell' episodio...
- aggiungere il netplaygiusto, ma aggiungerei ( :D ):
aggiungere il gioco tramite periferiche diverse dalla tastiera (gamepad digitale su gameport o USB) nonchè la personalizzazione dei tasti tramite una schermata di menu apposita (lo considererei task contingente ad alta priorità)
- aggiungere un paio di menu e lustrini vari qui e làalmeno le schermate delle opzioni e il menu in game ;)
- pubblicizzarci di brutto, come e più dei vecchi tempi
- goderci il download counter schizzare di brutto (insieme alla nostra autostima :ciapet: )il nostro PR avrà un gran daffare :D
Per una cosa del genere, lo ripeto fino allo sfinimento, serviranno impegno e serietà da parte di tutti quanti. Se siete arrivati a leggere fin qui e desiderate continuare a partecipare, state accettando esplicitamente quanto ho scritto e quanto ho scritto io più sopra ;)
e vi state impegnando a dare il massimo, ed è quello che mi aspetto da tutto il team, me compreso. ;)
OT per quanto riguarda Ufo13: l'ho tolto dalla mia ignore list su HWU perché se fosse interessato a partecipare ancora al progetto* lo saprò e potrò aggiungerlo nel team. in tal caso mi impegnerò ad ignorare qualsiasi attacco personale da parte sua limitandomi sempre ad esporre solo ragioni tecniche.
* spero di no
fine OT. per quanto riguarda invece il TDD a quanto pare dovrò adattarmi. e per quanto riguarda invece la revision da uppare su SF, per me è uguale: tanto ormai non ricordo molto ne' dell'una ne' dell'altra revision, e anche se quella attuale ha più bugs c'è da dire che quella della FP potrebbe essere troppo difficilmente integrabile con le ultime modifiche di jappilas, senza contare che qualcosa di utile ce l'avevamo messa (i menu sicuramente).
jappilas
13-03-2007, 16:59
OT per quanto riguarda Ufo13: l'ho tolto dalla mia ignore list su HWU così ti voglio :)
cmq io non avevo parlato esplicitamente di te eh :O :D
c'è da dire che quella della FP potrebbe essere troppo difficilmente integrabile con le ultime modifiche di jappilas, senza contare che qualcosa di utile ce l'avevamo messa (i menu sicuramente).allora due cose:
le modifiche che sto provando in questi giorni si riassumono in una manciata di nuovi file Java tra classi e interfaccie, nonchè un riadattamento di qualcuno già esistente (modifiche al costruttore delle menuaction, e dell' EscapeCommandHandler per dire) ma soprattutto modifiche a TestGameLoop.java... se le si vuole integrare, si può farlo in modo progressivo funzione per funzione - stavo pensando all' ordine migliore in cui farlo :O
inoltre, sono come tutto il codice, perfettibili per definizione... il pattern state con due oggetti Loop principali, mi sembrava una soluzione elegante, ma non vorrei che risultassero troppo pesanti da testare per quanto riguarda il loro avvicendamento, senza magari portare il vantaggio di ridurre la quantità di codice necessaria alla loro implementazione
QUINDI, se ci sono altre idee ben vengano :O
Baol (che invito a partecipare attivamente ;))
A chiamata rispondo :D
Account Sourceforge: bedrosian_baol ;)
I miei due cent:
1) Se si ripristina la First Playable se non ricordo male si reverta tutto il lavoro sulle biggem fatto da Bonfo , 71104 & co., ovvero ci si ritrova con uno schema di base "concettuale" completamente diverso.
2) Secondo me il problema grosso del progetto è stato il fatto che i test venivano fatti da persone che non ne avevano mai fatti, quindi erano errati o perlomeno ridondanti; ma soprattutto sia i test che il codice in generale non venivano ricontrollati, per ragioni di tempo o che, da chi gestiva il progetto o da chi avrebbe potuto correggere i vari errori sul nascere (questo senza dar colpe a nessuno, il carattere sperimentale del progetto aveva questo rischio :) ).
Ci si è trovati quindi con persone "inesperte" obbligate a scelte di design anche importanti.
Potrebbe essere un'idea (so che è difficile) affidare a qualcuno di "competente" il rapido controllo, ogni tanto, del codice scritto dai "novizi"?
3) D'accordissimo con la linea intransigente di Jappilas :asd:
io reverterei alla "post _logging_ infrastructure_removal" :O
Leggo solo ora.
A 'sto punto non si reverta niente, perchè dopo c'è stata solo correzione di bug :D
Almeno, se non mi sono perso qualcosa... :stordita:
jappilas
14-03-2007, 08:58
Leggo solo ora.
A 'sto punto non si reverta niente, perchè dopo c'è stata solo correzione di bug :D
Almeno, se non mi sono perso qualcosa... :stordita:no, in pratica hai ragione... è che ora come ora mi pareva che la versione su cui stavo portando avanti lo spike , l' ultima disponibile (build 2387 se non ricordo male) fosse abbastanza sana... :O
aggiornamenti: antares ha un problema col server svn. jappilas affermava che non fosse reperibile, ma in realtà il server è sempre stato up. ho provato a fare io un checkout e non ci sono riuscito: il server non indicizza più il database di quel repository, quindi c'è qualche problema di configurazione che però ne' io ne' anta sappiamo risolvere. possiamo decidere di perdere tempo a cercare di capire come si configura il server svn oppure possiamo uppare direttamente la versione di jappilas consapevoli del fatto che prima di vederla andare toccherà aggiustarla. nel frattempo rimane ancora il problema della build machine: qualcuno (alla fine io mi sa :mc: ) deve documentarsi su come si usa e configurarne una su Spartacus. dopodiché possiamo iniziare a lavorare.
jappilas
14-03-2007, 13:36
aggiornamenti: antares ha un problema col server svn. jappilas affermava che non fosse reperibile, ma in realtà il server è sempre stato up.ops :fagiano:
ho provato a fare io un checkout e non ci sono riuscito:sono :stordita: ma almeno gli errori di subclipse non li ho immaginati.. :( possiamo decidere di perdere tempo a cercare di capire come si configura il server svn oppure possiamo uppare direttamente la versione di jappilas oppure uppare la versione che hai tu <segue>
consapevoli del fatto che prima di vederla andare toccherà aggiustarla. <>, e le funzioni instabili del mio spike le si aggiunge una alla volta in TDD, non dovrebbe volerci molto ;)
nel frattempo rimane ancora il problema della build machine: qualcuno (alla fine io mi sa :mc: ) deve documentarsi su come si usa e configurarne una su Spartacus. cmq imparare come si usa toccherà anche ad altri , per dire il project admin ...
Gente, se intanto volete iniziare e non volete avere tutto quello che permette di fare cruise cotnrol, allora basta mettere su un script su cron che si sincronizza con il repository una volta ogni 5 minuti e dopo, se ci sono stati cambiamenti, fa la build con ant. Dopo basta inviare lo stderr tramite mail alla mailinglist. In alternativa alla mail ci potrebbe essere la pubblicazione dello stderr su un feed RSS (tutto fattibilissimo tramite shell).
welààà Riccardo! :D
sono molto lieto di vedere che parteciperai anche tu al tentativo di riesumazione, e ne sarà sicuramente molto contento anche Jocchan :)
vedo che sei già stato aggiunto al team, ma non ti hanno segnato come Developer :Prrr:
rimediamo...
PS: di', la password di diamondcrusher l'hai azzeccata tu ( :stordita: :stordita: :stordita: ) o ti ha aggiunto jappilas? :D
Mi ha aggiunto jappilas, ma per ora non se ne parla. Ho troppa roba da fare :cry:
riassumendo i permessi che ho impostato per i vari account:
Username CVS SVN Web Rel. Snap. Track. Task Forums Doc. News Screen
a71104 No Yes No No No - Tech Moderator - - -
antares88 No Yes Yes No No - Tech Moderator - - -
bedrosian_baol No Yes No No No - Tech - - - -
cionci No Yes No No No - Tech Moderator - - -
danielesv No Yes No No No - Tech - - - -
diamondcrusher No No Yes Yes No A Admin - - Editor Editor
jappilas No Yes No Yes No - Admin&Tech Moderator Editor - -
jmccain No Yes No No No - Tech Moderator - - -
jocchan No Yes Yes No No - Tech - Editor Editor Editor
raoul_benneth No Yes No No No - Tech - - - -
redcloud80 No Yes No No No - Tech - - - -
ovvero:
accesso al repository: tutti tranne diamondcrusher
accesso al web del progetto:
jocchan
antares
diamondcrusher
amministrazione delle release:
diamondcrusher
jappilas
amministrazione snapshots: nessuno perché non so cosa sono e credo di non averli manco abilitati :Prrr:
amministrazione trackers (creazione nuovi trackers, ecc.): solo diamondcrusher - è una cosa che si fa una volta sola
amministrazione tasks: diamondcusher e jappilas
task "technicians", ovvero chi svolge i tasks: tutti tranne diamondcrusher
moderazione forums: qui sono andato un po' a occhio conoscendo la gente che ha attidudine per la moderazione :Prrr: :fagiano:
cionci :D
io
antares :Prrr:
jappilas :O
daniele :p
documentazione: jocchan e jappilas
scrittura delle news: diamondcrusher e jocchan, sto pensando di togliere diamondcrusher
screenshots: diamondcrusher e jocchan
Gli snapshot sono delle build su cui si fa solitamente testing a livello utente, tipo la versione che abbiamo rilasciato l'anno scorso. Possono essere aperte solo agli sviluppatori o anche agli utenti.
^TiGeRShArK^
14-03-2007, 23:34
amministrazione snapshots: nessuno perché non so cosa sono e credo di non averli manco abilitati :Prrr:
ehmm..
gli snapshot se non erro sono i branches (o meglio i TAGS), ovvero immagini del repository nei momenti in cui il codice è abbastanza stabile tanto x intenderci :p
Direi che qualcuno dovrebbe pur amministrarli... o no? :D
Anke se ovviamente già da SVN si possono gestire come abbiamo fatto finora ;)
EDIT: ecco appunto..aveva già risposto cionci tra l'altro :asd:
ah :mbe:
vabbè, lascio a jappilas & diamondcrusher, poi forse un giorno vedrò bene come funzionano :P
dimenticavo di dire a tutti una cosa importante: prima lavoravamo sempre con un solo account "diamonds" e quindi nei log dei commit scrivevamo sempre il nostro nome all'inizio; ora chiaramente non ce ne sarà più bisogno perché ciascuno accede al repository col suo account e la sua password e quindi quello appare come autore del commit.
oggi vediamo di ripristinare il vecchio repository e committarne il contenuto nel nuovo.
è da ore che sto facendo il checkout completo, non immaginavo che tra branch e tag fossimo arrivati a più di mezzo giga, e ancora non ho finito... :|
dite quello che vi pare ma io su SourceForge tutta quella roba non ce la metto :Prrr: considerando che la banda in UL è molto inferiore a quella in DL ci impiegherei anni -.-
io su SF committerò trunk e forse qualche spike, poi se il resto vi sta a cuore ognuno committa un pezzetto :Prrr:
tanto ormai il repository di Antares è di nuovo accessibile con questo URL: svn://spartacus.nsn3.net:20140/diamonds
è da ore che sto facendo il checkout completo, non immaginavo che tra branch e tag fossimo arrivati a più di mezzo giga, e ancora non ho finito... :|
dite quello che vi pare ma io su SourceForge tutta quella roba non ce la metto :Prrr: considerando che la banda in UL è molto inferiore a quella in DL ci impiegherei anni -.-
io su SF committerò trunk e forse qualche spike, poi se il resto vi sta a cuore ognuno committa un pezzetto :Prrr:
tanto ormai il repository di Antares è di nuovo accessibile con questo URL: svn://spartacus.nsn3.net:20140/diamonds
Importerai tutto il repository con le verie revisioni oppure solo l'ultima versione?
ciao ;)
RaouL_BennetH
15-03-2007, 11:33
:cry:
mi concedete di chiedere di aprire un topic in questa sezione per la terminologia che usate?
Molti dei termini che usate mi sono sconosciuti :(
Non volendo rallentarvi il lavoro, se magari qualcuno di voi apre un piccolo topic con (per esempio):
TDD = significato e piccolissima descrizione
Revertare = "" ""
altrimenti ogni volta che cerco di seguirvi assumo un'espressione tipo :huh:
RaouL :)
Importerai tutto il repository con le verie revisioni oppure solo l'ultima versione?
ciao ;) solo l'ultima: non credo si possano importare quelle precedenti...
comunque non vorrei dire ma non ha ancora finito, e sto usando un disco fisso che era già quasi pieno :|
mi restano 600 mega di spazio libero, dopodiché il checkout s'incarta, io cancello tutto e rifaccio solo trunk :read:
ma ste ITERATION che sarebbero, degli snapshots?
:cry:
mi concedete di chiedere di aprire un topic in questa sezione per la terminologia che usate?
Molti dei termini che usate mi sono sconosciuti :(
Non volendo rallentarvi il lavoro, se magari qualcuno di voi apre un piccolo topic con (per esempio):
TDD = significato e piccolissima descrizione
Revertare = "" ""
altrimenti ogni volta che cerco di seguirvi assumo un'espressione tipo :huh:
RaouL :) intanto vedi se questo ti è d'aiuto: http://www.hwupgrade.it/forum/showthread.php?t=1016614
solo l'ultima: non credo si possano importare quelle precedenti...
Si puo fare e mantenere tutta la storia precedente solo che non ricordo come si fa :doh:
comunque non vorrei dire ma non ha ancora finito, e sto usando un disco fisso che era già quasi pieno :|
mi restano 600 mega di spazio libero, dopodiché il checkout s'incarta, io cancello tutto e rifaccio solo trunk :read:
ma ste ITERATION che sarebbero, degli snapshots?
Oddio pure le iteration :eek: Folle!!!
Scarica solo trunk e lascia perdere le iteration e gli spike che non vi servono a niente a questo punto dello sviluppo.
ciao ;)
ha finito finalmente: 578 mega :|
Si puo fare e mantenere tutta la storia precedente solo che non ricordo come si fa :doh: vabbè lasciamo perdere, anche perché i commit passati sono segnati tutti a nome dello stesso account.
Oddio pure le iteration :eek: Folle!!!
Scarica solo trunk e lascia perdere le iteration e gli spike che non vi servono a niente a questo punto dello sviluppo. e io che ne sapevo di cosa c'era dentro, ho fatto il checkout completo e basta :|
committato Trunk su SourceForge. :winner:
per il checkout da SF usate quest'URL: https://diamondcrush.svn.sourceforge.net/svnroot/diamondcrush/trunk
occhio al protocollo: è HTTPS, non SVN!
dulcis in fundo... committo anche tutto il resto escluse le ITERATION :|
(sto committando branch e FIRST-PLAYABLE)
jappilas
15-03-2007, 14:07
committato Trunk su SourceForge.ottimo :)
TDD = significato e piccolissima descrizioneTDD = Test Driven Development, sviluppo basato sui test ;)
detto in parole povere, si scrive un testCase con delle asserzioni che testino condizioni o valori risultanti dall' istanziazione di una classe o dall' esecuzione dei suoi metodi, e una volta appurato che il test non passa perchè manca il codice che lo soddisfa, lo si fa passare scrivendo il codice o modificando l' implementazione di quello attuale ;)
ti rimando comunque al thread aperto da fek ( http://www.hwupgrade.it/forum/showthread.php?t=1017489 ) e ai link in questo riportati ;)
Revertare = "" ""revertare, fare revert, vuol dire in pratica tornare indietro , cioè alla versione del codice precedente
se tu stai lavorando in Eclipse su dei sorgenti di cui hai fatto il checkout (primo scaricamento dal repository) o l' update, quelli che presentano modifiche apportate in locale rispetto alla versione presente sul repository vengono marcati con un asterisco ( adoro l' integrazione di Eclipse con gli strumenti di lavoro cooperativo :))
facendo revert, torni allo stato dei sorgenti che avevi con l' ultimo update da repository, annullando le modifiche apportate (Eclipse comunque permette di revertare a livello di singoli file) ;)
PS: ho sentito Cesare (cdimauro), saluti e auguri a tutto il team da parte sua :)
RaouL_BennetH
15-03-2007, 15:49
problema solo mio o non si riesce ad entrare in sf?
problema solo mio o non si riesce ad entrare in sf? se il link a cui non riesci ad accedere è quello del post #92 allora è un problema di (forse) Firefox: quando ci clicco non so perché ma mi viene aggiunto un numero di porta (9443 mi pare) che in realtà nel link originario non c'è! (passare il mouse sul link e vedere l'URL nella status bar di FF per credere)
toglici manualmente il numero di porta: deve selezionare quello predefinito di HTTPS.
RaouL_BennetH
15-03-2007, 16:34
uh no, mi riferivo proprio andando semplicemente su http://sourceforge.net, ora invece me lo apre. :)
Ne approfitto per chiedervi:
Da dove devo scaricare i sorgenti di diamonds? Mi basta scaricare la FP che sta su sf?
installa un client Subversion e fai il cosiddetto checkout (cioè appunto il download iniziale), ma solo di trunk: branch e tags lasciali perdere. quando fai il checkout usa quest'URL: https://diamondcrush.svn.sourceforge.net/svnroot/diamondcrush/trunk come vedi l'URL si riferisce solamente a trunk :)
se sei su Windows come client Subversion puoi usare Tortoise SVN (http://tortoisesvn.tigris.org/), mentre se sei su Linux può darsi che tu abbia già il comando testuale svn; ma l'alternativa migliore di entrambi è Subclipse (http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-47.html), il plugin SVN per Eclipse.
qualcuno (VICIUS :D) si ricorda gli argomenti che dovevo dare a Eclipse nel creare le configurazioni di avvio? quella roba per settare il library path... :help:
redcloud
15-03-2007, 19:50
uh no, mi riferivo proprio andando semplicemente su http://sourceforge.net, ora invece me lo apre. :)
Ne approfitto per chiedervi:
Da dove devo scaricare i sorgenti di diamonds? Mi basta scaricare la FP che sta su sf?
Raoul mi prendo cura io di te visto che sono quello più scarso qua in mezzo e magari ho più tempo per assistere le new entry.
Apri Eclipse, Help -> Software Updates -> Find and Install -> Search for new Features -> New Remote Site
inserisci come nome subclipse e come url http://subclipse.tigris.org/update
dai OK e poi Finish. Accetta di installare il plugin e restarta Eclipse. Dopodichè menù Window -> Open perspective -> Other... -> SVN Repository Exploring
a questo punto ti si apre una nuova view di SVN e devi cliccare sull'icona con scritto SVN+
inserisci questo URL https://diamondcrush.svn.sourceforge.net/svnroot/diamondcrush
dopodichè premi col tasto destro sulla cartella trunk e seleziona checkout (vai sempre avanti lasciando le impostazioni di base).
jappilas
15-03-2007, 21:20
qualcuno (VICIUS :D) si ricorda gli argomenti che dovevo dare a Eclipse nel creare le configurazioni di avvio? quella roba per settare il library path... :help:se non ricordo male:
Run as.. > Run... > Run (Debug) Configurations > VM Arguments:
-Djava.library.path=lib/win32
in più c' era da impostare ANT_HOME e JAVA_HOME nelle variabili d' ambiente, (rispettivamente a <path di Eclipse>\plugins\org.apache.ant_<versione di ant> e <path del jdk>) se non lo si è già fatto ;)
RaouL_BennetH
16-03-2007, 11:34
inserisci questo URL https://diamondcrush.svn.sourceforge.net/svnroot/diamondcrush
dopodichè premi col tasto destro sulla cartella trunk e seleziona checkout (vai sempre avanti lasciando le impostazioni di base).
Ciao Redcloud :)
Grazie mille per le indicazioni e la pazienza. Ho solo il problema che non riesco in nessun modo a collegarmi con l'url da te linkato, anche seguendo le indicazioni di 71104 :(
redcloud
16-03-2007, 11:56
Guarda è strano. Hai provato a fare così?
Incolla questo link nella barra degli url del browser
https://diamondcrush.svn.sourceforge.net/svnroot/diamondcrush/
in teoria dovresti gia vedere la pagina con le 3 cartelle
altrimenti, se non riesci ad accedere alla pagina è perchè nell'url è comparso il numero di porta
:9443
prova a cancellarlo direttamente nella barra degli url e a premere invio, dovrebbe andare!
Se va, copia il link direttamente dalla barra degli url e incollalo nella barra degli url di subclipse.
RaouL_BennetH
16-03-2007, 12:40
Boh, adesso è andata, ma lo stesso strano problema l'ho avuto ieri, nel senso che non riuscivo proprio ad andare su sourceforge anche digitando normalmente l'indirizzo nella barra del browser.
Ad ogni modo, ho fatto il checkout, solo che (magari è normale) se chiudo eclipse e poi lo riapro, anche se scelgo il workspace (nel mio caso è: /home/raoul/workspace/Diamonds) non mi da nessun file e/o directory nella tree, cioè, è come se non avessi selezionato nessun progetto.
Chiedo sempre scusa a tutti per le mie niubbaggini che di sicuro vi portano via tempo :(
RaouL.
redcloud
16-03-2007, 15:32
Boh, adesso è andata, ma lo stesso strano problema l'ho avuto ieri, nel senso che non riuscivo proprio ad andare su sourceforge anche digitando normalmente l'indirizzo nella barra del browser.
Ad ogni modo, ho fatto il checkout, solo che (magari è normale) se chiudo eclipse e poi lo riapro, anche se scelgo il workspace (nel mio caso è: /home/raoul/workspace/Diamonds) non mi da nessun file e/o directory nella tree, cioè, è come se non avessi selezionato nessun progetto.
Chiedo sempre scusa a tutti per le mie niubbaggini che di sicuro vi portano via tempo :(
RaouL.
Questo è strano anzichenò! Prova a fare un Import del workspace, e vedi se almeno te lo trova.
^TiGeRShArK^
17-03-2007, 00:54
Boh, adesso è andata, ma lo stesso strano problema l'ho avuto ieri, nel senso che non riuscivo proprio ad andare su sourceforge anche digitando normalmente l'indirizzo nella barra del browser.
Ad ogni modo, ho fatto il checkout, solo che (magari è normale) se chiudo eclipse e poi lo riapro, anche se scelgo il workspace (nel mio caso è: /home/raoul/workspace/Diamonds) non mi da nessun file e/o directory nella tree, cioè, è come se non avessi selezionato nessun progetto.
Chiedo sempre scusa a tutti per le mie niubbaggini che di sicuro vi portano via tempo :(
RaouL.
mmm..
stai usando il package explorer o il navigator view per vedere i progetti?
Non è che ti da qualche errore strano del tipo che non riesce a salvare il workspace?
che versione hai di eclipse?
.....lo so che sono pedante... ma visto che non partecipo + (x ora) al progetto almeno vedo se posso fare qualcosina :p
............
............dimenticavo...usi windows o linux? :D
RaouL_BennetH
18-03-2007, 10:17
mmm..
stai usando il package explorer o il navigator view per vedere i progetti?
Non è che ti da qualche errore strano del tipo che non riesce a salvare il workspace?
che versione hai di eclipse?
.....lo so che sono pedante... ma visto che non partecipo + (x ora) al progetto almeno vedo se posso fare qualcosina :p
............
............dimenticavo...usi windows o linux? :D
Ciao :)
Sto usando linux, e la versione di eclipse è la 3.2.
In nessun modo dopo aver fatto il check out del progetto riesco a visualizzarlo in eclipse a meno di non rimanere su SVN.
Questo è il messaggio che mi da quando cerco di importare il workspace:
"Exception in thread main `18A9FH716623C13B9` !!
Unable to read stream at build.xml"
Ho cercato di copiare l'errore pari pari su google ma non mi da nemmeno mezza pagina da visualizzare :(
Se faccio piccoli sorgenti da eclipse e li compilo, funzionano senza problemi.
Come soluzione ho cercato anche di eliminare quello che avevo importato e fare il check out da capo, ma sempre con la stessa problematica.
Lavoro da utente nella mia home, a scanso di equivoci sui permessi ho provato a fare lo stesso da root ma il problema mi è rimasto.
:help:
Ma come fai per importare il progetto dal browser SVN ?
Devi clickare col destro sulla cartella trunk e da lì scegliere non mi ricordo cosa...
Non è che lo fai dalla home del progetto ?
jappilas
18-03-2007, 10:31
Ma come fai per importare il progetto dal browser SVN ?
Devi clickare col destro sulla cartella trunk e da lì scegliere non mi ricordo cosa...
Non è che lo fai dalla home del progetto ?( se non ricordo male) checkout as new project in workspace
dovrebbe poi chiedere il nome con cui visualizzare nel workspace il " source tree" :O
RaouL_BennetH
18-03-2007, 11:15
Si, procedo come anche voi confermate. Ho seguito le indicazioni datemi da redcloud qualche post fa.
Ad ogni modo, non è il solo problema che mi sta affliggendo, tanto che sto reinstallando la debian sul portatile. Sto soffrendo di problemi molto strani, crash improvvisi dei programmi (mi capita anche che firefox si chiuda inaspettatamente). In pratica credo di avere tutti i sintomi di una ram che mi sta abbandonando :(
Sto facendo la netinstall cmq, poi riprovo il tutto e vi faccio sapere :)
Per il momento un grazie mille a tutti per il supporto :)
Anche a me Firefox dalla versione 2 mi sta dando crash improvvisi. Mi sembra molto buggata la versione 2 !!!
Comunque ho fatto ora il checkout con Eclipse su Ubuntu.
Posso darti le istruzioni precise:
- installa subeclipse dal'update site di Eclipse: http://subclipse.tigris.org/update_1.2.x
- Window -> Show view -> Other SVN -> SVN Repository -> Ok
- Da SVN Repository -> tasto destro sullo sfondo -> New -> Repository Location -> https://diamondcrush.svn.sourceforge.net/svnroot/diamondcrush -> Finish
- sfoglia il repository -> tasto destro su trunk -> Checkout -> Next -> Finish
redcloud
19-03-2007, 13:17
Ho visto che qualcuno ogni tanto fa un commit. Ma in che fase siamo ora? Prossimi sviluppi?
RaouL_BennetH
19-03-2007, 16:08
Grazie anche a te cionci ... ma sono bloccato, l'errore ha solo cambiato numero ma persiste :muro:
Ultima prova che posso fare è di sostituire la ram e meno male che questo pseudo portatile monta le ram normali e non quelle mini.
Vi faccio sapere fra poco :(
Grazie a tutti.
RaouL.
jappilas
19-03-2007, 16:45
Ho visto che qualcuno ogni tanto fa un commit. Ma in che fase siamo ora? Prossimi sviluppi?Alberto ha rifattorizzato alcuni test - e direi che vanno bene :)
ora, quello che stavo pensando di fare è stendere le task list ...
redcloud
19-03-2007, 17:31
Ecco, prima di fare questo, perchè non facciamo uno schema simil-UML delle classi principali? Giusto per dare la possiblità a tutti di capire a grandi linee qual è il flusso principale...
Ecco, prima di fare questo, perchè non facciamo uno schema simil-UML delle classi principali? Giusto per dare la possiblità a tutti di capire a grandi linee qual è il flusso principale... secondo me è inutile: se veramente si lavorasse il codice varierebbe talmente in fretta (anche pezzi grossi e fondamentali) che qualsiasi schema diverrebbe rapidamente obsoleto.
IMHO sarebbe bello poter generare automaticamente lo schema UML con la build...ma dubito che esista qualche tool adatto...
redcloud
19-03-2007, 18:17
secondo me è inutile: se veramente si lavorasse il codice varierebbe talmente in fretta (anche pezzi grossi e fondamentali) che qualsiasi schema diverrebbe rapidamente obsoleto.
Oddio, da quando è iniziato il progetto di cambiamenti ne sono stati fatti ma non credo che il flusso di gioco sia cambiato così tanto. Non parlo di schematizzare tutto ma solo di fare una sorta di diagramma di flusso striminzito al massimo per capire dove inizia la partita e dove finisce.
redcloud
19-03-2007, 18:19
IMHO sarebbe bello poter generare automaticamente lo schema UML con la build...ma dubito che esista qualche tool adatto...
Io qualche tempo fa usau un plugin per eclipse che generava automaticamente diagrammi UML ma ne veniva fuori un casino intricatissimo e soltanto utilizzando poche classi, non oso immaginare a farlo con Diamonds!
L'unica documentazione UML di Diamonds se non sbaglio la generai automaticamente io da un tool che non mi ricordo come si chiamava...il suo sporco lavoro lo faceva.
Quindi avendo il tool giusto suppongo che si possa fare...
IMHO sarebbe bello poter generare automaticamente lo schema UML con la build...ma dubito che esista qualche tool adatto...
quoto, secondo me si potrebbe pensare di fare l'UML solo se fosse possibile generarlo automaticamente con la build, altrimenti sarebbe tempo sprecato
Sto provando un po' Umbrello...importa il codice correttamente, ma rende le classi disponibili nella palette e non crea le associazioni fra le classi. Boh...
Intendi diagrammi di questo genere?
png, 185kb (http://www.tukano.it/SpriteDependencies.png)
Sì, con cosa l'hai fatto ? Si può implementare in un task ant ?
jappilas
20-03-2007, 10:51
Sì, con cosa l'hai fatto ? Si può implementare in un task ant ?a occhio sembra simile a quello che veniva prodotto da doxygen+graphviz, ma più bello e ordinato... se è un tool batch credo si possa integrare :)
ps: riccardo, ma a che ora scrivi? :eek:
Sì, con cosa l'hai fatto ? Si può implementare in un task ant ?
E' un'estensione di Eclipse che si chiama... NetBeans :D.
NetBeans :D.
Ma ha fatto tutto da solo ? Se ha fatto tutto da solo qualcuno si potrebbe anche prendere la briga di importare il progetto in NetBeans, che so, una volta al mese per realizzare il diagramma UML.
ps: riccardo, ma a che ora scrivi? :eek:
Mi ero addormentato sul divano...dovevo spegnere il computer, quindi ho risposto :)
jappilas
21-03-2007, 11:08
Mi ero addormentato sul divano...dovevo spegnere il computer, quindi ho risposto :)ah ok - temevo facessi come il sottoscritto, con certe sue tirate dalle 9 del mattino alle 3 di notte davati al crt... :D
Ma ha fatto tutto da solo ? Se ha fatto tutto da solo qualcuno si potrebbe anche prendere la briga di importare il progetto in NetBeans, che so, una volta al mese per realizzare il diagramma UML.se l' utilizzo è simile a quello di eclipse potrei provare io... però non in questi giorni (pc soggetto a cancellazione totale) :stordita:
redcloud
21-03-2007, 11:18
Io in questi giorni sto usando NetBeans per altri futili motivi, magari posso dare un'occhiata sotto la supervisione di PGI-Bis :stordita:
Io in questi giorni sto usando NetBeans per altri futili motivi, magari posso dare un'occhiata sotto la supervisione di PGI-Bis :stordita:
Per installare il tool UML ci vuole un attimo. Per generare i diagrammi ce ne vogliono tre o quattro... pure cinque.
Scarica e installa l'enterprise pack per NetBeans (5.5)
http://www.netbeans.info/downloads/index.php?rs=11&p=6
Nel menu di netbeans:
Tools -> update center
scarica Eclipse Project Importer (o una roba così), Subversion e il modulo UML
Importa il workspace di eclipse oppure fai il checkout (dal menu Subversion) e poi importa il progetto (File -> import project -> Eclipse Project -> ...from workspace)
Fai click col pulsante destro sul nome del progetto, scegli properties e controlla che ci sia la cartella dei sorgenti. Se no selezionala a mano.
Fai click col pulsante destro sul nome del progetto, scegli "reverse engineer"
Compare un secondo progetto, xyz-Model. Nel nodo "model" trovi package e classi. Scegli una classe e col pulsante destro puoi generare il diagramma delle dipendenze.
I diagrammi li crea da solo e sono notevoli i sequence, ma il tutto va sincronizzato a manina (nel menù del progetto uml c'è un pulsante "generate model report" che aggiorna tutti i diagrammi). Insomma, è efficace ma non è efficiente.
RaouL_BennetH
21-03-2007, 13:27
Dopo giorni di sbattimenti, finalmente il check out è andato a buon fine, mi ritrovo il mio bel progettino nella home :D
Cmq, per la cronaca, tutti i problemi sono cessati con il cambio della ram.
Resto in attesa di disposizioni :)
RaouL.
Date un'occhiata a questo...anche se implicherebbe probabilmente qualche cambiamento: http://maven-plugins.sourceforge.net/maven-dotuml-plugin/goals.html
Fa parte del origetti Maven di Apache: http://maven.apache.org/
redcloud
21-03-2007, 17:16
Compare un secondo progetto, xyz-Model. Nel nodo "model" trovi package e classi. Scegli una classe e col pulsante destro puoi generare il diagramma delle dipendenze.
Nel nodo model, diagrams ed imported elements non trovo nulla!
Come non detto!
Va bene così? http://www.autistici.org/redcloud/diamonds_dependencies.svg
Ragazzi vi consiglio di provare Omondo. Io l'ho usato per generare diversi diagrammi UML delle mie due tesi di laurea.
http://www.omondo.de/
Si integra con Eclipse.
Un posticino per me c'è? :) Mi piacerebbe svolgere qualche attività di volta in volta. Il mio nick su sourceforge è vifani
Un posticino per me c'è? :) Mi piacerebbe svolgere qualche attività di volta in volta. Il mio nick su sourceforge è vifani sicuro! ti ho aggiunto
jappilas
24-03-2007, 20:11
Un posticino per me c'è? :) Mi piacerebbe svolgere qualche attività di volta in volta. Il mio nick su sourceforge è vifanianche due (come le tue tesi) :)
scherzi a parte scusami per non aver letto il post ieri, se no ti avrei aggiunto io :O
Ragazzi vi consiglio di provare Omondo.stavo valutando LightUML che integrerebbe UMLGraph (quindi Graphviz) in Eclipse, ma ho come l' impressione che non faccia al caso nostro (si appoggia a JavaDoc e adotta un approccio dichiarativo ai diagrammi di relazione e sequenza)
quindi mi sa che mi registrerò su omondo asap...
jappilas
26-03-2007, 22:40
allora, abbiamo bisogno di una sessione di task propedeutici al rientro in opera... pensavo qualcosa del genere:
1) un task di ricerca e traduzione dei TODO scritti in italiano
notavo tra i TODO sparsi nel codice (una ventina se non ricordo male) testi in italiano commenti descrittivi
adesso che siamo su SF l' italiano va bandito da codice, documentazione, nonchè, importante, commit reason , che dovrenno essere scritte in inglese corretto e leggibile
difficoltà bassa, assegnato a: Raoul_Benneth, d' ufficio :D
( l' idea è che in questo modo tu dia un' occhio a parti del codice senza modificare nulla se non il testo dei commenti... e in questo prenda un po' di confidenza col codice assorbendo naming, coding style, sintassi e organizzazione dei package se finora questi aspetti ti appaiono nuovi ed estranei - ti chiedo scusa se ti sembra un task da newbye)
2) un task di documentazione della funzione delle classi, almeno di quelle principali, a livello di responsabilità e interfaccia attualmente implementata
quindi diagrammi di relazione e, mi piacerebbe, di sequenza delle classi, corredati da un minimo di documentazione testuale che verrà aggiunta in un thread sticky qui e nella sezione documentazione su sourceforge
in parte questo dipende dall' esito delle prove che avevo chiesto a VICIUS di fare con lightUML (se non è utile si proverà omondo e se nemmeno quello si rivelerà sufficientemente facile da essere usato con buoni risultati da tutti...)
3) un task di primo riesame dei test e reporting
questo consisterà in una lettura dei test, dire se sono leggibili e comprensibili per quanto riguarda cosa devono testare, e costruire un report comprendente quali test sono poco chiari o hanno più di una assert ciascuno ecc e relazionare
difficoltà media, lungo
3a) leggere e relazionare i test sul ciclo primario
TestGameLoop
TestGameRestartOnGameOver,
(raccomandata una scorsa al codice delle classi coinvolte Game e GameLoop)
4) un task di "auditing" manuale di code path e test
si tratterebbe di fare un confronto tra codice da testare e test, alla ricerca di condizioni e possibili percorsi che i test lasciano scoperti , creando un report e/o modificando direttamente i test
difficoltà medio - alta, lungo
ora, questo stesso post è una stesura preliminare, aspetto commenti per spezzarli in sottotask
redcloud
26-03-2007, 23:18
Mi sembra tutto ok. Potevo fare il task di Raoul ma aspetto i prossimi. Al limite posso dare una mano con i diagrammi UML.
Go go go!!!
4) un task di "auditing" manuale di code path e test
si tratterebbe di fare un confronto tra codice da testare e test, alla ricerca di condizioni e possibili percorsi che i test lasciano scoperti , creando un report e/o modificando direttamente i test
difficoltà medio - alta, lungo
Non avevamo Cobertura per questo ?
jappilas
27-03-2007, 09:56
ehm sì , mi pare ... ma rapporti sulla test coverage non ricordo di averne mai visti generare (sarebbe stato un task di ant?) e non ricordo dove eventualmente venissero salvati - lo ammetto, il mio livello di degenerazione neuronale ultimamente sta oltrepassando il punto critico, quindi ho bisogno che in parte mi aiutiate ad aiutarvi :O
cmq se mi dici come usarlo forse ci risparmiamo un po' di lavoro e possiamo restare al task 3 - il 4 diventerebbe correggere i test carenti
C'è il task di ant, è uno dei due: cover-test o cover-report
RaouL_BennetH
27-03-2007, 13:10
allora, abbiamo bisogno di una sessione di task propedeutici al rientro in opera... pensavo qualcosa del genere:
1) un task di ricerca e traduzione dei TODO scritti in italiano
notavo tra i TODO sparsi nel codice (una ventina se non ricordo male) testi in italiano commenti descrittivi
adesso che siamo su SF l' italiano va bandito da codice, documentazione, nonchè, importante, commit reason , che dovrenno essere scritte in inglese corretto e leggibile
difficoltà bassa, assegnato a: Raoul_Benneth, d' ufficio :D
( l' idea è che in questo modo tu dia un' occhio a parti del codice senza modificare nulla se non il testo dei commenti... e in questo prenda un po' di confidenza col codice assorbendo naming, coding style, sintassi e organizzazione dei package se finora questi aspetti ti appaiono nuovi ed estranei - ti chiedo scusa se ti sembra un task da newbye)
Ma figurati :) Da qualche parte devo pure cominciare :)
Oggi stesso rifaccio il check out (dato che adesso mi funziona tutto).
Ah, una cosa, ci sono scadenze o devo darle io?
Raoul.
jappilas
27-03-2007, 14:40
Oggi stesso rifaccio il check out (dato che adesso mi funziona tutto).ottimo :)
Ah, una cosa, ci sono scadenze o devo darle io?ah sì aspetto importante :)
quando lavoravamo (e lavoreremo) per TDD aggiungendo funzioni o rifattorizzando, solitamente la prassi era (è)
- capire dove si dovrà operare per quello specifico task
- stimare (almeno spannometricamente - certo, più precisione c'è meglio è) un tempo previsto per completare il task, derivante dalla sua difficoltà
- durante lo svolgimento, avvertire di eventuali difficoltà incontrate e/o delle necessità di spostare più in là la "consegna"
ora, siccome è il tuo primo task (quindi mi pare non hai precedente esperienza con il codice), e siccome te l' ho assegnato d' ufficio (proprio per il motivo precedente) prenditi il tempo che ti ci vuole, e "batti un colpo" quando hai finito ;)
anzi, non ti fare problemi a batterne più d' uno se hai dubbi o difficoltà ;)
ti ricordo la modalità di svolgimento
- apri Eclipse e fai il checkout (pare che tu abbia già visto come installare Subclipse - meglio ;))
- apri la Java perspective
- ora, il progetto appena checkoutato non deve avere croci rosse nel "Package Manager" di sinistra (una cosa bella di Eclipse è mostrare a colpo d' occhio che almeno un file contenuto in un package contiene almeno un errore sintattico ...)
- provi una volta Junit e ant (questo è un passo opzionale ma suggerito per farti prendere confidenza con le procedure - anche perchè non so se le hai già viste in precedenza)
selezionando un nodo del source tree (la radice che ha il nome del progetto nel workspace, ma it.diamonds dovrebbe andare bene), cliccando col tasto destro, e selezionando Run As... -> Junit Test
i test vengono eseguiti nel pannello che di default è vicino al package manager, aprilo - dovresti vedere la famigerata barra di Junit restare verde o al più diventare rossa per soli warning ( sulla mia copia ci sono 4 failures dovuti a warning - puoi ignorarli)
non ci devono essere nè segnalazioni di errori sintattici aperti nè test che falliscono (quando sono dei test a fallire, appaiono nel pannello di junit sopra l' errore che hanno sollevato)
nel Package Manager cerchi build.xml (è nella root del progetto, mostrato dopo i package e le librerie), lo selezioni, clicchi col tasto destro, e selezioni Run As - > Ant Build
e nella Console osservi l' avanzamento dei task di ant (prima compilazione, poi checkstyle, poi di nuovo i test) e la sua terminazione con un bel "BUILD SUCCESSFUL" blu
- se già non presente (ma se non erro dovrebbe apparire vicino alla console in basso ) aggiungi la vista "Tasks"
( menu Window - > Show View -> Other ... e nella finestra che si apre: Basic > Tasks)
- ti metti a caccia di TODO da tradurre
scrivi solo nei commenti, traduci quelli in italiano
già che ci sei:
prendi nota di eventuali TODO espressi in una forma poco chiara, o associati a pezzi di codice a loro volta inattivi (tra /*****/ , quindi mostrati in verde da Eclipse) o qualsiasi altra cosa che non capisci
"ti guardi intorno": prendi qualche attimo per osservare il codice che circonda il TODO o eventuali altri commenti, e per dare un' occhiata al pannello a destra dell' editor del codice (Ouline) , che contiene variabili e metodi membro della classe in cui ti trovi - osserva, senza cercare di capire "cosa fa", lo stile e il criterio seguito per dare i nomi a funzioni e metodi, per spezzettare funzioni lunghe in altre piccole maneggevoli
anche se non tutto il codice di DC è perfetto, ci sono dei punti dove rimane indicativo degli intenti per cui è nato ;)
- quando hai tradotto tutti i TODO, ripeti (più per scrupolo che altro - l' importante è che non ci siano differenze rispetto lall' esecuzione precedente) Junit e Ant dopodichè committi i file modificati
;)
PS: @ all: cmq i warning li toglierei asap :rolleyes:
ho scritto i task in inglese nel task manager di sf ^^
quello di raoul l'ho anche assegnato :P
però tocca stabilire per ciascuno una data di fine (per ora ho lasciato oggi come data di fine)
ehm, ribadisco... datemi delle scadenze :|
(andiamo bene, già scomparsi tutti °__° )
RaouL_BennetH
28-03-2007, 11:39
Io ci sono :)
Per darti una scadenza precisa sto ravanando nei sorgenti per il task che mi è stato assegnato. Anche se so che il mio nn è un task vitale, non per questo lo sto sottovalutando :)
A breve una coscienziosa sentenza :O (mi riferisco che vi do la scadenza del mio task :D )
intanto come valore orientativo metto... uhm, un paio di settimane?
jappilas
28-03-2007, 16:18
Io ci sono :):)
per darti una scadenza precisa sto ravanando nei sorgenti per il task che mi è stato assegnato.suggerimento: non è necessario ravanare ;)
fai così
- effettui le operazioni preliminari (checkout > junit > ant ) e controlli che già queste non ti diano problemi (risolvere i problemi che si incontrano a metà stada prende ulteriore tempo) e guardi quanto impieghi
- guardi la lista dei tasks nel pannello di eclipse (se non ricordo male erano circa una ventina)
- fai doppio click sul primo, l' editor salta alla sezione relativa del codice
- traduci il commento TODO (che è quello che eclipse interpreta come TASK e aggiunge al pannello)
- ti guardi intorno scrollando l' editor e il pannello Outline, leggendo con calma...
provi fare caso al naming di funzioni e variabili lì intorno, ai metodi delle classi (per farti un' idea almeno parziale di cosa "tratta" la classe in cui ti trovi)
- guardi quanto tempo hai impiegato e passi al successivo
una stima del tempo del task la hai moltiplicando per 30 il tempo che hai impiegato sulla singola scritta/osservazione e aggiungendo il doppio del tempo richiesto per le operazioni preliminari (che ripeterai prima di concludere il task)
;)
Anche se so che il mio nn è un task vitale, non per questo lo sto sottovalutando :)tutti i task sono importanti - anche se non lo sembra, questo lo è più di altri (nell' ottica "della squadra" più che in quella del codice in senso stretto) :)
EDIT : vorrei che quando hai finito postassi qui l' impressione che hai avuto come primo impatto e qualsiasi perplessità ;)
Appena torno a casa (sono a Milano per lavoro) mi faccio un task. Penso di tornare il 5 Aprile. Un po di pazienza ;)
jappilas
29-03-2007, 14:44
Appena torno a casa (sono a Milano per lavoro) mi faccio un task. Penso di tornare il 5 Aprile. Un po di pazienza ;)
ottimo :)
jappilas
29-03-2007, 15:09
piuttosto, chi ha scritto il LayerTestCase e non ha fatto girare nè Ant nè junit prima di committare?
albertooooo... dai non aver paura, non ti farà male... :D
e poi si tratta solo del mignolo sinistro, puoi farne anche a meno... :O :asd:
raoul: mi scuso perchè ho permesso che la build si sporcasse, devo chiederti di fermarti, aspettare che il prob sia risolto e riprendere facendo prima team-> update nel menu di eclipse :O
RaouL_BennetH
29-03-2007, 17:24
Va benone :)
Ma in genere, cosa si fa in questi casi?
Non ci dovrebbe sempre essere una `previous version` sempre pulita?
Grazie.
RaouL.
piuttosto, chi ha scritto il LayerTestCase e non ha fatto girare nè Ant nè junit prima di committare? ma veramente io JUnit lo faccio girare sempre... :|
per Ant chiedo pietà, non so come si usa e non l'ho ancora configurato nel workspace di Eclipse :cry:
ok, ho aggiustato tutto :D :D
(dovrei... O.o' )
jappilas
29-03-2007, 22:02
fatto update, ho questi 5 errori nel test runner :
testItemsAreDrawnInOrder(it.diamonds.tests.engine.TestLayer)
junit.framework.AssertionFailedError: expected:<2> but was:<1>
testLayersAreDrawnInOrder(it.diamonds.tests.engine.TestLayerManager)
junit.framework.AssertionFailedError: expected:<2> but was:<1>
testOpaqueLayersAreDrawnBefore(it.diamonds.tests.engine.TestLayerManager)
junit.framework.AssertionFailedError: expected:<2> but was:<1>
testNullExtraction(it.diamonds.tests.engine.input.TestInput)
java.util.NoSuchElementException
testTextureCannotbeNull(it.diamonds.tests.engine.video.TestSprite)
junit.framework.AssertionFailedError: exception not raised ora, non essendo cambiato il codice ma solo i test, il problema è solo in questi ultimi :O
bisogna sistemarli al più presto, spero sia evidente l' importanza del buon funzionamento della procedura "green bar in junit seguita da ant con BUILD SUCCESSFUL", a maggior ragione per introdurre membri meno esperti al modo di lavorare del progetto ;)
jappilas
29-03-2007, 23:00
Ho avuto anch'io problemi con ant, fino a che non ho ripensato che avevo rifatto il checkout dal repo di sourceforge come nuovo progetto nel workspace in Eclipse, quindi le impostazioni delle Run e Build erano quelle di default da modificare
ant ha bisogno che sia impostata una variabile d' ambiente ANT_HOME al path dell' eseguibile (<dir di Eclipse>/plugins/org.apache.ant_1.6.5/, nel mio caso): l' anno scorso l' avevo fatto a mano , ma si può impostare anche nel pannello delle impostazioni che si apre cliccando col destro sul file build.xml e selezionando "Ant Build..." e poi la tab Classpath
Inoltre ant abbisogna dei file JAR relativi ai task definiti nel file build.xml stesso:
nello stesso pannello di prima, cliccare su "Add JARs" e selezionarli da <directory root del progetto>/lib/
(questo perchè junit, e cobertura erano stati aggiunti al progetto, per cui non è necessario cercarli come External JARs)
ragazzi, appena mi libero un po con gli esami mi metto a lavoro
@jap: ho fatto il checkout e lanciato i test: verdi :|
idem per Ant
ragazzi, appena mi libero un po con gli esami mi metto a lavoro grazie cisc :)
jappilas
30-03-2007, 18:10
ho rifatto checkout di trunk, quindi update, synchronize with repository, e immancabilmente junit mi ritornava queste
testOneItemDrawn(it.diamonds.tests.engine.TestLayer)
java.lang.NullPointerException
testTwoItemsDrawn(it.diamonds.tests.engine.TestLayer)
java.lang.NullPointerException
testItemsAreDrawnInOrder(it.diamonds.tests.engine.TestLayer)
java.lang.NullPointerException
testLayersAreDrawnInOrder(it.diamonds.tests.engine.TestLayerManager)
junit.framework.AssertionFailedError: expected:<2> but was:<1>
testOpaqueLayersAreDrawnBefore(it.diamonds.tests.engine.TestLayerManager)
junit.framework.AssertionFailedError: expected:<2> but was:<1>
testNullExtraction(it.diamonds.tests.engine.input.TestInput)
java.util.NoSuchElementException
testTextureCannotbeNull(it.diamonds.tests.engine.video.TestSprite)
junit.framework.AssertionFailedError: exception not raised
:fagiano:
PS: raoul, per favore, faresti la controprova?
checkout, update, (o solo update) , tasto destro sul nome del progetto > Run As > Junit Test
ho rifatto checkout di trunk, quindi update, synchronize with repository, e immancabilmente junit mi ritornava queste
testOneItemDrawn(it.diamonds.tests.engine.TestLayer)
java.lang.NullPointerException
testTwoItemsDrawn(it.diamonds.tests.engine.TestLayer)
java.lang.NullPointerException
testItemsAreDrawnInOrder(it.diamonds.tests.engine.TestLayer)
java.lang.NullPointerException
testLayersAreDrawnInOrder(it.diamonds.tests.engine.TestLayerManager)
junit.framework.AssertionFailedError: expected:<2> but was:<1>
testOpaqueLayersAreDrawnBefore(it.diamonds.tests.engine.TestLayerManager)
junit.framework.AssertionFailedError: expected:<2> but was:<1>
testNullExtraction(it.diamonds.tests.engine.input.TestInput)
java.util.NoSuchElementException
testTextureCannotbeNull(it.diamonds.tests.engine.video.TestSprite)
junit.framework.AssertionFailedError: exception not raised si ma ti faccio notare che sono diversi da prima :D
Ho gli stessi errori di jappilas, ho fatto il checkout da zero ;)
Ho gli stessi errori di jappilas, ho fatto il checkout da zero ;) mi incolli qui la tua copia di TestLayer.java?
package it.diamonds.tests.engine;
import it.diamonds.engine.video.Layer;
public class TestLayer extends AbstractLayerTestCase
{
private Layer layer;
public void setUp()
{
layer = new Layer();
}
public void testOneItemDrawn()
{
layer.add(sprite);
layer.drawLayer(engine);
assertEquals(1, engine.getNumberOfQuadsDrawn());
}
public void testTwoItemsDrawn()
{
layer.add(sprite);
layer.add(sprite);
layer.drawLayer(engine);
assertEquals(2, engine.getNumberOfQuadsDrawn());
}
// FIXME: eliminare questo test -- e' una funzionalita' non richiesta alla classe
public void testItemsAreDrawnInOrder()
{
layer.add(sprite);
layer.add(otherSprite);
layer.drawLayer(engine);
spriteOrderTestHelper();
}
}
ti ringrazio; ok dovrei aver sistemato :D
il problema era che non vedevo i test che fallivano perché ne eseguivo solo una parte. grazie a jappilas oggi ho imparato che in Eclipse andando su Run -> Run... -> JUnit -> nome della configurazione JUnit -> Test -> Run all tests in the selected project, package or source folder, l'algoritmo di ricerca dei test case non è ricorsivo :muro: :D
per ovviare a questi problemi abbiamo bisogno il prima possibile d'una Build Machine, cosa che ovviamente io non so configurare :help:
Mi quoto per la build machine:
Gente, se intanto volete iniziare e non volete avere tutto quello che permette di fare cruise cotnrol, allora basta mettere su un script su cron che si sincronizza con il repository una volta ogni 5 minuti e dopo, se ci sono stati cambiamenti, fa la build con ant. Dopo basta inviare lo stderr tramite mail alla mailinglist. In alternativa alla mail ci potrebbe essere la pubblicazione dello stderr su un feed RSS (tutto fattibilissimo tramite shell).
E' uno script della shell, tra l'altro anche molto semplice...
Quindi basta che qualcuno abbia una macchina sempre online...il carico sulla macchina sarebbe minimo.
La struttura potrebbe essere molto semplice:
#aggiorno la copia locale con svn
svn ......
#eseguo ant
ant task (non mi ricordo quale) 2>&1 1>outfile.txt
se il valore di ritorno di ant è diverso da 0 allora invio outfile.txt tramite il comando mail sulla mailing list, altrimenti si invia una mail che comunica che la build ha avuto successo
jappilas
31-03-2007, 12:08
ti ringrazio; ok dovrei aver sistemato :Dbene :)
piccola osservazione: facendo update, ho ricevuto nuove versioni di file Java sia dei test sia di parti del codice
(il problema dell' altro giorno era emerso dalla riscrittura di TestLayer, quindi la soluzione riguarda solo la stesura dei test - spero che le modifiche al codice fossero solo refactoring invarianti rispetto al testing a scatola nera della classe stessa e quindi indipendenti dal problema :O)
comunque vorrei che per il futuro anche i commit siano il più possibile atomici (un "task" - che sia un debug o un refactoring - alla volta) ;)
per ovviare a questi problemi abbiamo bisogno il prima possibile d'una Build Machine, cosa che ovviamente io non so configurare :help:http://www.pragmaticprogrammer.com/starter_kit/au/scheduled.pdf
E' uno script della shell, tra l'altro anche molto semplice... avessi unix e/o una macchina accesa 24/7...:p
RaouL_BennetH
02-04-2007, 15:31
Ciao ragazzi :)
Se faccio il check out adesso, ho una versione `pulita` sulla quale lavorare al mio task?
Grazie.
RaouL.
jappilas
02-04-2007, 16:30
Ciao ragazzi :)
Se faccio il check out adesso, ho una versione `pulita` sulla quale lavorare al mio task?rifai checkout se non hai ancora il progetto nel workspace di Eclipse , altrimenti dovrebbe bastare fare l' update (click col destro sul nome > team > update) e nella console (c'è una lista delle "console", devi selezionare SVN esplicitamente per vederla) dovrebbe darti "at revision 14"
quindi , Junit (desto sulla root del progetto > run as > junit test ), ant (destro su build.xml > run as > ant build) e vedi la barra verde e la build successful (se hai problemi con junit e ant sono qui fino alle 21 circa)
al che ... vai e attacca quei todo! :D
a proposito: jap, ho dato una letta a quel pdf su come impostare una build machine; veramente interessante! :)
quando ho tempo mi metto d'accordo con antaz e cerco di configurare CruiseControl via VNC. dalla lettura del pdf non mi è sembrato tanto più difficile del fare lo script con cron.
jappilas
02-04-2007, 20:54
a proposito: jap, ho dato una letta a quel pdf su come impostare una build machine; veramente interessante! :)
quando ho tempo mi metto d'accordo con antaz e cerco di configurare CruiseControl via VNC. dalla lettura del pdf non mi è sembrato tanto più difficile del fare lo script con cron.no infatti, e poi è spiegato molto passo passo... :)
"oggi tutti ci consigliano di non rompere e cercare su google qualsiasi cosa
immagino un bimbo che chiede al papà:
"Papà, come sono nato io?......e il papà:"cerca su google...." e così venne la pubertà :asd:
però il papà dovrebbe anche specificare che per ottenere risultati esplicativi bisogna disattivare il SafeSearch... :asd:
RaouL_BennetH
03-04-2007, 11:15
:muro: :cry:
svn: REPORT request failed on '/svnroot/diamondcrush/!svn/vcc/default'
svn: Processing REPORT request response failed: required string: "D:checked-in" (/svnroot/diamondcrush/!svn/vcc/default)
Con il risultato che non mi fa finire il checkout :mc:
jappilas
04-04-2007, 12:17
:muro: :cry:
svn: REPORT request failed on '/svnroot/diamondcrush/!svn/vcc/default'
svn: Processing REPORT request response failed: required string: "D:checked-in" (/svnroot/diamondcrush/!svn/vcc/default)
Con il risultato che non mi fa finire il checkout :mc:
scusa se non ho risposto prima...
uhm, è da ieri che penso a quest' errore, googlando ovunque o spulciando anche nel manuale di subversion non se ne parla quasi mai esplicitamente, tranne che su alcuni newsgroup
sei dietro a un proxy?
Most likely your http traffic goes through a proxy that does not support the full range of commands required for svn / webdav.
Using https bypasses the proxy.
RaouL_BennetH
04-04-2007, 13:15
scusa se non ho risposto prima...
uhm, è da ieri che penso a quest' errore, googlando ovunque o spulciando anche nel manuale di subversion non se ne parla quasi mai esplicitamente, tranne che su alcuni newsgroup
sei dietro a un proxy?
Ciao jappilas :)
No, non sono dietro un proxy :(
Ma deduco quindi che il problema è solo mio. Ok, provo a rifare tutta la configurazione da zero.
jappilas
11-04-2007, 16:50
Il fatto che non abbia più postato non vuol dire che mi sia dimenticato di questo thread ...
Ma deduco quindi che il problema è solo mio. Ok, provo a rifare tutta la configurazione da zero.qualche progresso? ;)
RaouL_BennetH
12-04-2007, 19:59
Il fatto che non abbia più postato non vuol dire che mi sia dimenticato di questo thread ...
qualche progresso? ;)
Si :)
Non ho più il problema del check out, solo un problema di "path" quando lancio ant. Ma per questo sto già provvedendo. Credo di sistemare al max per domani pomeriggio i problemi relativi all'ambiente di lavoro, e fra sabato e domenica una buona parte del mio task.
jappilas
13-04-2007, 17:32
Si :)
Non ho più il problema del check out, solo un problema di "path" quando lancio ant. Ma per questo sto già provvedendo. Credo di sistemare al max per domani pomeriggio i problemi relativi all'ambiente di lavoro, e fra sabato e domenica una buona parte del mio task.
mi rendi felice ( :sob: -> :) )
RaouL_BennetH
20-04-2007, 13:16
Ragazzi, io ho quasi terminato tutti i TODO che ho trovato. Forse riesco a finire entro stasera. Dopo mi basta solo fare il commit o c'è altro che devo sapere?
Grazie :)
RaouL.
Ragazzi, io ho quasi terminato tutti i TODO che ho trovato. Forse riesco a finire entro stasera. Dopo mi basta solo fare il commit o c'è altro che devo sapere?
Quando lavori su molti file non fare un commit tutto insieme...altrimenti rischi di trovarti di fronte a casini se nel frattempo qualcuno ha aggiornato i file... Infatti, passi per la situazione dei todo, ma in molti casi fare un merge non è così agevole (ne so qualcosa io con il refactoring del timer 5 ore buttate al vento)...
Quindi imho quando hai finito un singolo file fai il commit...
In generale quando lavori sul codice, appena il codice è consistente (il codice compila, termina la build e i test funzionano tutti), allora fai il commit...anche se non hai finito il tuo task...
jappilas
21-04-2007, 13:24
Ragazzi, io ho quasi terminato tutti i TODO che ho trovato. :)Forse riesco a finire entro stasera. Dopo mi basta solo fare il commit o c'è altro che devo sapere? oltre al consiglio di riccardo, e a controllare che il codice sia consistente (che la compilazione con ant non fallisca) credo non ci sia altro che debba dirti per ora
invece, vorrei che parlassi tu - a rapporto! :D
seriamente, gli obiettivi (primari ma nascosti ) di questo task erano farti prendere un po' di confidenza con la forma e la struttura del codice, e con la procedura, nonchè avere le tue impressioni, in modo da chiarire con ordine e a beneficio di tutti ogni perplessità che possano derivare dal primo impatto col codice stesso ;)
RaouL_BennetH
21-04-2007, 14:24
Eccomi :)
Allora, meno male che non ho fatto il commit "globale" con tutte le correzioni che avevo fatto ai todo . Lo dico perchè essendo un cocciuto curiosone, ho fatto qualche piccolo casotto su 'vere' righe di codice (ma non mi sarei mai permesso di fare il commit! giuro!)). :D
Per quanto riguarda la fine e il commit del task, posso darvi garanzia al 100% per mercoledi. Oggi e domani sono incasinato con lo studio (a breve inonderò la sezione programmazione di mille mila post di richieste di aiuto) e lunedi e martedi non ci sono. Dato che ho praticamente finito ( a parte risistemare quel codicillo che per pura follia ho deciso di sabotare.....) mercoledi è la giornata ideale per la terminazione del mio compito.
RaouL.
P.S.: per me è ancora prematuro poter esprimere delle impressioni a riguardo. Per questo mi servirebbe un pò più di tempo :)
jappilas
23-04-2007, 16:19
Eccomi :)
Allora, meno male che non ho fatto il commit "globale" con tutte le correzioni che avevo fatto ai todo . ottimo, allora aspetta prima di committare - tanto non c'è fretta ;)
Lo dico perchè essendo un cocciuto curiosone, ho fatto qualche piccolo casotto su 'vere' righe di codice (ma non mi sarei mai permesso di fare il commit! giuro!)). :Dno problem, capita a tutti ;)
più che altro, è importante che ti ricordi qual' è il file incriminato? ...
Dato che ho praticamente finito ( a parte risistemare quel codicillo che per pura follia ho deciso di sabotare.....) ... perchè in questi casi revert is your friend :O
in Eclipse puoi revertare il singolo file (nel Package explorer : click tasto destro sul file, team -> revert... , dopodichè ti chiede conferma dei file da salvare se ci sono modifiche in sospeso, dopodichè ti chiede ti chiede conferma dei file da revertare tra quelli selezionati)
consiglierei di fare così :
copiaincolla da qualche parte del contenuto del file .java in questione (ctrl+a) , revert, e nuovo copiaincolla dei soli TODO che avevi tradotto
dopodichè, ANT e se passa puoi committare ;)
P.S.: per me è ancora prematuro poter esprimere delle impressioni a riguardo. Per questo mi servirebbe un pò più di tempo :)no problem, però ci tengo ;)
RaouL_BennetH
26-04-2007, 10:10
:( Avevo fatto una stima troppo ottimistica per ieri. Chiedo venia. Faccio il possibile per terminare in giornata.
RaouL.
allora ragazzi, pensavo di avere più tempo libero, ma ovviamente i miei calcoli erano sbagliati:|...tra esami, progetti e tesi, fino ad agosto in pratica è come se non ci fossi, ora, lascio a voi decidere di togliermi dai developer del progetto, e magari quando tornerò operativo riaggungermi, o tenermi così per numero=) mi dispiace:(
redcloud
02-05-2007, 20:46
Tranquillo, ci sono io a coprirti ;) A tal proposito faccio due domande al coach:
-sono contenuti in testcase non corrispondenti 1:1 (nel senso di nome e/o ripartizione per package) alle classi da testare
Me lo spieghi con un esempio?
Intanto sto finendo questo
-sono troppo complessi (devi intuire cosa facciano solo guardandoli, pur non conoscendo nei dettagli il codice che chiamano),
ma per questo
-contengono ridondanze
(nel senso: il test T1 esegue delle istruzioni che portano dallo stato iniziale costruito da setUp() a uno stato "S1" e fa asserzioni su questo,
poi il test T3 contiene il codice T1 per arrivare allo stato S1 e testarlo, per poi portarsi in un nuovo stato S4 e testare questo
in casi simili ci saranno asserzioni ridondanti perchè lo stato S0 è testato da T1 e dovrebbe essere suff. questo)
devo alzare bandiera bianca, non lo comprendo ancora bene :help:
jappilas
02-05-2007, 21:40
lascio a voi decidere di togliermi dai developer del progetto, e magari quando tornerò operativo riaggungermi, o tenermi così per numero=) mi dispiace:(diciamo che mi spiace che nemmeno tu abbia tempo per lavorare a DC, ma dalla lista non esci di sicuro :)
ah, approfitto per dare un update che causa stress mi era passato di mente in questi giorni
redcloud aveva cominciato a lavorare al task del controllo manuale dei test - scopo del quale è ottenere una lista dei test che:
-sono troppo lunghi (se vedi più di 8 - 9 righe di codice per un test ci sono ottime possiblità che debba essere riscritto), - fatto
-hanno if o altri costrutti condizionali, - fatto
-sono contenuti in testcase non corrispondenti 1:1 (nel senso di nome e/o ripartizione per package) alle classi da testare
-sono troppo complessi (si deve poter intuire cosa facciano solo guardandoli, pur non conoscendo nei dettagli il codice che chiamano)
-contengono ridondanze (in pratica se il code path di un test arriva nello stesso "stato" già coperto dalla assert di test precedente e lo ritesta prima di proseguire verso un nuovo stato, cosa che AFAIK avviene in certi test in cui si era replicato il corpo di quelli precedenti) - più laborioso, sarebbe benvenuto un volontario per svolgere questo check in parallelo
RaouL_BennetH
04-05-2007, 13:36
Non so perchè insisto a voler utilizzare tutto da linux, non che sia linux il problema ma sono io che non so usarlo. Ecco quello che succede ora quando lancio ant:
BUILD FAILED
/home/raoul/workspace/Diamonds/build.xml:128: Could not create task or type pf type: junit
Ant could not find the task or a class this task relies upon
This is common and has a number of causes; the usual solutions are to read
the manual pages then download and install needed JAR files, or fix the build file:
//blablabla
Ma.... quel jar io lo ho:
/home/raoul>locate junit.jar
/home/raoul/workspace/Diamonds/lib/cobertura/lib/junit/3.8.1/junit.jar
/home/raoul/workspace/Diamonds/lib/cobertura/lib/junit/3.8.1/.svn/prop-base/junit.jar.svn-base
/home/raoul/workspace/Diamonds/lib/cobertura/lib/junit/3.8.1/.svn/props/junit.jar.svn-work
/home/raoul/workspace/Diamonds/lib/cobertura/lib/junit/3.8.1/.svn/text-base/junit.jar.svn-base
/home/raoul/workspace/Diamonds/lib/junit.jar
/usr/share/ant/lib/ant-junit.jar
/usr/share/ant/lib/junit.jar
/usr/share/eclipse/plugins/org.apache.ant_1.6.5/lib/ant-junit.jar
/usr/share/java/ant-junit.jar
/usr/share/java/junit.jar
:help:
jappilas
04-05-2007, 14:16
ciao
Non so perchè insisto a voler utilizzare tutto da linux, non che sia linux il problema ma sono io che non so usarlo. credo non c' entri linux, dopo aver rifatto il checkout da sourceforge ho avuto anch'io quel problema
Ecco quello che succede ora quando lancio ant:
<cut>
:help:in Eclipse, click tasto destro sul nome del progetto nel PackageEditor -> Run As...
nella finestra Run:
dalla lista di configurazioni, cerca quella del progetto sotto Junit, vai al pannello ClassPath e apri le User entries
controlla che sia presente junit.jar, se non c'è (come penso) clicca su Add JARs e aggiungila a mano
poi riprova Junit e guarda se ti ridà l' errore
PS: c'è una cosa che mi preme... devi essere sicuro al 200% che il codice editato per sbaglio sia tornato esattamente come prima ;)
RaouL_BennetH
04-05-2007, 16:17
cut..
PS: c'è una cosa che mi preme... devi essere sicuro al 200% che il codice editato per sbaglio sia tornato esattamente come prima ;)
Si, tieni presente che da quando feci quel casino ho rasato al suolo tutto il sistema due volte (ma non per eclipse ovviamente ma per problemi vari). Quindi ho rifatto il checkout 'pulito'.
Grazie mille per il suggerimento, lo faccio subito :)
RaouL_BennetH
04-05-2007, 16:35
ho appena fatto il controllo ma.. :(
junit.jar è presente. Questo è quello che ho nelle user entries:
Diamonds(default classpath)
Diamonds
junit.jar - /Diamonds/lib/
lwjgl.jar - /Diamonds/lib/jar
lwjgl_devil.jar - /Diamonds/lib/jar
lwjgl_util.jar - /Diamonds/lib/jar
jorbis-0.0.15.jar - /Diamonds/lib/jar
trb.jar - /Diamonds/lib/jar
jogg-0.0.7.jar - /Diamonds/lib/jar
jappilas
04-05-2007, 19:47
ho appena fatto il controllo ma.. :(
junit.jar è presente. Questo è quello che ho nelle user entries:
...
uhm, è uguale al mio :p
vediamo, cosa potrebbe mancare (eppure, una volta installato il JDK, scompattato Eclipse , aggiunto subclipse e fatto checkout, ricordo di aver fatto pochissimo "setup" addizionale... ricordo due variabili d' ambiente, gli argomenti alla JVM (*), appunto controllare il classpath e mi pareva non ci fosse altro... :wtf: )
* : in Run... > [nome progetto] > linguetta Arguments > casella VM Arguments la stringa
-Djava.library.path=lib/win32
se nemmeno così funziona, non saprei... sarà davvero colpa di linux :stordita: (scherzo ;) )
jappilas
05-05-2007, 19:04
Tranquillo, ci sono io a coprirti ;) A tal proposito faccio due domande al coach:scusami, mi ero dimenticato di rispondere a questo :(
-sono contenuti in testcase non corrispondenti 1:1 (nel senso di nome e/o ripartizione per package) alle classi da testareallora: l' idea era, che per avere una code base ordinata, la gerarchia dei test segua più o meno quella delle classi che i test, testano concretamente
ora, non è detto che debba obbligatoriamente esserci una corrispondenza perfetta tra classi di codice e classi test, ma vedere quali classi non hanno un corrispondente test e quali test testano classi messi in package non corrispondenti nella gerarchia (*) possa servire per il successivo riordino (dei test e del codice)
(*) gerarchia intendo quella nel namespace dei package, in cui le "root" sarebbero it.diamonds per le classi di codice e it.diamonds.tests per i tests
Me lo spieghi con un esempio?certo,
in it.diamonds.tests c'è TestPlaybackLoop che non va a testare nessuna classe sotto it.diamonds;
sempre in it.diamonds.tests c'è TestMainMenu che va a testare la sola classe MainMenu che però si trova in it.diamonds.menu
in it.diamonds.grid.state ci sono 13 classi e it.diamonds.tests.grid.state 9, il che vuol dire che qualcuna non avrà un "proprio" test - si possono vedere quali
ecc ecc
dettagli di questo genere una volta acquisiti possono essere e saranno comparati con i risultati sulla test coverage prodotti da una build in cui si attivi il task di cobertura ;)
Intanto sto finendo questo
-sono troppo complessi (devi intuire cosa facciano solo guardandoli, pur non conoscendo nei dettagli il codice che chiamano), ottimo :)
ma per questo
<cut>
devo alzare bandiera bianca, non lo comprendo ancora bene :help:ti chiarisco anche questo con un esempio : prendi TestGameLoop in it.diamonds.tests, e scorrilo fino a 4 /5 circa , troverai
public void testSelectVersusModeMenuItem() throws IOException
{
assertFalse("The GameLoop must be stopped", gameLoop.inGameLoop());
assertFalse("The Menu Loop must be running", gameLoop.isMenuFinished());
gameLoop.menuLoop();
MainMenu mainMenu = gameLoop.getMainMenu();
mainMenu.selectMenuItem(MenuItem.VERSUS_MODE);
gameLoop.notify(Event.create(Code.KEY_ENTER, State.PRESSED));
gameLoop.notify(Event.create(Code.KEY_ENTER, State.RELEASED));
assertTrue("The MenuAction method must have been entered",
mainMenu.wasMenuActionEntered());
assertTrue("The MenuAction must have returned successfully",
gameLoop.checkMenuActionExecuted());
assertTrue("The Menu Loop must be stopped", gameLoop.isMenuFinished());
assertFalse("The GameLoop must be running", gameLoop.isFinished());
gameLoop.initBeforeGameLoop();
assertTrue("The GameLoop must be running", gameLoop.inGameLoop());
}
le prime asserzioni in blu sono in eccesso (sia nel senso che il test è troppo lungo, sia nel caso in cui già un altro test copra lo stato iniziale - vedi dopo) se fatte all' inizio del test, perchè testano lo "stato" della classe come il metodo setUp() che crea l' ambiente di esecuzione dei testcase, lo ha lasciato - non ha molto senso fare asserzioni all' inizio di un test , soprattutto se poi altri test (come testSelectQuitMenuItem() ) iniziano di nuovo con quelle stesse asserzioni...
ritestano lo stato iniziale, laddove la cosa migliore sarebbe avere "in testa" un test che verifichi appunto quello e solo quello ...
se pensi che ogni metodo di test è in pratica un frammento di una macchina a stati, con le assert corrispondenti agli stati e le altre righe di codice agli "archi" di connessione tra gli stati, e applichi agli "stati" successivi il criterio di cui sopra, ti dovrebbe essere più facile entrare nell' ottica di vedere se un test ripercorre gli stessi stati di un altro, e le eventuali assert in comune (che a questo punto saranno ridondanti in uno o nell' altro)
redcloud
14-05-2007, 12:01
Voglio solo far presente che sto lavorando, un po' per volta ma lo sto facendo, abbiate pazienza!
jappilas
14-05-2007, 14:12
Voglio solo far presente che sto lavorando, un po' per volta ma lo sto facendo, abbiate pazienza!ottimo
stavo pensando : svolgi intanto i primi due punti, lascia per ultimo quello in cui si parlava di "stati"
per quello si cerca qualcuno che ti affianchi ;)
^TiGeRShArK^
14-05-2007, 15:56
eccomi :O
non riesco a scrivere su msn :muro:
quando torno a casa se non vado in palestra vediamo ke si pò 'ffà :O
Ragazzi come le assegnate le attività? Ben presto potrei richiederne una.
jappilas
26-05-2007, 14:37
Ragazzi come le assegnate le attività? Ben presto potrei richiederne una.per adesso avevo pensato a dei task di riesame (dei test) che facilitassero l' introduzione di nuovi elementi volenterosi, avvicinandoli al codice in modo (relativamente) poco traumatico - e pensavo di tenere per dopo un ciclo di refactoring, seguito dall' introduzione del netplay, la quale cosa consisterà nell' integrazione di un protocollo che andrebbe progettato per tempo, del menu e di alcune cosine...
il fatto che non si siano più fatti vivi mi fa pensare che abbiano bisogno di aiuto, avresti mica voglia di dare un' occhiata alle asserzioni ridondanti nei test ? ;)
redcloud
27-05-2007, 12:14
-sono troppo lunghi (se vedi più di 8 - 9 righe di codice per un test ci sono ottime possiblità che debba essere riscritto), - fatto
-hanno if o altri costrutti condizionali, - fatto
-sono contenuti in testcase non corrispondenti 1:1 (nel senso di nome e/o ripartizione per package) alle classi da testare - working
-sono troppo complessi (si deve poter intuire cosa facciano solo guardandoli, pur non conoscendo nei dettagli il codice che chiamano) - working
-contengono ridondanze (in pratica se il code path di un test arriva nello stesso "stato" già coperto dalla assert di test precedente e lo ritesta prima di proseguire verso un nuovo stato, cosa che AFAIK avviene in certi test in cui si era replicato il corpo di quelli precedenti) - più laborioso, sarebbe benvenuto un volontario per svolgere questo check in parallelo
Ragazzi, l'ultimo non riesco a farlo per questioni di tempo. Sto completando il 3 e 4. Se qualche volenteroso vuole cominciare con il 5...
Ragazzi, l'ultimo non riesco a farlo per questioni di tempo. Sto completando il 3 e 4. Se qualche volenteroso vuole cominciare con il 5... committa non appena arrivi ad uno stato più o meno coerente; la build verde è un ottimo indice di "stato più o meno coerente" :p, percui se è già verde committa, sennò falla tornare verde al più presto.
jappilas
27-05-2007, 13:54
committa non appena arrivi ad uno stato più o meno coerente; la build verde è un ottimo indice di "stato più o meno coerente" :p, percui se è già verde committa, sennò falla tornare verde al più presto.fortunatatamente il suo task consiste nel leggere il codice senza modificare alcunchè (per ora) :p
il task deve produrre dei documenti che saranno postati qui o inviati ai membri del team - in modo che poi si discuta l' eventuale refactoring della batteria di test ... c'è poco da committare :stordita:
fortunatatamente il suo task consiste nel leggere il codice senza modificare alcunchè (per ora) :p
il task deve produrre dei documenti che saranno postati qui o inviati ai membri del team - in modo che poi si discuta l' eventuale refactoring della batteria di test ... c'è poco da committare :stordita:
Ah ma quindi le modifiche ai test le sta facendo solo su carta?
jappilas
28-05-2007, 17:18
sì, o meglio ni: non deve nemmeno fare modifiche ai test per ora... ma cercare ed elencare i test che non rispettano i criteri qualitativi del progetto (che vogliono codice autoesplicativo, metodi minimi, ridondanze ridotte o meglio nulle...)
ad esempio, la lista allegata contiene i test più lunghi di 10 righe e quelli contenenti if (complessità ciclomatica >1) - si potrebbe iniziare a mettere mano a quelli :)
sì, o meglio ni: non deve nemmeno fare modifiche ai test per ora... ma cercare ed elencare i test che non rispettano i criteri qualitativi del progetto (che vogliono codice autoesplicativo, metodi minimi, ridondanze ridotte o meglio nulle...)
ad esempio, la lista allegata contiene i test più lunghi di 10 righe e quelli contenenti if (complessità ciclomatica >1) - si potrebbe iniziare a mettere mano a quelli :)
Si ma scusate che vuol dire "si potrebbe" ? Se si deve lavorare, bisogna modificare ed effettuare la commit. Vediamo di essere un pochino più concreti. Oppure ditemi chiaramente cosa volete che sia fatto: un file txt come quello appena proposto? una modifica con commit ai test?
jappilas
28-05-2007, 22:20
Si ma scusate che vuol dire "si potrebbe" ? Se si deve lavorare, bisogna modificare ed effettuare la commit. indubbiamente, e chi vorrà farlo lo farà
il "ciclo" attuale in pratica si chiama "refactoring dei test", quindi si prevede che il codice dovrebbe subire modifiche di un certo livello
l' obiettivo ( mio, finora non messo in discussione ma sempre discutibile ;)) consiste nel rendere i metodi contenuti nei testcase ( per dirne uno, TestGameLoop.java, che mi balzò all' occhio quando pensai di rivedere il loop principale tempo fa) più semplici, atomici e sequenziali, e al tempo stesso aumentare la test coverage - cosa che, essendo ottenuta attraverso test con una sola asserzione ciascuno, in pratica può significare sostituire quelli attuali con altri (più numerosi) scrivendo, in ultima analisi, parecchio codice
solo, avevo pensato a un task che anche qualcuno con meno dimestichezza con la code base avrebbe potuto svolgere limitandosi al reporting, senza il timore di "rompere qualcosa" modificando e committando e senza il peso della relativa responsabilità - ma questo non è una limitazione per chi avesse voglia di lavorare direttamente al codice
Vediamo di essere un pochino più concreti. Oppure ditemi chiaramente cosa volete che sia fatto: un file txt come quello appena proposto? una modifica con commit ai test?quindi rifattorizza pure i test che non rispettano i criteri indicati più addietro (rispondo a te ma vale per tutti)
solo, vorrei che il refactoring fosse discusso pubblicamente qui il più possibile, e almeno, il commit preceduto da un "punto della situazione" sui test coinvolti e sulle modifiche apportate ( questo soprattutto per tenere traccia dello stato di avanzamento del lavoro ed evitare sovrapposizioni qualora altri si mettano a lavorare )
spero la mia risposta non sia troppo insoddisfacente - e mi dispiace che sia tardiva, ultimamente sono malaticcio oltre che esaurito (quello sempre) :stordita:
spero la mia risposta non sia troppo insoddisfacente - e mi dispiace che sia tardiva, ultimamente sono malaticcio oltre che esaurito :stordita:
La risposta è soddisfacente. Io però punterei oltre che a snellire i test, anche a snellire lo sviluppo. Mi spiego: sono mesi che si parla di rifattorizzare i test solo che a me sembra che si sia perso l'obiettivo finale di tutto il progetto e cioè sviluppare e completare il gioco. Insomma ho l'impressione che si siano concentrare le forze esclusivamente sul discorso "usiamo i test case, ecc...", quindi più da un punto di vista didattico che pratico ed il risultato che è stiamo dedicando un tempo immane per fare test, rifattorizzare test, far superare i test, ecc... ma passi in avanti dal punto di vista delle funzionalità del gioco non ne sono stati fatti. Insomma il tutto in barba all'agile development che qui teoricamente stiamo usando, ma che di fatto di agile mi sembra che ci sia stato ben poco visti i risultati ottenuti.
Detto questo darò un'occhiata ai test segnalati in quel file e proporrò le modifiche/split che troverò più opportuni.
Da una prima analisi sembra che effettivamente ci sia una ridondanza mostruosa dei test. In alcuni casi sembra che i test siano stati sviluppati in modo incrementale, dove cioè test successivi testano anche tutto ciò che è precedentemente testato da altri test. Tra qualche giorno vi posto l'elenco delle modifiche proposte.
redcloud
05-06-2007, 23:34
In allegato trovate le ultime modifiche. Nei commenti "// Troppo complicato" trovate segnalati i metodi che SECONDO ME sono da semplificare. Restano da fare i punti TODO
-sono troppo lunghi (se vedi più di 8 - 9 righe di codice per un test ci sono ottime possiblità che debba essere riscritto), - fatto
-hanno if o altri costrutti condizionali, - fatto
-sono contenuti in testcase non corrispondenti 1:1 (nel senso di nome e/o ripartizione per package) alle classi da testare - TODO
-sono troppo complessi (si deve poter intuire cosa facciano solo guardandoli, pur non conoscendo nei dettagli il codice che chiamano) - fatto
-contengono ridondanze (in pratica se il code path di un test arriva nello stesso "stato" già coperto dalla assert di test precedente e lo ritesta prima di proseguire verso un nuovo stato, cosa che AFAIK avviene in certi test in cui si era replicato il corpo di quelli precedenti) - più laborioso, sarebbe benvenuto un volontario per svolgere questo check in parallelo - TODO
Qualche volontario?
jappilas
06-06-2007, 11:26
La risposta è soddisfacente. Io però punterei oltre che a snellire i test, anche a snellire lo sviluppo. Mi spiego: sono mesi che si parla di rifattorizzare i test solo che a me sembra che si sia perso l'obiettivo finale di tutto il progetto e cioè sviluppare e completare il gioco. capisco il tuo punto di vista, e anch' io preferirei andare direttamente ad aggiungere menu in game, schermata opzioni, gioco in rete e rifiniture varie...
ma quando qualche mese fa provai a valutare l' impatto di alcuni cambiamenti ( il refactoring di gameloop di cui si parlava a inizio thread) come "spike", mi accorsi che i test che fallivano erano tali da richiedere uno sforzo tutto meno che banale a chi poi si fosse trovato a svolgere un task orientato all' aggiunta di una feature previa introduzione dei test relativi / modifica dei test preesistenti secondo il metodo "agile" secondo cui dovremmo procedere (soprattutto perchè ora come ora ci sono più probabilità che a svolgere nuovi task siano nuovi developer con meno "insight" sulle scelte di design, o sullo stile di stesura ed espansione dei testcase, dell' epoca),
il che mi ha fatto pensare all' utilità, in generale, di valutare lo stato della batteria di test e dare una ripulita - per facilitare il lavoro dopo
( tra l' altro, grazie a san Black Box Testing, alternando fasi di test refactoring e di task si potrebbe intervenire sui test direttamente coinvolti lasciando il riordino dei restanti per una fase successiva - certo, le si dovrebbe pianificare adeguatamente, ma dovrebbe essere fattibile, soprattutto avendo sempre presente un piano d' azione a medio termine - cioè la lista dei test "fuori specifiche")
Da una prima analisi sembra che effettivamente ci sia una ridondanza mostruosa dei test. In alcuni casi sembra che i test siano stati sviluppati in modo incrementale, dove cioè test successivi testano anche tutto ciò che è precedentemente testato da altri test. praticamente mi riferivo a quello :D
In allegato trovate le ultime modifiche. Nei commenti "// Troppo complicato" trovate segnalati i metodi che SECONDO ME sono da semplificare. Restano da fare i punti TODO
Tra qualche giorno vi posto l'elenco delle modifiche proposte.molto bene :)
ps: una volta a buon punto con questo, si partirà con il task del menu in game, promesso ;)
pps: se non si offre nessuno, le corrispondenze testcase <> package posso controllarle e sistemarle io ...
jappilas
10-06-2007, 15:21
per inciso - noto che le caption dei task ( "todo" ) sono ancora in italiano... Raoul, non avevi committato?
attenzione, ultimamente c'è un po' di attività sul repository - per limitare i problemi ricordo la regola di sempre, fare sempre un update da svn, prima di ogni commit
jappilas
10-06-2007, 18:59
ragazzi... salutate TestPlaybackLoop che ci lascia dopo (probabilmente anni di ) un onorato servizio silenziosamente svolto sotto it.diamonds.tests public class TestPlaybackLoop extends TestCase
{
public void testNothing()
{
assertEquals(1, 1);
}
}:D
in aggiunta, sono stati in parte riorganizzati i test per far meglio corrispondere le classi sotto it.diamonds.X a quelle in it.diamonds.tests.X...
spostamenti:
AbstractEnvironmentTestCase
da it.diamonds.tests a it.diamonds.tests.engine
AbstractGemsPairTestCase
da it.diamonds.tests a it.diamonds.tests.gems
AbstractGridTestCase
TestCell
TestCellsideCollision
TestGridReactionToInput
TestIncomingStones
da it.diamonds.tests a it.diamonds.tests.grid
TestMainMenu
da it.diamonds.tests a it.diamonds.tests.menu
rinominazioni:
it.diamonds.tests.gems
in it.diamonds.tests.droppable
Eh si però io non ho ancora completato il lavoro. Piano piano con le modifiche altrimenti mi sballi tutto.
redcloud
10-06-2007, 20:49
[QUOTE=jappilas;17475182]ragazzi... salutate TestPlaybackLoop che ci lascia dopo (probabilmente anni di ) un onorato servizio silenziosamente svolto sotto it.diamonds.tests
public class TestPlaybackLoop extends TestCase
{
public void testNothing()
{
assertEquals(1, 1);
}
}:D
lol miticus!
jappilas
10-06-2007, 20:52
:ops:
per queste evenienze consiglio di tenere sempre da parte una copia delle parti modificate, in modo da poterle riapplicare il più velocemente possibile sull' ultima versione del codice aggiornata da repository :p :O
^TiGeRShArK^
10-06-2007, 21:22
Eh si però io non ho ancora completato il lavoro. Piano piano con le modifiche altrimenti mi sballi tutto.
:stordita:
io ho anke spostato le classi e i test che erano in it.diamonds sotto it.diamonds.playfield... :fiufiu:
ma con un update + refresh + clean le cose non vanno a posto?
a me in quel modo mi hanno funzionato le modifiche di Jappy... (Dopo un primo attimo di terrore in cui vedevo sotto eclipse 235 test anzikè 822 :asd: )
Inoltre ho committato la lista dei test da controllare sotto docs/testsToCheck.txt eliminando i test che ho già sistemato.
P.S. ovviamente quando finite di lavorare ai test aggiornate la lista cancellando le parti che avete sistemato e ricommittatela :p
:stordita:
io ho anke spostato le classi e i test che erano in it.diamonds sotto it.diamonds.playfield... :fiufiu:
ma con un update + refresh + clean le cose non vanno a posto?
a me in quel modo mi hanno funzionato le modifiche di Jappy... (Dopo un primo attimo di terrore in cui vedevo sotto eclipse 235 test anzikè 822 :asd: )
Inoltre ho committato la lista dei test da controllare sotto docs/testsToCheck.txt eliminando i test che ho già sistemato.
P.S. ovviamente quando finite di lavorare ai test aggiornate la lista cancellando le parti che avete sistemato e ricommittatela :p
Ma come scusa? Li stavo vedendo io i test e ora mi dici che li hai modificati anche tu? Mah...
^TiGeRShArK^
10-06-2007, 23:34
Ma come scusa? Li stavo vedendo io i test e ora mi dici che li hai modificati anche tu? Mah...
ehmmm...
jappilas mi ha mandato la lista....
pensavo che quelli non li stesse vedendo nessuno :mbe:
E cmq è appunto per questo che ho committato la lista sotto docs così appena qualcuno cambia un test lo leva dalla lista e gli altri non lavorano sullo stesso test.
Qdi direi che tocca a te aggiornarla eliminando i test su cui stai lavorando :p
Certo ke se fosse stato deciso prima un meccanismo simile per la gestione della concorrenza sul lavoro sui test sarebbe stato meglio :stordita:
Se vi viene qualche idea migliore per evitare che il nostro lavoro si sovrapponga proponete pure...
Quella è stata la prima cosa ke m'è passata x la mente :D
jappilas
11-06-2007, 00:23
Ma come scusa? Li stavo vedendo io i test e ora mi dici che li hai modificati anche tu? Mah..tigershark oggi pomeriggio ha iniziato a rifattorizzare alcuni di quei test riportati come troppo complessi nella lista di cui sopra , nella fattispecie coinvolti nel sistema di input - TestInput, TestEvent, TestEventHandler
è stata eseguita una riorganizzazione di cui avevo detto che mi sarei occupato e di cui c' era bisogno, questa però ha modificato la posizione dei file nei package senza comportare modifiche al corpo, per quelli direttamente coinvolti, e con modifiche limitate in altri dovute all' aggiornamento automatico dei riferimenti ai primi (che quindi dovrebbero essere circoscritte alla parte relativa agli import)
ora, se non avevi ancora iniziato ad apportare modifiche non si pone il problema ( le valutazioni sulla ridondanza e complessità dei test non dipendono dal package in cui si trova la classe )
se avevi già iniziato a lavorare sui sorgenti, dovrebbe essere sufficiente se tieni da parte una copia del tuo codice e subito dopo l' update-clean fai copia incolla del corpo completo della classe relativa (senza nemmeno scomodare il merge di SVN)
è comunque vero che esaurito come sono ultimamente, ho trascurato un tantino la coordinazione - di questo chiedo scusa :O
tigershark oggi pomeriggio ha iniziato a rifattorizzare alcuni di quei test riportati come troppo complessi nella lista di cui sopra , nella fattispecie coinvolti nel sistema di input - TestInput, TestEvent, TestEventHandler
è stata eseguita una riorganizzazione di cui avevo detto che mi sarei occupato e di cui c' era bisogno, questa però ha modificato la posizione dei file nei package senza comportare modifiche al corpo, per quelli direttamente coinvolti, e con modifiche limitate in altri dovute all' aggiornamento automatico dei riferimenti ai primi (che quindi dovrebbero essere circoscritte alla parte relativa agli import)
ora, se non avevi ancora iniziato ad apportare modifiche non si pone il problema ( le valutazioni sulla ridondanza e complessità dei test non dipendono dal package in cui si trova la classe )
se avevi già iniziato a lavorare sui sorgenti, dovrebbe essere sufficiente se tieni da parte una copia del tuo codice e subito dopo l' update-clean fai copia incolla del corpo completo della classe relativa (senza nemmeno scomodare il merge di SVN)
è comunque vero che esaurito come sono ultimamente, ho trascurato un tantino la coordinazione - di questo chiedo scusa :O
Il problema è che ho fatto l'update inavvertitamente cancellando tutto ciò che ho fatto perché ricordavo che dopo l'OK partiva la procedura per vedere le differenze e accorparle e invece nisba. Vabbè vedrò quello che posso fare però in questo momento sto abbastanza seccato per tutto.
jappilas
12-06-2007, 22:06
Il problema è che ho fatto l'update inavvertitamente cancellando tutto ciò che ho fatto perché ricordavo che dopo l'OK partiva la procedura per vedere le differenze e accorparle e invece nisba. Vabbè vedrò quello che posso fare però in questo momento sto abbastanza seccato per tutto.scuuuuuuuuusa...... :( :ops2:
se ti ricordi delle modifiche che avevi implementato ( nel senso, che test -> che "forma" della modifica) posso provare a dedicarmici io (e magari stendere una task list per chi avesse voglia di effettuarle) senza costringere te a rifare del lavoro da capo :stordita:
PS: sfogati pure con me quanto vuoi, ma non mollare il progetto :O
scuuuuuuuuusa...... :( :ops2:
se ti ricordi delle modifiche che avevi implementato ( nel senso, che test -> che "forma" della modifica) posso provare a dedicarmici io (e magari stendere una task list per chi avesse voglia di effettuarle) senza costringere te a rifare del lavoro da capo :stordita:
PS: sfogati pure con me quanto vuoi, ma non mollare il progetto :O
Le modifiche erano su quasi tutti i test segnalati in quel file. Il problema è che ci vuole tempo a fare quel lavoro perché non è che ti metti a cancellare i test o a ridurne il numero di righe senza capirne la logica e capirne la logica è abbastanza complicato perché è lo stesso progetto ad essere diventato molto complicato. Mi torna in mente perché questo progetto è già morto una volta: troppo casino, troppo intricato, troppe astrazioni di classi. Io ci lavoro con l'informatica anche se non nel campo dei giochi e fino ad ora sviluppando applicazioni e componenti Java e C++ vi assicuro che praticamente mai ho trovato un progetto così complicato.
Mi rimetto a vedere i test però sappiate che è un lavoro estremamente noioso non solo per quello che c'è da fare in sé, ma anche perché sono fermamente convinto che quando inizieranno i task di aggiunta di funzionalità ogni volta ci saranno da rifare un sacco di test e la cosa mi fa già venire il mal di testa.
Le modifiche erano su quasi tutti i test segnalati in quel file. Il problema è che ci vuole tempo a fare quel lavoro perché non è che ti metti a cancellare i test o a ridurne il numero di righe senza capirne la logica e capirne la logica è abbastanza complicato perché è lo stesso progetto ad essere diventato molto complicato. Mi torna in mente perché questo progetto è già morto una volta: troppo casino, troppo intricato, troppe astrazioni di classi. Io ci lavoro con l'informatica anche se non nel campo dei giochi e fino ad ora sviluppando applicazioni e componenti Java e C++ vi assicuro che praticamente mai ho trovato un progetto così complicato.
Mi rimetto a vedere i test però sappiate che è un lavoro estremamente noioso non solo per quello che c'è da fare in sé, ma anche perché sono fermamente convinto che quando inizieranno i task di aggiunta di funzionalità ogni volta ci saranno da rifare un sacco di test e la cosa mi fa già venire il mal di testa.
P.S: Avete mai visto il codice di Quake II o Quake III Arena? Altro che classi, tutto C puro e semplice, dove tra l'altro non si capisce na mazza :sofico:
^TiGeRShArK^
13-06-2007, 07:50
Il problema è che ho fatto l'update inavvertitamente cancellando tutto ciò che ho fatto perché ricordavo che dopo l'OK partiva la procedura per vedere le differenze e accorparle e invece nisba. Vabbè vedrò quello che posso fare però in questo momento sto abbastanza seccato per tutto.
:mbe:
ma con l'update non cancella i file modificati di solito :fagiano:
se fai revert invece ti elimina i file modificati riprendendoli dal repository...
E cmq controlla nelle directory se x caso SVN ha creato delle copie di riserva.
^TiGeRShArK^
13-06-2007, 07:55
Io ci lavoro con l'informatica anche se non nel campo dei giochi e fino ad ora sviluppando applicazioni e componenti Java e C++ vi assicuro che praticamente mai ho trovato un progetto così complicato.
Beato te :sob:
a me stava venendo un orgasmo multiplo a rimettere le mani sul codice di Diamonds dopo lo schifo su cui sono costretto a lavorare ogni giorno.. :muro:
Roba che non potete nemmeno immaginare :asd:
Beato te :sob:
a me stava venendo un orgasmo multiplo a rimettere le mani sul codice di Diamonds dopo lo schifo su cui sono costretto a lavorare ogni giorno.. :muro:
Roba che non potete nemmeno immaginare :asd:
Non mi sono espresso correttamente. Il discorso non è che non ho mai trovato progetti così complessi, ma il problema è che rispetto all'inizio in cui sviluppavamo i test e successivamente le funzionalità e questa cosa andava avanti piuttosto bene. Adesso siamo arrivati ad un'architettura tale che questo processo non è più tanto agevole perché ogni volta che voglio toccare qualcosa, scattano un sacco di test. Probabilmente il peso del non aver studiato a tavolino l'architettura di Diamond, ma di essere arrivati a quella attuale basandosi solo sull'evoluzione delle funzionalità e relativi test sta mostrando tutti i suoi limiti. Ecco cosa intendevo per complessità.
redcloud
01-07-2007, 19:14
Qualcuno sta provando a fare gli altri task?
Qualcuno sta provando a fare gli altri task?
Io sto completando il lavoro che avevo fatto e che avevo accidentalmente cancellato.
redcloud
01-07-2007, 19:44
Ok! Ottimo, grazie ;)
Ho fatto la commit della prima parte delle modifiche. Purtroppo il mio tempo a disposizione è molto limitato in settimana e nei weekend faccio quello che posso. Se avete pazienza nelle prossime settimane committo anche la seconda parte.
La build è verde al momento.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.