Tuesday, July 27, 2010
#
Se c’è un aspetto che lo sviluppatore medio non tiene nella giusta considerazione quando scrive il codice è il cast tra tipi. Questo lo deduco solo dalla mia esperienza sul campo, ovvio.
Sto parlando del cast ridondante, cioè quel cast semplicemente inutile e che potrebbe essere tranquillamente evitato, basterebbe solo un pò di attenzione in più, e forse un pò di copia ed incolla in meno 
Spesso un cast ridondante non è immediatamente percepibile.
Se si scrive una cosa del genere:
1: XmlDocument xmlDoc = new XmlDocument();
2: // ......
3: // ....
4: XmlNode node = (XmlNode)xmlDoc;
non è immediatamente visibile (ad occhio, intendo) il cast ridondante della riga 4, poichè un oggetto XmlDocument può essere tranquillamente assegnato ad un oggetto XmlNode in quanto quest’ultimo è la classe da cui deriva, e quindi per i principi basilari del polimorfismo o per il principio di sostituzione di Liskov (al secolo Barbara Liskov, è quindi una donna ) , fate voi, per cui, se B è una classe derivata da A, allora oggetti di tipo A possono essere sostituiti da oggetti di tipo B senza alterare la correttezza dei risultati.
Quindi il codice precedente può essere riscritto senza la ridondanza del cast, cosi:
1: XmlDocument xmlDoc = new XmlDocument();
2: // ..
3: // ..
4: XmlNode node = xmlDoc;
Ma quando vedo cose del genere:
1: Byte b = (System.Byte) 0;
non riesco proprio a non rabbrividire, anche con il caldo torrido di questi giorni .
Ma come è possibile effettuare un cast del valore zero verso un tipo Byte !?!?!, quando, lo sanno pure i bambini, il tipo primitivo Byte rappresenta un valore intero senza segno compreso tra 0 e 255 ?.
Scusate lo sfogo…..
Friday, July 23, 2010
#
- Mandare una mail verso una cartella con ASP :Net
Decisamente utile
- Microsoft Network Monitor 3.4
Tool che permette di catturare, visionare ed analizzare il traffico di rete. Utile anche agli sviluppatori
- NHibernate Mapping Generator 2.0 Beta 1
Presente il supporto per la generazione del “fluent mapping”, anche se fino ad ora limitato a Sql Server
- Team Foundation Server 2010 Power Tools April 2010
Tuesday, July 20, 2010
#
Questo è un tool davvero impressionante per cosa riesce a tirar fuori da un assembly .Net, adesso con tanto di add-in per Visual Studio e per Reflector.
E’ un must per qualsiasi sviluppatore/architetto degno di questo nome.
Avendo visto negli ultimi anni un bel pò di applicazioni .Net di ogni tipo, avendo partecipato ad un bel pò di progetti e conseguentemente visto una quantità considerevole di righe di codice, di seguito elenco (in ordine sparso) le mie considerazioni sulla qualità media del codice sorgente da me visionato e su cui spesso e volentieri sono intervenuto in prima persona per correzioni e/o nuove funzionalità (leggasi elenco di brutture e/o coding horror):
- La visibilità delle classi è una questione non tenuta nella giusta considerazione. Quando si crea una classe la si marca come "public", e tale resta per sempre, anche se la classe potrebbe essere "internal";
- il paradigma "Object Oriented Programming" è scarsamente applicato, ed anche scarsamente conosciuto, e cosi si finisce spesso per avere, solo a titolò di esempio, codice duplicato, scarsamente coeso e altamente accoppiato;
- Boxing e unboxing: concetto non conosciuto dai più, e cosi accade che il tipo "object" è usato a sproposito, e la tipizzazione dei dati diventa una rarità;
- Concatenazioni di stringhe a go-gò, anche se è arcinoto che questa operazione non è performante a causa dell'immutabilità dell'oggetto stringa che "stressa" parecchio il garbage collector;
- Utilizzo delle eccezioni nella logica di business dell'applicazione per notificare situazioni particolari;
- Utilizzo indiscriminato di Dataset/Datatable in ogni layer applicativo (front-end compreso), al posto di oggetti di dominio non anemici, cioè dotati di attributi e di comportamento (sì lo so, chiedo forse troppo, questo è Domain Driven Design...), con conseguente profilerazione di classi per la gestione delle entità trattate dalla applicazione, es. CustomerManager, OrderManager, ecc.
Su questo argomento potrei aprire una lunga discussione, circa colui che io definisco "il programmatore del dataset";
- La modularità di una applicazione e il concetto di "Separation of Concern" (Soc) non attira l'interesse della maggior parte degli addetti ai lavori. Come già discusso qui, è più importante rispettare i termini di consegna puttosto che creare software di qualità, ed ecco che si finiisce per scrivere software quasi monolitici, dove le responsabilità si "accavallano" in modo netto ed evidente tra i vari moduli. In applicazioni ASP .Net il code-behind si è spesso rivelato una trappola, nel senso che la classe "pagina" contiene una quantità spropositata di codice, ad esempio negli event handlers, alla faccia del concetto di basso accoppiamento;
- Assenza di Unit Test, non nel senso che nessuno li scrive ma nel senso che il Test Driven Development per molti è una sigla non pienamente compresa; in quei pochi scenari in cui ho visto scrivere Unit Tests questi non erano mai strutturati nel modo corretto secondo lo schema arrange-act-assert ma erano per lo più invocazioni di metodi a scopo di debugging. In pratica, più che "Sviluppo guidato dal test" ho visto l'esatto opposto 
Fortunatamente ho anche visto codice scritto benissimo, bene, o almeno in modo decente
Friday, July 16, 2010
#
- Super cool MSBuild Debugging in Visual Studio IDE
Questa è una feature eccezionale non ufficialmente supportata. Seguendo il link è possibile scoprire i passi necessari per abilitarla in Visual Studio 2010.
- Tool di migrazione VB6 –> VB .NET / C# gratuito
Considerato che è gratuito e che promette bene vale sicuramente la pena provarlo.
- Visual Studio 2010 Dark background
Add-in per VS 2010 per impostare dei temi personalizzati circa i colori, tra cui un fantastico Dark
- Microsoft ADO .NET Entity Framework Feature CTP4
- Domain Driven Design di Alberto Brandolini Part 1; Part 2; Part 3
- Domain Model Pattern (Martin Fowler)
- ASP.NET Multi-Level Drop Down Menu – JQuery
- NUnit Result Manager
Web application per tener traccia dei risultati degli unit tests (per project manager & developer)
Tuesday, July 13, 2010
#
Sono sempre stato piuttosto "maniacale" nella scrittura di codice, circa il rispetto delle guidelines e circa uno stile di codifica che aiuti a migliorare la leggibilità dello stesso, e la sua manutenibilità.
Ho sempre sostenuto che il pezzo di codice scritto stilisticamente bene è quello che si "autodocumenta" semplicemente solo leggendolo.
La leggibilità aumenta, a mio parere, anche con opportuni accorgimenti o tecniche, non sempre utilizzati da tutti, anzi spesso ci sono pareri discordanti sull'effettiva utilità di alcune modalità di scrittura.
Mi riferisco, ad esempio, all'utilizzo delle parentesi graffe in alcuni casi particolari dove possono essere evitate (ovviamente il contesto è quello di applicazione scritta in C#, linguaggio principe nel mondo .Net).
A mio avviso, la leggibilità beneficia del fatto di scrivere qualcosa del genere:
1: if (condizione)
2: a = 1;
rispetto a questo codice:
1: if (condizione)
2: {
3: a = 1;
4: }
Quando mi ritrovo a svolgere code review oppure solo a guardare codice scritto da altri, la tentazione di eliminare le graffe è troppo forte, e, quando posso, finisco per toglierle.
La stessa tecnica la applico al ciclo for, ovviamente anche in questo caso l’istruzione da eseguire deve essere una sola.
Circa le if, sarebbe addirittura più valida l'idea di toglierle proprio, in perfetta aderenza ai principi della campagna anti-if, a cui ho aderito con entusiasmo, anche se qui il contesto è differente poichè le "if" andrebbero usate con parsimonia o evitate del tutto quando particolarmente annidate e ripeture (così come l'istruzione "switch"), sostituendole con una applicazione più rigorosa dei principi della programmazione ad oggetti, polimorfismo ed ereditarietà in primis.
Friday, July 09, 2010
#
Poichè mi piace tenere insieme i miei pensieri su questo blog, riporto la mia risposta all'amico Andrea Saltarello sullo spinoso tema da lui sollevato in un thread sul forum di GUISA, ovvero "ma siamo solo artigiani ?"
"Hai perfettamente ragione quando affermi che "siamo un settore artigianale", e ciò dipende a mio avviso
dal fatto che non tutti sono disposti a migliorarsi professionalmente per comprendere "il perchè" piuttosto del "come".
Molti sanno come impiantare un sito Web MVC; pochi conoscono però il pattern, ancora meno sanno che quel pattern si chiama "Model 2" e non MVC; qualcuno addirittura non conosce nemmeno il significato dell'acronimo, ma tutti però ci spacciamo come architetti poichè, come affermi giustamente, "architetto" è una buzzworld figa da mettere sul bigliettino da visita o nella firma elettronica della mail.
Questo è solo un esempio, ma ne potrei citare molti altri.
Come sicuramente ben sai, esistono realtà IT dove ad una applicazione è richiesto solo che funzioni; non è minimamente richiesto e non si ha nemmeno la consapevolezza dell'importanza di avere software modulare che evolve nel tempo con il minimo impatto sulle funzionalità esistenti.
La qualità del prodotto software è una caratteristica scarsamente apprezzata, anche dagli stessi addetti ai lavori; ciò che conta è consegnare la versione 1 funzionante, per poter fatturare, non importa come viene sviluppata.
Qesto è un settore dove "i fiorellini" non sono richiesti.
Quindi, altro che TDD e sviluppo incrementale... "
- SILF: Silverlight Install and Logging Framework
- How to Use a VBA Macro to Sum Only Visible Cells
Questo me lo appunto perchè davvero utile, e mi chiedo come mai non sia già presente una funzionalità simile in Excel 2007, ovvero la possibilità di sommare solo le celle visibili (vale a dire non filtrate) di un dato range, e non invece tutte le celle, anche quelle filtrate, come invece succede se si usa la classica funzione SUM.
Nota: non sono un programmatore VBA nè mai lo sarò, questo me lo appunto solo perchè molto utile (un tempo sono stato programmatore VB6, ma parlo di 15 anni fa, un'intera era geologica per il mondo dell'informatica).
Friday, July 02, 2010
#
- Patch per errore di memoria insufficiente a seguito di cut and copy in Visual Studio 2010
- Softoria Capture 1.0, tool utilissimo (e free) che permette il capture dell'intero schermo, di finestre e di porzioni di finestre per un successivo "copy and paste"
- Agilizer, tratto da CodePlex, semplice ma molto utile strumento di gestione di progetti Agili
- Visual Studio 2010 Architecture Tooling Guidance
Tuesday, June 29, 2010
#
Spesso applicare una metodologia per il gusto di farlo, oppure solo perchè si è un profondo sostenitore di una certa tecnica ignorando completamente il contesto in cui si sta operando, può essere più deleterio che non applicarla proprio, e si finisce per avere una attenzione maniacale ai dettagli (che di norma costtuiscono il dogma della metodologia / tecnica che si sostiene), anche ai più insignificanti e più difficili anche solo da notare, e contemporaneamente una completa disattenzione per aspetti molto più evidenti che emergono giorno per giorno, ai quali si finisce poi per non dare il giusto peso.
L'argomento di questo post sono le metodologie di gestione di un progetto software con elevata complessità e criticità, ed il post è volutamente ermetico, ma sicuramente, rileggendolo a distanza di tempo, mi ricorderò molto bene del contesto che mi ha portato a sfogarmi con un post come questo.
Sunday, May 09, 2010
#
Per il momento me lo appunto soltanto, ma conto di provare la cosa non appena mi sarà possibile.
Avere una applicazione Windows Service che non necessita del comando InstallUtil per l’installazione del servizio è una gran cosa, soprattutto quando bisogna delegare ad altri l’esecuzione di questo comando 
Fonte: http://blogs.ugidotnet.org/Alby/archive/2010/05/09/servizi-windows-autoinstallanti.aspx
Monday, May 03, 2010
#
E’ noto che il metodo virtuale Equals ereditato da ogni oggetto dalla classe System.Object permette di definire un criterio di uguaglianza tra due oggetti non basato esclusivamente sulla reference (ovvero 2 oggetti sono uguali se puntano alla stessa istanza di un determinato oggetto).
E’ altresì noto che ridefinendo il metodo Equals siamo costretti a ridefinire il metodo GetHashCode per far si che in presenza di 2 oggetti uguali (Equals che ritorna true), il metodo GetHashCode ritorni lo stesso valore di hash per i 2 oggetti, questo perchè l’oggetto in questione potrebbe essere usato come chiave in una collezione di tipo HashTable o Dictionary<T,V>.
L’implementazione di GetHashCode fornita dalla classe System.Object fornisce un valore di hash distinto per ogni istanza di una data classe presente in un dato AppDomain, e tutto ciò è in linea con l’implementazione di Equals fornita da System.Object.
Ma se per un dato oggetto volessimo forzare l’uguaglianza per riferimento ?
Non basta usare ReferenceEquals(x, y) perchè, come detto, alcune classi come i dizionari utilizzano il metodo Equals per definire l’uguaglianza tra due oggetti (che di default si traduce in “identità” di un oggetto e non in “uguaglianza”).
Dovremmo ridefinire il medoto Equals in questo modo:
1: public override bool Equals(object obj)
2: {
3: return System.Object.ReferenceEquals(this, obj);
4: }
ma in questo modo saremmo costratti ancha a ridefinire GetHashCode senza poter fornire l’implementazione standard di System.Object.
Questo problema si risolve utilizzando il medoto GetHashCode, ma quello fornito dalla classe System.Runtime.CompilersServices.RuntimeHelpers.
Questo metodo infatti, a dispetto del nome identito al metodo della classe System.Object, ritorna sempre un valore hash univoco per ogni istanza distinta di ogni oggetto in memoria, ovvero esattamente l’implementazione standard fornita da System.Object a prescindere se il metodo virtuale Object.GetHashCode sia o non sia ridefinito, ed adatta alla sola uguaglianza per riferimento.
Il tutto può essere inglobato in una classe Comparer apposita, in questo modo:
1: using System.Runtime.CompilerServices;
2:
3: public class ReferenceComparer<T> : IEqualityComparer<T>
4: {
5: #region IEqualityComparer<T> Members
6:
7: public bool Equals(T x, T y)
8: {
9: return System.Object.ReferenceEquals(x, y);
10: }
11:
12: public int GetHashCode(T obj)
13: {
14: return RuntimeHelpers.GetHashCode(obj);
15: }
16:
17: #endregion
18: }
Sunday, May 02, 2010
#
Il CLR consente di spostare il codice di una classe da un assembly ad un altro senza dover ricompilare il codice client che usa la classe in questione.
Questa caratteristica è nota come Type Forwarding.
Supponendo di avere la classe Class1 nell’assembly Ass1, se per questioni di refactory del codice sorgente la classe viene spostata nell’assembly Ass2, sembrerebbe a prima vista necessario ricompilare anche il codice che referenzia l’assembly Ass1 per aggiungere una reference all’assembly Ass2 e modificare la dichiarazione della classe Class1.
Tutto ciò non è necessario. Basta decorare l’assembly Ass1 (la nuova versione, quella priva della classe Class1) con l’attributo TypeForwardedToAttribute, in questo modo:
1: [assembly:TypeForwardedToAttribute(typeof(Class1))]
Così facendo, il codice client può continuare a referenziare l’assembly Ass1, e quindi non è necessaria una sua ricompilazione. Ogni richiesta che l’assembly riceverà per quella classe verrà reindirizzata al nuovo assembly che conterrà la classe stessa.
Ma tutto ciò ha una controindicazione a mio avviso non indifferente: l’assembly Ass1 che conteneva la classe che ora non contiene più dovrà per forza di cose referenziare l’assembly Ass2 che ora contiene il tipo.
Inoltre, e qui sarei curiosissimo di conoscere la motivazione, questo attributo non è utilizzabile in Visual Basic 2005 (e quindi con il .Net Framework 2.0). Infatti Visual Basic 2005 può solo “consumare un forwarded type” scritto in un altro linguaggio.
Friday, April 23, 2010
#
Negli ultimi tempi sono stato coinvolto in una attività di recruitment mirata a reperire figure professionali nel mondo IT con skill particolarmente elevato, diciamo una figura di senior developer con conoscenze anche in ambito architetturale. Ho accettato con entusiasmo questa attività poichè ero curioso di capire se la preparazione universitaria in ambito informatico fosse sufficientemente in grado di reggere l'impatto con il mondo del lavoro e con la realtà di tutti i giorni (questo ovviamente per i laureati, ma lo stesso discorso può essere applicato anche per chi laureato non è).
E le sorprese non sono mancate.
Ecco, in sintesi, le mie considerazioni:
- Una laurea non è assolutamente garanzia di preparazione e competenza. Spesso i neolaureati, si "adagiano sugli allori", pensando che il loro titolo di studio basti e avanzi, ma in realtà non è così, poichè i ritmi con cui si evolve la tecnologia sono talmente elevati che solo con una spiccata dose di passione e/o sacrificio è possibile essere aggiornati in modo almeno sufficiente;
- L'attività di senior developer o comunque qualsiasi attività prettamente tecnica spesso sono viste come attività "rognose" e molto impegnative, per cui le ambizioni dei candidati a volte si spostano verso ruoli di più alto livello, o comunque non a stretto contatto con la tecnologia (es. coordinatore di risorse o addirittura analista funzionale);
- I cv sono spesso gonfiati a sproposito. Per un appassionato non c'è nulla di male nell'inserire "ottima conoscenza teorica di ....." senza aver avuto la possibilità di mettere in pratica questa conoscenza. Diverso è inserire esperienze anche pluriennali senza alcuna valenza. Non è possibie sentirsi dire che non si sono mai utilizzate le caratteristiche più elementari del polimorfismo quando sul cv è scritto "pluriennale esperienza nella programmazione ad oggetti", oppure "ottima conoscenza di ASP. NET" e poi non si sa a cosa serve il ViewState;
- L'atteggiamento del candidato durante una intervista non è spesso quello giusto da tenere in situazioni del genere, dove, a mio avviso, occorre mostrare soprattutto umiltà di fronte a ciò che si conosce e soprattutto di fronte a ciò che non si conosce;
Fortunatamente si incontrano anche persone appassionate di questo lavoro e competenti, che ripagano ampiamente gli sforzi effettuati.
Tuesday, April 20, 2010
#
E’ online il mio primo articolo per UgiDotNet, ovvero “Programmazione per contratti con il Framework .Net 4.0”, argomento molto molto interessante poichè è ora possibile adottare l’approccio cosiddetto “Contract First Development” nel design delle proprie applicazioni.
Questo approccio aiuta sicuramente a scrivere applicazioni più robuste, cercando di limitare per quanto possibile i bugs a runtime.
Ovviamente sono graditissimi eventuali feedback, contattandomi mediante la form contact di questo blog.
Tuesday, April 13, 2010
#
Gli extension methods sono una feature estremamente potente ed interessante, introdotta a partire dal .Net Framework 3.5 SP1.
A tal proposito, su Codeplex è presente un interessantissima libreria di codice che raccoglie extension methods applicati a svariati tipi.
Davvero molto molto utile.
Come detto qui da Gianluca Carucci, questa feature non necessita necessariamente della versione 3.5 del .Net Framework per essere utilizzata, ma, con un piccolo accorgimento, è possibile sfruttarne a pieno le potenzialità utilizzando anche il .Net Framework 2.0.
Pertanto, nella pagina Codeplex sopra citata, i “requirements” sono errati.
Monday, April 12, 2010
#
Il pattern “Decorator” appartiene alla famiglia dei design pattern della GoF (Gang of Four), ed è classificato come pattern strutturale. E’ un pattern molto semplice da usare, che permette di aggiungere dei comportamenti personalizzati, e quindi delle responsabilità, ad una certa classe senza per questo utilizzare tecniche di subclassing.
Immaginiamo di avere un componente per il log delle informazioni. Esso invoca un servizio di logging e rispetta questo contratto definito mediante una semplice interfaccia:
1: public interface ILogger
2: {
3: void Write(Exception ex);
4: }
5:
6: public class Logger : ILogger
7: {
8: public void Write(Exception ex)
9: {
10: Console.WriteLine(ex.Message);
11: }
12: }
Abbiamo la necessità di aggiungere una informazione aggiuntiva al messaggio di log, ovvero la data odierna. Questo significa aggiungere responsabilità alla classe, ma per ottenere questo non intendiamo nè modificare la classe originaria, nè usare il subclassing. Il design pattern “decorator” permette di ottenere questo risultato in un modo molto semplice:
1: public class LoggerDecorator : ILogger
2: {
3: private ILogger loggerObj;
4:
5: public LoggerDecorator(ILogger logger)
6: {
7: loggerObj = logger;
8: }
9:
10: public void Write(Exception ex)
11: {
12: Console.WriteLine(DateTime.Now.Date.ToShortDateString());
13: loggerObj.Write(ex);
14: }
15: }
Il “decorator” consiste in una classe che implementa la stessa interfaccia della classe originaria, e con un costruttore che accetta come parametro una istanza di quest’ultima. L’implementazione dell’interfaccia permette al “decorator” di iniettare codice aggiuntivo prima ed anche dopo l’invocazione del corrispondente metodo della classe estesa.
Esempio di utilizzo:
1: Logger logger = new Logger();
2: ILogger loggerDecorator = new LoggerDecorator(logger);
3: loggerDecorator.Write(new Exception("Message from Exception"));
E’ importante notare che la classe estesa (Logger in questo caso) non sa assolutamente nulla che un’altra classe è usata come “decorator”.
Nonostante la semplicità e l’utilità di questo pattern è opportuno ricordare che con l’introduzione degli “extention methods” a partire dalla versione 3.5 del .Net Framework è possibile estendere una qualsiasi classe senza usare l’ereditarietà e con l’indubbio vantaggio di ritrovarsi gli extention methods di un tipo visibili nell’Intellisense di Visual Studio.
Esempio con l’extention method:
1: public static class LoggerExtention
2: {
3: public static void WriteData(this Logger logger)
4: {
5: Console.WriteLine(DateTime.Now.Date.ToShortDateString());
6: }
7: }
8:
9: // Utilizzo:
10: Logger loggerEx = new Logger();
11: loggerEx.WriteData();
12: loggerEx.Write(new Exception("Message from Exception"));
Friday, March 26, 2010
#
- Fluent Mock Builder, fornisce una “fluent interface” per costruire complessi oggetti “mockable” con il framework di mocking Mock, una libreria di mocking che sfrutta a fondo le nuove caratteristiche di .NET 3.5 (es. expression trees), o di C# 3.0 (es. le lambda expression). Il tutto può essere usato negli Unit test di progetti ASP .NET MVC;
-NInject, un framework open source di dipendency injection per .NET;
-StructureMap, altro tool di Dipendency Injection / Inversion of Control per il mondo .NET;
Friday, March 19, 2010
#
Ieri pomeriggio ho partecipato al Visual Basic Tips & Tricks Community Day tenutosi a Milano.
Devo dire che è stato un pomeriggio decisamente interessante dal punto di vista tecnologico, permettendomi di focalizzare alcuni concetti su tecnologie che uso o che vorrei usare, e mi riferisco a TFS 2010 ed Entity Framework 4.0
L’evento si apre con una sessione di Lorenzo Barbieri che parla delle varie versioni di Visual Studio 2010 che saranno disponibili a breve e delle novità, veramente tante, della nuova versione dell’IDE.
In ordine sparso:
- Possibilità di effettuare ricerche parziali con l’Intellisense;
- Intellisense nei file Javascript migliorato, ora vengono risolti anche i simboli presenti nei files inclusi, e non solo quelli del file in debugging;
- Funzionalità di “search a you type”, per intenderci tipo Google quando ci presenta i risultati della ricerca mano a mano che scriviamo il testo da ricercare;
- Funzionalità di “Call Hierarchy”, per il momento presente solo con il linguaggio C#, ovvero la possibilità di navigare a partire da un metodo / proprietà / costruttore verso il codice chiamante / chiamato a partire dal punto di navigazione scelto;
- Modalità “Web only” dell’IDE, ovvero la possibilità di utilizzare un IDE con il solo codice in primo piano e tutte le finestre di dialogo minimizzate;
- Selezione del testo per colonne;
- Gestione degli add-in con un apposito Extention Manager dedicato;
- Intellitrace (feature molto molto utile ed interessante per troubleshooting), ovvero un componente capace di registrare tutto quello che avviene nel codice quando questo è in esecuzione, una specie di scatola nera dell’applicazione, utilizzabile su applicazioni scritte con la versione 2.0 del Framework in poi ;
- Test di automazione della UI;
Poi è stata la volta di Alessandro Del Sole, che ha mostrato le novità di Team Foundation Server 2010 in ottica singolo sviluppatore o piccoli gruppi di lavoro.
Successivamente Antonio Catucci ha mostrato le novità di Entity Framework 4.0, ovvero:
- Possibilità di gestione della Foreign Key nel modello dati, senza che la stessa sia nascosta (come è noto nel mondo dei database relazionali una relazione tra 2 tabelle si traduce con la presenza di una colonna in comune tra le due tabelle, che costituisce appunto la relazione, nel mondo OOP una relazione di questo tipo si traduce con la presenza di una proprietà tipizzata nell’oggetto “padre”);
- “Lazy Loading” attivo sempre di default;
- “Pluralization” dell’Entity Set basato sulla grammatica inglese. Con Entity Framework 1.0 questa mancanza mi ha provocato qualche problema, in quanto va gestito a manina;
- “Model-First Design”, feature decisamente interessante che consente di creare un domain model senza che sia necessariamente presente un database da cui partire. Con la versione 1.0 il domain model è forzatamente creato a partire da una base dati esistente;
- “T4 Code Generation”. Con questa feature il codice generato da Entity Framework può essere basato su template, fornendo quindi la possibilità di generazione personalizzata dello stesso.
- “POCO Entity (Plain Old CLR Objects)”, anche questa è una feature molto interessante, ovvero la possibilità di usare nel Domain Model della classi “pulite”, magari già esistenti senza che debbano per forza di cose ereditare da una classe specifica di Entity Framework;
- Gestiona automatica delle relazioni molti a molti, senza la visualizzazione della terza tabella di legame tra le due relazionate;
- Nuovo controllo EntityDataSource per il binding dei dati in ASP .NET.
- Metodo “ApplyCurrentValues”. Permette di gestire le modifiche apportate su oggetti “detached”, ovvero al di fuori dell’ObjectContext attivo, e di propagare le stesse modifiche sull’oggetto avente la stessa chiave presente nell’ObjectContext (oggetto “attached”).
Come è evidente la versione 4.0 di Entity Framework contiene una pletora di novità, che sicuramente consentiranno a questo ORM made in Microsoft di superare alcuni limiti di “gioventù” della precedente versione.
Thursday, March 18, 2010
#
 |
MySolutionLab è un portale focalizzato sullo sviluppo di software visto come attività ingegneristica, e quindi conforme ai requisiti di (tratto dal sito):
…. correttezza, affidabilità, robustezza, efficienza, usabilita', scalabilita', fault tolerance.
|
1. Corretti e Affidabili:
un sistema e' corretto se si comporta come stabilito nei suoi requisiti funzionali.
2. Robusti:
un sistema e' robusto se si comporta in modo ragionevole in situazioni impreviste.
3. Efficienti:
un sistema e' efficiente se usa le risorse in modo performante.
4. Facili da usare:
un sistema e' facile da usare se un essere umano lo reputa tale; l’interfaccia utente
interviene molto sull’amichevolezza di un’applicazione.
5. Manutenibili:
un sistema e' manutenibile se e' facile apportarvi modifiche, aggiornamenti e miglioramenti
(evoluzione del software).
Vorrei porre l’accento sul discorso “manutenibilità”, concetto che ho spesso affrontato in questo blog. Spesso e volentieri un prodotto software deve soddisfare unicamente i requisiti di business (ovvero la sua vendita), non importa come questo prodotto venga costruito in laboratorio dagli sviluppatori (della serie “basta che funziona” per intenderci).
Se il software non viene sviluppato con il concetto di manutenibilità nella testa del suo progettista, basandosi magari su soluzioni comuni già collaudate a problemi ricorrenti (design patterns, idiomi, ecc), ciò che si ottiene è un prodotto magari inizialmente funzionante, ma i cui costi di evoluzioni, anche le più banali, diventano spesso esorbitanti per l’utente finale nonchè un incubo per gli sviluppatori.
Da MySolutionLab è possibile scaricare una libreria di codice di uso comune, utilizzabile in vari scenari.
Tuesday, March 02, 2010
#
Tutte le persone che possiedono una qualche certificazione Microsoft possono da questo sito crearsi una business card virtuale:
Ecco la mia:
Si lo so, E'¨ una certificazione che andrebbe aggiornata, ma sinceramente parlando il suo valore oggigiorno non è quello di una volta.
Comunque non è detto che prima o poi non l'aggiorni...
Wednesday, February 24, 2010
#
 |
Dietro indicazione di un amico, e spinto soprattutto dalla voglia di riprendere a frequentare eventi e workshop sulle ultime tecnologie Microsoft, ecco che mi annoto a calendario un evento molto interessante al quale non mancherò di assisterere. |
Sto parlando di .NET Campus. Tratto dal sito dell'evento:
NET Campus è un evento per sviluppatori organizzato dal gruppo DevLeap in collaborazione con il gruppo dei Microsoft Student Partner e le Community più attive per fornire a studenti e aziende una intensa mattinata di sessioni tecniche presso l'università Roma Tre. Insieme alle sessioni tecniche orientate alle novità che ruotano intorno al mondo .NET, la giornata rappresenta un momento unico dove aziende e studenti possono incontrarsi per confrontare i loro mondi e unire le loro esperienze
Questa è la mia agenda provvisoria:
Ci si vede all'evento.
Tuesday, February 23, 2010
#
Regola importante in una applicazione ASP .NET:
durante l'evento Application_Start dovrebbero essere assegnate solo variabili statiche e mai variabili d'istanza; ciò è dovuto al fatto che questo evento viene sollevato solo 1 volta durante il ciclo di vita dell'applicazione e, insieme all'evento Application_End, non è legato alla istanza in esecuzione della classe HttpApplication ma, al contrario, entrambi sono considerati eventi speciali.
Infatti, ogni applicazione ASP .NET in esecuzione è associata ad un oggetto HttpApplication, capace di gestire una richiesta alla volta. Durante il suo ciclo di vita possono essere create più istanze della classe HttpApplication, ognuna delle quali in ottica di ottimizzazione delle performance può essere riciclata. Tuttavia, i due eventi sopra citati non vengono sollevati per ogni istanza creata di HttpApplication ma, come detto, solo 1 volta durante la vita di una applicazione.
Un membro d'istanza creato in Application_Start quindi sarebbe visibile solo per la prima istanza creata di HttpApplication e non anche per le successive.
Viceversa, l'evento sollevato per ogni istanza creata di HttpApplication è invece Application_Init.
Monday, February 22, 2010
#
Quest’anno le conferenze internazionali a cui vorrei tanto assistere sono:
Speriano di averne l'opportunità , altrimenti mi devo accontentare, si fa per dire, di un evento made in Italy, a cui ho già assistito nella edizione del 2007, ovvero la DevLeap Conference 2010, che si terrà a Milano il 18-19 e 20 Maggio prossimi, che in quanto a conferenze tecniche di spessore qui in Italia non è seconda a nessuna, a mio modesto parere.
Se qualche lettore ha in programma di assistere a queste conferenze, tutte o in parte, può tranquillamente contattarmi mediante il form contact di questo blog.
Monday, February 15, 2010
#
Installando Visual Studio 2010 RC Premium ottengo questo errore bloccante:
File vs_setup.msi is invalid.
Sono in attesa di una risposta dal supporto Microsoft, dove ho aperto un ticket.
Chissà se qualche lettore di questo blog, occasionale o no, ha già una risposta a questa issue.
Ci spero!
UPDATE: La soluzione a questo inconveniente, che pochi sventurati al mondo hanno avuto (cosa che ho riscontrato leggendo i forum Microsoft) è scaricarsi direttamente il file ISO ed installare il tutto da lì, e non utilizzare invece il download dei 4 file separati che compongono l'ISO stesso.