di .NET e di altre amenità

Sto provando Resharper 4.0 da qualche giorno e come al solito lo trovo uno strumento utile e ben fatto che come dalla versione 3.0 è anche finalmente "delicato" nell'uso delle risorse della macchina e di conseguenza maggiormente usabile.

Quello che mi ha un po' indispettito è l'abitudine di Resharper di suggerire l'uso indiscriminato della keyword "var". E' pur vero che questo non ha alcun impatto nell'applicazione, ma la leggibilità del codice ne perde e anche parecchio. Perciò a mio parere la prima cosa da fare non appena installato Resharper è di recarsi nelle opzioni e sotto Code Inspection > Inspection Severity disabilitare le ultime due opzioni della sezione Code redundancies in particolare quelle che recitano:

• Use 'var' keyword when initializer explicitly declares type
• Use 'var' keyword when possible

Un bel "Do not show" a queste opzioni ricondurra Resharper alla ragione e ci lascerà scrivere il codice così come si dovrebbe fare cioe esplicitando il tipo ovunque possibile. A mio parere l'uso della keyword 'var' è legittimo esclusivamente quando abbiamo a che fare con degli anonymous types. Ogni altro uso è sostanzialmente uan illegittima scorciatoia.

Per puro caso mi sono imbattuto in questo HttpWatch Pro 5.3, e devo dire che a pochi minuti dall'installazione l'ho già inserito nella top-ten degli strumenti che si possono considerare un must-have.

E' davvero ben fatto, leggero, chiaro, preciso, veloce e soprattutto consente di filtrare efficacemente le chiamate per raggiungere puntualmente quelle che servono con estrema facilità.

Io lo sto trovando utile per monitorare le chiamate ai servizi wcf delle quali è in grado di intercettare i messaggi qualora serva trovare le eventuali anomalie.

HttpWatch Pro non è uno strumento gratuito, ma anche se il prezzo non è esattamente economico, la sua efficacia merita la spesa se avete esigenze di questo tipo.

Il percorso formativo che ho tenuto l'anno scorso a proposito di Silverlight 1.0 è stato recentemente aggiornato da Pietro Brambati che ha prodotto alcuni tutorial su Silverlight 2.0.

• Silverlight 2 (beta 2) – Iniziare a sviluppare
• Silverlight 2 (beta 2) – Costruire la User Interface
• Silverlight 2 (beta 2) – La User Interface e il DataBinding
• Silverlight 2 (beta 2) - Il Networking
• Silverlight 2 (beta 2) – Expression Blend 2.5 per “developer”

Ne trovate notizia nel post di oggi sul blog di MSDN Italia

http://blogs.msdn.com/italy/archive/2008/06/25/tutorial-su-silverlight-2-beta-2.aspx

Luglio è alle porte e con le agognate ferie si avvicina anche un importante appuntamento che mi vedrà presente. Si tratta della Conferenza Italiana Sviluppatori Access (CISA 2008), organizzata dallo AccessGroup.it nella persona di Massimiliano Amendola. il grupp infatti ha deciso di ospitare me e Davide Senatore, assieme a numerosi altri professionisti, per integrare i contenuti della conferenza con argomenti più generalisti che esulano da Access vero e proprio ma che sicuramente possono essere di aiuto per questi sviluppatori.

Come vi potete immaginare, sarò alla conferenza per un intervento di circa un'ora durante il quale presenterò Silverlight 2.0. Non ho ancora deciso esattamente quale sarà il taglio che darò alla sessione, ma ragionevolmente posso anticipare che affiancato ad una necessaria overview, cercherò di focalizzare il mio intervento su alcune tecniche per consumare e visualizzare dati provenienti da un Database.

Si tratta per me di un appuntamento molto importante, anche perchè sarà la primissima volta che mi cimenterò davanti al pubblico Milanese nella prestigiosa sede di Microsoft Italia. Vi aspetto perciò numerosi per confortarmi in questo difficile impegno.

Chi volesse iscriversi troverà informazioni in merito sul sito di AccessGroup.it al seguente indirizzo:

Link: CISA.NET%202008%20" target=_blank rel=tag>Agenda CISA.NET 2008

A presto.

La Beta 2 di Silverlight 2.0 ha visto la scomparsa di un controllo WatermarkedTextBox. In questo post di Brad Abrams trovate le motivazioni della scomparsa:

http://blogs.msdn.com/brada/archive/2008/06/24/watermarkedtextbox-for-silverlight-2-beta-2.aspx

Eventualmente potete scaricare il sorgente del controllo qui:

WatermarkedTextBox source code and unit test

Inoltre ne parla Kathy Kam nel sul blog:

http://blogs.msdn.com/kathykam/archive/2008/06/23/watermarkedtextbox-for-silverlight-2-beta-2.aspx

Leggo che qualcuno ha inviato una lettera aperta al team di sviluppo dell'Entity Framework per sollecitare alcune modifiche architetturali prima della release che ormai dovrebbe essere imminente:

http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Qui la risposta abbastanza estensiva di uno dei program manager del team EF

http://blogs.msdn.com/timmall/archive/2008/06/24/vote-of-no-confidence.aspx

Non esprimo opinioni... prima voglio leggermeli entrambi per bene.

Chi come me si è trovato a dover installare TFS in produzione sa che occorre sudare le proverbiali sette camicie. Quest'oggi, grazie al nuovo blog italiano su TFS ho visto la luce in fondo al tunnel. Si tratta di un weblog gestito dal nostro MVP in congedo, Lorenzo Barbieri, che oggi ha appunto aperto le danze pubblicando uno step-by-step con tanto di screenshots che si può tranquillamente classificare come "salvavita".

Link: [Step by Step] Installare TFS2008 in Italiano su Windows Server 2008

Grande Lorenzo!

Beh, ora nessuno potrà dire che io non ci abbia provato. Mi sono diligentemente iscritto a Twitter, ho postato per qualche giorno, ho perfino messo il codice nel blog per mostrare i messaggi...

Poi quest'oggi ho guardato nella home page e mi sono reso conto che l'ultimo mio post risaliva a più di un mese fa...  ho tolto tutto e Twitter è andato.

Mi chiedevo quale potesse essere l'utilità di Twitter... e in tutta sincerità continuo a chiedermelo...

In questi giorni, sono cominciati ad apparire alcuni post che mostrano come utilizzare il WSDualHttpBinding con la Beta 2 di Silverlight. Tale binding infatti è supportato a partire dall'ultima release, grazie alla presenza di due assembly, System.ServiceModel.PollingDuplex.dll, uno per la parte client e l'altro per la parte server.

Ma la domanda che mi sono posto, subito dopo i primi esercizi per vedere come trarne vantaggio è la seguente:

Assodato che questa tecnica fa uso di Polling (e tutti voi sapete quanto dannosa può essere per il webserver) per quale motivo dovrei ricorrere a tale binding anzichè implementare manualmente (e molto più semplicemente...) la medesima tecnica?

In effetti un reale vantaggio esiste ed è insito nella modalità con cui il polling viene effettuato. A differenza di quello che accade con un polling manuale, nel quale il client rimane sostanzialmente disconnesso per la maggior parte del tempo, e si accorge della presenza di informazioni solo allo scadere di un timeout, con il Polling di WCF quello che avviene è che il client si connette al server e rimane in questo stato per tutta la durata del timeout salvo eventualmente disconnettersi nel momento in cui arrivano informazioni utili.

La differenza che a prima vista pare banale è invece sostanziale. Infatti in questo modo si aggira il problema tipico del polling e cioè la latenza dei messaggi che costringono spesso a ridurre il più possibile l'intervallo tra due diverse chiamate. Con WCF potremmo avere un intervallo di poll anche molto ampio, ma continueremo ad ottenere in tempo reale i risultati dal server che si occuperà di chiudere la nostra connessione e notificarci l'arrivo nello stesso istante in cui i dati divengono disponibili.

A giudicare dal formato del messaggio SOAP, questa tecnica rispetta lo standard OASIS WS-MakeConnection, descritto ampiamente in questo documento. Quello che non mi è dato sapere è il livello di compatibilità dell'implementazione di Silverlight 2.0 con questo standard.

La tecnica quindi appare davvero interessante e apre la strada ad applicazioni in vero realtime anche per il web. Attenzione però che la licenza Go-Live di Silverlight 2.0 non si applica a questo assembly perciò dovremmo aspettare la RTM per poterlo portare in produzione (evidentemente si attendono modifiche importanti).

Se si costruisce un controllo di Layout, come già detto in precedenza, è necessario fare l'override dei metodi MeasureOverride e ArrangeOverride per mezzo dei quali determineremo lo spazio occupato dai controlli figlio e il relativo posizionamento rispetto ad una o più Attached Property che avremmo definito.

Tuttavia uan semplice implementazione di questo tipo è carente di un aspetto. Il controllo infatti sarà perfetto fintanto chè la sua configurazione non cambia ma non appena una delle Attached Properties cambia ci renderemo conto che il controllo non cambia il suo aspetto di conseguenza. Per fare in modo che un controllo di layout mantenga coerenza con i valori delle Attached Properties occorre fare uso di InvalidateMeasure() e InvalidateArrange(). Questi due metodi fanno in modo che il motore di layout ricalcoli ingombro e posizionamento dei controlli rispetto al pannello sul quale sono invocati.

Per fare in modo che al variare di una proprietà automaticamente si aggiorni il pannello dovremmo intercettare la notifica della Attached Property e chiamare uno dei due metodi in base al fatto che la proprietà coinvolga o meno la fase di Measure o solo quella di Arrange:

   1: public static void Property_Changed(DependencyObject sender, DependencyPropertyChangedEventArgs e)

   2: {

   3:     FrameworkElement element = sender as FrameworkElement;

   4:  

   5:     if (element != null)

   6:     {

   7:         DockPanel panel = element.Parent as DockPanel;

   8:  

   9:         if (panel != null)

  10:             panel.InvalidateArrange();

  11:     }

  12: }

Nel riquadro ho mostrato come arrivare al controllo di layout relativo una AttachedProperty. Non va dimenticato infatti che il DependencyObject passato come argomento non è il controllo di layout stesso, ma bensì il controllo a cui la proprietà si applica. Occorre quindi fare un cast su "FrameworkElement" e cercare nella proprietà Parent il controllo di layout che contiene il controllo che stiamo aggiornando.

La scelta del metodo, sia esso InvalidateArrange o InvalidateMeasure è importante. Infatti il metodo InvalidateMeasure implica anche che venga nuovamente effettuato l'Arrange perciò è molto più pesante in termini di elaborazione. Spesso e volentieri chiamare l'uno o l'altro ha il medesimo effetto perciò la scelta in tal caso dovrebbe ricadere su InvalidateArrange che ha un minor impatto.

Ho appena fatto l'upload della nuova release della mia Silverlight Library 1.0.3093.0 che aggiunge un nuovo controllo di layout. Il controllo in questione è il DockPanel, mutuato da WPF. Del suo omonimo acquisisce la medesima funzionalità tanto che è possibile incollare un dockpanel da un progetto WPF (o viceversa) e tutto funziona a dovere con l'unico onere di dover aggiornare i namespace.

Ecco un esempio di uso del mio DockPanel:

   1: <UserControl x:Class="Silverlight.DockPanelSample"

   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 

   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 

   4:     xmlns:ec="clr-namespace:Elite.Silverlight.Controls;assembly=Elite.Silverlight"

   5:     Width="Auto" Height="Auto">

   6:     <ec:DockPanel x:Name="LayoutRoot" Background="White" LastChildFill="True">

   7:         <Rectangle x:Name="rect1" ec:DockPanel.Dock="Top" Height="50" Fill="Red" Margin="3" />

   8:         <Rectangle x:Name="rect2" ec:DockPanel.Dock="Left" Width="180" Fill="Green" Margin="3" />

   9:         <Rectangle x:Name="rect3" ec:DockPanel.Dock="Right" Width="100" Fill="Blue" Margin="3" />

  10:         <Grid x:Name="fillGrid" ec:DockPanel.Dock="Bottom" Background="Transparent" Margin="3">

  11:             <Button Width="100" Height="50" Content="Click to Change" Click="Button_Click" />

  12:         </Grid>

  13:     </ec:DockPanel>

  14: </UserControl>

Il risultato lo potete vedere a questo indirizzo se avete Silverlight 2.0 beta 2 installato

Il codice di Windows Presentation Foundation è esattamente lo stesso tranne che per il namespace "ec:" che in silverlight deve essere obbligatoriamente espresso perchè il controllo si trova in una libreria esterna.

Progetto su codeplex: http://www.codeplex.com/silverlight

Area di test: http://silverlight.boschin.it/library

Ho giusto ora trovato il tempo di testare e modificare la mia library per silverlight in modo che funzioni anche con la beta 2. Le modifiche apportate non sono moltissime e il funzionamento finale dei controlli non ha subito alcuna perdita o guadagno. La cosa che mi ha fatto perdere più tempo è che ora le proprietà annidate dei controlli richiedono che venga specificato il namespace così quello che prima era:

   1: <ed:CollectionViewSource x:Name="rssView" Source="{Binding Items, Source={StaticResource dataSource}}" Filter="rssView_Filter">

   2:     <CollectionViewSource.SortDescriptions>

   3:         <ed:SortDescription PropertyName="PublishDate" Direction="Ascending" />

   4:     </CollectionViewSource.SortDescriptions>            

   5: </ed:CollectionViewSource>

ora è diventato

   1: <ed:CollectionViewSource x:Name="rssView" Source="{Binding Items, Source={StaticResource dataSource}}" Filter="rssView_Filter">

   2:     <ed:CollectionViewSource.SortDescriptions>

   3:         <ed:SortDescription PropertyName="PublishDate" Direction="Ascending" />

   4:     </ed:CollectionViewSource.SortDescriptions>            

   5: </ed:CollectionViewSource>

Altra cosa interessante, che promette bene il fatto che la dichiarazione di una DependencyProperty ora non richiede più solamente il callback per la notifica delle modifiche (PropertyChagedCallback) ma invece necessita di una classe PropertyMetadata (come in WPF). Questo apre la strada in futuro all'implementazione piena delle DependencyProperty.

Il progetto su Codeplex ora è aggiornato e contiene anche il MouseDoubleClick manager che avevo tempo fa rilasciato separatamente. Qui trovate l'articolo che ne parla (inglese): Creating a MouseClickManager to handle single and double mouse clicks