giovedì 14 maggio 2009

Se davvero volete un numero Random....

E' possibile che vi torni utile questo....




Già perchè dopo un lungo Test mi sono accorto che le cose non sono sempre belle come vengono dipinte.. anzi

5000 è il numero più accettabile di iterazioni .. vi dico solo che sono partito da 100... e fino a 200 niente risulati...

Ma si tratta davvero di random ?

Nel framework esiste la comoda classe Random... che a volte va a volte no.
Se fate qualche prova vi renderete conto che non sempre funziona a dovere, questo perchè "ptrebbe essere troppo veloce" o "troppo breve la latenza" fra una generazione e l'altra.

Osservate questo codice che cosa genera.



Qualcosa non convince...


Gli elementi evidenziati sono uguali e questo appare discretamente rischioso.

Mi sono accorto di questo problema utilizzando xna, nella creazione di uno screen saver mi sono accorto che tutti gli elementi generati a caso avevano le stesse coordinate.

I più saccenti potrebbero suggerire lo spostamento di Random r = new Random() all'interno del for e utilizare come seed, o l'indice del for o qualche altro strano valore...

Ma se osservate bene il codice... quelli generati per la terza colonna provengono da un nuova variabile "b"...
E' questo quello che secondo me è grave..


Perchè è questo che si verifica se le metto nel for...

Quindi Random .. random .. proprio no direi !!

Server.MapPath()... Dove come quando...

Si potrebbe suppore che in un applicazione Web torni decisamente utile sapere sia dove ci si trova, fisicamente sia logicamente.
E' pur vero che si possa utilizzare una variabile di sessione o un parametro di configurazione a cui accedere liberamente, ma non sempre è così.

In asp.Net possiamo trovare due comodi operatori Server.MapPath() e "~", che sono indispensabili o quasi in tutte le applicazioni web.

Supponiamo di avere un applicazione con larga scala di distribuzione, questa deve essere :
Semplice
Facilmente Configurabile
Decisamente MOLTO fruibile.

Questi pochi termini implicano che il "mazzo" che si deve fare lo sviluppatore è davvero enorme.
Con semplice Si intende che qualsiasi tipo di utente deve potere essere nella condizione di installare e agire sul prodotto.
Non con i classici Wizard di Start up che una volta usati scompaiono... e chi si è visto si è visto...
Questo implica che Facilmente Configurabile è la possibilità di intervenire sul prodotto Tempestivamente per modficarne la configurazione e non "disinstalla tutto fai 300 backup... e spera".
Con decisamente molto fruibile intendo che l'applicazione ovunque essa sia possa essere modificata in toto o quasi.

A tal proposito è di fondamentale importanza partire con una struttura di configurazione ben strutturata.
E' possibile usare una classe che mantenga viva la configurazione del sito sempre... o fino a quando non scade la sessione.

Dal mio canto mi trovo comodo a rimmapare qualcosa come
string SiteVirtualRootPath = "~";
string SiteRealRootPath = Server.MapPath("~");

in questo modo posso richiedere al mio Configuration Provider come e quando voglio il dove e come sono.

mercoledì 13 maggio 2009

Non andiamo molto bene....


Come sempre mi trovo ad affrontare cose mai viste.... ma questa le batte davvero tutte.

Sembrerebbe che si verifichi un eccezione in SYSTEM.XML.DLL, e va bene ma dato che sfrutto la libreria, invocando la chiamata all'interno di un try catch mi aspetto che sia il mio codice a gestirlo... ma qualcosa non va.

Quando si verifica questa schifezza...
Semplice quanto state cercando di serializzare un file xml che non contiene elementi.. più o meno qualcosa di simile a
questo:

Che cosa si può fare per evitare un problema simile ???
utilizzando un piccolo "trucco" verificando che la lunghezza del file sia consona con almeno un elemento...

cmq... non andiamo bene. Se un applicativo non riesce a rilasciare la gestione di un eccezione .. e perchè già al suo interno
non è gestita..

ahi ahi ahi !!