Configuration file

[^TiGeRShArK^]

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?

[thebol]

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.

[Jocchan]

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

[fek]

Originariamente inviato da Jocchan

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.

[VICIUS]

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

[Ufo13]

secondo me in XML è molto figo e permette un controllo migliore...

[DanieleC88]

Originariamente inviato da Ufo13

secondo me in XML è molto figo e permette un controllo migliore...

Si vabbe' ma non dobbiamo usarlo perche' e' PHIGO.
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.

[fek]

Originariamente inviato da Ufo13

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.

[fek]

Originariamente inviato da VICIUS

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.

[Ufo13]

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]

Originariamente inviato da Ufo13

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.

[fek]

Originariamente inviato da Ufo13

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.

[Bonfo]

PHIGO??? e chè vuol dire??

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à

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.

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ì??

[fek]

Originariamente inviato da Bonfo

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à

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ì??

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.

[Bonfo]

Domanda da ingegnere... o meglio futuro ingegnere (mi manca a poco):
ma allora che cacchio ci hanno spiegato e insegnato??

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 :
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 ).
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

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

Grazie a tutti voi...
...mi sto divertendo e esaltando come da un po' non mi succedeva!

[^TiGeRShArK^]

Innanzitutto mi dispiace per vicius...
so cosa si prova e il suo codice nel config mi piaceva anke molto
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

[fek]

Originariamente inviato da Bonfo

Domanda da ingegnere... o meglio futuro ingegnere (mi manca a poco):
ma allora che cacchio ci hanno spiegato e insegnato??

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 :
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 ).
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^]

Originariamente inviato da fek

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

MA LOOOLLLL!!!!
bellissimo quest'esempio!

[Bonfo]

Grazie mille Fek
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 () 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...

[thebol]

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 ), 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 )