View Full Version : Configuration file
^TiGeRShArK^
14-01-2006, 17:03
Ero capitato dalle parti del codice in cui accediamo alla configurazione....
mi stavo chiedendo... ma abbiamo davvero bisogno di un file xml per scrivere la configurazione del gioco?
non basterebbe uno dei normalissimi properties file che vengono usati in java?
piu' che altro questo semplificherebbe notevolmente il codice di gestione della configurazione.
questo è il codice per caricare la configurazione da un file di properties e leggere una qualsiasi proprietà sotto forma di stringa:
// Read properties file.
Properties properties = new Properties();
try {
properties.load(new FileInputStream("filename.properties"));
} catch (IOException e) {
}
String property1 = properties.getProperty("key");
il formato del file invece è semplicemente:
GravityMultpiplier = 8
InputRate = 60
...
Perchè quindi abbiamo usato l'xml? :fagiano:
truissimo, anche a lavoro si usano per lo piu file di properties.
l'xml viene usato se le info di configurazione sono un po piu strutturate, tipo per descrizione di tabelle, oppure per le connesioni a db.
Non so se c'è un qualche motivo fondamentale, ma visto che gli oggetti in GameConfig stanno iniziando a diventare tanti, passare ad una struttura più semplice sarebbe una cosa molto gradita ;)
Non so se c'è un qualche motivo fondamentale, ma visto che gli oggetti in GameConfig stanno iniziando a diventare tanti, passare ad una struttura più semplice sarebbe una cosa molto gradita ;)
Quando lo reputi necessario inseriscilo pure in una Storia.
Una parte di me è favorevole a questo cambiamento. L'altra non sopporta di vedere il codice attuale di Config venir cancellato con un semplice svn commit. Dopo tutto il sudore che ho versato durante il suo refactoring mi ci sono affezionato.
ciao ;)
secondo me in XML è molto figo e permette un controllo migliore...
DanieleC88
15-01-2006, 09:11
secondo me in XML è molto figo e permette un controllo migliore...
Si vabbe' ma non dobbiamo usarlo perche' e' PHIGO. :D
Se ci e' utile XML lo utilizziamo, altrimenti ciccia. Mi dispiace solo per VICIUS che si e' fatto un mazzo tanto per la configurazione e va orgoglioso del risultato. In effetti cancellare tutto con un click sembra quasi crudele, ma se necessario... facciamolo. :)
secondo me in XML è molto figo e permette un controllo migliore...
Se possiamo fare quello che ci serve con un sistema piu' semplice, usiamo quello. Quando e se ce ne servira' uno piu' complesso lo valuteremo.
Una parte di me è favorevole a questo cambiamento. L'altra non sopporta di vedere il codice attuale di Config venir cancellato con un semplice svn commit. Dopo tutto il sudore che ho versato durante il suo refactoring mi ci sono affezionato.
ciao ;)
Mi hanno cancellato interi mesi di lavoro con un click :(
Purtroppo e' cosi', quello che conta e' il progetto. A me piace pensare che tutto il codice che scrivo mi abbia insegnato qualcosa, quindi anche se non venisse usato, ho comunque imparato qualcosa dal lavoro che ho fatto e non e' andato perso.
Daniele: Il fatto del phigo ovviamente è per dire che è molto versatile e permette il controllo sui dati tramite lo schema... Avere il config in XML NON è un problema al momento...
Fek: Il sistema più semplice non è lasciare tutto com'è senza perdere altro tempo per rifarlo da capo?
DanieleC88
15-01-2006, 11:55
Daniele: Il fatto del phigo ovviamente è per dire che è molto versatile e permette il controllo sui dati tramite lo schema... Avere il config in XML NON è un problema al momento...
Si lo so, XML e' decisamente piu' completo, ma e' anche piu' complesso. Se abbiamo un semplice file con linee tipo "foo = bar" non ci mettiamo niente a gestirlo. Se la complessita' non ci serve, la eliminiamo.
Daniele: Il fatto del phigo ovviamente è per dire che è molto versatile e permette il controllo sui dati tramite lo schema... Avere il config in XML NON è un problema al momento...
Fek: Il sistema più semplice non è lasciare tutto com'è senza perdere altro tempo per rifarlo da capo?
La flessibilita' si paga sempre in termini di flessibilita'. Se non abbiamo bisogno di questa complessita', non ne vogliamo pagare il suo costo (codice piu' complesso). "Do the simples thing that could possibly work".
Il sistema piu' semplice e' fare refactoring del codice di Config per usare qualcosa di piu' semplice, meno flessibile ma che risolve perfettamente le nostre esigenze del momento. In futuro vedremo: YAGNI.
PHIGO??? e chè vuol dire?? :confused: :bimbo:
Il sistema di configurazione lo abbiamo già ??
Bhè alllora lasciarlo lì è la cosa più semplce per far funzionare il tutto!
Poi non mi sembra molto furbo sostituire il tutto per avere qualcosa di più semplice se poi in un futuro per avere qualcosa di più potente e felssibile bisogna riniziare da capo...dove la mettiamo la riusabilità :D
Poi l'XML ci garantisce l'uso di uno standard interpiattaforma...da non sottovalutare per futuri sviluppi e poi se mai dovessimo gestire dati complessi avremmo già tutto pronto.
io voto XML. :sofico:
:doh: Mi sono appena reso conto che ritorno alle metodologie classiche di progettazione software scordandomi l'ordine YAGNI ...va contro ogni mia abitudine :(
@Fek: ma dove hai imparato a essere così "agile"? là in inghilterra sviluppate così?? :eekk:
Poi non mi sembra molto furbo sostituire il tutto per avere qualcosa di più semplice se poi in un futuro per avere qualcosa di più potente e felssibile bisogna riniziare da capo...dove la mettiamo la riusabilità :D
Non ci interessa la riusabilita', ci interessa la produttivita', quindi... YAGNI :)
Poi l'XML ci garantisce l'uso di uno standard interpiattaforma...da non sottovalutare per futuri sviluppi e poi se mai dovessimo gestire dati complessi avremmo già tutto pronto.
YAGNI.
@Fek: ma dove hai imparato a essere così "agile"? là in inghilterra sviluppate così?? :eekk:
In parte. L'Industry e' un ambiente un po' reazionario da questo punto di vista, ma in un'ambiente altamente sotto pressione si impara comunque a non overingegnerizzare (e io lo facevo spesso e volentieri) e a risolvere i problemi in maniera semplice.
Diciamo che quando vi dico di non overingegnerizzare, ve lo dico perche' io lo facevo e ne ho pagate spesso e volentieri le conseguenze.
Domanda da ingegnere... o meglio futuro ingegnere (mi manca a poco):
ma allora che cacchio ci hanno spiegato e insegnato?? :wtf:
Mi hanno fatto una testa tanta nel dire: "non fate subito codice...pensate e studiate per trovare la soluzione che vi garantisce massima resa e minimo sforzo per il futuro...in modo che ogni cosa che ti capita nel futuro sei pronto a risolverla"
L'immagine più bella che ho in mente è del mio prof di ingegneria del Software, quello della triennale non quello della specialistica che lo ammazzerei :mad: :incazzed: :
Lo sviluppo software è come una palo di legno in un muro. Quando capita qualcosa è come un peso che va a colpire l'asta...se arriva subito non c'è problema perchè il muro ci aiuta, ma se arriva più avanti dipende quando siamo stati bravi ad essere flessibili (insomma tutto quello che fek ci dice di scordarci :D :D).
Così se il cliente arriva e ti chiede una cosa nuova e imprevista (per lui, ma no per te che già in analisi l'avevi calcolata) gli dici: faccio tutto quello che vuole...aggiunga 2 zeri alla cifra ;) ... e il tutto con sforzo nullo (sempre contando di aver guardato avanti).
AIUTO :help: :help:
Scusate se sono andato così OFF TOPIC, ma non vi posso negare come il TDD mi stia appassionando e piacendo...ma anche lo sforzo disumano che sto chiedendo alla mia natura :D :D
Grazie a tutti voi... :ave: :ave:
...mi sto divertendo e esaltando come da un po' non mi succedeva! :yeah:
^TiGeRShArK^
15-01-2006, 15:54
Innanzitutto mi dispiace per vicius...
so cosa si prova e il suo codice nel config mi piaceva anke molto :D
però anche a livello di gestione del file di configurazione guadagniamo molto in leggibilità:
<configuration>
<property type="integer" name="GravityMultiplier">8</property>
<property type="integer" name="StrongestGravityMultiplier">20</property>
<property type="integer" name="InputRate">60</property>
<property type="integer" name="NormalRepeatDelay">200</property>
<property type="integer" name="FastRepeatDelay">100</property>
<property type="integer" name="FrameRate">20</property>
<property type="integer" name="UpdateRate">10</property>
<property type="integer" name="GemAnimationDelay">3500</property>
<property type="integer" name="GemAnimationUpdateRate">100</property>
<property type="integer" name="NewGemDelay">300</property>
<property type="integer" name="width">800</property>
<property type="integer" name="height">600</property>
<property type="integer" name="rows">14</property>
<property type="integer" name="columns">8</property>
<property type="integer" name="SizeMultiplier">4</property>
<property type="integer" name="SpeedDivisor">10</property>
</configuration>
invece con le properties normali si ha:
GravityMultiplier = 8
StrongestGravityMultiplier = 20
InputRate = 60
NormalRepeatDelay = 200
FastRepeatDelay = 100
FrameRate = 20
UpdateRate = 10
GemAnimationDelay = 3500
GemAnimationUpdateRate = 100
NewGemDelay = 300
width = 800
height = 600
rows = 14
columns = 8
SizeMultiplier = 4
SpeedDivisor = 10
Immagino non ci siano dubbi su quale sia il piu' semplice e leggibile ;)
Domanda da ingegnere... o meglio futuro ingegnere (mi manca a poco):
ma allora che cacchio ci hanno spiegato e insegnato?? :wtf:
Mi hanno fatto una testa tanta nel dire: "non fate subito codice...pensate e studiate per trovare la soluzione che vi garantisce massima resa e minimo sforzo per il futuro...in modo che ogni cosa che ti capita nel futuro sei pronto a risolverla"
I professori universitari spesso e volentieri non hanno esperienza sul campo dello sviluppo software, ma solo un'esperienza teorica. E le teorie si modificano col tempo quando si hanno piu' dati a disposizione e piu' tecniche fra le quali scegliere.
Quello che ti hanno insegnato si sa oggi che non e' il modo piu' produttivo di scrivere la maggior parte del codice, non si sapeva ieri: l'Ingegneria del Software e' una materia ancora relativamente giovane, ha poche decine di anni. L'Ingegneria Civile, ad esempio, ha una storia di milenni.
L'immagine più bella che ho in mente è del mio prof di ingegneria del Software, quello della triennale non quello della specialistica che lo ammazzerei :mad: :incazzed: :
Lo sviluppo software è come una palo di legno in un muro. Quando capita qualcosa è come un peso che va a colpire l'asta...se arriva subito non c'è problema perchè il muro ci aiuta, ma se arriva più avanti dipende quando siamo stati bravi ad essere flessibili (insomma tutto quello che fek ci dice di scordarci :D :D).
Così se il cliente arriva e ti chiede una cosa nuova e imprevista (per lui, ma no per te che già in analisi l'avevi calcolata) gli dici: faccio tutto quello che vuole...aggiunga 2 zeri alla cifra ;) ... e il tutto con sforzo nullo (sempre contando di aver guardato avanti).
Se arriva il cliente e ti chiede una cosa nuova e prevista da te ti costa zero da aggiungere, pero' ti e' costato svariati zeri introdurre quella flessibilita' e tutto il resto della flessibilita' che non hai usato.
Di contro, se introduci flessibilita' solo al momento in cui ne hai bisogno e adotti pratiche tali che il costo di un cambiamento sia relativamente costante durante tutto il corso del progetto, allora potrai prevedere con buona esattezza quanto la nuova feature che ti e' stata chiesta ti costera', e non ti sara' necessario averla prevista e avrai sempre e solo pagato per cio' che hai usato.
Al contrario il professore ti sta insegnando questo: se tu devi andare da Roma a Milano entro domani, affitta un elicottero, perche' magari il treno si rompe, magari a Milano la stazione e' in sciopero, magari piove e arrivi in ritardo, magari poi decidi che vuoi arrivare prima, magari poi prenota un viaggio a New York perche' ti potrebbe servire, cerca di prevedere tutto. Ma a te serve solo arrivare a Milano entro domani ;)
^TiGeRShArK^
15-01-2006, 16:01
Al contrario il professore ti sta insegnando questo: se tu devi andare da Roma a Milano entro domani, affitta un elicottero, perche' magari il treno si rompe, magari a Milano la stazione e' in sciopero, magari piove e arrivi in ritardo, magari poi decidi che vuoi arrivare prima, magari poi prenota un viaggio a New York perche' ti potrebbe servire, cerca di prevedere tutto. Ma a te serve solo arrivare a Milano entro domani ;)
:rotfl:
MA LOOOLLLL!!!!:rotfl:
bellissimo quest'esempio! :D
Grazie mille Fek :ave:
Ma ora mi vengono altre domande:
e adotti pratiche tali che il costo di un cambiamento sia relativamente costante durante tutto il corso del progetto
...ma come cacchio fai ha essere in grado di aumentare la flesibilità all'improvviso se prima non hai fatto nulla che te lo premettesse.
E poi se domani facessimo Fruit Crush (:rotfl:) dovremmo ricominciare da capo...non è detto che i componenti creati, senza fornigli in anticipo la felsibilità necessaria, possano essere riutilizzati facendo sì che dobbiamo rifare lavoro inutile, senza mai poter procedere in avanti.
Sono tutta cavolate... :confused: :(
la flessibilita si realizza non facendo overenginering(meno roba cè, a meno roba dovrai pensare quando fai un cambiamento in corso) e procedendo per refactoring. Il refactoring risulta possibile perche il codice è scritto in maniera semplice(non facile) e ci sono i test che assicurano un passaggio di refactoring piu sicuro.
cmq se vuoi approfondire, ti consiglio extreme programming explained di beck(si trova anche online :fagiano: ), che spiega l'xp e perche secondo lui(che ne è praticamente il creatore) dovrebbe funzionare.
il libro non è neanche molto lungo(in confronto a quello sui pattern e quello sul refactoring...rispettivamente 300 e 400 pagine :help: )
Bonfo anche XP programming fa parte del campo dell'Ingegneria del Software...
Esistonono svariati metodi di sviluppo SW... Citando i più comuni: Phased Development, XP Programming, V-Model, Waterfall, etc...
Se i docenti ti hanno insegnato che il metodo "giusto" è solo uno non sono dei buoni docenti...
Poi la riusabilità dipende molto da quello che stai facendo... All'interno di certe aziende la riusabilità è importante...
Conosco il signor Beck...o meglio Beck2000 e Beck2003 :D
NO...certo che mi hanno onsegnato tutti i modelli di sviluppoi software: cascata, spirale, iterativo incrementale, XP, ecc..
Il mio ultimo corso ha praticamente speso il 90% ( non insegnandoci niente di strumenti per lo svilupppo di software :incazzed: ) sul dilemma:
Model Driven o XP ?? :mbe:
Ovvero è meglio porsi tutti problemi prima e fare tutta una serie di documenti che descrivonbo il progetto facendo sì che l'implemntazioni risulti solo un passo conclusivo oppure sviluppare in modo che il codice stesso raprresenti il progetto, sia implementazione che documenrtazione ?
Qui siamo XP, o meglio TDD, che mi risulta essere XP all'ennesima potenza :D e ripeto che mi sta piacendo e appassionando. :D
Ma capite che dopo 2 mesi sulla discussione.... :muro:
Grazie mille Fek :ave:
...ma come cacchio fai ha essere in grado di aumentare la flesibilità all'improvviso se prima non hai fatto nulla che te lo premettesse.
E' proprio perche' non hai fatto nulla prima (e hai adottato certe pratiche) e quindi la qualita' del codice e' alta che puoi velocemente introdurre flessibilita' al momento che ti serve, e puoi introdurla ad un costo costante nel tempo. E' questa la chiave di volta: non e' tanto importante che qualcosa costi poco, e' importante che tu possa prevederne in maniera il piu' possibile esatta il suo costo.
Esempio:
1) La feature X costa da 10 a 1000, non lo sappiamo
2) La feature X costa 20 a 25
Quale scegli?
E poi se domani facessimo Fruit Crush (:rotfl:) dovremmo ricominciare da capo...non è detto che i componenti creati, senza fornigli in anticipo la felsibilità necessaria, possano essere riutilizzati facendo sì che dobbiamo rifare lavoro inutile, senza mai poter procedere in avanti.
Se domani facessimo Fruit Crush guarderemmo la nostra code base alla ricerca di tutto cio' che e' potenzialmente riutilizzabile e da li' partiremo ad aggiungere le sole funzionalita' che ci servono, sicuri che il codice di partenza sia ad alta qualita' ed ogni modifica che gli faremo avra' un costo costante e prevedibile.
Il progetto precedente avra' pagato solo la flessibilita' di cui aveva bisogno e non di piu', e sara' stato concluso nel tempo strettamente necessario. D'altronde, e se non ci fosse mai un Fruit Crush? Perche' pagarlo in anticipo?
Ovvero è meglio porsi tutti problemi prima e fare tutta una serie di documenti che descrivonbo il progetto facendo sì che l'implemntazioni risulti solo un passo conclusivo oppure sviluppare in modo che il codice stesso raprresenti il progetto, sia implementazione che documenrtazione ?
Che cosa ti hanno risposto? :)
Guarda il dev plan di Diamonds Crush, noi sappiamo con una precisione davvero alta quando finiremo, perche' sappiamo ad ogni iterazione quanti task riusciamo a svolgere e sappiamo quanti task ci mancano alla fine. E siamo in grado, qualora fossero necessari cambiamenti imprevisti (e lo saranno), cambiare il dev plan e rifare una previsione accurata del costo di quel cambiamento. Noi sappiamo che possiamo svolgere 10/12 task a iterazione e pianifichiamo sulla base di queste metriche che descrivono la nostra velocita'.
Non puoi fare la stessa cosa con una metodologia Waterfall, ad esempio, perche' se ci fosse un cambiamento nei requisiti dovremmo rifare l'analisi e il design, aggiustarlo per qualcosa di imprevisto, cambiare il codice di conseguenza e questo cambiamento avra' un costo imprevedibile. Perche' e' matematico che non puoi prevedere tutto, non puoi aggiungere flessibilita' infinita al sistema, significherebbe avere infinito codice e poi chi ci vuole lavorare con codice infinito? :D
Risposta: nessuna !
Bhè...diciamo che il mio ultimo porofessore era Model driven...anche se devo essere sincero ha cercato, durante il corso, di lasciarci scegliere.
Anche se però all'orale ( :incazzed: :incazzed: :incazzed::incazzed: :incazzed: )
si è lanciato con la dichiarazione: "è per questo che l'XP non ha futuro: ogni volta che in un altro progetto o in futuro avrà bisogno di qualcosa di già fatto ma non uguale dovrà rifarselo" (parlava di infrastutture di comunicazione . se si riesce ad averne una flessibile si può utilizzarla in tutti i progetti...diciamo un framework)
significherebbe avere infinito codice :eekk: :asd: :asd:
Ecco..rispondendo mi è venuto un altro dubbio...
Siamo nella azienda HWUpgrade e stiamo facendo un progetto. Facciamo per esempio che si chiami Diamond Crush (:asd:) e pensiamo in futuro di fare altri 10000 videogiochi...con processi di sviluppo agili è possibile pensare di introdurre un Framework per lo sviluppo di tutti i videogiochi??
@fek: dai...raccontaci come fate al lavoro. Perchè non ci credo che non avete un framework di sviluppo !!!
Se posso dire la mia... Come si comportano i properties file con elementi diversi...stringhe, interi o floating point ? Se poi bisogna stare a fare il parsing credo che per ora convenga tenere questo...poi se alla fine viediamo che carichiamo solo interi allora non ci saranno problemi ad usare un properties file... Ovviamente imho :)
si è lanciato con la dichiarazione: "è per questo che l'XP non ha futuro: ogni volta che in un altro progetto o in futuro avrà bisogno di qualcosa di già fatto ma non uguale dovrà rifarselo" (parlava di infrastutture di comunicazione . se si riesce ad averne una flessibile si può utilizzarla in tutti i progetti...diciamo un framework)
E su questo invece ha clamorosamente torto :)
Le metodologie agili non affermano che non si debba usare un framework o non se ne debba scrivere uno, affermano che non si deve scrivere un intero framework prima di iniziare lo sviluppo.
Ora, a parte che nel 90% dei casi non c'e' un altro progetto, a parte che non si puo' scrivere un framework che vada bene per tutti i progetti per ovvi motivi, nulla vieta di prendere il framework che e' emerso dall'ultimo progetto e riutilizzarlo tutto o in parte per il nuovo progetto. E' li', e' minimale, e' facile da estendere per tutto quello che abbiamo detto, e' ben testato, ha gia' funzionato, non vedo perche' non se ne possa riutilizzare una parte. Ed infatti e' quello che succede ad esempio in ThoughtWorks.
Ecco..rispondendo mi è venuto un altro dubbio...
Siamo nella azienda HWUpgrade e stiamo facendo un progetto. Facciamo per esempio che si chiami Diamond Crush (:asd:) e pensiamo in futuro di fare altri 10000 videogiochi...con processi di sviluppo agili è possibile pensare di introdurre un Framework per lo sviluppo di tutti i videogiochi??
Non solo e' impossibile, ma e' controproducente. Tutti quelli che ci hanno provato hanno fallito. Quello che possiamo fare e' prendere il codice che abbiamo gia' sviluppato e usarne parti che sono emerse generali in altri progetti. Avere una specie di repository gerarchico dove alla fine di ogni iterazione fai "salire" nella gerarchia porzioni di codice. Ti dico di piu', appena capisco come condividere progetti in Java e' esattamente quello che faremo :)
@fek: dai...raccontaci come fate al lavoro. Perchè non ci credo che non avete un framework di sviluppo !!!
Lasciamo perdere che e' meglio, qui e' una lotta per la sopravvivenza e litigo un giorno si' e l'altro pure per difendere il concetto di Semplicita' :)
Non applichiamo una metodologia agile (e ne paghiamo le conseguenze), come ti avevo scritto l'Industry e' piuttosto reazionaria. Quello che mi piacerebbe in futuro, fra qualche anno, e' coadiuvare una metodologia agile con la necessita' di essere creativi e portare questi concetti stabilmente nell'Industry. Chissa' se ci riusciro' :)
(Qui stanno cercando di costruire un framework per tutti i giochi, sono mesi che ci lavorano e ancora non si e' visto nulla, in compenso ci ritarda il lavoro; il che dovrebbe farti capire il perche' non sono molto favorevole alla cosa ;))
Se posso dire la mia... Come si comportano i properties file con elementi diversi...stringhe, interi o floating point ? Se poi bisogna stare a fare il parsing credo che per ora convenga tenere questo...poi se alla fine viediamo che carichiamo solo interi allora non ci saranno problemi ad usare un properties file... Ovviamente imho :)
Cionci e' il contrario. Per ora ci servono solo interi, se poi scopriamo che ci servono elementi piu' complessi allora cambiamo. YAGNI.
Cionci e' il contrario. Per ora ci servono solo interi, se poi scopriamo che ci servono elementi piu' complessi allora cambiamo. YAGNI.
Lo so...ma ormai è stato fatto...avremo dovuto pensarci prima :D
Lo so...ma ormai è stato fatto...avremo dovuto pensarci prima :D
Ci pensiamo adesso :)
Waccka Fek...grazie mille per la disponibilità!! :ave:
Mi sati convincendo molto più tu del mio prof :asd: :asd: :asd:
Molto bella il concetto di gerarchia dinamica al termine di ogni iterazione di progetto ;)
Ma cosa intendi per condividere i progetti in Java??
Non avendo mai usato Java per nulla di serio prima di oggi, non so come condividere decentemente una libreria fra piu' progetti con Eclipse :p
Non avendo mai usato Java per nulla di serio prima di oggi, non so come condividere decentemente una libreria fra piu' progetti con Eclipse :p
allora, se in un progetto vuoi condividere all'esterno qualcosa la strada è:
progetto->properties->Java build path->order and export: qua selezioni librerie e codice da esportare(se sono jar li devi avere prima addati alle libraries come adesso in diamonds).
se invece in un progetto vuoi addare un altro progetto in modo che utilizzi le risorse dell'altro progetto:
progetto->properties->Java build path->Projects: Addi il project e via.
mi rimane solo un dubbio, ora faccio una prova, creando un progetto per le opengl e poi lo lego a diamonds e vedo come va :)
provato, e funge(ho spostato solo i jar di lwjgl però)
pero ant non segue eclipse e non li trova...
bisogna ridisegnare i path nel build file
ma LOL, stiamo buttando all'aria qualche centinaio di righe di codice e tutti gli YAGNI che dice fek non so voi ma a me suonano tanto come dei "GNE' GNE-GNE GNE'!!! :Prrr: :Prrr: :Prrr:" :rotfl: :rotfl: :rotfl:
cmq scherzi a parte (:D) anche io sono nettamente a favore dell'eliminazione dell'overhead dovuto al caricamento del file XML; VICIUS, non lo ripete forse spesso fek che non dobbiamo affezionarci al codice che scriviamo?? :Prrr:
^TiGeRShArK^
16-01-2006, 18:49
ma LOL, stiamo buttando all'aria qualche centinaio di righe di codice e tutti gli YAGNI che dice fek non so voi ma a me suonano tanto come dei "GNE' GNE-GNE GNE'!!! :Prrr: :Prrr: :Prrr:" :rotfl: :rotfl: :rotfl:
cmq scherzi a parte (:D) anche io sono nettamente a favore dell'eliminazione dell'overhead dovuto al caricamento del file XML; VICIUS, non lo ripete forse spesso fek che non dobbiamo affezionarci al codice che scriviamo?? :Prrr:
:rotfl:
e le tue pernacchiette non sono forse uno GNE' GNE-GNE GNE'!!!???
:D
:rotfl:
provato, e funge(ho spostato solo i jar di lwjgl però)
pero ant non segue eclipse e non li trova...
bisogna ridisegnare i path nel build file
Questo non e' affatto un problema, ci posso pensare io.
Grazie per l'aiuto :)
ps.
fare un progetto(o piu) con solo i jar, lib e dll sarebbe molto comodo per fare un replace di diamonds, che non sarebbe piu da 20M.
inoltre sarebbe piu agile fare branch per spike e cose simili :)
Secondo me la soluzione migliore è:
-cartella lib
-si fa un file build.xml che impacchetti in un jar qualcosa e lo metta in lib
- nei progetti dopo si mette nel classpath la cartella lib
in questo modo ogni progetto pesca da lib e se un progetto risulta essere una libreria, si compila prima quello per fare il jar e poi il secondo che così lo utilizza
A voelre fare i grossi :sofico: si potrebbe fare un build.xml generale che invoca in ordine i build dei sotto progetti
Mi sono spiegato o ho fatto solo casino??
^TiGeRShArK^
16-01-2006, 21:24
infatti è ks ke si fa...
si crea la distribuzione in jar del progetto sotto la cartella dist o lib e gli altri progetti ke lo usano importano quel jar..
addirittura si può fare in modo di invocare la compilazione su diamonds prima di compilare un progetto ke lo usi in modo da essere sempre sicuri di utilizzare la versione aggiornata.
Un minuto di silenzio per i file .xml, lo schema .xsd e il codice della vecchia classe Config che ci hanno lasciato per sempre. Sono sicuro che ora si trovano in un PC migliore in cui il codice sorgente può girare liberamente per sterminati banchi di ram senza preoccuparsi dei bugs. :D
ciao ;)
http://www.rochdale.gov.uk/images_RMBC/Living/grave.gif
jappilas
17-01-2006, 11:45
Un minuto di silenzio per i file .xml, lo schema .xsd e il codice della vecchia classe Config che ci hanno lasciato per sempre. Sono sicuro che ora si trovano in un PC migliore in cui il codice sorgente può girare liberamente per sterminati banchi di ram senza preoccuparsi dei bugs. :D
ciao ;)
pace all' anima sua... :cry:
DanieleC88
17-01-2006, 12:15
Un minuto di silenzio per i file .xml, lo schema .xsd e il codice della vecchia classe Config che ci hanno lasciato per sempre. Sono sicuro che ora si trovano in un PC migliore in cui il codice sorgente può girare liberamente per sterminati banchi di ram senza preoccuparsi dei bugs. :D
ciao ;)
:mbe:
:eek: :cry: :cry: :cry:
:D
^TiGeRShArK^
17-01-2006, 13:39
Rest In Peace
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.