View Full Version : Chiusura del progetto...
Ho ricevuto come molti di voi la mail sulla chiusura del progetto...
Volevo sapere la vostra impressione...
Io sinceramente sono disposto a portarlo avanti anche allungando i tempi di realizzazione...
Le scadenze si possono rispettare in un'ambiente lavorativo, ma difficilmente possono essere determinanti e determinate in un progetto come questo realizzato nel "tempo libero"...
Probabilmente molti fattori, come quello del calendario, non sono stati tenuti in cosiderazione durante la stesura delle scadenze...
Ad esempio doveva essere tenuto in considerazione che la partecipazione degli studenti universitari (praticamente un buon 50% dei partecipanti) nei periodi Gennaio-Febbraio, Giugno-Luglio e Settembre sarebbe stata minima...
Inoltre ci sono stati altri fattori che sicuramente hanno reso il codice difficilmente manutenibile... Ad esempio i refactoring di BigGem e degli stati sarebbero dovuti avvenire molto tempo prima...
Io direi di portare il codice ad un livello gestibile e dopo stabilire nuove scadenze...
Io la mail non l'ho ricevuta :cry: :cry:
Cionci, ti contato in pvt così me la passi ;)
Pur non avendo l'idea di cosa ci sia nella mail, dico già le mie prim eimpressioni dal post di cionci.
IL PROGETTO NON VA CHIUSO. :mad:
Ecco al proposta.
Riportare il codice ad un livello gestibile.
1 task bisettimanale per ognuno.
Recuperare sulla tabella di marcia appena i tempi saranno un po' meno scuri (vacanze).
Rilasciare Diamonds alle stesse date !!! :Prrr: :Prrr:
Le difficoltà ci sono e possono capitare anche nei team seri: si ammalano di varicella i 2 programmatori delle animazioni 3D...che si fà?
Sono convinto che il calo ci sia e sia pure fisiologico considerando che siamo tutti amatori, ma per un paio di cilcli che vanno storti...mica si muore.
Il problema vero è BigGem... :muro: :muro:
Ripeto quello che ho già detto in altri thread: sono nella cacca e posso fare giusto il task bisettimanale e sarò più specifico per far capire l'entità della mia situazione personale:
28 giugno -> Robotica
5 Luglio -> Sistemi Real-Time
13 Luglio -> Calcolatori Elettronici (Mattone infinito)
e nel tempo libero cercare di finire un progetto di Metodologie di Progettazione Hardware & Software e fare, totalmente, il progetto di Elaborazione dell'Immagine.
Il tutto entro il 21 Luglio.
Secondo voi lo trovo il tempo per andare in bagno ?!?! :nono:
Insomma la testa non ce la posso mettere tranne che per cose molto self-conteined. Se qualcuno però, in relazione hai refactoring, riesce a trovare dei mini-task....io sono qua :D :D
jappilas
23-06-2006, 16:23
IL PROGETTO NON VA CHIUSO. :mad:
.
Ecco al proposta.
Riportare il codice ad un livello gestibile.
1 task bisettimanale per ognuno.
Recuperare sulla tabella di marcia appena i tempi saranno un po' meno scuri (vacanze).
.
Sono convinto che il calo ci sia e sia pure fisiologico considerando che siamo tutti amatori, ma per un paio di cilcli che vanno storti...mica si muore.
credo anch'io ;)
la mia impressione e' che cancellare il progetto a giugno, quando la deadline per la versione finale era a dicembre... sia quantomeno prematuro e, aggiungerei, uno zinzino impulsivo ( sbagliero' ma mi sembra che l' effetto emotivo dello sconforto per il rallentamento, prevalga sulla lucida presa di coscienza che il rallentamento sussista ma che il progetto possa comunque andare avanti, alla peggio, ma proprio nel caso pessimo, con qualche feature di meno... e soprattutto mi preoccupa che il primo a gettare la spugna sia stato il coach )
Insomma la testa non ce la posso mettere tranne che per cose molto self-conteined. Se qualcuno però, in relazione hai refactoring, riesce a trovare dei mini-task....io sono qua :D :D
idem ;)
imho la cosa migliore e' recuperare lo sprito degli inizi, spezzare il lavoro in task molto basilari che chiunque puo' fare in un' ora (realistica) al massimo ...
Grazie jappy, ora ho letto. ;)
Non è una mail che pone il problema, ma è solo una mail che comunica la decisione della chiusura.
2 cose:
- come al solito si potrebbe almeno parlare con tutto il team prima di decidere
- e mò chi vuole andare avanti come fa??
P.S.: come al solito queste cose capitano quando il mattachhione non può scrivere :rotfl: :rotfl:
...ahi, le mie ditine. :ave:
[...]
Probabilmente molti fattori, come quello del calendario, non sono stati tenuti in cosiderazione durante la stesura delle scadenze...
Ad esempio doveva essere tenuto in considerazione che la partecipazione degli studenti universitari (praticamente un buon 50% dei partecipanti) nei periodi Gennaio-Febbraio, Giugno-Luglio e Settembre sarebbe stata minima...
Inoltre ci sono stati altri fattori che sicuramente hanno reso il codice difficilmente manutenibile... Ad esempio i refactoring di BigGem e degli stati sarebbero dovuti avvenire molto tempo prima...
[...]
Certo, poi nell'ultimo periodo anche i task non sempre erano indovinati al 100% perchè portavano sepsso problemi.
Inoltre anche il log e il playback sono stati problemi sottovalutati.
in ogni caso fichè non si capisce come andare avanti è inutile guardare indietro ;)
Bonfo...io sono in una situazine simile alla tua...solo che devo studiare l'esame di sistemi operativi che comprende anche sistemi operativi real-time in 20 giorni...
Il 23 giugno ho dato il mio settimo esame (30 !!!!) contando a partire da settembre 2005...e sto cercando di arrivare al più presto a prendere la tesi della specialistica...che posso prendere a luglio solo se riesco a passare il prossimo esame...
Ho dovuto ad ogni costo dare delle priorità e fino a metà luglio purtroppo non c'è spazio per Diamonds...senza contare che a casa della mia ragazza non posso sviluppare (quindi toglici minimo 3 giorni alla settimana)...
Quindi ripeto...propongo di riorganizzare il codice...non importa quanto tempo ci
mettiamo... Quando abbiamo raggiunto il livello di pulizia e facilità di gestione che ci aggrada possiamo ripartire a darci delle scadenze...
mi pare ridicolo.
Si è voluto seguire una timeline lavorativa in un contesto non lavorativo.
E poi si chiude il progetto, senza discuterne.
Ripeto mi pare ridicolo.
Fra l'altro non ho ricevuto la mail, e non capisco una cosa.
Il progetto era di qualcuno? O era del gruppo?
Chi è che ha deciso sta cosa?
Si potrebbe pubblicare qua la mail?(oppure thebol[atttt]wooow[puntooo]it) thx
Quindi ripeto...propongo di riorganizzare il codice...non importa quanto tempo ci
mettiamo... Quando abbiamo raggiunto il livello di pulizia e facilità di gestione che ci aggrada possiamo ripartire a darci delle scadenze...
IMHO abbiamo cercato troppo la pulizia e la facilta di gestione nel codice dimenticandosi dei task.
ripeto IMHO.
Io sinceramente sono disposto a portarlo avanti anche allungando i tempi di realizzazione... NO, NO, e NO!! :mad:
ricordi quando Jocchan ci ha parlato di quel progetto stupidissimo (stupidissimo rispetto al nostro) dilungatosi per anni?? non è questa la fine che ho in mente per DC, no! il 12 Dicembre verrà rilasciata la release finale di DC, chi c'è c'è chi non c'è non c'è; quello che abbiamo fatto in tempo a mettere bene, tutto il resto pazienza, non ci sarà mai.
Le scadenze si possono rispettare in un'ambiente lavorativo, ma difficilmente possono essere determinanti e determinate in un progetto come questo realizzato nel "tempo libero"... ma questo tra le altre cose vuole essere il primo progetto freelance e didattico sviluppato con metodologie serie e all'avanguardia; tra queste troviamo il Test Driven Development nell'ambito della programmazione e timelines ben definite nell'ambito della gestione. se rimandiamo DC continueremo a farlo ancora e poi ancora e ancora, e finirà per diventare una puttanata che non esce mai (come tanti altri progetti che si vedono); il 12 Dicembre l'utenza avrà ciò che siamo riusciti a fare.
Probabilmente molti fattori, come quello del calendario, non sono stati tenuti in cosiderazione durante la stesura delle scadenze... altro discorso: il sistema dei task e delle storie non tiene conto delle sessioni di esami che molti universitari hanno, cioè dei famosi periodi di Settembre, Gennaio-Febbraio, e Giugno-Luglio; ma all'inizio questo non era un problema, e se adesso lo è la causa non sono gli esami di per se' o la mancanza di tempo, ma il semplicerrimo fatto che buona percentuale del nostro codice fa piuttosto schifo e devo dire che mi sto rendendo conto che in parte la colpa è anche mia: sto riguardando classi che sviluppai tempo fa in TDD, ma se le rifacessi adesso le rifarei decisamente meglio: più semplici, meno metodi inutili, e tutto in meno tempo; un esempio? GemQueue, se ricordo bene l'ho fata proprio io. per ulteriori informazioni vedere il mio messaggio allo staff.
Ad esempio doveva essere tenuto in considerazione che la partecipazione degli studenti universitari (praticamente un buon 50% dei partecipanti) nei periodi Gennaio-Febbraio, Giugno-Luglio e Settembre sarebbe stata minima... si, ma perché? in teoria per fare un task ci vogliono 10 minuti, no? 10 minuti non sono un problema per nessuno, non mi vorrete far credere che nella vostra vita non avete neanche 10 minuti. o forse non ci vogliono esattamente 10 minuti nelle condizioni attuali del codice... no, io direi piuttosto una giornata sana per un task semplice e una settimana per uno complesso; non parliamo dei pair...
Inoltre ci sono stati altri fattori che sicuramente hanno reso il codice difficilmente manutenibile... Ad esempio i refactoring di BigGem e degli stati sarebbero dovuti avvenire molto tempo prima... eh, fosse solo quello, ROTFL :D
Io direi di portare il codice ad un livello gestibile e dopo stabilire nuove scadenze... bravissimo: di nuovo, per ulteriori informazioni fate riferimento al mio messaggio allo staff.
IMHO abbiamo cercato troppo la pulizia e la facilta di gestione nel codice dimenticandosi dei task. ---------_________---------''''''
meglio che editi chè sto affilando già la katana -.-'
mi pare ridicolo.
Si è voluto seguire una timeline lavorativa in un contesto non lavorativo.
E poi si chiude il progetto, senza discuterne. certo, come ho detto anche a cionci: questo è un progetto che, pur essendo affrontato in un contesto totalmente freelance, vuole essere serio e usare metodi professionali in tutti i sensi, non solo nello sviluppo. è in questo che sta la sua didatticità
Ripeto mi pare ridicolo.
Fra l'altro non ho ricevuto la mail, e non capisco una cosa.
Il progetto era di qualcuno? O era del gruppo?
Chi è che ha deciso sta cosa? il coach, no? ti pare strano? sopresa: il coach è quello che prende le decisioni :Prrr:
lo sai perché c'è un coach? perché deve prendere decisioni che altrimenti non si prenderebbero mai; chi non è d'accordo lo sarà col tempo.
certo, come ho detto anche a cionci: questo è un progetto che, pur essendo affrontato in un contesto totalmente freelance, vuole essere serio e usare metodi professionali in tutti i sensi, non solo nello sviluppo. è in questo che sta la sua didatticità
sono d'accordo su questo, l'ho gia detto.
Ma se ci sono dei ritardi perche la gente ha esami, ce poco da fare.
Non siamo un contesto lavorativo. Questo è un dato oggettivo.
Ok le deadline, sono uno stimolo e un avvicinarsi ad un contesto lavorativo, ma non è un contesto lavorativo.
il coach, no? ti pare strano? sopresa: il coach è quello che prende le decisioni :Prrr:
lo sai perché c'è un coach? perché deve prendere decisioni che altrimenti non si prenderebbero mai; chi non è d'accordo lo sarà col tempo.
non sapevo che il coach avesse potere di vita o di morte sul progetto.
O forse non ho capito qual è il contenuto della mail che gira :mumble: e che non mi è arrivata.
IMHO abbiamo cercato troppo la pulizia e la facilta di gestione nel codice dimenticandosi dei task.
ripeto IMHO.
La pulizia invece va cercata...e probabilmente l'abbiamo cercata poco... Prima un task occupava pochi minuti, mentre gli ultimi diverse ore...
IMHO bisogna cercare di ripulire tutto...e reimpostare altre scadenze... In modo da riuscire a ricreare altri task da 10 minuti...
71104: ma in un contesto lavorativo le ore settimanali che un team può impiegare su un progetto sono più o meno una costante... Nel nostro caso invece non lo sono...e questa cosa secondo me andava tenuta di conto...
---------_________---------''''''
meglio che editi chè sto affilando già la katana -.-'
affila quello che ti pare.
E la mia opinione, e giusta o sbagliata che sia la esprimo.
La pulizia invece va cercata...e probabilmente l'abbiamo cercata poco... Prima un task occupava pochi minuti, mentre gli ultimi diverse ore...
IMHO bisogna cercare di ripulire tutto...e reimpostare altre scadenze... In modo da riuscire a ricreare altri task da 10 minuti...
La pulizia và cercata, ma non va forzata. Se serve per fare un task bene, altrimenti è yangi. Ok il refactoring(quello delle bigGem è tanto grosso e dispendioso quanto utile), ma se si arriva a fare + refactoring che task, rischiamo di arrivare a dicembre senza aver completato gli obiettivi.
Poi il confine fa troppo e troppo poco è personale, e molto probabilmente si basa anche sull'esperienza che uno ha in queste situazioni(per precisare, la mia è limitata ;) )
Per quanto riguarda i task da 10 minuti:
la complessità dell'applicazione è aumentata, secondo me è utopico aspettarsi che i task(o almeno tutti) richiedano 10 minuti(o cmq poco) per essere fatti. Sicuramente l'uso dell tdd/test/xp etc ha aiutato molto, forse avrebbe potuto fare di piu, ma la complessita è aumentata cè poco da fare. Nell'applicazione ci saranno sempre delle interazioni, si possono diminuire con le tecniche che abbiamo usato ma ne rimarranno sempre e aumenteranno man mano che aumenta la carne al fuoco.
ps.scusa a tutti per il fatto che l'email che avevo dato precedentemente non è piu valida(mi hanno chiuso l'account senza dirmi nulla) e pensavo di averne data un altra :|
pps.secondo me possiamo andare avanti cmq. Ci si conta e si vede il da farsi.
e spero in un ripensamento del coach. Un mio collega con cui ogni tanto faccio una parta, ci rimarrebbe molto male :(
71104: ma in un contesto lavorativo le ore settimanali che un team può impiegare su un progetto sono più o meno una costante... Nel nostro caso invece non lo sono...e questa cosa secondo me andava tenuta di conto...
sono d'accordo...penso che questo sia stato un qualcosa che avremmo dovuto tenere in conto...cmq, a me sembra che ci siano ancora molte persone interessate al progetto, dobbiamo cercare di organizzarci a mio avviso in modo tale da considerare queste variabili che prima forse non avevamo tenuto in considerazione...
sono d'accordo su questo, l'ho gia detto.
Ma se ci sono dei ritardi perche la gente ha esami, ce poco da fare.
Non siamo un contesto lavorativo. Questo è un dato oggettivo.
Ok le deadline, sono uno stimolo e un avvicinarsi ad un contesto lavorativo, ma non è un contesto lavorativo. era solo un esperimento; io ci credevo, e se il progetto riuscirà a riaprire ci crederò di nuovo.
non sapevo che il coach avesse potere di vita o di morte sul progetto. te l'ho detto: sorpresa!! :Prrr:
O forse non ho capito qual è il contenuto della mail che gira :mumble: e che non mi è arrivata. nonnò, hai capito benissimo: Diamond Crush è ufficialmente chiuso; diciamo chiuso per restauri, non si sa se riaprirà, ancora una volta dipende solo da noi
affila quello che ti pare.
E la mia opinione, e giusta o sbagliata che sia la esprimo. farai bene a toglierti queste idee dalla testa perché su Diamond Crush non siamo in una democrazia: la democrazia è troppo lenta e non funziona; siamo in una dittatura, che è molto più veloce ed efficiente. la storia della katana è tutta scena, se non esegui gli ordini e non fai diventare quel codice un bijoux di eleganza altro che katana, vedrai che sensazione le tue ditine... :asd:
EDIT: e le tue ginocchia :asd:
Cosa velocisssima...altrimenti al mia ragazza mi strozza se mi trova qua a scrivere :asd: :asd:
I task non sono da 10 minuti, mai stati...forse da 1 ora.
E la risposta è : "sì, un ora per Diamond ce l'ho" :D :D
Il problema è che i task proposti non sempre sono stati pensati per l'ora (basti pensare che log e playback sono stati assegnati come un task unico e ancora adesso non ne siamo usciti fuori dopo un mese).
Inoltre anche i task pensati per l'ora ora richiedono molto di più perchè il codice è poco gestibile. Uno dei vantaggi edl TDD è che vedi subito i risultati e ti viene voglia di andare avanti e sei "gasato"...bene, con il codice ridotto così le bollicine spariscono appena cerchi di capire cosa fa che cosa e dove mettere le mani.
In ogni caso vedo che siamo tutti d'accordo.
Il progetto non deve morire (mi sento Stephen King :asd:).
Allora non lo si rianima con le parole.
Facciamo vedere al coach che abbiamo le palle.
Mettiamo a posto il tutto e finiamo sti cavolo di refactoring
Poi bombardiamo Jocc di mail finchè non ci dà nuovi task ;)
Domani mi trovate su Diamonds almeno per 1 ora.
FORZA CHE SIAMO ER MEGLIO :yeah:
te l'ho detto: sorpresa!! :Prrr:
Però almeno parlarne della decisone che si prenderà... :rolleyes:
nonnò, hai capito benissimo: Diamond Crush è ufficialmente chiuso; diciamo chiuso per restauri, non si sa se riaprirà, ancora una volta dipende solo da noi
Appunto.
DIAMOCI SOTTO E FACCIAMO CAMBIARE IDEA AL PROJECT MANAGER
In ogni caso vedo che siamo tutti d'accordo.
Il progetto non deve morire (mi sento Stephen King :asd:).
Allora non lo si rianima con le parole.
Facciamo vedere al coach che abbiamo le palle.
Mettiamo a posto il tutto e finiamo sti cavolo di refactoring
Poi bombardiamo Jocc di mail finchè non ci dà nuovi task ;)
Domani mi trovate su Diamonds almeno per 1 ora.
FORZA CHE SIAMO ER MEGLIO :yeah: come non quotare... io comunque penso che dopo questo significativo refactoring il sistema dei task sarà anche un attimino da rivedere: task più semplici e non solo la descrizione, ma anche una guida precisa di ciò che va fatto, elenco delle classi su cui bisogna lavorare per portarlo a termine e magari un abbozzo di test list; qualsiasi dubbio o proposta di alternativa naturalmente si discute nel thread del ciclo.
come non quotare... io comunque penso che dopo questo significativo refactoring il sistema dei task sarà anche un attimino da rivedere: task più semplici e non solo la descrizione, ma anche una guida precisa di ciò che va fatto, elenco delle classi su cui bisogna lavorare per portarlo a termine e magari un abbozzo di test list; qualsiasi dubbio o proposta di alternativa naturalmente si discute nel thread del ciclo.
mo non esageriamo.....la presentazione dei task a mio avviso andava bene...il task lo dobbiamo fare noi, non il coach.....
mo non esageriamo.....la presentazione dei task a mio avviso andava bene...il task lo dobbiamo fare noi, non il coach..... ah guarda, non siamo nella posizione di considerare nulla un'esagerazione... :mc:
e come se non bastasse, Eternal down... ci mancava solo questa -.-
Rubberick
24-06-2006, 00:39
un riavvio di 5 min lo chiami down?
relax please eh... :rolleyes:
ok, è tutto apposto ragazzi ^^
task più semplici e non solo la descrizione, ma anche una guida precisa di ciò che va fatto, elenco delle classi su cui bisogna lavorare per portarlo a termine e magari un abbozzo di test list
Se vuoi la lista delle classi, test list parziale e una implementazione basilare devi trovare qualcuno che si ricordi a memoria le 30 mila righe di codice del sistema e riesca a seguire tutti i refactoring che vengono fatti. :p
ciao ;)
farai bene a toglierti queste idee dalla testa perché su Diamond Crush non siamo in una democrazia: la democrazia è troppo lenta e non funziona; siamo in una dittatura, che è molto più veloce ed efficiente. la storia della katana è tutta scena, se non esegui gli ordini e non fai diventare quel codice un bijoux di eleganza altro che katana, vedrai che sensazione le tue ditine... :asd:
EDIT: e le tue ginocchia :asd:
dell'eleganza nel codice non mi interessa. Mi interessa l'efficenza, e non nel senso di tempo macchina ma nel tempo di realizzazione del progetto. Star a cercare il codice perfetto, lo si puo fare in ambito didattico ma non lavorativo, dove si hanno degli altri obbiettivi, cioè il lavoro finito.
Questo vuole dire spaghetti-code?
assolutamente no, altrimenti ti trovi del codice ingestibile e il lavoro non lo finisci :) o se lo finisci poi dopo scappi per non metterci piu mano :asd:
ma cercare l'estetismo nel codice puro a se stesso, non ti fa finire il lavoro.
per quanto riguarda i task non piu da 10 minuti, come ho gia detto mi sembra naturale come cosa. Cè piu carne al fuoco, puoi fare decupling finche vuoi, ma le relazioni fra oggetti sono destinate ad aumentare.
E apparte task grossi(log/refactoring vari) i task non mi sembrano poi cosi lunghi da fare. Ci sono piu cose da tenere conto, ma per quelle ci sono i test che il 90% delle volte danno una mano. E vero anche che è diventato + complicato scriverli che all'inizio, ma ripeto, è una cosa che si puo limitare, ma non eliminare
come non quotare... io comunque penso che dopo questo significativo refactoring il sistema dei task sarà anche un attimino da rivedere: task più semplici e non solo la descrizione, ma anche una guida precisa di ciò che va fatto, elenco delle classi su cui bisogna lavorare per portarlo a termine e magari un abbozzo di test list; qualsiasi dubbio o proposta di alternativa naturalmente si discute nel thread del ciclo.
Sono d'accordo che il sistema dei task va calibrato meglio.
Ripeto, il log\playback e le dinamiti sono stati ottimi esempi per capire come una non ottimale divisione dei task porta a ridurre l'efficenza.
Però non possimao chiedere la coach di fare il task, possiamo però chiedergli di starci un po' più col fiato sul collo nel caso siamo un po' in difficoltà :sofico:
relax please eh... :rolleyes:
In questo periodo sarà fondamentale :D :D
dell'eleganza nel codice non mi interessa. Mi interessa l'efficenza, e non nel senso di tempo macchina ma nel tempo di realizzazione del progetto. Star a cercare il codice perfetto, lo si puo fare in ambito didattico ma non lavorativo, dove si hanno degli altri obbiettivi, cioè il lavoro finito.
Questo vuole dire spaghetti-code?
assolutamente no, altrimenti ti trovi del codice ingestibile e il lavoro non lo finisci :) o se lo finisci poi dopo scappi per non metterci piu mano :asd:
ma cercare l'estetismo nel codice puro a se stesso, non ti fa finire il lavoro
Esattamente!!
Il fatto è che spesso per avere del codice gestibile deve essere elegante.
Ma l'eleganza deve essere un mezzo non un fine!! :O
Bene...direi che per organizzare il lavoro di pulizia del codice ci si vede nel thread della storia 1 :D :D
NO, NO, e NO!! :mad:
ricordi quando Jocchan ci ha parlato di quel progetto stupidissimo (stupidissimo rispetto al nostro) dilungatosi per anni?? non è questa la fine che ho in mente per DC, no! il 12 Dicembre verrà rilasciata la release finale di DC, chi c'è c'è chi non c'è non c'è; quello che abbiamo fatto in tempo a mettere bene, tutto il resto pazienza, non ci sarà mai.
ma questo tra le altre cose vuole essere il primo progetto freelance e didattico sviluppato con metodologie serie e all'avanguardia; tra queste troviamo il Test Driven Development nell'ambito della programmazione e timelines ben definite nell'ambito della gestione. se rimandiamo DC continueremo a farlo ancora e poi ancora e ancora, e finirà per diventare una puttanata che non esce mai (come tanti altri progetti che si vedono); il 12 Dicembre l'utenza avrà ciò che siamo riusciti a fare.
altro discorso: il sistema dei task e delle storie non tiene conto delle sessioni di esami che molti universitari hanno, cioè dei famosi periodi di Settembre, Gennaio-Febbraio, e Giugno-Luglio; ma all'inizio questo non era un problema, e se adesso lo è la causa non sono gli esami di per se' o la mancanza di tempo, ma il semplicerrimo fatto che buona percentuale del nostro codice fa piuttosto schifo e devo dire che mi sto rendendo conto che in parte la colpa è anche mia: sto riguardando classi che sviluppai tempo fa in TDD, ma se le rifacessi adesso le rifarei decisamente meglio: più semplici, meno metodi inutili, e tutto in meno tempo; un esempio? GemQueue, se ricordo bene l'ho fata proprio io. per ulteriori informazioni vedere il mio messaggio allo staff.
si, ma perché? in teoria per fare un task ci vogliono 10 minuti, no? 10 minuti non sono un problema per nessuno, non mi vorrete far credere che nella vostra vita non avete neanche 10 minuti. o forse non ci vogliono esattamente 10 minuti nelle condizioni attuali del codice... no, io direi piuttosto una giornata sana per un task semplice e una settimana per uno complesso; non parliamo dei pair...
eh, fosse solo quello, ROTFL :D
bravissimo: di nuovo, per ulteriori informazioni fate riferimento al mio messaggio allo staff.
Caro Berto, direi che hai colto in pieno il punto :)
Scusate se rispondo solo ora, ho un bel pò di impicci personali.
Antares88
24-06-2006, 11:19
Mi dispiace molto leggere queste cose. E soprattutto mi dispiace molto aver perso il post scritto un attimo fa -.-
Riassumo di corsa altrimenti il contadino qua dietro mi spara (sono in un agriturismo in umbria, torno stasera, e avendo letto le mail sul cellulare mi sono precipitato a cercare un pc con internet).
Mi dispiacerebbe molto se il progetto venisse cancellato in questo modo. E' vero, c'è stato un calo, ma in un certo senso era da prevedere: tutti in questo periodo abbiamo avuto grossi impegni di studio e lavoro.
Onestamente credo che nel realizzare il calendario non si sia tenuto abbastanza conto di queste cose, ma quel che è fatto è fatto. Il nostro progetto ha una scadenza precisa e abbiamo l'obbiettivo di rispettarla (anche se le software house reali hanno dipendenti che lavorano 8 ore al giorno, non soggetti ai problemi di cui sopra, nonostante questo rinviano spesso la pubblicazione dei loro prodotti).
Però come si può dire con certezza che non ce la faremo ? come si può esser sicuri che a questo forte calo non segua una forte ripresa in seguito al ritorno di quelli di noi che erano impegnati in questo periodo ?
Io per esempio ho rispettato tutte le scadenze che mi ero prefisso e di cui vi avevo parlato tempo fa, e nel giro di una settimana potrei tornare attivo.
E' vero, sono un grafico e non un programmatore, quindi sono meno importante per il progetto. Ma anche molti programmatori daranno i loro esami e presto potranno rimettersi al lavoro.
Credo sia veramente spiacevole cancellare il progetto a questo punto, quando tra l'altro lo abbiamo sbandierato a tutto il mondo. Potete immaginarvi i lettori di TGM che tra poco leggeranno di noi sulla rivista, andranno sul sito e troveranno che il progetto è cancellato ?
E soprattutto, che dispiacere proveremo tutti noi vedendo che il nostro lavoro è stato vano e che non vedremo mai completato questo bel progetto ?
Ripensateci please :cry:
Ripensateci please :cry:
Ripeto...per me, qualunque sia la decisione dei piani alti, il progetto non è chiuso...
dell'eleganza nel codice non mi interessa. Mi interessa l'efficenza, e non nel senso di tempo macchina ma nel tempo di realizzazione del progetto. Star a cercare il codice perfetto, lo si puo fare in ambito didattico ma non lavorativo, dove si hanno degli altri obbiettivi, cioè il lavoro finito. ora capisco mooolte cose :muro:
thebol, qui lavoriamo in maniera molto diversa; e ci devi stare perché il coach non sei tu :Prrr:
noi lavoriamo con metodologie che se usate nella maniera giusta ci porteranno si a codice efficiente, ma in primis semplice ed elegante!
Ripeto...per me, qualunque sia la decisione dei piani alti, il progetto non è chiuso... chiuso? ma quale chiuso... la build machine sta ancora là a cazziarci... :asd:
ora capisco mooolte cose :muro:
thebol, qui lavoriamo in maniera molto diversa; e ci devi stare perché il coach non sei tu :Prrr:
noi lavoriamo con metodologie che se usate nella maniera giusta ci porteranno si a codice efficiente, ma in primis semplice ed elegante!
Ok. Certo. Ma ricordiamoci una cosa.
SEMPLICITA' E ELEGANZA SONO UN MEZZO NON UN FINE.
Ok. Certo. Ma ricordiamoci una cosa.
SEMPLICITA' E ELEGANZA SONO UN MEZZO NON UN FINE. il che li implica ancora di più ;)
DanieleC88
24-06-2006, 13:11
dell'eleganza nel codice non mi interessa. Mi interessa l'efficenza, e non nel senso di tempo macchina ma nel tempo di realizzazione del progetto. Star a cercare il codice perfetto, lo si puo fare in ambito didattico ma non lavorativo, dove si hanno degli altri obbiettivi, cioè il lavoro finito.
Qui mi sa che abbiamo perso di vista lo scopo iniziale di Diamond crush. È nato proprio come progetto didattico, che significa che "lo si puo fare in ambito didattico ma non lavorativo"? Siamo in ambito didattico, dobbiamo scrivere codice pulito!! :p
Allora, lo si continua o no questo progetto? :)
Il problema principale per il quale si sono allungati i tempi di sviluppo è esattamente il tempo di sviluppo dei task.
Personalmente prima di accettare un task, dovendo anche fornrie una stima dei tempi di sviluppo, mi faccio una guardata al codice per capire esattamente dove bisogna mettere le mani e ben presto vi assicuro che ci si perde. Del resto il progetto è cresciuto, ormai abbiamo decine di classi e metodi sparsi ovunque ed è evidente che pretendere che il tempo di realizzazione di un task rimanga lo stesso dall'inizio alla fine del progetto è impossibile. O meglio si potrebbe fare, ma bisognerebbe agire sulla complessità del singolo task. Ricordo quando dovetti sviluppare il task per il riconoscimento delle BigGem... la descrizione del task era molto generica considerando tutte le possibili combinazioni e situazioni e infatti il task fu sviluppato solo in parte e poi completamente rifattorizzato e migliorato in altri task. Non bisogna arrivare a situazioni simili.
Proprio recentemente, poiché mi sto togliendo alcuni esami, stavo pensando che proprio il periodo designato come periodo di paura ad Agosto, per me sarebbe l'ideale da dedicare al progetto perché non sono uno di quei italiani che parte il 1 Agosto e torna il 31. Al massimo mi farò una settimana di vacanza, ma avrò molto più tempo libero a disposizione da dedicare a Diamond Crush.
Tra l'altro sto dedicando indirettamente molto tempo a Diamond visto che per un esame io, insieme ad altri amici, stiamo eseguendo il Reverse Engineering di Diamond della FPS e devo dire che sono emersi aspetti interessanti :)
Inoltre molto probabilmente un amico che sta facendo questo esame con me entrerà a far parte del team perché gli sta interessando molto il progetto (spesso invece di fare l'esame si mette a giocare :D).
ora capisco mooolte cose :muro:
thebol, qui lavoriamo in maniera molto diversa; e ci devi stare perché il coach non sei tu :Prrr:
noi lavoriamo con metodologie che se usate nella maniera giusta ci porteranno si a codice efficiente, ma in primis semplice ed elegante!
perfetto
abbiamo un progetto didattico, che vuole essere didattico nel modo di procedere, ma vuole avere timeline da progetto lavorativo.
la botte piena e la moglie ubriaca...
ps.
questo è un progetto didattico, per l'uso di xp, tdd, pattern, OOP e build integration(ho dimentica qualcosa?). L'eleganza fine a se stessa non mi sembrava fra i requisiti. L'eleganza è solo un mezzo per avere un codice piu manutenibile, e per portare a termine il lavoro nel minore tempo possibile. Ma è un mezzo, non il traguardo.
Non sono contro il codice elegante, per carità, anzi...
Ma (IMHO) non dev'essere l'obbiettivo primario. L'obbiettivo primario è arrivare alle scadenze col prodotto finito, e con un codice testato e pulito
pps.puo essere che o io o te o tutti e 2, abbiamo frainteso gli scopi del progetto, dell'xp, tdd, dell'eleganza, etc etc.
perfetto
abbiamo un progetto didattico, che vuole essere didattico, ma vuole avere timeline da progetto lavorativo.
Le timeline non sono da progetto lavorativo, così come non è vero che non sono stati considerati i mesi da impegnare in esami/vacanze/etc.
La dimostrazione di ciò è il fatto che la release date, che inizialmente era l'1 ottobre, è stata via via rinviata fino al 12 dicembre. Oltre due mesi, e non sono pochi.
Tutto questo per un progetto che, se fosse stato realmente lavorativo, sarebbe stato completato in 6 mesi al massimo, anche da un team più piccolo (ricordo che il team conta una ventina abbondante di nomi, dunque è bello grosso).
Ovviamente nessuno ha mai preteso sacrifici immani, e nessuno ha mai provato piaceri perversi nel proporre task complessi (anzi, al contrario, l'obiettivo è frazionarli quanto più possibile).
Il motivo per cui ieri ho mandato questa mail, dopo la discussione con Fek, è appunto il modo in cui - sistematicamente - ci blocchiamo. Quasi tutto il team sparisce, e non riusciamo più ad andare avanti. Ne discutiamo, e non cambia nulla (ecco il motivo per cui non abbiamo aperto un thread, in cui ci sarebbero state solo sterili discussioni), torniamo sempre al punto di partenza.
Solo un maggiore impegno da parte del team potrebbe sbloccare la situazione. E' vero che tutti noi abbiamo i nostri impegni (io stesso è da una settimana che entro ed esco da cliniche e laboratori di analisi... e ancora non ho finito...), ma non cambia il fatto che il codice di Diamonds, purtroppo, non si scrive da solo, e - se vogliamo completarlo - l'unico modo è svolgere i task.
Il fatto che i task restino liberi, e che non ci sia alcun commit per giorni interi (basta dare una sbirciata alla build machine), significa avere ben poche possibilità di arrivare fino a dicembre con almeno le feature minime necessarie per lanciare degnamente il gioco. Ed ecco quindi il perchè della decisione di ieri.
Ragazzi, ma allora ci siamo tutti.
Mi sembra che solo 2 o 3 persone non si sobno fatte vive.
Vuol dire che il TEAM c'è ancora.
Ora ognuno deve fare il suo. Poco, molto poco, ma ognuno lo deve fare.
Bene...se andate nel thread della storia 1 ci sarebbe TiledSprite da fare :D :D
DanieleC88
24-06-2006, 14:47
ps.
questo è un progetto didattico, per l'uso di xp, tdd, pattern, OOP e build integration(ho dimentica qualcosa?). L'eleganza fine a se stessa non mi sembrava fra i requisiti. L'eleganza è solo un mezzo per avere un codice piu manutenibile, e per portare a termine il lavoro nel minore tempo possibile. Ma è un mezzo, non il traguardo.
Io trovo che sia un mezzo necessario. Altrimenti, oltretutto, fek non avrebbe sprecato tanto fiato all'inizio del progetto dicendo che "il codice si commenta da sé".
DanieleC88
24-06-2006, 14:51
Vuol dire che il TEAM c'è ancora.
Per questo non voglio che Diamonds finisca ora, e in questo modo.
E poi è normale avere periodi difficili. Del resto, come hai scritto tu nella sign, "Per arrivare alla luce del giorno bisogna attraversare il buio della notte". ;)
questo è un progetto didattico, per l'uso di xp, tdd, pattern, OOP e build integration(ho dimentica qualcosa?). si, hai scordato il Black Box Testing, che è stato ampiamente sottovalutato. senza di esso vengono a crearsi innumerevoli complicazioni inutili, come ad esempio metodi pubblici usati esclusivamente dalla classe che li contiene e dai test; mi dici a cosa servono?
L'eleganza fine a se stessa non mi sembrava fra i requisiti. credo che ti sei perso qualcuna (ma giusto qualcuna :rolleyes: ) delle innumerevoli prediche di fek: non mi pare ci abbia mai insegnato a scrivere porcherie, altrimenti come mai non dobbiamo usare la getType?
Non sono contro il codice elegante, per carità, anzi...
Ma (IMHO) non dev'essere l'obbiettivo primario. L'obbiettivo primario è arrivare alle scadenze col prodotto finito, e con un codice testato e pulito senti, qui sprofondiamo ampiamente nella sessione onanista mentale; poche seghe: abbiamo un codice che fa schifo, impossibile da mantenere, dobbiamo semplificarlo. se proprio non ti entra in testa lascia perdere il concetto di eleganza, fai come se non ne avessi mai parlato, in fondo è una pippa mentale pure quello; tu devi solo programmare come dice fek, ok? come abbiamo programmato finora non va bene perché è troppo complicato; più semplice, punto. ok? e adesso ti dico di preciso un po' di cose che vanno fatte che ho scritto nel mio messaggio allo staff:
1) eliminare tutti i metodi pubblici usati solo dai test: sono inutili
per definizione (si fa eccezione per i vari createForTesting)
2) rendere privati i metodi usati solo dai test e dalla classe stessa;
ma così i test non li possono più usare? appunto...
3) trasformare tutti gli if e gli switch che potete in polimorfismo
(sapete come fare no? l'ho scritto anche su CodeGuru)
4) non usate le getType-like, usate sempre soluzioni eleganti;
cercate di eliminare la getType di Droppable; per quanto sia stata
ammortizzata con isQuesto e isQuello vari, sempre una getType è
5) ci sono certi test che fanno veramente c***re: sono lunghissimi,
prolissi, incomprensibili, non si capisce come cazzo funzionano,
occupano schermate intere, fanno 3000 asserzioni inutili già fatte da
altri test e quando tocca fare un task è la morte: se fallisce uno di
quei test non si sa più come fare per farli andare, e allora talvolta
li si commenta e via (rischiando così veramente di lasciare qualche
funzionalità untested). tutta sta roba deve solo che sparì, vogliamo
test semplici, lineari e ne vogliamo vedere 3 a schermata usando
risoluzione 800x600 ed Eclipse col pannello inferiore aperto
pps.puo essere che o io o te o tutti e 2, abbiamo frainteso gli scopi del progetto, dell'xp, tdd, dell'eleganza, etc etc. si può essere, infatti lasciamo perdere e torniamo coi piedi per terra.
E poi è normale avere periodi difficili. Del resto, come hai scritto tu nella sign, "Per arrivare alla luce del giorno bisogna attraversare il buio della notte". ;) Daniele, quando fai così sento che è un gran bene avere nel team un official ballbreaker :D :D
Mazza quanto mi piaci 71104.
Ora invece di Cesare mi sposo te :kiss:
A parte gli scherzi, forse 71104 è l'unico che ha capito come risolvere la crisi.
Ovvero apro Eclispe e incomincio a cancellare tutto quello che trovo continuando a mantenere la Build verde.
Quando non ci sarà più niente da cancellare...allora riniziamo coi task ;)
Le timeline non sono da progetto lavorativo, così come non è vero che non sono stati considerati i mesi da impegnare in esami/vacanze/etc.
La dimostrazione di ciò è il fatto che la release date, che inizialmente era l'1 ottobre, è stata via via rinviata fino al 12 dicembre. Oltre due mesi, e non sono pochi.
Tutto questo per un progetto che, se fosse stato realmente lavorativo, sarebbe stato completato in 6 mesi al massimo, anche da un team più piccolo (ricordo che il team conta una ventina abbondante di nomi, dunque è bello grosso).
Ovviamente nessuno ha mai preteso sacrifici immani, e nessuno ha mai provato piaceri perversi nel proporre task complessi (anzi, al contrario, l'obiettivo è frazionarli quanto più possibile).
Il motivo per cui ieri ho mandato questa mail, dopo la discussione con Fek, è appunto il modo in cui - sistematicamente - ci blocchiamo. Quasi tutto il team sparisce, e non riusciamo più ad andare avanti. Ne discutiamo, e non cambia nulla (ecco il motivo per cui non abbiamo aperto un thread, in cui ci sarebbero state solo sterili discussioni), torniamo sempre al punto di partenza.
Solo un maggiore impegno da parte del team potrebbe sbloccare la situazione. E' vero che tutti noi abbiamo i nostri impegni (io stesso è da una settimana che entro ed esco da cliniche e laboratori di analisi... e ancora non ho finito...), ma non cambia il fatto che il codice di Diamonds, purtroppo, non si scrive da solo, e - se vogliamo completarlo - l'unico modo è svolgere i task.
Il fatto che i task restino liberi, e che non ci sia alcun commit per giorni interi (basta dare una sbirciata alla build machine), significa avere ben poche possibilità di arrivare fino a dicembre con almeno le feature minime necessarie per lanciare degnamente il gioco. Ed ecco quindi il perchè della decisione di ieri.
mi riferivo piu alle priorità di completamento task/refactoring avendo una timeline precisa.
Cmq e vero che siamo in 20, ma effettivi molti meno. I task grossi scoraggiano i meno skillati, e quelli che hanno poco tempo da dedicarci.
E vero che la partecipazione è diminuita, ma non è sparita. Chi cè ancora magari ha ancora voglia di andare avanti, sarebbero da considerare anche loro.
Mazza quanto mi piaci 71104.
Ora invece di Cesare mi sposo te :kiss: :Prrr:
Ovvero apro Eclispe e incomincio a cancellare tutto quello che trovo continuando a mantenere la Build verde.
Quando non ci sarà più niente da cancellare...allora riniziamo coi task ;) ehm, ora non esageriamo però ^^
mica intendo dire cancellare alla brutto cane, ovviamente quando committi deve possibilmente essere tutto verde e le modifiche che fai devono aver avuto senso; è permesso rompere la build solo quando il checkstyle fa veramente lo str:fiufiu: :sofico:
mi riferivo piu alle priorità di completamento task/refactoring avendo una timeline precisa.
Lo so, ma senza delle deadline precise non si va da nessuna parte.
Quell'esempio che avevo fatto tempo fa, e che Berto ha riportato in questo thread, non era stato fatto casualmente: è un esempio eclatante di quel che rischiamo a lavorare senza essere costretti a rientrare in dei tempi fissi.
Il fatto che questo sia un progetto amatoriale, e non professionale, significa ovviamente prevedere dei tempi ben più larghi ma - attenzione! - essendo il progetto didattico, questo non ci autorizza assolutamente a comportarci in maniera poco professionale.
Al contrario, se vogliamo davvero imparare qualcosa, dovremmo cercare di avvicinarci alla realtà lavorativa il più possibile. Quindi, avere un atteggiamento poco professionale e non rispettare le deadline non significherà licenziamento (cosa che avverrebbe in una software house reale), ma ugualmente significherà danneggiare il progetto e - allo stesso tempo - attirarsi le ire di tutto il resto del team.
Da un atteggiamento più permissivo e senza conseguenze (si tarda? rinviamo le date!), nessuno imparerebbe nulla: dunque, il progetto in sè sarebbe un fallimento.
Per quel che riguarda l'importanza dei refactoring, la dimostrazione l'avete data voi: completare un task è un inferno, visto che il codice non è praticabile.
Dunque, non si tratta di sterili esercizi di stile: mantenere la codebase pulita è fondamentale per lavorare. Il refactoring, insomma, è uno strumento alla pari di Eclipse. Quindi, anche dedicare interi cicli al refactoring, non è mai un errore: anche se il vantaggio non è visibile subito, lo sarà in seguito ;)
Cmq e vero che siamo in 20, ma effettivi molti meno. I task grossi scoraggiano i meno skillati, e quelli che hanno poco tempo da dedicarci.
E vero che la partecipazione è diminuita, ma non è sparita. Chi cè ancora magari ha ancora voglia di andare avanti, sarebbero da considerare anche loro.
Ci sono stati anche task piuttosto semplici, e che nessuno ha prenotato.
Il punto è che lo stop ai lavori non è un'imposizione venuta dall'alto per chissà quale astruso motivo (chi vi parla ci tiene a Diamonds esattamente quanto voi, e ha passato una quantità abnorme di ore a lavorarci su, e si sta mordendo le mani al solo pensiero di bloccare lo sviluppo): la causa è appunto il crollo di partecipazione che stiamo avendo sistematicamente.
Se vi serve uno in più...
Ho finito ieri gli scritti della maturità, fra una settimana ho l'orale, ma tempo libero adesso un po' ne ho, e, come promesso tempo fa, sono disponibile.
I miei problemi sono:
- Mai usato Java, ho scaricato Eclipse, sto cercando di capire come funziona etc. Sto leggendo qua e la per imparare Java, ma le guide che trovo sono basiche o piene di quelle che sembrano baggianate. Comunque non mi sembra complesso, ma rischio di fare e(o)rrori concettuali abbastanza grossi (programatore "self-made" :stordita: ).
- Mi sto leggendo il più possibile sul progetto ma a quanto sembra il codice si è complicato molto, l'ho scaricato e sto provando a darci un'occhiata, spero di riuscire a capire la maggior parte delle cose (speriamo :( ).
- Il TDD mi è completamente nuovo, anche qui sto cercando di capire. :mc: Ho visto che per i nuovi facevate task in pair, ma dubito che questo sia il momento migliore...
- Fra 2 settimane parto per le vacanze (computer proibiti) e torno gli ultimi di Luglio. :muro: Cercherò in questi giorni di portarmi in pari con il progetto, poi da agosto penso di potervi aiutare meglio, e sicuramente in modo costante.
Non credo di potervi dare una grossa mano a livello di codice in questi giorni: a quanto sembra l'urgenza ora è il refactoring, e senza conoscenza buona del progetto e di Java rischierei di creare più danni che altro.
Credo che la vostra decisione di continuare sia giusta, anche perchè chiudere il progetto ora sarebbe come fallire perchè si rimanda; secondo me vi serve solo un po' di impegno e qualche aiuto.
Dunque eccomi qua (sperando di diventare un aiuto il prima possibile).
Baol, purtroppo come hai notato giungi proprio nel momento sbagliato ^^ e dico purtroppo perché di norma diamo sempre volentieri il benvenuto a nuovi volontari; credo che la cosa migliore per te e per noi sia che tu ora ti concentri sui tuoi esami e torni dopo, quando (si spera che) saremo riusciti a dare una sonora sistemata al codice :)
intanto comunque grazie per l'offerta :)
Perfetto.
Buon lavoro allora! ;)
^TiGeRShArK^
24-06-2006, 23:59
Ho ricevuto come molti di voi la mail sulla chiusura del progetto...
Volevo sapere la vostra impressione...
Io sinceramente sono disposto a portarlo avanti anche allungando i tempi di realizzazione...
Le scadenze si possono rispettare in un'ambiente lavorativo, ma difficilmente possono essere determinanti e determinate in un progetto come questo realizzato nel "tempo libero"...
Probabilmente molti fattori, come quello del calendario, non sono stati tenuti in cosiderazione durante la stesura delle scadenze...
Ad esempio doveva essere tenuto in considerazione che la partecipazione degli studenti universitari (praticamente un buon 50% dei partecipanti) nei periodi Gennaio-Febbraio, Giugno-Luglio e Settembre sarebbe stata minima...
Inoltre ci sono stati altri fattori che sicuramente hanno reso il codice difficilmente manutenibile... Ad esempio i refactoring di BigGem e degli stati sarebbero dovuti avvenire molto tempo prima...
Io direi di portare il codice ad un livello gestibile e dopo stabilire nuove scadenze...
mail? :stordita:
in effetti ora ke ci penso è da un pò ke non leggo la mail....:muro:
cmq ora mi leggo il thread e rsp... :(
^TiGeRShArK^
25-06-2006, 00:24
boh... ke dire...
io mi sono fatto un anno di lavoro a torino ke tornavo praticamente distrutto dopo 8 ore di programmazione e quando potevo mi mettevo su diamonds.....
poi ho avuto 'sto concorso che mi ha impegnato da vari mesi e onestamente, oltre a lavorare e a studiare la sera e i we per il concorso non mi restava + niente.
Ovviamente la vita sociale a torino non era zero, ma anke meno.
L'anno + brutto della mia vita da una parte, ma il + bello x le cose che ho imparato sia al lavoro che con diamonds.
Onestamente dopo che tutti noi ci siamo dedicati a questo progetto, e abbiamo letteralemente sudato sangue a volte per finire qualche task, mi sembrerebbe un abominio vederlo fallire così.
Da parte mia, come dicevo già nell'altro thread, io ci sarò a partire dalla metà della prox settiamna quando finalmente finirò 'sto kazo di concorso, ma cmq imho la prima cosa da fare è "domare" il codice che ultimamente ho visto che agiva troppo di sua volontà prendendo il sopravvento su di noi.......
redcloud
25-06-2006, 09:27
Spero che il progetto, grazie a voi, continui ad andare avanti. Io ultimamente sto incasinatissimo con l'uni (crush finale) e ne ho gia parlato con UFO su MSN. Per quanto mi riguarda mi ha un po' bloccato tutta sta fase di refactoring ma conto di riprendere in mano il codice, se mi vanno bene sti 5 esami di luglio, ad Agosto. Non mollate se potete!
cdimauro
26-06-2006, 08:14
La build machine è tornata a funzionare... :D
Che dire, ragazzi: speriamo che la buona volontà continui fino alla fine del progetto.
Per quanto mi riguarda, e per quel che hanno detto più o meno tutti finora, forse è meglio fermarsi a risistemare (ed eventualmente ripensare) il codice.
L'avevo scritto tempo fa, quando si doveva fare realizzare il log e c'era da rifattorizzare BigGem e Grid, per cui non aggiungo nulla di nuovo.
DanieleC88
26-06-2006, 10:58
Daniele, quando fai così sento che è un gran bene avere nel team un official ballbreaker :D :D
È sempre un bene avere ogni tanto qualcuno che spacca i coglioni a destra e a manca. :D
Volutamente non ho ancora postato :) chiaramente io voglio continuare a lavorare a Diamonds
Propongo di ridimensionare il progetto in maniera tale da renderlo completabile in tempo con la scaletta, l'estate incide parecchio (io sarò via 2 sett a Luglio, Francesco a quanto pare tutto Luglio, altri ad Agosto) sui ritmi senza contare chi ha gli esami...
Nei prossimi giorni propongo una versione light di DC :)
ostrica ragazzi, da oggi fek non è più sospeso... fek, se ci sei batti un colpo :D
Volutamente non ho ancora postato :) chiaramente io voglio continuare a lavorare a Diamonds
Propongo di ridimensionare il progetto in maniera tale da renderlo completabile in tempo con la scaletta, l'estate incide parecchio (io sarò via 2 sett a Luglio, Francesco a quanto pare tutto Luglio, altri ad Agosto) sui ritmi senza contare chi ha gli esami...
Nei prossimi giorni propongo una versione light di DC :)
Che bello sentirti.
Più che una versione Light, proporrei un maggior dettaglio nell'elenco delle features da implemnetare presente nel therad-sticky e associargli una priorità.
Poi incominciamo, sempre con il modello dei task, a farle fuori unaalla volta come abbiamo fatto con i bug per la First Playable.
In questo modo possiamo anche recuperrare sulla tabella di marcia.
DanieleC88
01-07-2006, 09:07
Ma che fine abbiamo fatto?
A vedere dai log della build machine, l'unico vivo qui dentro è 71104.
Vogliamo farlo finire questo gioco o lo si continua? Io sto cercando di fare qualche correzione a certi test, in modo che siano più leggibili. Ho ancora poco tempo, visto che il 4 parto e sto via due settimane, ma comunque ci sto provando. Non è molto quello che sto facendo, ma già è un contributo. Facendo ognuno di noi una piccola parte potremmo tenere in vita Diamond crush senza problemi. Certo, poi se ad occuparsene è solo 71104, è inevitabile che prima o poi molli. :(
Ma che fine abbiamo fatto?
A vedere dai log della build machine, l'unico vivo qui dentro è 71104.
Vogliamo farlo finire questo gioco o lo si continua? Io sto cercando di fare qualche correzione a certi test, in modo che siano più leggibili. Ho ancora poco tempo, visto che il 4 parto e sto via due settimane, ma comunque ci sto provando. Non è molto quello che sto facendo, ma già è un contributo. Facendo ognuno di noi una piccola parte potremmo tenere in vita Diamond crush senza problemi. Certo, poi se ad occuparsene è solo 71104, è inevitabile che prima o poi molli. :(
In realtà non ci sono neanche i tuoi di commit :D :D
In ogni caso sto lavorando a TiledSprite...e fare i test è più difficile di quel che pensassi.
Comunque entro oggi dovrei farcela.
Fatto questo basta mettere a posto canMoveDown e moveDown di BigGem (che mi sa diventare uguale a quello di AbstractDroppable) e possimao eliminare la lsita di gemme da BigGem, e poi eliminare la lista di BigGems da grid.
A quel punto unficare tutto...al punto che molte Action spariscono.
Buon lavoro...
P.S.: in ogni caso basta vedere che è attivo sul forum per capire chi sta seguendo Diamonds e chi no.
Daniele...posta anche tu :D :D
In realtà non ci sono neanche i tuoi di commit :D :D
Qualche giorno fa a fatto un commit dopo circa 5 mesi ma si è scordato di mettere il nick nel messaggio del commit :D
ciao ;)
Qualche giorno fa a fatto un commit dopo circa 5 mesi ma si è scordato di mettere il nick nel messaggio del commit :D
ciao ;)
Allora Daniele...BRAVO!!! :vicini:
Io un po' meno...il mio non c'è ancora :cry:
DanieleC88
01-07-2006, 15:22
Qualche giorno fa a fatto un commit dopo circa 5 mesi ma si è scordato di mettere il nick nel messaggio del commit :D
ciao ;)
La fretta. :ops2:
:fiufiu:
Antares88
01-07-2006, 17:16
io ho finito iersera di formattare spartacus e di reinstallare le cose fondamentali. oggi devo configurare un po di strumenti (dreamweaver, photoshop, font, pennelli e compagnia bella) e domani mi rimetto a lavoro sullo sprite di Vlad ^^
ragazzi, osservate il log: non sono più solo io a committare ^^
sono contento di vedere che il progetto sta riprendendo :)
jappilas
07-07-2006, 00:05
:ave:
^TiGeRShArK^
07-07-2006, 01:59
ragazzi, osservate il log: non sono più solo io a committare ^^
sono contento di vedere che il progetto sta riprendendo :)
si...ma non ci dobbiamo sedere sugli allori :p
io ieri ho passato 5-6 ore intere su diamonds e oggi non ho fatto praticamente nulla..:muro:
domani spero di continuare a contribuire..
basta che ognuno di noi faccia quello ke può e il progetto può andare avanti.
il_luridone
07-07-2006, 15:53
Scusate se m'intrometto vi conosco per sentito dire (ciao Valerione sono Jack :huh: :asd: )
Solo per dire:
1) un progetto rilasciato al pubblico dominio non c'è modo di chiuderlo, al massimo è inattivo. Il coach dice "è chiuso" se è l'unico ad avere la proprietà del codice, altrimento in pratica è un "lascio" (e può essere traumatico finchè si vuole ma non per forza "mortale"),
2) avevo intenzione di partecipare, quindi pulite il codice e date modo ai niubbi di entrare :asd:
Baci e strizzate di capezzoli così, a random.
Scusate se m'intrometto vi conosco per sentito dire (ciao Valerione sono Jack :huh: :asd: )
Solo per dire:
1) un progetto rilasciato al pubblico dominio non c'è modo di chiuderlo, al massimo è inattivo. Il coach dice "è chiuso" se è l'unico ad avere la proprietà del codice, altrimento in pratica è un "lascio" (e può essere traumatico finchè si vuole ma non per forza "mortale"),
2) avevo intenzione di partecipare, quindi pulite il codice e date modo ai niubbi di entrare :asd:
Baci e strizzate di capezzoli così, a random.
Ciao commendatore :D
Effettivamente la tuo osservazione è molto sensata.
Il fatto è che la mancanza di alcuni elementi si sente e molto :cry:
In ogni caso, come vedi il progetto non è proprio chiuso o inattivo, solo è un po' molto ansimante!!
In ogni caso ci stiamo facendo il :ciapet: proprio perchè non muoia :D :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.