Ho conosciuto recentemente Travis CI un servizio di continuous integration integrato con github. Così ho deciso di sperimentarlo con il mio primo progetto open source...

Integrazione con Travis CI

• Passo 1 - Registrazione

  Per prima cosa mi sono registrato sul portale di Travis CI all'indirizzo https://travis-ci.org effettuando il Sign in with GitHub e confermando le rispettive richieste di autorizzazione

• Passo 2 - Attivare gli hooks dal repository verso il servizio Travis CI

  Ho dovuto quindi abilitare il servizio Travis CI ad agganciarsi al mio repository dalla pagina di configurazione del mio progetto nella sezione Webhooks & Services

  
  
  
• Passo 3 - Committare il file di configuazione per la build e il run dei test

  Ho committato il file .travis.yml nella root del mio progetto

• Passo 4 - Modificare il file README.md per visualizzare l'esito dell'ultima build

  Questa la riga che ho aggiunto
  
  # Last Build [![Build Status](https://travis-ci.org/waldrix/FxCommon.svg?branch=master)](https://travis-ci.org/waldrix/FxCommon)
  
  il cui percorso l'ho copiato direttamente dallo snippet presente nella rispettiva pagina del mio progetto su Travis CI

  
  
  

Risultato

Adesso ogni commit al sorgente del mio repository scatena una corrispondente build e l'esecuzione dei test automatici.

I risultati dell'ultima build (del branch master) sono visibili graficamente dalla pagina principale del mio progetto github...

Diversi anni fa (fine 2008) pubblicai un post intitolato "ergonomia dell'architettura", oggi mi sento di fare un punto pensando anche all'evoluzione della programmazione in generale. Ovviamente tutto con spirito IMHO!

Una nuova definizione

Dopo attenta riflessione, ho ribattezato il vecchio post in API ergonomics (mi piace tanto come suona in inglese :)), che tradotto in italiano è ergonomia dell'interfaccia di programmazione di un'applicazione. La definizione contenuta nelle prime righe di wikipedia di Application programming interface è calzante e musa ispiratrice per aprire questo post: "Con Application Programming Interface (in acronimo API, in italiano Interfaccia di Programmazione di un'Applicazione), in informatica, si indica ogni insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per l'espletamento di un determinato compito all'interno di un certo programma. Spesso con tale termine si intendono le librerie software disponibili in un certo linguaggio di programmazione" (Ho evidenziato punti chiave in grassetto)

Le API independemente dalla modalità di pubblicazione, dal linguaggio in cui sono state realizzate o dal sistema operativo/architettura fisica in cui si eseguono, sono strumenti disponibili al programmatore per realizzare il proprio lavoro, cioè il software.

Conclusione

In altre industrie è stato ed è fondamentale lo studio dell'ergonomia, tanto che ormai è un elemento che fa parte del processo di progettazione e realizzazione di qualsiasi nuovo prodotto. Non sarebbe corretto dire che nella nostra industria non si tenga conto di quest'aspetto, in effetti fa implicitamente parte di diverse pratiche e pattern di sviluppo, ed emerge in alcune librerie di successo, ma non è certamente definito in modo rigoroso come pratica e/o all'interno forse di un approccio metodologico più ampio (che non possa essere quello agile? :D)

Spero che queste riflessioni possona produrre maggiore sensibilità da parte di programmatori, archittetti e responsabili tecnici a quest'aspetto che ho definito 'API ergonomics' soprattuto nell'ambito di progettazione e sviluppo di librerie e strumenti che dovranno usare altri sviluppatori. Sarebbe utile individuare in modo più rigoroso le pratiche, le metodologie, gli strumenti che sono utili allo sviluppo di librerie applicative più ergonomiche, tenendo conto che anch'esse a loro volta, dovrebbero rispondere a criteri di ergonomia. Sarebbe interessante anche poter misurare il livello di ergonomia di una libreria o di una applicazione defininendo e applicando oppurtune metriche (ad esempio come possiamo dare un indice di complessità al codice applicando determinati algoritmi)

E' possibile che per alcuni questa disquisizione possa sembrare mera filosofia, in realtà dal mio punto di vista la preoccupazione di scegliere, o progettare e sviluppare, strumenti più facili e comprensibili da usare per la realizzazione di un progetto software da un vantaggio competitivo e tecnologico non indifferente. Io ho vissuto questa esperienza occupandomi dello sviluppo e della manutenzione di una libreria "enterprise" per un grosso progetto gestionale e ho visto che lavorando nell'applicare pratiche per rendere più intuitivo ed efficacie l'utilizzo dell'infrastruttura al programmatore ne hanno beneficiato in maniera effettiva produttività e qualità.

Problema

Verificare se un evento "incapsulato" ( public event ... ) è già registrato dato l'oggetto origine che genera ed incapsula l'evento, l'oggetto di destinazione che ha registrato l'evento e il nome dell'evento.

Soluzione

Esempio

Vedi progetto FxCommon sorgente ReflectionExtensions.cs test ReflectionExtensionsTest

• Ho creato il repository del progetto GIT su GitHub applicando la licenza Apache 2.0
  
  
• Ho quindi clonato il nuovo repository in locale con SourceTree
  
  
  
• Ho effettuato il merge da un precedente repository git dei progetti FxCommon e FxCommonTest da cartelle diverse
• Sono partito da questo post Git: Copy a file or directory from another repository preserving the history
• Merge progetto FxCommon

      mkdir /c/temp/mergepatchs
      export reposrc=/c/Sviluppo/Libreria/FxCommon
      git format-patch -o /temp/mergepatchs $(git log $reposrc|grep ^commit|tail -1|awk '{print $2}')^..HEAD $reposrc
      cd /c/Sviluppo/FxCommon
      git am /temp/mergepatchs/*.patch
      

  Merge progetto FxCommon

      mkdir /c/temp/mergepatchs
      export reposrc=/c/Sviluppo/Tests/FxCommonTest
      git format-patch -o /c/temp/mergepatchs $(git log $reposrc|grep ^commit|tail -1|awk '{print $2}')^..HEAD $reposrc
      cd /c/Sviluppo/FxCommon
      git am /temp/mergepatchs/*.patch
      

• Ho creato la soluzione VS.2013 vuota e aggiunti i due progetti di Sviluppo e Test
• Ho preparato una build rudimentale del pacchetto NuGet
  1. Ho configurato le proprieta' del nuovo progetto (Properties/AssemblyInfo.cs)
  2. Ho creato la cartella /Build sotto la root ed aggiunto il file NuGet FxCommon.nuspec

                 <?xml version="1.0" encoding="utf-8" ?>
                 <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
                     <metadata>
                         <id>MBaldessari.FxCommon</id>
                         <version>0.0.1</version>
                         <title>FxCommon</title>
                         <description>.NET core library used by FxXXX projects</description>
                         <authors>Marco Baldessari</authors>
                         <language>en-US</language>
                         <projecturl>https://github.com/waldrix/FxCommon</projecturl>
                         <tags>fx</tags>
                     </metadata>
                 </package> 
         

  3. Ho quindi creato un batch denominato Build.bat

                 mkdir .\bin
                 del .\bin\*.nupkg
                 ..\.nuget\nuget.exe pack ..\FxCommon\FxCommon.csproj -Build -Properties Configuration=Release -OutputDirectory .\bin\
                 pause        
             

• Effettuato l'upload su NuGet (triviale) da Upload Your Package
  
  
  

  Nota: Non ha preso l'url del progetto dal pacchetto (mi chiedo il perche'??), ma e' stato possibile modificare le proprieta' prima di confermare il pacchetto

• Il gioco e' fatto! ... ecco il mio pacchetto visibile su NuGet, e' solo una libreria di base con pochissima roba ma comunque "testata", più avanti vorrei pubblicare una libreria più significativa! :)
  

(Vedi Re[studing] C# 5 - (WinRT))

• Delegates

  • I delegati sono oggetti immutabili, quindi, ad esempio ogni chiamata di sottoscrizione o cancellazione +=/-= determina sempre la creazione di una nuova istanza.
  • Tutti i delegati sono implicitamente di tipo System.MultiCastDelegate che a sua volta estende System.Delegate
  • Quando viene assegnato un metodo di classe, l'istanza della classe viene referenziata dal delegato. Conoscere questo è molto importante perché possibile causa di memory leak non previsti: In caso di eventi statici sottoscritti da un metodo di classe, allora l'istanza di quest'ultima non viene rilasciata se non viene effettuata la rimozione della sottoscrizione (Vedi ad es. Windows.Forms, ToolStrip and Memory Leak
  • I delegati supportano la varianza e la covarianza secondo logiche simili a quelle delle interfacce (vedi Re[studing] C# 5 - (... covariance and controvariance))
  • Questo spiega l'utilizzo dello standard degli eventi basato sulla classe System.EventArgs che essendo un parametro di input supporta la controvarianza
    • Seguendo la stessa regola delle interfacce generic, per sfruttare la varianza e controvarianza con i generic delegates dobbiamo esplicitare la direzione dei parametri. (I vari generic delegates Action e Function sono definiti seguendo questa logica
      • delegate TResult Func<out TResult>(); - Varianza
      • delegate void Action<in T>(T arg); - Controvarianza
  
  

• Events

  • Il brodcaster è la classe che invoca l'evento, il subscriber il metodo che sottoscrive l'evento.
  • Aggiungendo la keyword event nell'esposizione del metodo:
    • Il compilatore incapsula il delegato, in particolare espone solo Add (+=) e Remove (-=)
    • Il compilatore implementa un meccanismo di sincronizzazione (lock-free compare-and-swap alghoritm)
  • Per evitare side-effects in ambito multi-thread copiare all'interno del metodo di invocazione il delegato prima di effetuare l'invoke
  • I delegati EventHandler ed EventHandler<T> implementano il pattern .NET standard degli eventi
  
  
  Code Snippet

  1.         class Broadcaster
  2.         {
  3.             public event EventHandler<EventArgs> EventOccured;
  4.  
  5.             public void InvokeOnEventOccurred()
  6.             {
  7.                 OnEventOccured();
  8.             }
  9.  
  10.             public Task InvokeOnEventOccurredAsync()
  11.             {
  12.                 return Task.Factory.StartNew(OnEventOccured);
  13.             }
  14.  
  15.             protected virtual void OnEventOccured()
  16.             {
  17.                 var eventOccured = EventOccured;
  18.                 if (eventOccured != null)
  19.                     EventOccured(this, EventArgs.Empty);
  20.             }
  21.         }
  
  

• Lambda expressions

  • Una lambda expression è una funzione o un metodo anonimo, nella forma (parameters) => expression-or-statment-block, quest'ultima può definire:
    • Un istanza di un delegato: System.Delegate
    • Un albero di espressione: System.Linq.Expressions.Expression<TDelegate>
  • Nel caso più comune, il delegato, il compilatore genera un metodo privato nel quale sposta l'implementazione
  • I parametri di una Lambda Expressions possono essere "puri" oppure specificati es: (int x) => x * x
  • Quando una variabile esterna è utilizzata all'interno di una lambda expression, quest'ultima viene chiamata captured variable, mentre l'espressione viene chiamata closure, le importanti conseguenze sono:
    • Il ciclo di vita delle variabili catturato è esteso a quello del delegato
    • Le variabili sono valutate quando il delegato è invocato e non quando la variabile è catturata. (NOTA: Questo vale anche per gli Anonymous Methods in gran parte assorbiti dalle Lambda Expressions)


Code Snippet
1.         [Test]
2.         public void TestOnCapturedVariable()
3.         {
4.             var exprs = new Func<int>[3];
5.             
6.             for (int i = 0; i < 3; i++)
7.                 exprs[i] = () => i;
8.  
9.             Assert.AreEqual(3, exprs[0]());
10.             Assert.AreEqual(3, exprs[1]());
11.             Assert.AreEqual(3, exprs[2]());
12.         }



• Exceptions

  • Le eccezioni sono molto pesanti da gestire occupando centinaia di cicli di clock.
  • Le eccezioni .NET devono essere sottoclassi di System.Exception (Questo non è vero in C++ dove è possibile "lanciare" qualsiasi oggetto come eccezione, in questo ultimo caso il CLR incapsula l'oggetto in una System.Runtime.CompilerServices.RuntimeWrappedException)
  • Importante: Quando si gestisce cattura un eccezione con lo statment catch è possibile "rilanciarla" con lo statment throw, con la sottile differenza che throw; (senza parametri) rilancia l'eccezione originale senza modificarne gli attributi mentre throw ex; (dove ex è il nome della variabile assegnato all'eccezione nello statment catch) modifica l'eccezione propagata cambiando lo StackTrace che non riflette più quello dell'eccezione originale.
  
  
Code Snippet
1.         [Test]
2.         public void TestDifferentStackTraceOnExceptionThrown()
3.         {
4.             try
5.             {
6.                 CaptureExceptionAndRethrowWithoutParameter();
7.             }
8.             catch (Exception ex)
9.             {
10.                 Console.WriteLine("-----CaptureExceptionAndRethrowWithoutParameter-----");
11.                 Console.WriteLine(ex.StackTrace);
12.                 Console.WriteLine("----------------------------------------------------");
13.                 Console.WriteLine();
14.             }
15.  
16.             try
17.             {
18.                 CaptureExceptionAndRethrowWithParameter();
19.             }
20.             catch (Exception ex)
21.             {
22.                 Console.WriteLine("-----CaptureExceptionAndRethrowWithParameter-----");
23.                 Console.WriteLine(ex.StackTrace);
24.                 Console.WriteLine("-------------------------------------------------");
25.                 Console.WriteLine();
26.             }
27.         }
28.  
29.         void CaptureExceptionAndRethrowWithoutParameter()
30.         {
31.             try
32.             {
33.                 NotImplementedMethod();
34.             }
35.             catch (Exception ex)
36.             {
37.                 throw;
38.             }
39.         }
40.  
41.         void CaptureExceptionAndRethrowWithParameter()
42.         {
43.             try
44.             {
45.                 NotImplementedMethod();
46.             }
47.             catch (Exception ex)
48.             {
49.                 throw ex;
50.             }
51.         }
52.  
53.         void NotImplementedMethod()
54.         {
55.             throw new NotImplementedException();
56.         }

Di seguito lo Stack Trace notate le differenze, nel secondo cas perdiamo l'origine dell'eccezione

-----CaptureExceptionAndRethrowWithoutParameter-----
in snftest.CSharp5.AdvancedCSharp.NotImplementedMethod() in c:\Sviluppo\privatedev.sinformatic\Libreria\snftest\CSharp5\AdvancedCSharp.cs:riga 100
in snftest.CSharp5.AdvancedCSharp.CaptureExceptionAndRethrowWithoutParameter() in c:\Sviluppo\privatedev.sinformatic\Libreria\snftest\CSharp5\AdvancedCSharp.cs:riga 84
in snftest.CSharp5.AdvancedCSharp.TestDifferentStackTraceOnExceptionThrown() in c:\Sviluppo\privatedev.sinformatic\Libreria\snftest\CSharp5\AdvancedCSharp.cs:riga 51
----------------------------------------------------

-----CaptureExceptionAndRethrowWithParameter-----
in snftest.CSharp5.AdvancedCSharp.CaptureExceptionAndRethrowWithParameter() in c:\Sviluppo\privatedev.sinformatic\Libreria\snftest\CSharp5\AdvancedCSharp.cs:riga 96
in snftest.CSharp5.AdvancedCSharp.TestDifferentStackTraceOnExceptionThrown() in c:\Sviluppo\privatedev.sinformatic\Libreria\snftest\CSharp5\AdvancedCSharp.cs:riga 63
-------------------------------------------------


• Enumerator (IEnumerator) e Enumerable (IEnumerable)

  • Un enumeratore si può definire come un cursore in sola lettura, che può iterare solo in avanti, su di una sequenza di elementi.
    • NOTA: Qualsiasi oggetto implementi MoveNext() and Current è enumerabile.
    • Quando un oggetto enumeratore implementa IDisposable, lo statment foreach() chiama Dispose() al termine dell'enumerazione.
• Un oggetto enumerabile espone una sequenza logica di elementi, la differenza sostanziale è che l'oggetto enumerabile NON è un cursore ma PRODUCE un cursore.
  • Lo statment foreach implementa l'iterazione su un oggetto enumerabile chiedendo all'oggetto di produrre l'enumeratore con GetEnumerator() per iterarlo.
• yield keyword
  • C'è una sostanziale differenza tra un restituire l'istanza di un oggetto enumeratore o enumerabile oppure usare la parola chiave yield.
  • Quando si usa uno statment yield return x (dove x è il tipo da enumerare) si esprime il concetto di ritornare il "prossimo elemento richiesto dell'enumerazione", questo richiede che lo stato del chiamante sia conservato fino alla prossima iternazione (MoveNext()).
    • Dal punto di vista del programma questo approccio modifica profondamente il flusso di esecuzione: La funzione viene eseguita solo quando è enumerata e non quando viene chiamata, infatti il compilatore incapsula il nostro metodo in un oggetto enumeratore, in grado di conservare lo stato del metodo.
    • Lo statment yield break interrompe l'enumerazione, non è obbligatorio a meno che non sia necessario interrompere prematuramente l'iterazione.
    • Per ragioni di complessità l'istruzione yield non può essere presente in un blocco try/catch/[finally] mentre può comparire nella clausola try di un blocco try/finally
  
  
Code Snippet
1.         static int GeneratedNumbers = 0;
2.  
3.         [Test]
4.         public void EnumerateFirstHundredIntegerNumbers()
5.         {
6.             GeneratedNumbers = 0;
7.             foreach (var number in IntNumbers)
8.                 if (number == 99)
9.                     break;
10.             Assert.AreEqual(100,GeneratedNumbers);
11.         }
12.  
13.         IEnumerable<int> IntNumbers
14.         {
15.             get
16.             {
17.                 for (int i = 0; i < int.MaxValue;                  i++)
18.                 {
19.                     GeneratedNumbers++;
20.                     yield return i;
21.                 }
22.             }
23.         }



• Nullable<T>

  • Quando dichiaramo un T? dove T è un value-type (tipo nativo o struct) la nostra dichiarazione viene tradotta dal compilatore come Nullable<T>.
  • Il compilatore ridefinisce automaticamente gli operatori, come > < o ==, per renderli "semanticamente uguali" agli operatori dei corrispondenti not nullable value-type.
    • Ad esempio: a < b viene ridefinito come (a.HasValue && b.HasValue) ? (a.Value < b.Value) : false
  • Nel caso di confronto con gli operatori logici & oppure | il null viene considerato come valore sconosciuto
    • Ad esempio: a | b dove a è true è b nullo il risultato è true, mentre se a fosse false allora il risultato sarebbe null

Premessa

E' cosa nota per chi programma in Windows Forms (ma non solo...) situazioni di inaspettata ricorsione in fase di gestione degli eventi. Di solito capita quando un gestore di un evento, o indirettamente e più facilmente, un metodo comune chiamato da quest'ultimo, modifica un controllo UI che a sua volta scatena un nuovo evento il cui gestore invoca lo stesso codice... ed ecco la situazione di ricorsione imprevista che nella maggioranza dei casi porta ad avere una "fastidiosa" ;) StackOverflowException!

Soluzione

Ci sono varie soluzioni al problema, oltre a riprogettare il gestore per evitare queste situazioni, un metodo potrebbe essere quello di deregistrare temporaneamente gli eventi sul controllo che dobbiamo modificare, anche se quest'ultimo approccio non mi piace e di solito non lo utilizzo perché troppo macchinoso. Io preferisco utilizzare una variabile di classe che mi dice se sto già eseguendo quella parte di codice. Di seguito riporto un esempio.

Ho pensato però di ridurre questo "overhead" progettando una classe, l'idea alla base è quella di utilizzare un dizionario per registare le invocazioni di metodi legati ad istanze di classe, e l'interfaccia IDisposable per racchiudere il tutto in un elegante statment using. Ecco il risultato:

Di seguito vi riporto il codice della classe: (NOTA: Ci sono due miglioramenti che voglio introdurre successivamente: 1. Sincronizzazione per funzionare in ambito di concorrenza 2. Tipizzare il nome del metodo usando una Lambda Expression...

NOTA: TryGetValue(...) è il metodo più performante per verificare se un entry esiste in un dizionario in quanto evita situazioni di doppio matching ...

(Vedi Re[studing] C# 5 - (WinRT))

• const versus static readonly

  Un campo dichiaranto come costante (const) è valutato staticamente in fase di compilazione e sostituto nel codice. Per questa ragione vanno dichiarati constanti i valori o le stringhe realmente immutabili nel tempo, pena side-effects non voluti nel caso di aggiornamento di un Assembly dipendente senza ricompilare, in questi casi definire il campo static readonly, .

• Partial methods (C# 3.0)

  Utili nell'utilizzo di classi generate automaticamente quando si ha la necessità di modularizzare parti di implementazione da parte dell'utente, infatti la classe è compilabile anche quando il metodo non viene implementato, in questo caso la chiamata del metodo non viene generata. Il metodo deve essere privato e non deve avere tipo di ritorno (void).

  Code Snippet

  1.         partial class PartialExample
  2.         {
  3.             public PartialExample()
  4.             {
  5.                 CustomInitObject(); //If not implemented the call is not generated
  6.             }
  7.  
  8.             partial void CustomInitObject();
  9.         }
  10.  
  11.         partial class PartialExample
  12.         {
  13.             partial void CustomInitObject()
  14.             {
  15.                 //Implementation ...
  16.             }
  17.         }
  
  

• class and inheritance

  • class A : B: A è la sottoclasse (o subclass), B è la superclasse (o superclass)
  • La conversione di una referenza di tipo A in una di tipo B è definita upcast ed è implicita
  • La conversione di una referenza di tipo B in una di tipo A è definita downcast e deve essere esplicita
  
  

• structs

  • Le struct sono tipi-valore, per la precisione sono di classe System.ValueType, e di conseguenza implicitamente object
  • Le struct non supportano i parameterless constructor, finalizers e virtual members
  
  
  Code Snippet

  1.         struct S
  2.         {
  3.         }
  4.     
  5.         [Test]
  6.         public void TestStruct()
  7.         {
  8.             S s = default(S);
  9.  
  10.             Assert.IsInstanceOf<object>(s);
  11.             Assert.IsInstanceOf<ValueType>(s);
  12.         }
  
  

• internal access modifier

  • Il modificatore internal rende visibili i tipi solo all'interno dello stesso assembly
  • I tipi internal possono anche essere visibili a friend assemblies utilizzando l'attributo InternalsVisibleToAttribute
  
  

• flags enum

  • Quando un tipo enum è dichiarato con l'attributo [Flags], i suoi valori possono essere combinati con gli operatori bit a bit (come | e &)
  • La chiamata a ToString() su di un enum di tipo Flags produce l'elenco del nome dei valori separati da "," quando c'è corrispondenza altrimenti solo un numero
  
  
  Code Snippet

  1.         [Flags]
  2.         enum Options
  3.         {
  4.             One = 1,
  5.             Two = 2,
  6.             Three = 4
  7.         }
  8.  
  9.         [Test]
  10.         public void TestEnumFlags()
  11.         {
  12.             var o = Options.One | Options.Three;
  13.             Assert.AreEqual("One, Three", o.ToString());
  14.             var o2 = (Options) 6;
  15.             Assert.AreEqual("Two, Three", o2.ToString());
  16.             var o3 = (Options) 8;
  17.             Assert.AreEqual("8", o3.ToString());
  18.         }
  
  

• Generics: Naked Type constraint (vedi C# Naked Type constraint)

  Un argomento di un tipo generic può essere dichiarato con la constraint where TY:TX indicando che TY deve essere di tipo TX.

  Code Snippet

  1.         class Generic1<TClass, TSubClass> where TSubClass : TClass
  2.         {
  3.             public bool IsTClassAssegnabileFromTSubClass {get { return typeof (TClass).IsAssignableFrom(typeof (TSubClass)); }}
  4.         }
  5.  
  6.         class A { }
  7.         class B:A { }
  8.  
  9.         [Test]
  10.         public void TestGenericUseWithNakedType()
  11.         {
  12.             var generic1 = new Generic1<object, A>();
  13.             var generic2 = new Generic1<A, B>();
  14.             //var generic3 = new Generic1<B, A>(); Compile error
  15.  
  16.             Assert.IsTrue(generic1.IsTClassAssegnabileFromTSubClass);
  17.             Assert.IsTrue(generic2.IsTClassAssegnabileFromTSubClass);
  18.         }
  
  

• Generics: Self referencing declarations

  Un argomento di un tipo generic può essere dichiarato dello stesso tipo della classe, obbligando di fatto ad effettuare un subclassing per poterlo istanziare.

  Code Snippet

  1.         class SelfGeneric<T> where T : SelfGeneric<T> { }
  2.         class SubSelfGeneric : SelfGeneric<SubSelfGeneric> {}
  3.  
  4.         [Test]
  5.         public void TestGenericUseWithSelfType()
  6.         {
  7.             var generic1 = new SelfGeneric<SubSelfGeneric>();
  8.             var generic2 = new SubSelfGeneric();
  9.             //var generic3 = new SelfGeneric<object>(); //Compile error
  10.         }
  
  

• Generics: Open/Close Type e differenze con i template C++

  • Un generic nella forma class<T> è definito un open type (che appunto è un modello di classe)
  • Quando dichiarato con il parametro, ad esempio class<int> è definito un close type (tipo concreto ed instanziabile a runtime)
  • In c++ il close type viene generato a compile time per questo le librerie di template c++ (ad es. ATL,STL) sono rilasciate come sorgente
  
  

• Covariance and controvariance

  • Nel caso di A : B (A è implicitamente convertibile in B - vedi upcast) allora I<A> è implicitamente convertibile in I<B>, quest'ultima caratteristica è detta covarianza (covariance)
    • La covarianza è applicabile per le interfacce generic, i delegati generic, gli array, ma NON per le classi generic, questo nel rispetto della static type safety c#
    • Nelle interfacce generic la covarianza è supportata solo per i parametri modificati con out, esempio IProducer<out T> { T Produce(); }
      • Il modificatore out indica che T può essere indicato solo come parametro di output nel contratto dell'interfaccia

• Quando I<B> è implicitamente convertibile in I<A> allora si parla di controvarianza (controvariance)
  • Questa caratteristica è possibile solo definendo un interfaccia controvariante, dove uno o più paremtri sono indicati con il modificatore in.
  • In questo caso il parametro decorato con il modificatore in può comparire solo come input nel contratto dell'intefaccia, esempio IConsumer<in T> { void Consume(T value); }

NOTA: Stiamo parlando di interfacce cioè di contratti e non di tipi concreti, in questo caso la covarianza e la controvaianza sono meccanismi avanzati che ci permettono di dichiarare contratti che ci garantiscono il controlo sui tipi a compile tyme (static type safety). Riprendendo gil esempi sopra riportati (produttore, consumatore), nel caso della covarianza, stiamo dichiarando che un produttore ha un metodo che ritorna l'istanza di un oggetto di tipo T: dato un tipo concreto, ad esempio A (sottoclasse di B) possiamo sempre convertire implicitamente questo tipo nella sua superclasse (in B o in object), ecco perché IProducer<A> sarà convertibile in IProducer<B> ma NON vieceversa. In realtà quando parliamo di controvarianza stiamo facendo fondamentalmente la stessa operazione ma in modo simmetrico, infatti stiamo dichiarando che un consumatore ha un metodo che prende in input un oggetto di tipo T: dato un tipo concreto, ad esempio B (classe base) possiamo sempre convertire A (sottoclasse) in B ed è per questo che IConsumer<B> è convertibile in IConsumer<A> ma NON viceversa.

• Conoscevo Git in linea teorica ma non l'avevo mai usato (sono un utilizzatore di SVN da molti anni ...) quindi ho scelto queste risorse per acquisire un minimo known-out iniziale:
  • Seguito il corso tryGit su Code School
  • Letto l'introduzione e alcune sezioni di Pro Git, un ottimo book on-line

• Scelto un servizio di host: Volevo provare GitHub, sul quale mi sono registrato, ma purtroppo con l'account gratuito è possibile creare solo repository pubblici, così ho optato per il servizio di hosting offerto Assembla. (GitHub l'ho utilizzerò in seguito per pubblicare un eventuale progetto open source...)

• Ho scelto come client windows GitHub for Windows, senza per il momento utilizzare/configurare la connessione verso il portale GitHub.

• Ho creato cercato di creare il mio primo repository facendo un clone dal repository privato inizializzato su Assembla, ma prima era necessario risolvere un problema di sicurezza, in quanto il comando git clone falliva con un errore di sicurezza ...
• Ho seguito la soluzione trovata in questo post permission denied git push FATAL: COULD NOT READ FROM REPO: In altre parole ho dovuto creare, nel profilo locale, un certificato per la crittografia SSH con l'utility ssh-keygen e installare la chiave pubblica nel profilo di Assembla (NOTA: tutte le operazione a riga di comando le ho eseguite dalla powershell di GitHub for Windows)
• Ho quindi potuto eseguire con successo il clone del mio repository in locale (vuoto) con il comando git clone git@git.assembla.com:xxx.yyy.git


• Ho fatto la mia prima commit Git e quindi sincronizzato il mio repository (effettuando la mia prima push :))

• Volevo copiare il mio repository SVN mantenendo tutta la storia delle commit. Dopo aver fatto parecchie ricerche su Internet ...
• Ho clonato il repository SVN trasformando in un repository Git con il comando git svn clone [SVN repo URL]
• Ho seguito, in parte, i suggerimenti di questo post How to import existing GIT repository into another?: ho creato un branch sul mio nuovo repository Git, ho importato tutto il repository Git clonato da SVN, ho mergiato il branch sul trunk e quindi ho aggiornato il server.

Problema

Ogni tanto e "in situazioni di emergenza", mi capita di dover preparare una singola DLL, per la fixare in un produzione un bug. Dato che il nostro gruppo di sviluppo utilizza SVN come repository del codice, con un unico trunk sul quale vengono fatte le build, etichettate con specifica commit da un sistama di build automatico, procedo nel seguente modo:

• Dalla versione del sw rilasciata in produzione ottengo la revision della build (rev)
• Effetto una checkout to revision alla rev così determinata
• Isolo la o le revision che includono la fix: [revfix1], [revfix2] ... dove revfixX>rev
• Effettuo o una svnupdate sui singoli file oggetto della build o un merge delle revision [revfix1], [revfix2] ...

Ho pensato di dedicare qualche minuto e scrivere un batch (svnfix.bat) che faccia questa operazione in automatico che di seguito riporto:

SET PT=%1
SET REV=%2
SHIFT
SHIFT
svn update %PT% -r %REV%
:start_merge
IF "%1"=="" (GOTO :end_merge)
CD %PT%
svn merge -c %1 %PT%
SHIFT
GOTO :start_merge
:end_merge

L'utilizzo è il seguente: svnfix path_working_copy rev [revfix1] [revfix2] ... ricordatevi di fare una revert dei file mergiati dopo aver buildato ...

PS: So che esistono i workflow che prevedono la creazione di apposite branch per il deploy dalle quale poi sarebbe possibile fare il fix, ma attualmente per varie ragioni questa modalità non è implementata dal nostro gruppo di lavoro.