Di seguito tutti gli interventi pubblicati sul sito, in ordine cronologico.
 
 

Eccomi sbarcato nel mondo dei blog.

Perchè un ulteriore blog in ambito informatico?
Semplicemente perchè durante il mio quotidiano lavoro in ambienti come .NET, Sql Server o più semplicemente applicazioni .asp,
mi sono trovato a cercare soluzione a problematiche che probabilmente qualcun altro ha o ha avuto e che voglio condividere.

Questi 'appunti di viaggio' sono dichiaratamente pratico/operativi e lasciano ad altri riferimenti più titolati la trattazione rigorosa e teorica comunque indispensabile per approfondire tali argomenti.

Il nuovo sito, naturalmente, eredita tutti i contenuti delle precedenti versioni adattati al nuovo 'container' dasBlog.

Capiterà, probabilmente, che i giorni successivi ad un gran premio di F1 inserisca un mio commento sull'esito della gara,
ma questo esula dallo scopo principale del sito.

dario

F0SO - Formul@ 0ne Strategy Optimizer

Cosa e' F0SO Da grande appassionato di competizioni ed in particolare di F1 e lavorando nel settore dell'IT, mi sono spesso domandato come queste due passioni potessero convergere in qualcosa di interessante (almeno per me). A questo si aggiunge una ciclica amarezza (stranamente questo sentimento occorre proprio durante le domeniche in cui si corre un gp...) nel costatare le quantomeno discutibili strategie adottate dai team che seguo con affetto (japan-oriented). Da questi presupposti nasce l'idea di un analizzatore di strategie per le competizioni motoristiche, in particolare quelle in cui sono previsti dei pit-stop mirati al cambio gomme e al rifornimento di carburante. Il nome F0SO altri non e' che un acronimo per l'altisonante definizione Formul@ 0ne Strategy Optimizer, anche perche' credo che ognuno abbia diritto al proprio quarto d'ora di megalomania! La @ finale su Formul@ e lo zero su 0ne sono doverosi per evitare che il caro Bernie mi chieda $$$ di royalties per aver usato il nome... non si sa mai!

Come funziona F0SO F0SO e' un'applicazione compilata in C#; per il suo funzionamento ha bisogno di alcuni files di configurazione in formato XML che definiscono i parametri dei circuiti, la configurazione delle squadre, le tipologie delle gomme, etc etc. L'applicazione a runtime verifica i suddetti files, li carica e si inizializza.

Principio di funzionamento Il principio di funzionamento di F0SO si basa sul fatto che per vincere una corsa, da un punto di vista prettamente teorico e trascurando per il momento ingressi di safety car, doppiaggi di auto lente, sorpassi impossibili o condizioni al contorno, e' necessario coprire la distanza prevista nel minor tempo possibile. [Fanno eccezione in questo caso eventi come la 24 ore di Le Mans o la 12 ore di Sebring dove vince chi percorre piu' giri nel tempo a disposizione.]

F0SO: analisi Iniziamo molto semplicemente con il dire che il tempo totale di gara (il pilota che riesce a tenere piu' basso questo valore vince la gara) e' dato da: dove e' il tempo complessivo di gara, e' il numero totale dei giri e il tempo ideale sul giro. Ovviamente, a questo primo livello di approssimazione, si considera che un pilota sia in grado di girare con lo stesso ritmo per tutta la durata della corsa e che le prestazioni e l'affidabilita' della meccanica siano costanti nonche' gli imprevisti in pista siano assenti, ma piu' avanti terremo bene in considerazione queste variabili. Il tempo ideale, però, per sua stessa natura, non tiene in cosiderazione le varibili necessarie a descrivere, pur con le dovute approssimazioni, il decadimento delle prestazioni delle gomme, il consumo di benzina, la conformazione del tracciato e tutto il resto. Miglioriamo la precedente equazione: dove con il termine viene indicato il tempo reale mentre con lo scostamento del giro g-esimo dal tempo ideale in cosiderazione di quanto ancora non considerato. Raffinando ancora di poco il calcolo del tempo sul giro, possiamo considerare che il peso della benzina che via via diminuisce, abbassi il tempo sul giro, come anche il fatto che questo handicap di peso influisca in misura diversa in relazione alla tipologia di tracciato: in questa terza equazione sono comparsi i termini per la valutazione del consumo di benzina e conseguentemente dell'handicap dovuto al suo peso, Essendo M la massa dell'auto e mg la massa del carburante, il termine (M/M+mg), vale 1 quando la macchina e' scarica di benzina. e' il fattore che specifica quanto l'unita' di carburante sia penalizzante in relazione al circuito. Fino ad ora, le correzioni dovute alle nuove grandezze considerate, hanno variato il tempo reale sul giro in modo lineare che, per adesso, approssima ad un livello accettabile quanto stiamo ricercando. Quando parliamo di variazione delle prestazioni delle gomme, però, l'andamento delle performance non varia in modo lineare; posto naturalmente che contribuisce in modo evidente come il pilota utilizzi le coperture nei primissimi chilometri di utilizzo, si assiste ad un comportamento di questo tipo: i primi 4/5 km (corrispondenti al primo, massimo due giri) ad altissime prestazioni che si tradcono in alta aderenza, seguiti da un intervallo di 15/20 giri a resa costante per poi ricominciare con un lieve peggioramento nella risposta. E' evidente che un fattore correttivo lineare non può riprodurre quanto desiderato. Per questo motivo, nel considerare la resa delle gomme durante tutta la gara, ma in particolare all'interno di uno stint (ognuna delle frazioni di gara genarate dalla fermata ai box per il rifornimento ed il cambio gomme) e' opportuno organizzare le correzioni alla resa teorica della gomma in una struttura dati adatta, come un array. Ecco allora che usufruendo anche di questo nuovo fattore, possiamo correggere la precedente equazione con il contributo delle gomme: Si nota subito che e' il nuovo termine aggiunto alla equazione. Alla luce di quanto anche prima esposto, cioe' di come un pilota utilizzi le gomme durante i primi giri, ma anche di possibili lotti difettosi, errate pressioni di gonfiaggio ed altro, ho ritenuto sensato considerare anche queste possibilita' correggendo di poco quanto sopra: dove si e' aggiunto rispetto a prima . Bene, fino ad ora si e' calcolato il tempo reale di un giro come scostamento rispetto al tempo ideale (quello calcolato dai supercomputer di ogni team come tempo di riferimento...). La gara, però, e' costituita da n giri. La sommatoria, quindi, viene attuata su tutti i giri previsti dalla gara considerando le approssimazioni e le correzioni di tutti i fattori sino ad ora evidenziati. Si e' detto, poco sopra, che la gara viene divisa in due o piu' stint a seconda di quanti pit-stop sia conveniente/necessario effettuare durante la gara. L'equazione precedente, alla luce di questa ultima osservazione diventa: Vediamo cosa abbiamo aggiunto in questo ultimo passaggio: La sommatoria degli s stint su cui articolare la gara. Il tempo necessario per percorrere la corsia dei box con il limite imposto dalla commissione variabile di gara in gara. Il tempo necessario per il refuelling che dipende dalla quantita' di benzina imbarcata, visto che la portata di carburante dell'apparato per il rifornimento e' fissata a 12l/s (vr). Notare che anche due termini precedentemente definiti, adesso sono stati correlati allo stint in esame e non pi all'intera gara (nel caso di un solo stint questi due casi coincidono) La sommatoria degli n giri dell's-simo stint. Decadimento delle prestazioni delle gomme al giro n-simo del s-simo stint. L'equazione suona piu' o meno cosi': Il tempo totale di gara e' dato dalla sommatoria degli s-stint da 1 a m della somma del tempo di percorrenza della pitlane, del tempo di rifornimento per lo stint s+1 e della sommatoria del g-giro da 1 al giro n dello s-stint del tempo ideale di percorrenza corretto dai fattori dell'handicap dovuto al peso della benzina e alla conformazione della pista relativa alla benzina imbarcata, al decadimento di prestazioni delle gomme al giro g-esimo dello stint s-simo e delle condizioni delle gomme. Quest'ultima equazione per il calcolo del tempo totale di una gara, rappresenta una prima, buona approssimazione di quello che ci serve. Faccio notare che l'obiettivo ultimo di questa breve analisi e' trovare il MINIMO (T). Naturalmente, questa equazione viene utilizzata (in una forma piu' articolata) nel codice del programma per fornire il tempo sul giro di ogni pilota; la precisione del risultato dipende in larga misura dalla accuratezza dei parametri inseriti, quindi diventa necessario curare in modo scrupoloso questo aspetto. Ripeto che in questa prima parte dello sviluppo non vengono tenuti in considerazioni doppiaggi, safety car, problematiche di sorpasso e tutto quanto e'.... una gara in pista. Spero di riuscire a costruire qualcosa di via via piu' completo ed interattivo che tenga conto anche della macchina (affidabilita'a', decadimento delle prestazioni in gara, variazione limitaore di giri motore), dei differenti piloti (inclinazioni, stili di guida, resistenza....), e delle variabili non deterministiche (pioggia, safety car etc etc). Per il momento abbandono la parte teorica per mettere a disposizione, quanto prima, una prima beta per il download (o forse una webapp online..? mah, vediamo come evolve). Ringraziando quanti si siano spinti fino a qui nella lettura e prego chiunque volesse aggiungere qualcosa o correggere mie inesattezze di mandarmi una mail all'indirizzo info@idsee.net. Ringrazio anche il sito www.rogercortesi.com per aver messo a disposizione un equation editor online LaTeX-based.

Tutti i marchi, i nomi ed i riferimenti presenti in questa pagina appartengono ai legittimi proprietari.

Capita molto spesso di dover aggiungere alcuni controlli di vario tipo (checkbox, radiobutton ed altri) in una WebForm in modo dinamico, magari in funzione del risultato di una query su un database.
Naturalmente è indispensabile poi recuperare tali valori per processare eventi nella fase di postback (eventuali INSERT o UPDATE nel database).

Un metodo molto facile è quello di inserire nella WebForm un Panel (ToolBox > Standard > Panel) e di inserirvi all'interno i controlli chiamati in modo opportuno.
Nella fase di postback, andremo a verificare se e quali controlli sono stati selezionati dall'utente basandoci sul nome che gli abbiamo dato a runtime.

Esempio: Disegno un elenco di checkbox e voglio sapere le scelte operate dall'utente

Codice della funzione che genera dinamicamente i controlli

Public Function DisegnaFrutta()
'Definisco i DataSet, il DataAdapter e la stringa di SELECT per il Database
Dim DSFrutta As New Data.DataSet
Dim MyCommand As New Data.SqlClient.SqlDataAdapter

Dim sqlStr As String = "SELECT Elemento From Frutta ORDER BY Elemento"
MyCommand = New Data.SqlClient.SqlDataAdapter(sqlStr, MyConnection)

DSFrutta = New Data.DataSet()
MyCommand.Fill(DSFrutta, "Frutta")

For IndiceFrutta As Integer = 0 To DSFrutta.Tables("Frutta").Rows.Count - 1 ' Ciclo su tutti i record del db
Dim ControlCheck As New CheckBox ' Definisco un nuovo controllo
ControlCheck.Checked = False ' Decido a priori che è unchecked
ControlCheck.ID = "CB_" & DSFrutta.Tables("Frutta").Rows(IndiceFrutta)(0) ' Impongo il nome del controllo che sarà "CB_01", "CB_02", ...

ControlCheck.Text = DSFrutta.Tables("Frutta").Rows(IndiceFrutta)(1) ' Scrivo accanto al checkbox la sua descrizione
ControlCheck.AutoPostBack = True ' Aggiungo al pannello il controllo
PanelFrutta.Controls.Add(ControlCheck)
Next
Return True
End Function

Con una seconda Function andiamo a recuperare i valori spuntati in precedenza.


Dim myControl As Control ' Creo un nuovo controllo per la verifica del nome
For Each myControl In PanelLicenze.Controls ' Ciclo su tutti i controlli che mi arrivano con il postback
If TypeOf (myControl) Is CheckBox Then ' Se si tratta di un controllo checkbox (quelli che vogliamo noi)
Dim myCheckBox As CheckBox ' Ho bisogno di un secondo controllo per la verifica del valore
myCheckBox = CType(myControl, CheckBox)
If myCheckBox.ID = "CB_01" And myCheckBox.Checked = True Then ' E' il controllo che vogliamo?
xxxxxxxxxxx
xxxxxxxxxxx ' Nostro codice
xxxxxxxxxxx
End If
End If
Next

Supponiamo di voler generare un albero di navigazione per il nostro sito o per una applicazione web-based,magari basato su una serie di record risultato di una query SQL.

E' possibile mediante il controllo TreeView (ToolBox > Standard > TreeView) generare un albero di link/opzioni.

La via più semplice è quella di avere già inserito nella webform un Panel e al suo interno un TreeView;
successivamente, a runtime, definiamo tutti i suoi rami e le foglie e poi aggiungere tale albero al Panel.

Vi è mai capitato di dover permettere ad un utente di inserire o aggiornare dei valori in un controllo GridView?
Come ci si garantisce dal fatto che non vengano inseriti valori sballati o tipi di dato che poi mettono in crisi il database?
E' necessario effettuare un controllo sui dati inseriti nel GridView prima di lanciare le operazioni di inserimento o aggiornamento della tabella.
Semplice, associando un controllo di tipo 'Validator' alla textbox editabile.

Viene dato per scontato che la connessione, le query di selezione, aggiornamento e inserimento dal database ed il binding al controllo del GridView siano correttamente configurati; concentriamoci sul controllo GridView.

Quello che voglio ottenere è permettere all'utente di modificare il valore del quarto campo [Campo4] e salvare l'operazione; è necessario controllare che quanto inserito non sia una stringa ma un numero e che, per mia decisione, sia non nullo e minore di 1000.

Una volta inseriti e correttamente configurati connessione, datasource e gridview, selezionando quest'ultimo e guardando tra le sue Proprietà notare 'Columns';

Andando a cliccare sui puntini si aprirà una finestra di dettaglio:



Ora, dopo aver configurato il RangeValidator nel modo più opportuno (dovrà considerare validi soltanto i numeri 0

Ovviamente è possibile integrare nel controllo GridView molti altri controlli di diverso tipo (come in questo caso un controllo 'Range Validator') senza andare a scrivere righe di codice ma solamente utilizzando il DesignView.