ASP.NET

Jquery che potenza

Gian Maria Ricci — Tue, 19 Aug 2008 13:24:57 GMT

Dopo avere letto il libro JQuery in Action (che caldamente consiglio a tutti coloro che sviluppano web) ho iniziato a usare le prime istruzioni JQuery.. e debbo dire che rimango affascinato da come semplifichi la vita nella gestione delle classiche funzionalità ajax di un sito. Decisamente una libreria molto utile e potente.

alk.

L'importanza dei documenti di Deploy

Gian Maria Ricci — Fri, 25 Jul 2008 07:51:19 GMT

Fare un deploy di una applicazione non sempre è semplice, soprattutto se realizzata da vari sviluppatori, ogniuno dei quali gestisce parti che hanno bisogno di settaggi particolari, permessi particolari, file in alcune cartelle etc etc.

Per questa ragione è necessario fare un documento che spiega in maniera dettagliata le procedure che si debbono seguire per effettuare il deploy di un sito.

Purtroppo ieri, non per la prima volta, mi capita di guardare un sito che ha gravi problemi di performance, fino a generare talvolta degli OutOfMemoryException, si va nel web.config e ci si trova

<trace enabled="true" pageOutput="false" requestLimit="10000" localOnly="true"/>

Oltre al classico debug="true".

Questo errore purtroppo è più tipico di quello che si pensa. Quando si mette un sito in produzione bisogna prima di tutto compilare tutti gli assembly in modalità Release, e poi bisogna assicurarsi che debug="false" e anche che il trace sia disabilitato.

La morale è che non si può mettere un sito in produzione con gli stessi settaggi che si usano durante lo sviluppo e poi meravigliarsi se ci sono problemi di performance, il deploy dei siti asap.net è una operazione che spesso viene fatta in modalita xcopy, ma non va assolutamente bene. Per la sicurezza è necessario fare un utente specifico sotto cui far girare sia il webserver che il worker process asp.net, dare a quell'utente solo i permessi minimi (e questi debbono essere specificati nel documento di deploy), non mettere le stringhe di connessione ai sql server con nome utente e password ma usare l'autenticazione integrata etc etc.

In sostanza, un deploy di una applicazione asp.net è una operazione delicata e va stilato un documento, anche informale, affinche chiunque possa effettuarlo senza introddure buchi di sicurezza o mettere online un sito che, come si dice dalle mie parti, non si strascina :D

alk.

Oggi giornata strana

Gian Maria Ricci — Wed, 23 Apr 2008 12:47:51 GMT

In un progetto web ad un certo punto vedo che in una certa pagina il layout è tutto sballato, la pagina in questione ha una funzione che renderizza dell'html dentro una label, cosi penso che la funzione sia sbagliata.

Vado in debug e non trovo nulla di strano, fino a che non mi rendo conto che dal database arriva una stringa di testo che visivamente ha tipo un 250 caratteri ma la sua length è 989.......guardate che caratteri contiene ad un certo punto

In sostanza il carattere dal 260 al 265 sono una serie di nothing ... se faccio un Text.Encoding.Unicode.GetBytes(previewData) e vado a vedere attorno alla posizione incriminata trovo

L'array di byte restituito da Text.Encoding.Unicode.GetBytes(previewData) ha 1978 caratteri ed è giusto visto che la lunghezza della stringa la da com e989, peccato che internamente ci siano una sequenza di zeri e dato che 00 00 è il terminatore stringa unicode, purtroppo la stringa viene gestita male e crea casino con l'update panel. Se infatti vado a vedere nel fiddler cosa viene passato trovo questo pezzetto

"completa \ÿ\\ÿ\\ÿ\\ÿ\\ÿ\\ÿ\Dal primo"

Ovvero ci sono dei caratteri che nemmeno il fiddler riesce a renderizzare, questo significa che poi il javascript dell'update panel probabilmente va in errore dato che gli arriva uno stream di caratteri non validi......

A qualcuno è già capitato??

Alk.

Attenzione ai formati delle date

Gian Maria Ricci — Wed, 06 Feb 2008 18:47:48 GMT

Spesso mi capita di vedere persone alle prese con problemi di formato di date, in particolare nelle applicazioni web. Nello specifico ci sono cose che sconsiglio vivamente, come ad esempio memorizzare le date in un database in un campo varchar. I Campi DateTime e soprattutto il tipo di dato DateTime serve a gestire le date, per cui sempre meglio usare quello che usare stringhe.

Quando la conversione in stringa è inevitabile, come ad esempio quando dovete passare date tramite querystring, un altro errore comune è quello di usare il ToString() e poi il Parse o TryParse, il problema deriva dal fatto che in asp.net la cultura dell'UI può essere impostata in modo che sia la stessa della lingua del browser utilizzato, se convertite una data in stringa da un thread della ui, la salvate da qualche parte e poi magari la riprendete da un servizio che esegue task in background ecco che sorgono problemi, perché il servizio utilizzerà per default i formati della lingua impostata nella macchina. Ricordate quindi di convertire le date in stringa e viceversa sempre con lo stesso formato. La soluzione è utilizzare sempre uno stesso formato, cosa molto semplice se si ricorda che il ToString ha un metodo in overload che accetta un IFormatProvider

String converted;
System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("IT-it");
converted = now.ToString();
System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("EN-en");
DateTime parsed;
try {
   parsed = DateTime.Parse(converted);
   Console.WriteLine(parsed);
} catch (FormatException fex) {
   Console.WriteLine("Impossibile convertire {0} in data", converted);
}

System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("IT-it");
converted = now.ToString(CultureInfo.InvariantCulture);
System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("EN-en");
parsed = DateTime.Parse(converted, CultureInfo.InvariantCulture);
Console.WriteLine("{0:D}", parsed);
Console.ReadKey();

Nello snippet si fa vedere cosa succede se si converte una data in stringa e poi cambia la cultura del thread, la seconda parte dello snippet invece utilizza la cultura invariante, per cui qualsiasi sia la cultura corrente per il thread il formato non cambia e la data può essere convertita da e in una stringa senza problemi.

Alk.