Archive

.NET

Today I tried to upgrade ODataLib 5.2.0 to ODataLib 5.3.0 in a VisualStudio project.

NuGet complained that this wasn’t possibile because that some versions of some library were not compatible. For example I obtained the message:

Unable to find a version of ‘Nivot.WCFDataServicesToolkit’ that is compatible with ‘Microsoft.Data.Services 5.3.0’.

The solution was very simple: I uninstalled the old version and then I installed the new version.

Ebbene sì! Ho comprato un nuovo Mac! Ci servirà per sviluppare delle applicazioni su iPad. Prima che pensiate che io abbia cambiato bandiera, vi rammento che, come azienda, non lavoriamo solo su Microsoft e preciso anche che stiamo sviluppando alcune di queste applicazioni su tablet PC multitouch con Windows 7.

Tornando al Mac, ho installato xCode e ho cominciato a vedere anche come si sviluppa su OSX. Dopo pochi minuti avevo una sensazione forte di deja-vu… all’inizio pensavo fosse legata alla mia lunga esperienza in Smalltalk ma dopo un po’ mi sono reso conto da dove arrivava: da alcuni esperimenti fatti con NextStep e il suo Interface Builder molti anni fa! Devo dire che la cosa mi è piaciuta… e devo aggiungere che anche OSX mi piace e che lavorarci sopra è divertente ma… Windows 7 (o meglio .NET) è assai meglio. Sicuramente il fascino di OSX sta nella coerenza mentre Windows, per questioni di compatibilità con il passato, soffre un po’ sotto questo aspetto.

Comunque OSX sarà anche il sistema operativo più avanzato al mondo (parole di Apple)ma sinceramente alcune delle sue API sono vecchie! Quando NextStep è uscito era sicuramente un oggetto incredibilmente avanzato ma ora mi sembra che dimostri tutta la sua età. Ad esempio le API e i controlli/widget per lavorare con la GUI sono interessanti ma datate. Su .NET si può lavorare con WPF che permette di ottenere risultati migliori con uno sforzo nettamente minore. E anche gli strumenti di sviluppo sono all’altezza di tale ambiente: VisualStudio 2010 e Blend 4 ti fanno lavorare assai meglio e in minor tempo.

Bah… magari cambierò idea più avanti.

Oggi io e un mio collaboratore siamo quasi impazziti per capire come mai le chiamate seguite da una portlet Java (ospitata in un IBM WCS) non funzionavano con un servizio REST/POX scritto in WCF. La cosa interessante è che le chiamate al servizio effettuate da un paio di (veramente piccoli) script PowerShell di prova funzionavano. Era evidente quindi che si trattava di un problema di comunicazione fra i due mondi. I problemi spaziavano dalla dalla indicazione della codifica alla mancanza di namespace e di campi. Il tutto dovuto fondamentalmente allo stack Java troppo vecchio (con l’IBM WebSphere Portal Server 6 non sarebbe successo).

image

Per fortuna che il WCF ha delle ottime funzionalità di tracing che ci hanno aiutato a isolare i problemi. E, nonostante questo, ci abbiamo perso delle ore.

Forse l’ho già detto ma io penso che il WCF sia proprio un gran bel pezzo di software!  🙂

A causa di un problema di specifiche supportate troppo vecchie da parte di una vecchia versione di portale IBM WebSphere Portal Server, ho dovuto cimentarmi nell’esporre in WCF un servizio tramite REST e POX. Andato a caccia di un po’ di esempi nell’SDK e dopo qualche esperimento in poco tempo ho avuto il servizio attivo. Indubbiamente il framework è molto potente e permette il controllo praticamente totale del dialogo. Però utilizzare un modello REST con POX vuol dire scendere ad un livello più basso cioè “lavorare con le tubature”. Efficace ma sicuramente meno elegante.

Invidiate il NY Times per il loro lettore offline? Volete creare una rivista elettronica aziendale? Aggiornata in modo automatico? Volete fare in modo che le stampe siano di ottima qualità e in stile giornalistico? Oppure semplicemente volete vedere come costruire una applicazione del genere usando WPF?

Allora il Syndicated Client Experiences Starter Kit è quello che ci vuole.

Come esempio forniscono MSDNReader, un lettore per gli articoli MSDN Magazine.

Devo dire che all’inizio LINQ in C# mi lasciava un po’ perplesso. L’idea di complicare il linguaggio di programmazione aggiungendo costrutti mi rende nervoso. Io la chiamo sindrome da PL/I ma l’ho sperimentata con il C++: il linguaggio diviene così complesso che per realizzare un progetto serve un esperto del linguaggio stesso.

LINQ in realtà si integra bene con C# e diviene presto naturale utilizzarlo. Per provarlo ho aggiunto delle funzioni di ricerca relativamente sofisticate ad un mio programma (in realtà è il mio Pet Project che uso per fare esperimenti) utilizzando il binding SQL.

image

Ho creato un piccolo parser utilizzando una serie di if con una serie di espressioni regolari. Ho cablato diverse query utilizzando i risultati di questo piccolo parser. In pratica prelevo il contenuto del TextBox di ricerca e quando soddisfa il match con una espressione regolare simile a questa (ho semplificato il codice)

Regex reAnnoMese = 
   new Regex(@"^([0-9]){4}\s+[a-zA-Z]+$");

eseguo la query corrispondente simile a questa

if (reAnnoMese.Match(searchText).Success)
{
   RicevutaDataContext dcRicevuta
      = new RicevutaDataContext();
   int posSpazio = searchText.IndexOf(" ");
   string anno = searchText.Substring(0, posSpazio);
   string mese = searchText.Substring(posSpazio + 1);
   int numeroMese = GetMonthNumber(mese);
   var queryRicevuta = 
      from ricevuta in dcRicevuta.Ricevutas
      orderby ricevuta.Anno descending,
              ricevuta.Numero descending
      where ricevuta.Anno.Equals(anno)
         && ricevuta.DataEmissione.Value.Month
            == numeroMese
      select ricevuta;
   DataContext = queryRicevuta;
}

RicevutaDataContext è un DataContext creato con un semplice drag&drop della tabella Ricevuta dal mappatore del VS2008. GetMonthNumber è una funzione che restituisce il numero ordinale corrispondente al mese e utilizza al suo interno le funzioni .NET per la localizzazione e che restituiscono i nomi dei mesi. Nell’ultima istruzione effettuo il binding della query con un elemento WPF (una Page contenente una ListView in questo caso).

Se nel TextBox scrivete 2006 giugno (o June: dipende dalle impostazioni) questo codice estrae tutte le ricevute emesse nel giugno 2006. LINQ genere codice SQL del tipo:

SELECT [t0].[IdRicevuta], 
       [t0].[Numero], [t0].[Anno], 
       [t0].[DataEmissione], [t0].[Intestazione], ....
FROM [dbo].[Ricevuta] AS [t0]
WHERE ([t0].[Anno] = @p0) 
AND (DATEPART(Month, [t0].[DataEmissione]) = @p1)
ORDER BY [t0].[Anno] DESC, [t0].[Numero] DESC

Il fatto che il risultato della query LINQ non sia altro che una collezione .NET (per la precisione un IEnumerable su cui è possibile navigare) ne rende l’utilizzo praticamente trasparente.

Il codice non è particolarmente furbo (e neanche elegante) ma è proprio questa la sua bellezza: l’ho scritto senza pensarci troppo e ho ottenuto un buon risultato. Altri meccanismi mi avrebbero costretto a ragionare troppo (Ehi, sono quasi in vacanza!), ad utilizzare classi più complesse, a passare per sofisticati ORM, a scrivere SQL.