Maurizio's blog 3.0

– 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).

– 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

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.

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

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:

public override bool Equals(object obj) 
{ 
   return System.Object.ReferenceEquals(this, obj); 
}

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:

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:

[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.

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.

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.

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.

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:

public interface ILogger
{
    void Write(Exception ex);

}  
public class Logger : ILogger
{
   public void Write(Exception ex)
   {
      Console.WriteLine(ex.Message);
   }
}

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:

public class LoggerDecorator : ILogger
{
   private ILogger loggerObj;
  
   public LoggerDecorator(ILogger logger)
   {
        loggerObj = logger;
   }

public void Write(Exception ex)
{
       Console.WriteLine(DateTime.Now.Date.ToShortDateString());
       loggerObj.Write(ex);
}

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:

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:

 public static class LoggerExtention
 {
     public static void WriteData(this Logger logger)
     {
         Console.WriteLine(DateTime.Now.Date.ToShortDateString());
     }
 }
   
// Utilizzo:
Logger loggerEx = new Logger();
loggerEx.WriteData();

– 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;

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:

1. Possibilità di effettuare ricerche parziali con l’Intellisense;
2. Intellisense nei file Javascript migliorato, ora vengono risolti anche i simboli presenti nei files inclusi, e non solo quelli del file in debugging;
3. 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;
4. 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;
5. 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;
6. Selezione del testo per colonne;
7. Gestione degli add-in con un apposito Extention Manager dedicato;
8. 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 ;
9. Test di automazione della UI;