View Full Version : [XNA] Creare un videogame
franksisca
16-12-2006, 16:23
Ragazzi, guiide o tutorial, possibilmente in ita, per creare qualcosa con XNA ("http://www.tweakness.net/index.php?topic=22512)???
e poi, che ne direste di fare qualcosina con xna???
franksisca
20-12-2006, 07:31
uppete
franksisca
24-12-2006, 15:07
Ragazzi, guiide o tutorial, possibilmente in ita, per creare qualcosa con XNA ("http://www.tweakness.net/index.php?topic=22512)???
e poi, che ne direste di fare qualcosina con xna???
possibile che non interessi a nessuno, e che nessuno abbia informazioni al riguardo???
qui ci sono info (http://learnxna.com/archive/2006/12/20/The-first-ever-XNA-contest-announces-winners.aspx)
Ciao Franksisca, informazioni le trovi sul sito http://xbox360homebrew.com/
Io sono molto interessato in queste librerie, durante la beta stavo sviluppando un gioco però ho messo il progetto da parte un attimo perchè sto preparando una demo in C++/DirectX che per trovare lavoro è più utile. Presto mi rimetterò a giocare con questa fantastica libreria :)
franksisca
24-12-2006, 19:48
Ciao Franksisca, informazioni le trovi sul sito http://xbox360homebrew.com/
Io sono molto interessato in queste librerie, durante la beta stavo sviluppando un gioco però ho messo il progetto da parte un attimo perchè sto preparando una demo in C++/DirectX che per trovare lavoro è più utile. Presto mi rimetterò a giocare con questa fantastica libreria :)
anche io, siccome amo i videogioco e crearne per lavoro sarebbe fantastico, vorrei studiarmela per benino, e vorrei anche fare qualcosa in directx/c++, non è che hai qualche guida molto semplice, perchè le dx non le conosco proprio.
Comunque, se siamo in numero suficiente, potremmo anche fare il diamand fatto in java (dopo che lo finiscono) in XNA
jappilas
24-12-2006, 22:36
Comunque, se siamo in numero suficiente, potremmo anche fare il diamand fatto in java (dopo che lo finiscono) in XNAè quel "dopo che lo finiscono" il problema - we need help (lots of) :p
seriamente, perchè non entri nel team ? ;)
lo stesso vale per PGI Bis e parecchi altri che bazzicano questa sezione che più volte hanno dimostrato di padroneggiare java anche meglio di me ;)
franksisca
24-12-2006, 23:49
è quel "dopo che lo finiscono" il problema - we need help (lots of) :p
seriamente, perchè non entri nel team ? ;)
lo stesso vale per PGI Bis e parecchi altri che bazzicano questa sezione che più volte hanno dimostrato di padroneggiare java anche meglio di me ;)
quasi quasi, ora che mi sono laureato, un giro vengo a farmelo......magari domani leggo a che punto siete
lascia perdere, se vuoi intraprendere la carriera nella games industry ti consiglio di iniziare a guardare su www.gamedev.net
franksisca
28-12-2006, 00:10
lascia perdere, se vuoi intraprendere la carriera nella games industry ti consiglio di iniziare a guardare su www.gamedev.net
grazie per l'info:D
RaouL_BennetH
28-12-2006, 11:41
mi intrometto in questa discussione per due motivi:
1) anche a me interesserebbe imparare a fare qualcosa con xna.
2) vorrei rientrare in diamond, e dico rientrare perchè sono stato uno degli autori della storia, ma poi, per diversi problemi ho abbandonato il progetto. Non lo sto seguendo perchè purtroppo non conosco java, anzi, a dire il vero, ho solo delle piccole nozioni rudimentali su diversi linguaggi, ma non ne conosco nessuno per bene.Non so quanto ve ne possa fregare, ma prendetelo come un "up" .
RaouL.
franksisca
28-12-2006, 11:51
mi intrometto in questa discussione per due motivi:
1) anche a me interesserebbe imparare a fare qualcosa con xna.
2) vorrei rientrare in diamond, e dico rientrare perchè sono stato uno degli autori della storia, ma poi, per diversi problemi ho abbandonato il progetto. Non lo sto seguendo perchè purtroppo non conosco java, anzi, a dire il vero, ho solo delle piccole nozioni rudimentali su diversi linguaggi, ma non ne conosco nessuno per bene.Non so quanto ve ne possa fregare, ma prendetelo come un "up" .
RaouL.
guarda, diamond per quanto ho letto negli ultimi post è andato oramai......quindi, se vogliamo fare qualcosa del genere in xna siamo consapevoli che ci sono buone possibilità di fare la stessa fine......quindi, magari possiamo raccogliere un paio di idee, oppure riprendere quella del diamond, e vedere se c'è qualcuno che se la sente.
Ci sono una paio di cose che mi trattengono dal partecipare a Diamonds. Giusto due pinzillacchere. Non uso IDE (ecplise, netbeans aut similia), non approvo il TDD, non uso pattern, ant, subversion, cvs, non moccko, fricco, fracco. Per ogni linea di codice scrivo un romanzo di commenti e per ogni due un PDF a parte che spiega perchè ho usato la lettera 'a' anzichè 'b'. Per chi ha avuto la sfortuna di incappare in un mio tutorial: chiacchiere del genere accompagnano ogni cosa che scrivo. La mia filosofia di sviluppo collaborativo prevede che ogni programmatore faccia quello che, in quanto essere umano, è naturalmente predisposto a fare: sfornare idee e risolvere problemi. A scrivere il codice basta che sia uno, per tutti. Poi ci vuole qualcuno che scriva la documentazione a latere. Tutti leggono, propongono, discutono ma nessuno parla di "codice" salvo il gorilla che digita.
Ora, poichè Diamonds non è un progetto che mira a scrivere un videogioco ma ha come obiettivo un modello di sviluppo del software, il TDD, a me pare che il modo in cui io interverrei per portarlo a termine (tabula rasa di tutto salvo gli artworks e le idee) non sia proponibile. Anche perchè sta malissimo dire "il progetto, iniziato come TDD, è stato portato a termine dopo aver abbadonato refactoring, test e str... del genere" :D.
franksisca
28-12-2006, 15:36
Ci sono una paio di cose che mi trattengono dal partecipare a Diamonds. Giusto due pinzillacchere. Non uso IDE (ecplise, netbeans aut similia), non approvo il TDD, non uso pattern, ant, subversion, cvs, non moccko, fricco, fracco. Per ogni linea di codice scrivo un romanzo di commenti e per ogni due un PDF a parte che spiega perchè ho usato la lettera 'a' anzichè 'b'. Per chi ha avuto la sfortuna di incappare in un mio tutorial: chiacchiere del genere accompagnano ogni cosa che scrivo. La mia filosofia di sviluppo collaborativo prevede che ogni programmatore faccia quello che, in quanto essere umano, è naturalmente predisposto a fare: sfornare idee e risolvere problemi. A scrivere il codice basta che sia uno, per tutti. Poi ci vuole qualcuno che scriva la documentazione a latere. Tutti leggono, propongono, discutono ma nessuno parla di "codice" salvo il gorilla che digita.
Ora, poichè Diamonds non è un progetto che mira a scrivere un videogioco ma ha come obiettivo un modello di sviluppo del software, il TDD, a me pare che il modo in cui io interverrei per portarlo a termine (tabula rasa di tutto salvo gli artworks e le idee) non sia proponibile. Anche perchè sta malissimo dire "il progetto, iniziato come TDD, è stato portato a termine dopo aver abbadonato refactoring, test e str... del genere" :D.
diciamo che condivid in parte le tue idee, pure io commento tutto il commentabile, e molte volte non uso pattern, non perchè li considero male, ma solo perchè non ci penso, per quanto riguarda refactoring e TDD non sò manco cosa siano, idem per junit:D
comunque, se l'idea del gioco in xna vi gusta, mettiamocci d'accordo, io tra un paio di mesi apro un'associazione all'unical con l'obiettivo di far conoscere i videogiochi ai più, e magari mettere su un team di sviluppo, potremmo collaborare un pò tutti.
Io ho un viziaccio, non commento mai nulla, ma quando vado a ripescare codice MIO vecchio mi ci trovo sempre subito.
C'è da dire che quando scrivo del codice lo scrivo in modo molto "logico" praticamente scrivo codice che si autocommenta da solo.
Però so che è un brutto vixzio, dovrei iniziare pure io a scrivere commenti...
Tanto per portare ancora più alla deriva l'offtopic.
Quelli che hanno ripreso in mano Diamonds nelle ultime settimane mi sembra non abbiano avuto nessun problema a capire il codice privo di commenti.
Se scrivi bene il codice non servono commenti a spiegarne il funzionamento, è una cosa addirittura dannosa. Sto lavorando ad un altro gioco, siamo in tre e nessuno scrive commenti (è vietato :D) ovviamente nessun problema e se una parte di codice non è comprensibile basta rifattorizzarla (anche un semplice extract method spesso va benissimo).
Il codice autocommentante è l'unica ragione per cui sarei favorevole alla reintroduzione della tortura :D
hahah hai ragione!
Comunque salvo casi particolari i commenti al mio codice non portano nessuna informazione in più.
Roba del tipo
tabella.inserisciUnaNuovaColonna(nomeColonna,valore);
Giusto per farti capire, un commento a cosa serve?
La commenterei così: questo metodo inserisce una nuova colonna nella tabella.
Ecco che info hai avuto in più? Io scrivo praticamente tutto cos', aggiungici che è tutto bello ordinato e vedi che nel mio codice ti ci trovi anche senza commenti :D
ps.magari poi quello che c'è scritto sono cazzate :D
E aggiungo che anche le cose più complesse le puoi sempre scrivere in modo che abbiano un senso logico e quindi rendere inutili i commenti.
Roba del tipo
tabella.inserisciUnaNuovaColonna(nomeColonna,valore);
Giusto per farti capire, un commento a cosa serve?
Quale tra quei due parametri può essere null? E se uno o tutti e due possono essere null, che succede? Dove va a finire la colonna? In testa, in coda o nel mezzo? Se fa parte di una libreria, ci sono delle alternative? Se sì, perchè dovrei usare questo metodo e non un altro?
E tralascio quello che io scrivo ma che mi pare si ritenga comunemente superfluo. Cioè come fa quel metodo a inserire una colonna.
Quale tra quei due parametri può essere null? E se uno o tutti e due possono essere null, che succede? Dove va a finire la colonna? In testa, in coda o nel mezzo? Se fa parte di una libreria, ci sono delle alternative? Se sì, perchè dovrei usare questo metodo e non un altro?
Il comportamento con null dovrà essere documentato dai test... Se uno di quei parametri potrà (o non potrà) essere null ci sarà un test:
testInsertNewColumnWithNullParameters
E tralascio quello che io scrivo ma che mi pare si ritenga comunemente superfluo. Cioè come fa quel metodo a inserire una colonna.
In quel metodo ci sarà un codice autocommentante che definirà come fa ad inserire la colonna...
jappilas
28-12-2006, 20:12
hahah hai ragione!
Comunque salvo casi particolari i commenti al mio codice non portano nessuna informazione in più.
Roba del tipo
tabella.inserisciUnaNuovaColonna(nomeColonna,valore)
Giusto per farti capire, un commento a cosa serve?
La commenterei così: questo metodo inserisce una nuova colonna nella tabella.
io la commenterei pressapoco (a titolo esemplificativo) così :
/* Complessità: algoritmica: O(n), ciclomatica: 11 (attenzione - il metodo attualmente viola la coding guideline)
* WARNING: la condizione d' inserimento a sinistra della prima colonna non è coperta dai test
* TODO: scrivere test case esaustivi, rifattorizzare per ridurre i code path
*/
void Tabella::inserisciUnaNuovaColonna(nomeColonna,valore); :O
i commenti interni al metodo riguardanti quello che il metodo stesso fa, devono (dovrebbero) tendere a zero
commenti in testa o in certi casi, frammezzati, che riportano metriche SUL codice, o avvertenze operative, o di naming, o "perchè si è scritta quella cosa" a volte servono
Ci sono una paio di cose che mi trattengono dal partecipare a Diamonds. Giusto due pinzillacchere. leggendo quelle che hai scritto posso dire che ne manca una (sempre una fesseria, ma mi piace essere pignolo... :asd: ): il progetto è fallito :cry: :cry: :cry:
Non uso IDE (ecplise, netbeans aut similia), pessimo, pessimo... da quando uso Eclipse per il progetto di Programmazione di Rete la mia produttività si è centuplicata. il training iniziale per imparare ad usarlo è durato pochissimo quando lo feci a suo tempo per lavorare a Diamond Crush.
non approvo il TDD, ci posso anche stare: tutto sommato non so quanto valga la pena di scrivere tutti quei test che raddoppiano il tempo di scrittura del codice e costituiscono un'arma a doppio taglio quando ti ritrovi test che non hai più la minima idea di cosa c***o testassero...
non uso [...] ant, usarlo senza IDE credo sia un attimino una rottura :D
subversion, cvs, non hai neanche idea di cosa sono... :|
i sistemi di concurrent versioning per me da quando li ho scoperti sono l'ottava meraviglia, i progetti a gruppi che faccio all'università li faccio sempre usando un repository.
non moccko, conseguenza diretta del non approvare il TDD. ma approvandolo, mockare è necessario perché altrimenti (lo dico per esperienza diretta) vengono fuori dei test nauseanti e totalmente irrispettosi delle buone regole di black box testing. vuoi sapere la mia? sono quelli che hanno ucciso Diamonds. ci credi che è colpa loro? credici, te l'assicuro.
Per ogni linea di codice scrivo un romanzo di commenti e per ogni due un PDF a parte che spiega perchè ho usato la lettera 'a' anzichè 'b'. in tal caso non ha senso disprezzare il TDD: in quel modo il tempo di scrittura del codice si CENTUPLICA :D mentre il TDD te lo raddoppia soltanto :D
A scrivere il codice basta che sia uno, per tutti. Poi ci vuole qualcuno che scriva la documentazione a latere. Tutti leggono, propongono, discutono ma nessuno parla di "codice" salvo il gorilla che digita. questa è un'idea molto interessante... però devi ammettere che al crescere della complessità del software tende a non essere una soluzione applicabile... te la immagini una sola persona a scrivere un sistema operativo? :Prrr:
e aivoja a proporre e sfornare idee... :asd:
Ora, poichè Diamonds non è un progetto che mira a scrivere un videogioco ma ha come obiettivo un modello di sviluppo del software, il TDD, a me pare che il modo in cui io interverrei per portarlo a termine (tabula rasa di tutto salvo gli artworks e le idee) non sia proponibile. Anche perchè sta malissimo dire "il progetto, iniziato come TDD, è stato portato a termine dopo aver abbadonato refactoring, test e str... del genere" :D. eppure temo che per portarlo realmente a termine il TDD andrebbe veramente eliminato: oppure dovresti contare che tutto il team magicamente impari a scrivere test decenti, rispettosi del black box testing, chiari, brevi, esaustivi, e mockati.
Io ho un viziaccio, non commento mai nulla, ma quando vado a ripescare codice MIO vecchio mi ci trovo sempre subito.
C'è da dire che quando scrivo del codice lo scrivo in modo molto "logico" praticamente scrivo codice che si autocommenta da solo.
Però so che è un brutto vixzio, dovrei iniziare pure io a scrivere commenti... io non la penso così, visto che faccio anche io come te... alla fine l'importante è ritrovarcisi dopo tanto.
A me l'idea di usare un altro pezzo del programma per documentare un metodo sa di bizarre. Un po' lo dico qui, un po' lo dico là. Mi parrebbe meglio tentare di esprimere il significato in un punto solo. E farlo usando una convenzione che certamente il lettore possiede, cioè quella della lingua umana scritta da lui parlata. Che è fatta di una marea di regole tra semantica, sintassi e, trattandosi di scritto, geometrie. Io non so se esista un linguaggio di programmazione che consenta di mimare queste regole. So per certo che Java non gli si avvicina neanche ad un kilometro. Smalltalk è un po' più vicino, più che altro per la sua capacità di intromettere i nomi dei parametri nel descrittore del metodo:
somma a con: b
valore := somma 1 con: 2
Vale a dire che un metodo Smalltalk offre l'opportunità di modellare l'invocazione su un pattern comune delle lingue scritte occidentali. Non penso sia un caso che Fowler sia un reduce dell'utopia Smalltalk.
Per quanto riguarda il test in sè è bacato in radice da un ineliminabile regressio ad infinitum: prima del test devi scrivere il test del test, che richiede il test del test del test e via dicendo. Senza questa serie infinita un test ti da le stesse garanzie di nessun test.
Non che sia un cosa tanto grave. Non è meno strambo di tante altre teorie sullo sviluppo. Anzi, è proprio questo suo non essere nè più ne meno strambo a rendere l'XP indifferente.
questa è un'idea molto interessante... però devi ammettere che al crescere della complessità del software tende a non essere una soluzione applicabile... te la immagini una sola persona a scrivere un sistema operativo? :Prrr:
e aivoja a proporre e sfornare idee... :asd:
Tu guarda a volte il caso. Ma sai dove ho trovato l'ispirazione del "Soviet Driven Development" :D ? Dai, prova a buttarla lì! Libro e autore famosissimo, una volta litigò con tal Torvalds...
Per quanto riguarda il test in sè è bacato in radice da un ineliminabile regressio ad infinitum: prima del test devi scrivere il test del test, che richiede il test del test del test e via dicendo. Senza questa serie infinita un test ti da le stesse garanzie di nessun test.
Se si scrive un test dal niente è chiaro che possa essere così, ma nel TDD il test non lo si scrive dal niente: si evolve con il codice. Un test deve fallire prima di poter essere base per l'evoluzione del codice che testa ! Se il test passa o è un test superfluo o è un test errato ;)
E il fallimento del test deve provocare una minima variazione del codice per far passare il test. E' chiaro che se il test che fallisce è sbagliato devo inserire codice sbagliato per farlo passare. Quindi è il codice stesso che verifica la correttezza del test ed è il test che verifica la correttezza del codice. Si procede quindi su due binari paralleli fino ad arrivare alla versione finale del test e del codice.
Prima costruisci il test che fallisce. Perfetto. Il test è sbagliato: fallisce per un bug del test o del codice. Dove vanno a finire i binari?
franksisca
28-12-2006, 22:13
Prima costruisci il test che fallisce. Perfetto. Il test è sbagliato: fallisce per un bug del test o del codice. Dove vanno a finire i binari?
crash :stordita: :stordita: :stordita:
Prima costruisci il test che fallisce. Perfetto. Il test è sbagliato: fallisce per un bug del test o del codice. Dove vanno a finire i binari?
Ragioniamo per induzione...la testbase e la codebase sono vuote. Scrivi il primo test: deve fallire, quindi non può fallire per un bug nel codice (perchè non c'è codice). Mettiamo che il test fallisca per un bug nel test.
Il TDD dice che bisogna procedere a piccoli passi, il codice che bisogna inserire è quindi sicuramente più semplice di quello necessario a scrivere il test. Di conseguenza scrivo il codice che penso sia adatto a rendere verde il test. Non mi riesce rendere il test verde, ma sono abbastanza (data la minima quantità di codice) sicuro del codice che ho scritto: ergo l'errore è nel test.
Cerco l'errore nel test, se l'errore non è banale elimino il codice, modifico il test e riscrivo il codice.
A questo punto la code base è consistente con la test base. Per definizione, perchè il codice fa quello che il test gli richiede.
Andiamo al secondo test. La code base è consistente con la test base di conseguenza se scrivo un test sono sicuro che un test fallisce per uno di questi due motivi: o ho scritto male il test o l'ho scritto bene e devo modificare di conseguenza il codice (non può fallire per un bug del codice perchè la test base è consistente con la code base).
Se ho scritto male il test: visto che il TDD impone piccoli passi, di conseguenza il codice che dovrò scrivere sarà molto semplice. Scrivo il codice che penso faccia passare il test, ma non funziona, quindi vado a pensare che l'errore sia nel test.
Andiamo al passo N. E così via.
IMHO l'unico modo per far diventare verde un test scritto male è inserire sia un bug nel test che un bug nel codice che esso testa ;)
Prima costruisci il test che fallisce. Perfetto. Il test è sbagliato: fallisce per un bug del test o del codice. Dove vanno a finire i binari?
Ricordati che un programmatore ha un cervello che deve bene o male funzionare decentemente per scrivere un software. Ovviamente devi sempre scrivere test semplici per poterti accorgere di un errore all'interno di essi.
A me è successo molte volte d iscrivere il test sbagliato e me ne sono sempre accorto, come mai?
Inoltre con il test almeno hai un feedback. Se scrivi codice sbagliato senza test è peggio non trovi?
Per quanto riguarda la cosa del soviet driven development (Ma chi lo ha detto, Tanenbaum?)... Mi dici dove sta il punto? Ma ci credi veramente? Non ho mai sentito una cavolata simile in vita mia, giuro.
Inoltre come fai a lavorare senza source control scusa??? Io lo uso anche per lavorare da solo fai un po' te :D
Be', non è necessario esacerbarsi. Per inciso, non è Tanembaum a chiamarlo "Soviet Driver Development" (ma cita l'idea senza approfondirla in Modern Operating System) è un'etichetta che ho usato io a mo' di scherno.
Premetto che se a uno il TDD piace io non mi permetterei mai di dirgli "non devi usarlo": non ho un'alternativa che sia meno incerta del TDD. Negli anni ne ho sperimentati parecchi. Una volta ho addirittura usato l'approccio "alla vulcaniana": tutta logica e certezze. Due bug mi son saltati fuori lo stesso. Nota: "alla vulcaniana" è un nomignolo e no, non ci credevo veramente.
Quello di cui non mi capacito sono le orde di genuflessi schierate di fronte ai nuovi profeti del nulla.
Nelle 412 pagine di "Refactoring" di Fowler non è detta una sola ragione per cui un Giovannino qualunque dovrebbe usare una qualsiasi delle tecniche descritte. E il libro chiude con Beck che ti prende anche per il culo: "Now you have the pieces of the puzzle". No, signori, "Now you have un bel pugn' de mosch'".
Trent'anni fa i libri di programmazione terminavano con un capitolo sul "Conceptual Framework", dove gli autori esponevano i fondamenti di ciò che avevano detto. BETA è ancora un campione in merito. Esiste una migliore dimostrazione di onestà intellettuale? "Hey, l'ho detto perchè x, y, z. Se x, y o z sono cavolate, allora sono cavolate anche le mie".
Sono convinzioni mie: non per questo dovete smettere di usare xP e TDD. Potendo chiederei solo che non sia spacciato per logico, semplice, evidente, quello che logico, semplice ed evidente non è.
Ho letto il libro di Tanenbaum e non ricordo di aver letto nulla del genere... Comunque son passati un po' di anni...
Riguardo Fowler... Guarda che loro ti scrivono delle cose, poi sta a te decidere il motivo per cui dovresti utilizzarle. Nessuno ti deve venire a dire il perchè, il perchè lo devi trovare tu. Quando vai dal ferramenta ci sono i martelli e non c'è scritto il perchè dovresti comprarli, il perchè lo decidi tu (esempio: non voglio piantare i chiodi a testate). E guarda bene che il paragone del ferramenta è pure azzeccato perchè qui si parla di "necessità" <=> "strumento"
Se tu non riesci a trovare un perchè sta bene a tutti, ma da qui a dire che programmare come si faceva 30 anni fa senza source control e scrivendo commenti è figo ce ne passa direi! L'esempio "30 anni fa" è proprio sbagliato concettualmente, le cose evolvono e così fa l'ingegneria del software.
Guarda io lavoro con gente che programma così ed è un incubo, non esiste proprio paragone con la semplicità e la pulizia con cui le cose venivano fatte in Diamond Crush e quelli con cui lavoro hanno molta più esperienza del team di DC.
Tu guarda a volte il caso. Ma sai dove ho trovato l'ispirazione del "Soviet Driven Development" :D ? Dai, prova a buttarla lì! Libro e autore famosissimo, una volta litigò con tal Torvalds... se è Tanenbaum (si scrive così...? :mbe: ) non è un esempio valido: non ce la vedo molto l'utenza media a usare Minix :Prrr:
parlando di sistema operativo prima avevo in mente qualcosa più come Linux munito di XGL, o peggio ancora Windows Vista :sofico: :sofico: :sofico:
dici che ce la fa una persona sola...? :asd:
[...] IMHO l'unico modo per far diventare verde un test scritto male è inserire sia un bug nel test che un bug nel codice che esso testa ;) ragionamento impeccabile, ma anche in quel modo ti accorgi che qualcosa non va per il semplice motivo che nel caso di test e codice entrambi buggati hai scritto un programma che funziona (non buggato), solo che non funziona come vuoi tu :) e questo lo vedi semplicemente a runtime.
di conseguenza il TDD è orientativamente infallibile :D (dico orientativamente perché si basa sempre sull'assunzione che il programmatore sbaglia nello scrivere tanto codice ma non sbaglia nello scriverne poco).
però io dopo l'esperienza su DC penso che all'atto pratico non sia realmente vantaggioso: su DC lo usavamo e il codice è diventato un casino; ok, colpa di alcuni membri del team che non rispettavano le buone norme di black box testing. però io nel mio progetto di Programmazione di Rete (un programma di filesharing) ti posso assicurare che senza usare TDD sto avendo assieme al mio amico una velocità di sviluppo mostruosa che non abbiamo mai raggiunto neanche su DC, infatti secondo me a questo punto il nostro programma inizia ad essere persino più complesso di DC. e procede fluidamente senza rallentamenti e senza codice incasinato. e siamo in due, mentre su DC eravamo (almeno all'inizio) una dozzina. e com'è sta storia? :Prrr:
ragionamento impeccabile, ma anche in quel modo ti accorgi che qualcosa non va per il semplice motivo che nel caso di test e codice entrambi buggati hai scritto un programma che funziona (non buggato), solo che non funziona come vuoi tu :) e questo lo vedi semplicemente a runtime.
di conseguenza il TDD è orientativamente infallibile :D (dico orientativamente perché si basa sempre sull'assunzione che il programmatore sbaglia nello scrivere tanto codice ma non sbaglia nello scriverne poco).
però io dopo l'esperienza su DC penso che all'atto pratico non sia realmente vantaggioso: su DC lo usavamo e il codice è diventato un casino; ok, colpa di alcuni membri del team che non rispettavano le buone norme di black box testing. però io nel mio progetto di Programmazione di Rete (un programma di filesharing) ti posso assicurare che senza usare TDD sto avendo assieme al mio amico una velocità di sviluppo mostruosa che non abbiamo mai raggiunto neanche su DC, infatti secondo me a questo punto il nostro programma inizia ad essere persino più complesso di DC. e procede fluidamente senza rallentamenti e senza codice incasinato. e siamo in due, mentre su DC eravamo (almeno all'inizio) una dozzina. e com'è sta storia? :Prrr:
Chiaramente un team di 2 persone è molto meglio gestibile di un team di 10 persone. Inoltre in DC non tutti avevano lo stesso livello di esperienza (quanta gente non aveva mai usato Java prima? E OpenGL?), inoltre in DC il codice non è diventato così uno schifo come dite... Eliminando le parti sviluppate da Marzo in poi si è ritornati ad avere qualcosa di decente :)
Comunque il problema non è nel TDD ma nella voglia del team. Tu stai facendo un progetto per l'università quindi hai la motivazione capisci? In DC appena le cose son diventate un pelo complesse la gente ha cominciato a non lavorare più, a non fare refactoring, a scrivere prima il codice e poi i test, a non mockare, e così via.
Comunque onestamente non mi sento ancora di dare un giudizio finale al TDD, DC è stato un esperimento, tale esperienza ha mostrato alcuni punti che potevano essere migliorati nel processo di sviluppo e in futuro qualcuno farà tesoro dell'esperienza acquisita. Tale esperienza insegna anche quando il TDD NON va utilizzato. Sto lavorando ad un progetto con due amici e so che il TDD mi sarebbe solo di ostacolo e quindi non lo uso (è tutta rob
Ma poi non ho capito 272613742 qualche mese fa facevi tutto il gasato del tdd e ora dici così? :)
Chiaramente un team di 2 persone è molto meglio gestibile di un team di 10 persone. infatti è proprio questo il motivo percui trovo molto intelligente il "Soviet Driven Development" :D l'ingestibilità di un team è un problema che scompare nel momento in cui a scrivere è uno solo che facendo da se' fa per tre. però è anche vero che non è pensabile per software giganteschi: in quei casi secondo me il software dovrebbe essere prima suddiviso in più parti a cui assegnare un "gorilla" ciascuna. nel caso di un sistema operativo potrebbe ad esempio trattarsi di un gorilla per ciascun modulo eseguibile.
Comunque il problema non è nel TDD ma nella voglia del team. Tu stai facendo un progetto per l'università quindi hai la motivazione capisci? In DC appena le cose son diventate un pelo complesse la gente ha cominciato a non lavorare più, a non fare refactoring, a scrivere prima il codice e poi i test, a non mockare, e così via. esatto, ma la voglia del team è scomparsa anche a causa della scomodità el TDD: per fare qualsiasi cosa dovevi prima testare, veder fallire i test, farli diventare verdi, e cercare di capire perché qualche altro stramaledetto incomprensibile test falliva. troppo scomodo, se il team avesse avuto il via libera sul codice (cioè la possibilità di modificarlo come meglio credeva senza essere schiavi dei test) sarebbe stato molto più facile fare modifiche, correggere bug, ecc.
non nego che dovevano comunque esserci delle guidelines di scrittura del codice: fek ci ha insegnato a scrivere codice in una maniera secondo me PERFETTA, tant'è vero che il mio progetto per l'esame è scritto interamente a quel modo (codice "autoesplicativo", complessità ciclomatiche bassissime, quasi tutte inferiori a 4, identificatori kilometrici, zero commenti, pochi TODO, un solo FIXME), ed è stato sviluppato senza TDD.
Ma poi non ho capito 272613742 qualche mese fa facevi tutto il gasato del tdd e ora dici così? :) qualche mese fa il mio programma per l'università non l'avevo ancora iniziato :Prrr:
scherzi a parte, che "facessi il gasato del TDD" era vero ma non perché ne fossi diventato un fanatico che intendeva usarlo per il resto della sua vita. piuttosto perché volevo che il team lavorasse bene e che la smettessi di vedere schifezze di test che riportavano le seguenti caratteristiche:
* nome non esplicativo quasi identico a quello di tutti gli altri test del case
* 3 schermate di codice
* complessità ciclomatica superiore a 1!!!! questa nei test è una cosa che non ho mai potuto soffrire... :incazzed:
cioè cercavo semplicemente di spiegare agli altri la forma canonica di sviluppo che secondo me fek aveva voluto insegnarci (devo essere stato uno di quelli che l'hanno capita meglio visto che sono stato il primo a cui fek abbia dedicato un'intera serata per insegnarmela con un pair :))
(devo essere stato uno di quelli che l'hanno capita meglio visto che sono stato il primo a cui fek abbia dedicato un'intera serata per insegnarmela con un pair :)) oddio a pensarci bene non sono molto sicuro... :wtf:
forse c'è stato VICIUS prima di me :D
però io alla fine ero l'unico maniaco che dopo qualche tempo s'è messo a sviluppare in TDD in forma pura :Prrr:
franksisca
29-12-2006, 13:30
a proposito, ma fek che fine ha fatto???
comunque, mi spieghi, brevemente, cosa intendi per complessità ciclomatica???
Ho ritrovato la storia del soviet development. E' citata nel Tanenbaum (Modern Operating System, 2nd ed., Ch 12, 12.5.2, p. 891) ma l'ho erroneamente attribuita all'Autore. E' di Harlan Mills e pare chiamarsi Chief Programmer Team. Risale agli anni '70 e non viene più usata da un bel po'.
comunque, mi spieghi, brevemente, cosa intendi per complessità ciclomatica??? un indicatore che ti da una buona idea della reale complessità del codice. una maniera semplice di calcolarlo per un metodo Java è partire da 1 ed incrementare ad ogni if, for, do, while, try. l'else invece non si conta.
era nell'idea di fek che lo stato "canonico" che avrebbe dovuto raggiungere Diamonds sarebbe stato nessun metodo di complessità ciclomatica superiore a 4 (che già era tanto per lui: quando un metodo raggiungeva 4 toccava suddividerlo, cosa che ho fatto anche io nel mio progetto).
Ho ritrovato la storia del soviet development. E' citata nel Tanenbaum (Modern Operating System, 2nd ed., Ch 12, 12.5.2, p. 891) ma l'ho erroneamente attribuita all'Autore. E' di Harlan Mills e pare chiamarsi Chief Programmer Team. Risale agli anni '70 e non viene più usata da un bel po'.
Chissà come mai eh :D
71104 se vuoi sviluppare agile i test ti servono, se devi fare refactoring i test ti servono è un dato di fatto, io non credo avrei la voglia di farmi il refactoring di BigGem senza i test. Devi inoltre considerare che il team di Diamonds è composto da gente inesperta con poco tempo e forse con poca voglia (non tutti). Secondo me il risultato ottenuto è stato molto molto buono considerando questi punti e comunque il TDD non è a prova di proiettile e se lo fai male lo fai male (concordo pienamente sulla pessima qualità di molti test).
Molti test avevano una qualità pessima perchè non sono state rispettate, per inesperienza o qualsivoglia, le famose regole KISS etc etc e ben pochi hanno rifattorizzato il codice dei test perchè pochi avevano voglia di scriverli.
Ricorda comunque che è stato un esperimento e molte cose probabilmente sarebbero potute funzionare meglio. A me l'esperienza è servita moltissimo e non darei assolutamente la colpa ai test perchè secondo me senza quelli non avremmo manco raggiunto la first playable.
Ricorda comunque che è stato un esperimento e molte cose probabilmente sarebbero potute funzionare meglio. A me l'esperienza è servita moltissimo e non darei assolutamente la colpa ai test perchè secondo me senza quelli non avremmo manco raggiunto la first playable. chi può dirlo... ricordati il vero scopo dei test: fallire quando si introducono bug. a me pare che la maggior parte delle volte che un test falliva su DC toccava refattorizzare quello piuttosto che il codice... io invece sono dell'idea che ciò che ci abbia veramente portato avanti fino ad un buon punto sia semplicemente il modo in cui fek ci ha insegnato a scrivere il codice vero e proprio (leggi post precedente: complessità ciclomatiche basse, ecc. ecc.).
chi può dirlo... ricordati il vero scopo dei test: fallire quando si introducono bug. a me pare che la maggior parte delle volte che un test falliva su DC toccava refattorizzare quello piuttosto che il codice... io invece sono dell'idea che ciò che ci abbia veramente portato avanti fino ad un buon punto sia semplicemente il modo in cui fek ci ha insegnato a scrivere il codice vero e proprio (leggi post precedente: complessità ciclomatiche basse, ecc. ecc.).
Secondo me si parla di due cose diverse, vabè dai l'off topic è durato troppo :D
comunque, mi spieghi, brevemente, cosa intendi per complessità ciclomatica???
E' una metrica del codice sorgente (anche detto McCabe complexity) che misura la complessità basandosi sul grafo di flusso del sorgente...
Ogni arco del grafo è una condizione di un costrutto di flusso (if, else, while, switch). Ogni nodo è un blocco di istruzioni raggiungibile solo attraverso gli archi entranti.
Dati n il numero di nodi e a il numero di archi la complessità ciclomatica è definita come:
V(g) = a - n + 2
franksisca
29-12-2006, 15:00
quindi, se ho quattro if innestati complessità 4, altrimenti se sono separati complessità 1, giusto???
interessante come concetto, nel corso di algoritmi e strutture dati ci hanno parlato di altre complessità, ma questa, sinceramente, non l'avevo mai sentita.
Sempre 4 ;)
Un "if" genera sempre un biforcazione del flusso...
http://en.wikipedia.org/wiki/Cyclomatic_complexity
quindi, se ho quattro if innestati complessità 4, altrimenti se sono separati complessità 1, giusto??? no! a parte che non è 4 ma è 5 perché si parte da 1, ma comunque rimane 5 anche se gli if stanno allo stesso livello. non importa se un branch è potuto avvenire solo perché ne è avvenuto un altro, di fatto ci stanno N branch e il programma potrebbe prendere N+1 strade diverse.
no! a parte che non è 4 ma è 5 perché si parte da 1, ma comunque rimane 5 anche se gli if stanno allo stesso livello. non importa se un branch è potuto avvenire solo perché ne è avvenuto un altro, di fatto ci stanno N branch e il programma potrebbe prendere N+1 strade diverse.
cioè prendi sempre il caso peggiore?
Come c'è scritto nel link sopra, misura il numero di percorsi linearmente indipendenti per attraversare il codice... Se entro in un if ho un percorso, se non ci entro ne ho un altro diverso...
franksisca
29-12-2006, 16:55
e con lo switch, ne considera n, per n casi dello switch???
jappilas
29-12-2006, 19:59
e con lo switch, ne considera n, per n casi dello switch???EDIT: sì, infatti per la comp ciclomatica contano sempre i code paths e:
uno switch dirama il codice in N paths qualora gli N statement case di cui è composto, includano anche default: , altrimenti dovrebbero essere N+1 ;)
franksisca
29-12-2006, 20:08
uno switch dirama il codice in N code paths se negli N statement case di cui è composto, rientra anche default:
altrimenti doivrebbero essere N+1 ;)
siamo d'accordo, ma a complessità, come lo considero???
siamo d'accordo, ma a complessità, come lo considero???
Sono N percorsi diversi e quindi conta N ;)
jappilas
29-12-2006, 20:32
come mio solito mi spiego male ... :stordita:
EDIT: ho editato anche il post precedente (scusa cionci :O)
franksisca
29-12-2006, 20:45
come mio solito mi spiego male ... :stordita:
capita anche a me, comunque grazie cionci.
Mi stavo guardando le SDL...rispetto alle OpenGL cosa cambia come difficoltà?
(Le SDL sono abbastanza usabili)
Ci sono una paio di cose che mi trattengono dal partecipare a Diamonds.
Il non saper programmare ad esempio?
Il non saper programmare ad esempio?
O il non voler mettermi alla testa di una colonna per poi sparire lasciandola al suo destino.
Buon anno! :D
Il non saper programmare ad esempio?
O________________________________________________________O''''''
morte agli infedeli l'Unica Mente è tornata arriva il Giudizio inchinatevi mortali O__O'
O il non voler mettermi alla testa di una colonna per poi sparire lasciandola al suo destino.
Buon anno! :D spiacente, ma a questo punto brucerai in eterno :ave:
ti sei ribellato e ti sei rivolto con insolenza a chi ha più potere di te :|
non vorrei essere nei tuoi panni :|
intanto però mi sa che qua l'Unica Mente se continua così la bannano di nuovo :asd: :D :D :D
jappilas
03-01-2007, 20:13
the fek is back , let's rejoyce... :)
... finalmente posso completare il mio addestramento facendomi insegnare come mettere su una build machine cruisecontrol :D
Invece di flammarvi che dite di rispondere alla domanda di un umile giovine avido di sapere posta proprio sopra il flame? :fagiano:
Ma che flame. E', anzi, un momento di pura ilarità. Andiamo, c'è chi ha tanto parlato del diavolo che alla fine è spuntato fekzebù in persona!
...brucerai in eterno
:D Quale fiero esempio dell'indomita esposizione al rischio di sostenere le proprie idee! E cosa mai sarà questo suono?! Odo forse un rumor di sciacquone? Chi, dunque, si affretta a gettar nel cesso le prove del suo misfatto pensiero! E a quali formidabili capriole stiamo per assistere amici miei! :D
Ma che flame. E', anzi, un momento di pura ilarità. HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHA no.
Andiamo, c'è chi ha tanto parlato del diavolo che alla fine è spuntato fekzebù in persona! FEKZEBù è stupenda :rotfl: :rotfl: :rotfl:
:D Quale fiero esempio dell'indomita esposizione al rischio di sostenere le proprie idee! E cosa mai sarà questo suono?! Odo forse un rumor di sciacquone? Chi, dunque, si affretta a gettar nel cesso le prove del suo misfatto pensiero! ma quali prove... :huh:
E a quali formidabili capriole stiamo per assistere amici miei! :D hoplà! hoplà! holplààà!!
PS: +1 :fagiano:
franksisca
04-01-2007, 09:34
Il non saper programmare ad esempio?
chi non muore si rivede, vorrà dire che DIAMONDS risorgerà???
mmm mi viene in mente una discussione di circa un anno fa... dove qualcuno ( :fiufiu: ) sosteneva che senza fek diamonds sarebbe morto :asd: .
ps. l'eXtreme Programming è un argomento che ho affrontato in un corso universitario.. consiglio la lettura di questo articolo http://homes.dico.unimi.it/~monga/lib/xp-md.pdf che in larga parte condivido
ho trovato un sito con le lessons su opengl :fagiano:
http://nehe.gamedev.net/
ho trovato un sito con le lessons su opengl :fagiano:
http://nehe.gamedev.net/
ci ho passato l'adolescenza a leggere quei tutorial :fagiano: ottimi comunque! forse solo un pò datati.. ma per la didattica superlativi :D
ho trovato un sito con le lessons su opengl :fagiano:
http://nehe.gamedev.net/ fidati, il problema di Diamond Crush non è l'uso di OpenGL... :fagiano:
fidati, il problema di Diamond Crush non è l'uso di OpenGL... :fagiano:
No, dato che voi non rispondevate al quesito ho trovato da solo la risposta e ve l'ho postata :asd:
A diamond crush non ci ho pensato proprio a dire il vero :asd:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.