martedì 2 dicembre 2008
Chiunque di voi scriva test unitari per il proprio codice (perché esiste ancora qualcuno che non lo fa?? 
) consiglio questi brevi video di Google:
venerdì 28 novembre 2008
Anch’io nei miei progetti WPF per rendere testabile la logica della mia applicazione senza rinunciare alla pontenza del DataBinding utilizzo (anche) il Pattern Model-View-ViewModel. L’interfaccia INotifyPropertyChanged gioca un ruolo fondamentale nell’implementazione di questo pattern quindi ne faccio un uso massiccio. Quello che non mi è mai piaciuto di questa interfaccia è l’uso delle stringe per indicare qual è la proprietà modificata, vediamo un semplice esempio dell’uso di INotifyPropertyChanged:
1: public class Person : INotifyPropertyChanged {
2: public event PropertyChangedEventHandler PropertyChanged;
3:
4: private string firstName = String.Empty;
5: public string FirstName {
6: get { return firstName; }
7: set {
8: if (firstName != value) {
9: firstName = value;
10: RaisePropertyChanged("FirstName");
11: }
12: }
13: }
14:
15: private void RaisePropertyChanged(string propertyName) {
16: if (PropertyChanged != null)
17: PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
18: }
19: }
Se cambio il nome della proprietà FirstName Visual Studio si accorge del cambiamento e mi permette con un solo click di rinominare la proprietà ovunque venga utilizzata, però questo sistema di refactoring non è abbastanza smart da modificare la stringa FirstName (riga 10). Grazie alla Static Reflection possiamo eliminare questo problema, il “trucco” sta nel passare al metodo RaisePropertyChanged la proprietà come tipo Expression<Func<T>>, convertire successivamente il Body nel tipo MemberExpression ed in fine recuperare il nome tramite le proprietà Member. Risultato:
1: public class Person : INotifyPropertyChanged {
2: public event PropertyChangedEventHandler PropertyChanged;
3:
4: private string firstName = String.Empty;
5: public string FirstName {
6: get { return firstName; }
7: set {
8: if (firstName != value) {
9: firstName = value;
10: RaisePropertyChanged(() => FirstName);
11: }
12: }
13: }
14:
15: private void RaisePropertyChanged<T>(Expression<Func<T>> property) {
16: var expression = property.Body as MemberExpression;
17: var member = expression.Member;
18: if (PropertyChanged != null)
19: PropertyChanged(this, new PropertyChangedEventArgs(member.Name));
20: }
21: }
Adesso il nostro codice supporta pienamente il
rename refactoring. Come ultimo passo possiamo incapsulare la logica di manipolazione dei tipi
Expression in un
Extension methods rendendo il codice molto più leggibile:
1: public static class PropertyExtensions {
2: public static PropertyChangedEventArgs CreateChangeEventArgs<T>(this Expression<Func<T>> property) {
3: var expression = property.Body as MemberExpression;
4: var member = expression.Member;
5: return new PropertyChangedEventArgs(member.Name);
6: }
7: }
8:
9: public class Person : INotifyPropertyChanged {
10: public event PropertyChangedEventHandler PropertyChanged;
11:
12: private string firstName = String.Empty;
13: public string FirstName {
14: get { return firstName; }
15: set {
16: if (firstName != value) {
17: firstName = value;
18: RaisePropertyChanged(() => FirstName);
19: }
20: }
21: }
22:
23: private void RaisePropertyChanged<T>(Expression<Func<T>> property) {
24: if (PropertyChanged != null)
25: PropertyChanged(this, property.CreateChangeEventArgs());
26: }
27: }
martedì 2 dicembre 2008
Una delle
novità di WPF 3.5 SP1 sono gli Shader Effects, adesso il Team di WPF ha pubblicato su
CodePlex la
Windows Presentation Foundation Pixel Shader Effects Library, una libreria contenente molti Shader Effects, direttamente dalla home del progetto:
Initial seed includes:
Effects:
BandedSwirl, Bloom, BrightExtract, ColorKeyAlpha, ColorTone, ContrastAdjust, DirectionalBlur, Embossed, Gloom, GrowablePoissonDiskEffect, InvertColor, LightStreak, Magnify, Monochrome, Pinch, Pixelate, Ripple, Sharpen, SmoothMagnify, Swirl, Tone, Toon, and ZoomBlur
Transition Effects:
BandedSwirl, Blings, Blood, CircleReveal, CircleStretch, CircularBlur, CloudReveral, Cloudy, Crumble, Dissolve, DropFade, Fade, LeastBright, LineReveal, MostBright, PixelateIn, PixelateOut, Pixelate, RadialBlur, RadialWiggle, RandomCircleReveal, Ripple, Rotate, Saturate, Shrink, SlideIn, SmoothSwirl, Swirl, Water, Wave.
Ora non resta che provarli tutti 
.
Fra i vari controlli presenti nelle prime versioni di Silverlight c’era la WatermarkedTextBox. Dalla release Beta2 tale controllo è stato rimosso. Adesso, pressati dalle forti richieste, il team di Silverlight ha rilasciato il codice sorgente del suddetto controllo.
Fonte: Silverlight 2 Watermarked TextBox Control
Technorati Tag:
Silverlight
Visual Studio 2008 Sp1 non visualizza l’evento MouseDoubleClick per un ListBoxITem, come se non esistesse:
In realtà tale evento esiste, è solo un problema di IntelliSense, quindi basta digitare il nome e tutto funziona:
Al seguente url è disponibile una piccola demo: ListItemDoubleClickDemo
XAML è un linguaggio dichiarativo general-purpose, sviluppato da Microsoft e derivato dall’XML, atto alla rappresentazione di gerarchie di oggetti. Attualmente XAML è utilizzato in Silverlight, Windows Presentation Foundation (WPF) e Windows Workflow Foundation (WF), ognuno con il proprio parser e runtime. Sul sito MSDN possiamo trovare un articolo che spiega le differenze fra il parser di Silverlight e quello di WPF.
Questo post doveva essere pubblicato già da po’ di settimane, ma gli impegni sono sempre pronti a mettere il bastone fra le ruote.
In WPF se mettete in Binding una proprietà di tipo boolean con un controllo RadioButton vi accorgerete presto di un bug nel motore di Binding.
Maggiori info su questo thread sul newsgroup di C#.
Grazie a Corrado per la segnalazione
Un interessante confronto tra il framework di una WPF Composite Application (Expression Blend) e un framework per creare WPF Composite Application (CompositeWPF).
Fonte: Expression Framework versus Composite WPF
Non sono bravo a fare gli annunci formali quindi vado dritto al sodo, insieme ad un gruppo di amici abbiamo dato vita allo User Group Toscano su .NET, il sito è ufficialmente online da Venerdì 10 Ottobre. Alcuni di noi erano presenti alla tappa Toscana dell’evento Microsoft Days dove Pietro Brambati ha accettato la nostra proposta di sfruttare l’occasione per presentare il neonato gruppo (con tanta insistenza da parte nostra non poteva rifiutare ). Pietro si è dimostrato molto disponibile ed alla fine ha fatto molto di più di quello che abbiamo chiesto…
Sempre in quell’occasione ho avuto il piacere di conoscere Gabriele Castellani, Giuseppe Guerrasio e Alessandro Del Sole, che ringrazio e saluto!
Per finire un particolare grazie va a Paolo Carpitelli, una persona molto disponibile che, nonostante non abbia niente a che fare con il modo IT, ne tanto meno con quello delle communities, con pochissimo preavviso è stato in grado di fornirci un logo in tempo per l’evento di Giovedì, sopportando anche le nostre esigenze. Grazie Paolo!
PS: mentre UGIdotNET era off-line per i problemi che sappiamo, Marco Minerva era in totale astinenza da blogging, dato che ormai aveva perso tutti i capelli e non sopportava più quello stato di ansia e tensione ha iniziato a bloggare sulla nostra community :D
Technorati Tag:
DotNetToscana
No, non il famoso
film, ma il programma di
Mentana in onda su Canale 5. Direte voi, che c’entrano i Livornesi con Matrix?
Venerdì sera prima di andare a dormire ho dato un’occhiata in tv scoprendo (devo ammettere con piacere) che Matrix dedicava una puntata sui Livornesi, soprattutto sulla nostra satira, il
Vernacolo della mia città e lo splendido giornale
Il Vernacoliere. Com’è andata a finire?? non sono più andato a dormire e sono rimasto a farmi un po’ di risate!!
Sempre che a qualcuno di voi possa interessare,
qui sono disponibili i video della puntata di Venerdì e
qui una pagina piena di proverbi Livornesi.
venerdì 29 agosto 2008
Accettare la sfida è stato facile ...però ora arriva la parte difficile, raggiungere l'obbiettivo!! 
La prima fase è un test iniziale nel quale ho fatto 25 flessioni di fila!! ( + 1 infarto )
lunedì 25 agosto 2008
Interessato dal post di Antonio sull'uso del TDD per progettare applicazi multithreading ho deciso di riprovare senguendo il percorso logico da lui espresso, usando RhinoMocks come framework di mocking piuttosto che i mocks manuali usati da Antonio per non complicare il codice di test. La versione di RhinoMocks utilizzata è la 3.5 RC che potete scaricare a questo url, questa versione della libreria supporta la sintassi Arrange/Act/Assert permettendo di scrivere test molto più chiari, per maggiori info visitate questa pagina.
Adesso vediamo e commentiamo i vari metodi di test, cominciamo con il primo:
Le differenze sostaziali sono, alla riga 4 e 9, nella prima generiamo un mock dell'interfaccia ILogWriter e nella seconda "chiediamo" al mock object di verificare se è stato chiamato il metodo Write e se il parametro in ingresso era uguale a log. Proseguiamo con il secondo test:
La parte interessante in questo test sono le righe dalla numero 9 alla 14, dove istruisco il mock object. In pratica non faccio altro che "dire" al mock object "quando viene invocato il metodo Write con una qualsiasi istanza di Log, esegui la seguente Action". Il delegate passato come Action al metodo Do esegue la solita logica del mock manuale usato da Antonio. Per il resto il codice di test è sostanzialmente identico. La logica del terzo metodo di test è la solita quindi vi posto solo il codice:
In fine passiamo all'ultimo metodo di test:
Anche qui la parte interessante è la configurazione del mock object, in questo test la sintassi del mock rimane uguale ai test precedenti, quello che cambia è la logica contenute nell' Action delegate passato al metodo Do, il quale scatena un' eccezione.
Nel mio repository personale ho creato tre proggeti uno con la versione manuale dei mocks, uno che usa RhinoMocks ed in fine uno che usa Moq, il tutto è reperibile a questo url: http://makesimple.googlecode.com/svn/trunk/UnitTestMultithreading
mercoledì 6 agosto 2008
Dopo aver chiesto ad i CDays2008 a Mauro cosa pensava dei mixin, dopo aver letto i vari post di Andrea, Raffaele e Gian Maria che parlano di POCO e dopo aver letto i due post (qui e qui) nel blog inglese di Gian Maria ho deciso di spiegare meglio cosa intendevo con il mio commento al post di Andrea.
Gian Maria mostra due modi diversi per rivolvere il "problema" dell'interfaccia INotifyPropertyChanged creando proxy a run-time, io avevo risolto il solito problema usando Spring.NET AOP. Questo dimostra che come al solito ci sono svariati modi per ottenere il solito risultato.
Finita questa piccola anticipazione arrivo al nocciolo del discorso e sparo la mia sentenza...nessuna di queste implementazioni è usabile!! Vi chiederete perchè ed io sono qui per dimostrarvelo. Piccola demo, provate a creare una semplice BindingList<Customer>, aggiungete ad essa un numero imprecisato di Customer-proxaty, agganciate l'evento ListChanged ed in fine provate a modificare la proprietà di un Customer della BindingList...et vualà l'evento non viene scatenato, cosa che dovrebbe accadere se Customer implementasse normalmente INotifyPropertyChanged.
Quando per la prima volta mi sono trovato davanti a questo problema armato di Reflector sono andato a sbirciare il codice della classe BindingList<T> ed ho trovato l'inghippo. Guardando il codice mostrato nell'immagine vediamo che la seconda linea di codice verifica se il tipo INotifyPropertyChanged è assegnabile dal tipo Customer, questa verifica nel caso di Customer in versione POCO è assolutamente falsa dato che il tipo Customer non sa niente di INotifyPropertyChanged. Per confermare questa teoria mi sono creato un po di test unitari che riproducono il problema, vediamoli. In entrambi i casi di test la creazione del Customer è stata "nascosta" dentro dei metodi Factory dato che non mi interessa mostrarne l'implementazione in questo post. Per prima cosa ho creato due classi Customer la prima implementa INotifyPropertyChanged e la seconda no, però ha le properties marcate come virtual per permettere la creazione del proxy a run-time.
1: public class Customer : INotifyPropertyChanged
2: {
3: public event PropertyChangedEventHandler PropertyChanged;
4: private Guid id = Guid.NewGuid();
5: private string name;
6:
7: public Guid Id {
8: get { return id; }
9: }
10: public string Name {
11: get { return name; }
12: set {
13: if (name != value) {
14: name = value;
15: RaisePropertyChanged("Name");}
16: }
17: }
18: private void RaisePropertyChanged(string propertyName)
19: {
20: if (PropertyChanged != null)
21: PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
22: }
23: }
1: public class CustomerPoco
2: {
3: private Guid id = Guid.NewGuid();
4:
5: public virtual Guid Id {
6: get { return id; }
7: }
8: public virtual string Name { get; set; }
9: }
Dopodiché ho creato due metodi di test, uno verifica se il Customer è castabile a INotifyPropertyChanged mentre l'altro verifica se è assegnabile.
1: [Fact]
2: public void ShouldBeCompatibleWithTypeINotifyPropertyChanged()
3: {
4: Customer customer = CustomerFactory.CreateCustomer();
5: (customer is INotifyPropertyChanged).ShouldBeTrue("Is not INotifyPropertyChanged");
6: }
7: [Fact]
8: public void ShouldBeAssignableToTypeINotifyPropertyChanged()
9: {
10: typeof(INotifyPropertyChanged).IsAssignableFrom(typeof(Customer))
11: .ShouldBeTrue("INotifyPropertyChanged is not assignable from Customer");
12: }
In questo caso entrabi i test passano perfettamente, proseguiamo eseguendo i soliti test su CustomerPoco:
1: [Fact]
2: public void ShouldBeCompatibleWithTypeINotifyPropertyChanged()
3: {
4: CustomerPoco customer = CustomerFactory.CreateCustomerPoco();
5: (customer is INotifyPropertyChanged).ShouldBeTrue("Is not INotifyPropertyChanged");
6: }
7: [Fact]
8: public void ShouldBeAssignableToTypeINotifyPropertyChanged()
9: {
10: typeof(INotifyPropertyChanged).IsAssignableFrom(typeof(CustomerPoco))
11: .ShouldBeTrue("INotifyPropertyChanged is not assignable from CustomerPoco");
12: }
In quest'ultimo caso il primo test passa mentre il secondo no distruggendo i nostri sogni di sviluppatore lazy che non doveva più implementare INotifyPropertyChanged . Ecco perchè nel mio commento al post di Andrea ho detto: "...perchè il framework di per se non conosce i mixin quindi è stato scritto "bloccandone" l'uso". Problemi simili sono risolvibili con diversi hack, basta barare con un po di reflection dopo aver istanziato la collection:
1: private static void EditRaiseItemChangedEvents(BindingList<Customer> list)
2: {
3: FieldInfo _fi = list.GetType().GetField("raiseItemChangedEvents", BindingFlags.NonPublic | BindingFlags.Instance);
4: bool raiseItemChangedEvents = (bool)_fi.GetValue(list);
5: if (!raiseItemChangedEvents) _fi.SetValue(list, true);
6: }
ed il gioco è fatto ma in generale hanno un costo troppo alto, sia di implementazione che di manutenzione dato che il problema non si presenta solo per collection come la BindingList ma anche per controlli come il BindingSource delle WindowsForm.
mercoledì 16 luglio 2008
Nei miei projetti C# faccio un largo uso di test unitari, utilizzando
NUnit o
xUnit.NET, so già che entro la fine dell'anno prenderò in consegna una grande applicazione C++, quindi in passato avevo dato un'occhiata veloce a quello che era il framework di testing di riferimento:
CppUnit .
Adesso Google ha rilasciato il proprio
framework per fare testing automatico di codice C++, non l'ho ancora provato (...aaahhhh il tempo) ma sembra proprio ottimo!
Fonte:
InfoQ: Announcing: New Google C++ Testing Framework
lunedì 14 luglio 2008
Leggendo il libro LINQ in Action vinto ai Community Days 2008 (consegnato direttamente da Andrea) ho scoperto un comportamento degli Extension Methods che non conoscevo. Il quesito posto nel libro è: cosa succede se un Extension Method va in conflitto con un Instace Method? Semplicemente "perde la battaglia" in quanto un Extension Method ha una priorità più bassa. Riporto lo snippet e l'output presenti nel libro:
1: using System;
2:
3: namespace ExtensionMethods
4: {
5: class Class1
6: {
7: }
8: class Class2
9: {
10: public void Method1(string s)
11: {
12: Console.WriteLine("Class2.Method1");
13: }
14: }
15: class Class3
16: {
17: public void Method1(object o)
18: {
19: Console.WriteLine("Class3.Method1");
20: }
21: }
22: class Class4
23: {
24: public void Method1(int i)
25: {
26: Console.WriteLine("Class4.Method1");
27: }
28: }
29: static class Extension
30: {
31: static public void Method1(this object o, int i)
32: {
33: Console.WriteLine("Extension.Method1");
34: }
35: }
36: class Program