di .NET e di altre amenità

Una azienda di Cittadella (PD) mi ha chiesto il riferimento di qualche programmatore web da selezionare per il proprio organico. Sono richieste conoscenze ASP.NET, C# e Sql Server. Costituisce titolo preferenziale la conoscenza del CMS Umbraco.

Chi fosse interessato mi scriva nei contatti o al messenger.

Può suonare come un motto di stampo politico, ma in questo caso la politica non c'entra nulla, almeno non quella cui in Italia siamo tutti allergici. Il fatto è che letti e riletti gli assiomi di ieri sera, m'è venuto in mente un altro punto che vorrei portare alla vostra riflessione.

Mi riferisco all'abitudine di "risolvere problemi che non si ha". Vi prego, considerate il fatto che  il nostro lavoro è già abbastanza difficile da solo, senza dover anche estrarre la sfera di cristallo e scrutarci dentro. Questa pratica ha principalmente due problemi:

1. La sfera di cristallo non ce l'avete (e se l'avete ci sono almeno 1000 modi migliori di usarla) perciò tutto quello che potrete prevedere sara sempre e solo una piccola, personale e limitata parte di quello che realmente potrà accadere alla vostra applicazione nel futuro... ergo lasciate perdere.
2. Assodato che tutto quello che prevederete probabilmente si rivelerà sbagliato, tutto il lavoro che farete a coprire requisiti che escono dalla suddetta sfera è semplicemente tempo buttato al vento. Il risultato sarà che alla fine vi troverete con un sistema che fa bene una cosa che non vi serve. Questo naturalmente sempre che riusciate a farlo bene... visto che nel frattempo ci sarà qualcuno che ripetutamente vi stresserà perchè le cose utili non ci sono.

Questo si applica sia a livello macroscopico che microscopico. Progettare architetture "galattiche" o scrivere in anticipo una classe che forse-un-giorno-se-siete-fortunati-dovrebbe-potenzialmente-servirvi-ancora appartengono entrambe allo stesso problema.

Credetemi meglio concentrarsi innanzitutto a risolvere i problemi che si ha. L'unica concessione al futuro che posso ammettere è quella di pensare a non realizzare qualcosa che non può evolvere, ma questo il più delle volte è un problema che ha a che fare con l'architettura e con la vostra conoscenza della tecnologia che dovete usare. Sapere che un particolare tipo di oggetto non scala e cercare di evitarlo ad esempio è una precauzione accettabile, ma costruire una architettura che nessuno vi ha mai chiesto non è una buona idea.

Perciò, la prossima volta che qualcuno esclama qualcosa del tipo: "Ma se poi il cliente vorrà anche..." oppure "Forse un giorno..." fermatevi un attimo e chiedetegli quanto vi costerà oggi fare una cosa che probabilmente nessuno vi pagherà mai... magari viene fuori che li mette di tasca sua!

Mi capita spesso di sentire persone che giustificano la mediocrità delle proprie soluzioni adducendo problemi di scarso tempo e sempre più spesso tendo a vivere con fastidio questo tipo di situazioni perchè il più delle volte chi si giustifica ha anche l'ardire di aggiungere che è costantemente in ritardo e per questo continua ad accumulare soluzioni mediocri le une sulle altre. Ma come... si buttano giù quantità industriali di codice, senza un minimo di analisi, senza fermarsi un attimo a coordinarsi, senza meditare un po' sul design, tutto in nome del risparmio di tempo e alla fine ci si ritrova in ritardo oltre che con una soluzione che ha ben poche possibilità di rivelarsi vincente sul mercato?!?!

Il problema che tutti dimenticano è che la fretta si paga e prima o poi si trasforma in ritardo perchè i danni che si procurano con questo incedere di solito diventano malfunzionamenti, requisiti mancati, o semplicemente rigidità nell'architettura che impediscono il poter soddisfare nuovi requisiti. Un po' come se per attraversare una sala di cristallerie si decidesse di farlo di gran carriera. Si arriverà certamente in fondo molto rapidamente ma poi si sarebbe costretti a tornare sui propri passi per riparare i danni che si sono fatti, a trovare una scopa e una paletta, a raccogliere i frammenti più piccoli e alla fine a conti fatti per attraversare quella sala ci si sarà messo il triplo del tempo necessario.

Tutto questo per arrivare ad alcune considerazioni:

1. quando pensate alle vostre soluzioni non abbiate paura di perdere tempo ad analizzare quale sia il modo migliore di condurre il vostro lavoro e di architettare la soluzione. Una classe pensata bene per quello che deve fare vi porterà così tanti benefici da annullare l'eventuale ritardo iniziale in tempo brevissimo.
2. se dovete risparmiare tempo è sempre meglio rinunciare a funzionalità piuttosto che a qualità. Mi rendo conto che questo cozza con i requisiti che vi da il cliente, ma il tempo purtroppo è una misura fissa e quindi fare più cose nello stesso tempo significa semplicemente farle peggio. Se poi dovrete tornarci sopra per sistemarle giocoforza vi rimangerete con gli interessi il tempo che avete risparmiato. Una cosa così si può anche scegliere coscientemente per motivi "commerciali" (i peggiori intendiamoci) ma lavorare sempre così significa imbrogliare se stessi oltre che i propri clienti.
3. La mediocrità è dei perdenti. Sembra una battuta, ma è la pura verità. Se iniziate un lavoro pensando in modo mediocre il vostro risultato sarà qualcosa compreso tra lo scarso e al massimo il mediocre (e probabilmente tenderà fortemente allo scarso). Se invece iniziate pensando in grande le vostre possibilità di fare un ottimo lavoro aumentano in partenza. Ma attenzione, pensare in grande non significa "strafare". Il punto 2 è sempre valido, pensare e fare sono due cose ben diverse.
4. Non pensate mai di inventare l'acqua calda. Può sembrare un punto che esula dall'argomento del post, ma spesso e volentieri fermarsi a considerare tecnologie esistenti può far risparmiare tempo in modo esponenziale. Non è bello arrivare in fondo e rendersi conto che se si fosse fatto un minimo di software selection o di formazione probabilmente un'intero sottosistema della vostra architettura l'avreste trovato già bello e pronto. Se poi considerate che chi ha sviluppato un prodotto consolidato ha probabilmente impegnato decine se non centinaia di persone per realizzarlo, testarlo e perfezionarlo ecco che il risparmio decuplica in valore.

Credetemi, quanto ho scritto può sembrare banale, scontato e ovvio, ma non è così. Nella mia ormai abbastanza lunga carriera in questo strano lavoro mi sono scontrato e continuo a scontrarmi con palesi violazioni di questi semplici assiomi e sempre queste violazioni finiscono per condurre al fallimento dei propri obbiettivi.

Mano a mano che prendo confidenza mi rendo sempre più conto della potenza dello strumento LINQ nella sua declinazione LINQ To Objects. Ecco un esempio pratico da tenere in considerazione:

   1: string text = (from ListItem item in chkLines.Items

   2:                where item.Selected == true

   3:                select item.Text)

   4:                .DefaultIfEmpty()

   5:                .Aggregate((a, b) => a = a + (!string.IsNullOrEmpty(a) ? ", " : "") + b);

Questo esempio in due parole fa:

1. prende tutte le checkbox selezionate da una CheckBoxlist (where...)
2. ne estrae il testo (select item.Text)
3. lo concatena separando gli elementi con una virgola solo quando serve (Aggregate)
4. gestisce il caso in cui la sequenze sia vuota (DefaultIfEmpty)

L'esempio è banale forse, ma la domanda è: quante righe di codice occorrevano prima per un risultato del genere?

Curiosando un po' nella sezione del sito di Microsoft che riguarda il Product Lifecycle mi sono reso conto che una data storica si sta rapidamente avvicinando... l'8 aprile prossimo infatti terminerà il supporto esteso per Visual Basic 6.0. Considerato che la settimana successiva sarò a Seattle con gli altri MVP italiani per il Summit, potrebbe essere una gran bella occasione per organizzare un party in memoria. Una specie di festa della liberazione... :D

Stanotte ci ho sbattuto la testa per un paio di ore e alla fine mi sono convinto che la serializzazione delle entities di Linq To SQL sostanzialmente... non è possibile! Il mio primo tentativo banale è stato di serializzarle in binario ma immediatamente mi sono reso conto che vengono tutte generate senza l'attributo [Serializable]. Perciò ho provato a scrivere le partial class e metterci l'attributo ma alla fine mi sono dovuto arrendere per il semplice fatto che EntitySet e EntityRef non sono serializzabili a loro volta. A questo punto ho deciso che a me bastava serializzare e quindi anche Xml sarebbe andato bene ma... XmlSerializer non ci riesce, perchè da un errore relativo una circular reference.

Il fatto è che se curiosate nel designer di Visual Studio 2008 scoprirete in fretta una proprietà "Serialization Mode" che può assumere i valori None e Unidirectional. Assegnando Unidirectional la classe generata verrà decorata con gli attributi DataContract e DataMember (e meno male!) e quindi diventerà serializzabile per mezzo del DataContractSerializer o del NetDataContractSerializer. Ecco un esempio di come fare espresso sotto forma di 2 extension methods:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5: using System.IO;

   6: using System.Runtime.Serialization;

   7: using System.Xml.Serialization;

   8:  

   9: namespace Elite.Linq2SQL

  10: {

  11:     public static class Extensions

  12:     {

  13:         /// <summary>

  14:         /// Serializes the specified obj.

  15:         /// </summary>

  16:         /// <param name="obj">The obj.</param>

  17:         /// <returns></returns>

  18:         public static string ToXml<T>(this T obj)

  19:         {

  20:             using (MemoryStream stream = new MemoryStream())

  21:             {

  22:                 NetDataContractSerializer serializer = new NetDataContractSerializer();

  23:                 serializer.Serialize(stream, obj);

  24:                 return Encoding.UTF8.GetString(stream.ToArray());

  25:             }

  26:         }

  27:  

  28:         /// <summary>

  29:         /// Deserializes the specified data.

  30:         /// </summary>

  31:         /// <typeparam name="T"></typeparam>

  32:         /// <param name="data">The data.</param>

  33:         /// <returns></returns>

  34:         public static T FromXml<T>(this string xml)

  35:         {

  36:             using (MemoryStream stream = new MemoryStream(Encoding.UTF8.GetBytes(xml)))

  37:             {

  38:                 NetDataContractSerializer serializer = new NetDataContractSerializer();

  39:                 return (T)serializer.Deserialize(stream);

  40:             }

  41:         }

  42:     }

  43: }

Detto questo può sembrare che bene o male (io propendo per il male...) si sia risolta la questione ma prima di cantare vittoria è opportuno ragionare sul significato di Unidirectional. In breve questo termine sottindente il fatto che la serializzazione comprende esclusivamente l'oggetto radice della gerarchia ed esclude qualunque oggetto che crei un riferimento esterno. Perciò se avete una proprietà collection popolata di oggetti questa non verrà nemmeno presa in considerazione. Il motivo è semplice: così non ci saranno mai circular references.

Quindi tirate le somme si può dire che è meglio togliersi subito dalla testa l'idea di serializzare le entities di Linq To SQL a meno che non vi vogliate impegnare ad implementare ISerializable, che davvero non è la cosa più semplice e immediata che mi venga in mente. Questo, almeno dal mio punto di vista di programmatore ASP.NET significa che le entities non potranno mai essere messe nella ViewState, oppure che se decido inopinatamente di tenerne anche una sola in Session, l'applicazione non potrà mai utilizzare lo State Server di ASP.NET perchè il suo uso implica la serializzazione degli oggetti...

La morale è quindi: occhio a quello che fate!

Mi è appena stata comunicata una notizia strepitosa: anche i partecipanti ai Community After Hour riceveranno il Kit di Lancio, con i 3 nuovi prodotti:

• Windows Server 2008 Enterprise Edition (32 bit e 64 bit)
• Visual Studio 2008 Standard
• SQL Server 2008 Standard

Si tratta di versioni full (senza limitazioni temporali UPDATE: windows server 2008 ha una licenza valida per 365 giorni), utilizzabili a scopo di test/sviluppo/studio.

Se non siete riusciti ad iscrivervi all'evento (che al momento da tutto esaurito) o se non avevate il tempo di andarci ecco un altro buon motivo per venire a trovarci.

M'è capitato di sentir parlare dell'entity designer di LINQ come "uno dei tanti inutili designer" di Visual Studio. Non sono un amante dei designer, e quando posso li evito. Ad esempio, per quanto ben fatto sia il designer delle WebForm mi capita di usarlo molto di rado per il semplice fatto che di solito scrivere il codice a mano mi è più rapido.

Ed è proprio questo il punto... il designer deve essere uno strumento che aiuta a risparmiare tempo e non a complicare la vita, perciò mentre un designer come quello per le WebForms ha un utilità relativamente bassa, quello di LINQ è pressochè indispensabile. Per quanto sia possibile scriversi a mano le classi di Linq To SQL chi ci abbia provato si sarà sicuramente reso conto che si tratta di un lavoro improbo e ripetitivo. Non si tratta infatti semplicemente di creare proprietà e metodi, ma anche implementare le interfaccie INotifyPropertyChanged e INotifyPropertyChanging che implicano i dover intervenire sulle proprietà una ad una. Questa implementazione è resa obbligatoria dal fatto che l'object tracking si basa su queste interfacce e senza di esse non sarà in grado di garantire il corretto funzionamento perdendo una delle caratteristiche più importanti di LINQ.

L'uso del designer consente di risparmiare moltissimo tempo e per questo motivo è sicuramente opportuno usarlo.

Ho perso due giorni per cercare di risolvere un problema che credevo derivasse dall'ultima hotfix installata venerdì scorso. Stamattina, dopo aver fatto un repair completo di Visual Studio ed essermi assicurato che della hotfix non ci fosse più traccia, il problema continuava a presentarsi e così mi sono convinto che nonostante le apparenze non fosse imputabile alla hotfix. Così mi sono messo a cercare e alla fine ho scoperto un comportamento "malsano", che ho segnalato nel Product Feedback Center e che vi vado ad illustrare:

Dall'uscita di Visual Studio 2008 sono state introdotte le referenze tra file Javascript che hanno il solo scopo di consentire a VS2008 di fornire un intellisense anche sui propri file javascript. Ne esiste una versione particolare che consente di referenziare un file javascript che sia inserito in un assembly come risorsa embedded. Il problema è che dopo aver inserito tale referenza il compilatore trova bloccato l'assembly nella directory bin e quindi non riesce a sovrascriverlo. L'errore che si ottiene è il seguente:

Unable to copy file "obj\Debug\ClassLibrary.dll" to "bin\Debug\ClassLibrary.dll". The process cannot access the file 'bin\Debug\ClassLibrary.dll' because it is being used by another process.

Il sintomo si presenta solamente quando il file che contiene la referenza è aperto e si lancia la compilazione tanto che se si chiude e si riapre Visual Studio 2008 senza prima chiudere il file Javascript, questo viene riaperto da Visual Studio e il problema continua a presentarsi.

Ecco una piccola solution che riproduce il problema: download

Chi avesse il tempo di provare a riprodurre il problema dovrà semplicemente caricare la solution in Visual Studio 2008, aprire i file javascript e poi compilare il progetto. Se il bug è convalidato è possibile segnalarlo nella relativa pagina del Feedback Center: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=328999

Nei link di oggi di Scott Guthrie c'è ne uno in particolare che ritengo molto utile. Si tratta di un esempio di uso dell'Expression Tree Visualizer, che è stato incluso nell'ultimo aggiornamento degli esempi di CSharp di Visual Studio 2008.

Il tool, che deve essere compilato e installato in Visual Studio (vedere il post originale per le istruzioni), consente di esplorare la struttura di una Expression Tree generata ad esempio in una query LINQ. Si tratta sicuramente di un buon sistema per capire come funzionano questi "strani" oggetti...

Link: LINQ Farm Seed: Using the Expression Tree Visualizer

Ho appena lanciato il download della SP1 di Vista e mentre il contatore è giunto al 19% è arrivata l'ennesima persona che lamentava i presunti problemi di Vista...

Questo incipit puo dare l'idea che in questo post si intenda tirare le somme di un pessimo sistema operativo ma non è così. In questi mesi - sono utente di Vista solo da pochi mesi perchè ho dovuto prima aggiornare il mio hardware - ho lavorato con Vista molto intensivamente, sia sul lavoro sia a casa con il mio nuovo portatile e non posso dire ci sia mai stata una sola volta che il sistema operativo mi abbia tradito. Se paragonato a Windows XP il livello di stabilità se non è nettamente superiore è almeno identico.

Con questo non voglio negare che Vista non abbia qualche problema, ma i problemi che ci sono sono ben delimitati e conosciuti. L'accesso alla LAN ad esempio è molto lento, e questo è risaputo, ma oltre a questo non mi sento di condannare a priori Vista come sento fare gratuitamente ogni giorno.

Il fatto è che chiunque si permetta di parlare di Vista lo fa a sproposito, e ad una più prodonfa indagine appare evidente che i paventati "problemi" che dovrebbe avere sono sconosciuti. Se quando uno vi dice: "ah... Vista ha un sacco di problemi" provate a chiedere: "Ma a quali problemi ti riferisci?"... nella maggior parte di casi la risposta sarà completamente disarticolata, priva di reali fondamenti e con tutta probabilità fondata sul "sentito dire".

Nella restante parte dei casi, quelli che vengono identificati come problemi sono semplicemente non imputabili al Sistema Operativo, ma ad applicazioni scritte male, a incomprensioni dell'utente e all'errata convinzione che la UAC sia un'inutile perdita di tempo. Quest'ultima, viene spesso e volentieri messa sul patibolo, ma i più dimenticano che grazie ad essa un utente inesperto come sono la maggior parte delle persone comuni, può usare il pc in tutta tranquillità senza rischiare di infestare il proprio sistema con le più immonde schifezze. E non è nemmeno vero che un utente esperto non possa lavorare con la UAC abilitata. Io lo faccio tutti i giorni e ora che me ne sono abituato tutto fila liscio come e più di prima.

Per tirare le somme quindi, mentre il download è al 34%, c'è la necessità a mio parere di rompere la cortina di disinformazione che è stata costruita attorno a Vista perchè a tutti gli effetti si tratta di un buon Sistema Operativo che non ha nulla da invidiare al proprio - eccellente - predecessore. La speranza è che la SP1 risolva i problemi reali di Vista e che lo metta sulla giusta strada.

Parola di utente soddisfatto...

Da alcuni giorni è disponibile una hotfix per Visual Studio 2008 che contiene numerosi aggiornamenti che hanno un impatto sulle prestazione dell'IDE. In particolare mi sento di segnalarne una, riprendendo il blogi di Scott Guthrie che ne ha dato segnalazione:

When opening a JavaScript file, colorization of the client script is sometimes delayed several seconds.

Credo si tratti del problema più evidente che infatti in molti mi hanno già segnalato. La hotfix è disponibile per il download al link riportato in calce

UPDATE1: Leggete nei commenti una nota importante riguardo i WebSite project.

UPDATE2: Ho verificato la segnalazione e pare che nella hotfix che ho scaricato io il casing sia stato corretto.

Download: https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=10826

Notizia: Scott's blog

Fonte: VS 2008 Web Development Hot-Fix Roll-Up Released