Blog

Orario Treni si aggiorna alla versione 1.2.2

Wed, 16 May 2012 08:18:52 GMT

Vi segnalo che è stata appena rilasciata la versione 1.2.2 di Orario Treni, l'app di riferimento per chi viaggia in treno, che introduce le seguenti migliorie:

Prestazioni: sono state migliorate le prestazioni su tutti gli iPhone 3GS/4/4S
Grafica: alcuni elementi dell'interfaccia grafica sono stati migliorati
iOS 5.1: è stato aggiunto il supporto ufficiale a iOS 5.1
Bug: una serie di bug che ci sono stati segnalati sono stati risolti

La versione 2.0 è in lavorazione e sarà ricca di tantissime novità. Stay tuned!

Community Days 2012 Bari: due giorni da favola

Thu, 10 May 2012 08:55:04 GMT

Negli ultimi due giorni ho preso parte all'evento Community Days 2012 Bari, evento che si è tenuto per la prima volta a Bari e che mi ha colpito notevolmente. Non capita tutti i giorni di vedere nella mia città professionisti nel settore dello sviluppo software di tale caratura ed è stato un vero piacere conoscere di persona speaker che negli ultimi anni ho potuto solo seguire sul web o al WPC. Noi di DotNetSide chiaramente abbiamo dato il nostro contributo e, grazie anche alla sponsorizzazione di Edilportale.com, gli ultimi due giorni li ho trascorsi piacevolmente tra confronti, sessioni tecniche, nuove e vecchie conoscenze, oltre che chiaramente cene, pranzi e coffee break :) Il tutto ha avuto luogo nella fantastica sede di Edilportale.com, una realtà che si conferma come tra le più giovani, dinamiche ed interessanti nel panorama pugliese delle aziende in qualche modo legate al web.

Nel mio piccolo ho contribuito con una sessione sulle Push Notification in Windows Phone, della quale potete trovare slide e demo sul sito dell'evento.

AutomationFactory in Silverlight 5

Mon, 23 Apr 2012 07:32:18 GMT

E' da diverse versioni che Silverlight supporta la possibilità di richiamare Automation Server mediante l'API AutomationFactory. In Silverlight 5, tuttavia, la possibilità di avere applicazioni in browser di tipo Trusted, consente un più ampio ventaglio di utilizzi di questa tecnologia. Fino a Silverlight 4, infatti, qualsiasi operazione che richiedesse un aumento dei privilegi poteva essere eseguita solo ed esclusivamente se l'applicazione era di tipo out of browser il che, soprattutto dal punto di vista commerciale/marketing, potrebbe rappresentare un problema. Diciamolo chiaramente: gli addetti al settore sanno benissimo che Silverlight, così come Flash, non possono essere definite tecnologie puramente web. Se si vuole fare un sistema web puro, si deve usare HTML, Javascript e qualche linguaggio server side. Tuttavia, benché con HTML 5, CSS 3 e tutto ciò che gira attorno, tale tendenza sembra essere quella che inevitabilmente da qui a qualche anno si diffonderà, utilizzare ambienti di sviluppo come Silverlight rappresenta a mio parere, almeno fino ad ora, un notevole vantaggio nei seguenti aspetti:

linguaggio di programmazione - con tutto il rispetto per javascript, usare C# garantisce una netta superiorità dal punto di vista della produttività, degli strumenti di sviluppo/debug, degli strumenti per test automatici e dell'implementazione di design pattern
accesso a risorse locali - non tutte le applicazioni possono astrarsi dalla macchina su cui lavorano, alcune necessitano si accedere a dispositivi hardware e molto spesso non possibile accedervi usando javascript

In Silverlight 5 è possibile, quindi, lavorare con applicazioni Trusted in browser e questa peculiarità ci permette di eseguire operazioni come, per esempio, il deploy in locale di un pacchetto Windows Installer che, una volta installato, potrebbe esporci mediante una libreria COM visible, funzionalità normalmente non accessibili. Di seguito un esempio di codice che recupera il pacchetto di installazione da risorse dello XAP stesso (ma potreste scaricarlo da un web server o in qualunque altro modo), lo scrive sul disco (la funzione WriteStreamIntoStream non fa altro che travasare gli stream) e poi lo esegue utilizzando l'oggetto COM WScript.Shell e, in particolare, il metodo Run:

StreamResourceInfo srMSI = Application.GetResourceStream(new Uri("Test;component/Packages/Test.msi", UriKind.Relative));
var filePath = System.IO.Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), "Test.msi");
using (var setupStream = File.Open(filePath, FileMode.OpenOrCreate))
{
	WriteStreamIntoStream(srMSI.Stream, setupStream);
}

var shell = AutomationFactory.CreateObject("WScript.Shell");
var result = shell.Run(filePath, 1, true);
return result == 0;

Chiaramente se il pacchetto di installazione richiede privilegi di amministratore, in ambienti come Windows Vista o Windows 7 con UAC attivo, verrà richiesta l'elevazione dei privilegi e, a tal proposito, vi consiglio caldamente di firmare con un certificato digitale il pacchetto MSI in modo che il cliente abbia ben chiara l'origine dell'operazione.

Microsoft .NET Framework 4.0.3

Fri, 13 Apr 2012 18:51:21 GMT

In attesa che esca il nuovo .NET Framework 4.5 in versione definitiva, Microsoft ha rilasciato un aggiornamento del .NET Framework 4 alla versione 4.0.3. Analogamente ai precedenti aggiornamenti (4.0.1 e 4.0.2), questo introduce alcune novità ed una serie di migliorie, oltre chiaramente a risolve bug più o meno gravi. Tra le novità principali segnalo la possibilità di utilizzare l'engine di Workflow Foundation 4 anche in ambienti medium trust, il che amplia significativamente gli ambiti d'uso di questa libreria. Workflow Foundation 4 è una libreria probabilmente poco conosciuta, ma in termini di workflow engine, rappresenta un significativo passo in avanti rispetto all'ormai obsoleta versione introdotta con il framework 3.0: nel caso in cui sia a voi sconosciuta, consiglio caldamente di dargli un'opportunità.

Altri miglioramenti riguardano la gestione di ADO.NET con configurazioni di SQL Server particolarmente care a chi utilizza SQL Azure, per le quali sono stati risolti una serie di antipatici bug.

Maggiori informazioni sull'aggiornamento potete trovarle qui. Potete invece scaricare l'aggiornamento che include anche un'update di Visual Studio 2010 SP1 qui.

Visual Studio 2010 SP1 loading toolbox...

Wed, 04 Apr 2012 18:45:00 GMT

Se avete installato i Silverlight 5 Tools per Visual Studio 2010 SP1 è molto probabile che al primo accesso alla toolbox, Visual Studio si blocchi per 50-60 secondi con il seguente messaggio nella status bar:

Loading toolbox content from package Microsoft.VisualStudio.IDE.Toolbox.ControlInstaller.ToolboxInstallerPackage '{2C98B35-07DA-45F1-96A3-BE55D91C8D7A}'

Il problema sembra essere causato dall'installazione dei Silverlight 5 Tools e, in particolare, dal toolkit dei WCF RIA Services e di Silverlight 5 stesso. Per risolvere questo problema potete trovare online una serie di workaround, ma quello che a mio parere è il più valido è il seguente

Disinstallate WCF RIA Services V1.0 SP2
Disinstallate WCF RIA Services Toolkit
Disinstallate Silverlight 5 Toolkit
Avviate Visual Studio 2010 -> Pulsante Destro sulla Toolbox -> Reset Toolbox
Chiudete Visual Studio 2010
Andate in %USERPROFILE%\Local Settings\Application Data\Microsoft\VisualStudio\10.0 ed eliminate tutti i file .TBD

Dopo aver eseguito questa procedura, il primo avvio di Visual Studio sicuramente sarà più lento del solito, in particolare per caricare la toolbox, ma tutti i successivi avvii non vi riproporranno più l'antipatico problema. Se avete necessità di utilizzare i vari toolkit disinstallati, vi consiglio caldamente di abbracciare l'approccio NuGet e di smetterla di installarvi sull'ambiente di sviluppo e in GAC tutte le librerie che usate.

Banding su Windows Phone

Tue, 03 Apr 2012 06:46:21 GMT

Anche se non sono un grafico, aver lavorato per diversi anni come redattore per Hardware Upgrade e, in particolare, fare recensioni di schede video, mi ha reso particolarmente sensibile ad alcuni artefatti grafici tipici delle schede di un tempo. Dovete sapere, infatti, che fino a quando il monopolio delle schede video acceleratrici 3D era in mano a 3dfx Interactive (e qui una lacrima riga il mio viso), buona parte delle elaborazioni grafiche veniva eseguita a 16 bit. Per chi non lo sapesse, questo significa che il numero massimo di colori visualizzabili sullo schermo era pari a 65536, tanti potreste pensare voi, ma in realtà pochissimi in molte circostanze.

Il problema si pone in particolare quando è necessario sfruttare un'ampio spettro di sfumature di uno stesso colore. In questo specifico ambito i 16 bit mostrano tutti i loro limiti e gli oltre 16 milioni di colori che oggi ammiriamo grazie ai 32 bit diventano indispensabili. L'effetto più evidente che si nota quando il numero di colori diventa insufficiente è il cosiddetto banding.

L'immagine sopra esposta ben evidenzia la problematica. A questo punto alcuni si staranno chiedendo: cosa c'entra il banding con i Windows Phone? Purtroppo molto perché Microsoft ha deciso di impostare 16 bit come profondità di colore predefinita delle applicazioni Windows Phone sviluppate in Silverlight. La motivazione è presto detta: 16 bit richiedono molta meno potenza di calcolo, molta meno memoria video e di sistema, oltre a rappresentare il minimo comune denominatore dei colori supportati dagli schermi sui Windows Phone.

Ecco quindi che, esattamente come alla fine degli anni 90 abbiamo dovuto lottare per conquistare i 32 bit nella grafica tridimensionale dei videogiochi, oggi ci tocca fare altrettanto con i Windows Phone. Fortunatamente, contrariamente all'epoca, la scelta di Microsoft non è dettata da limiti hardware, ma da una scelta votata all'ottimizzazione delle risorse di un telefono, il che significa che per abilitare i 32 bit nelle vostre app per Windows Phone non dovrete fare altro che aprire il file WMAppManifest.xml ed impostare l'attributo BitsPerPixel a 32.

Controindicazioni? In teoria vi macchierete del crimine di non risparmiare le risorse hardware del Windows Phone sul quale gira la vostra app, ma onestamente a mio parere è più alto il rischio di fare brutta figura con il banding, che non quello di perdere qualche decimale di batteria in più. Detto questo, valutate su uno smartphone (e non sull'emulatore) l'entità della problematica e, eventualmente, prendete le dovute contromisure.

Font custom in Windows Phone

Tue, 20 Mar 2012 06:17:12 GMT

Mi è capitato di dover far uso in un'applicazione Windows Phone di font custom, che vanno quindi oltre i classici disponibili nel piccolo OS di casa Microsoft dedicato agli smartphone. Implementare questa funzionalità è abbastanza banale, ma ve lo riporto perché non sempre le cose semplici vengono in mente facilmente. Innanzitutto è necessario aggiungere al progetto il font in questione ed assicurarsi che la Build Action sia impostata su Resource. A questo punto il font vi comparirà magicamente nell'elenco dei font disponibili, per esempio, per il testo di una TextBox.

Info Uovo: le uova non hanno più segreti

Sun, 18 Mar 2012 12:33:01 GMT

Oggi vi propongo una piccola e simpatica app sviluppata nel tempo libero che vi consente di identificare l'origine delle vostre uova. Forse non tutti sapete, infatti, che secondo una normativa europea le uova che acquistiamo devono avere un codice identificativo attraverso il quale è possibile risalire a tipo, nazione, provincia e comune dell'allevamento in cui è stata allevata la gallina che lo ha deposto.

L'aspetto che ho trovato più interessante è quello relativo alle tipologie di allevamenti. Infatti, la prima cifra del codice va da 0 a 3 e vi dice il tipo di allevamento: consiglio caldamente di non acquistare uova con tipologia 2 o 3 in quanto le condizioni di vita della gallina sono assurde (ad esempio, vivono in un box delle dimensioni di una scatola di scarpe fino alla fine dei loro giorni), il che indipendentemente dal fatto di essere più o meno amanti degli animali, secondo una serie di studi influenza negativamente la qualità delle uova.

Info Uovo vi illustra queste informazioni e si integra anche con Bing Maps per mostrarvi direttamente il comune di origine dell'uovo identificato. L'app è disponibile gratuitamente per Windows Phone sul Marketplace.

Orario Treni 1.1 per Windows Phone

Tue, 13 Mar 2012 18:14:43 GMT

Orario Treni per Windows Phone giunge alla versione 1.1 che introduce una serie di novità. Innanzitutto è ora disponibile la trial mode, cioè è possibile provare l'applicazione in versione di valutazione in cui non sono disponibili le seguenti funzionalità:

Scioperi
Preferiti
Dettaglio di un treno

Maggiori informazioni su come implementare la trial mode saranno disponibili in un prossimo post di questo blog. Sono state inoltre risolte alcune problematiche nella ricerca delle soluzioni di viaggio al fine di migliorarne l'usabilità quando per una determinata fascia oraria non sono disponibili soluzioni. Bene, in attesa delle prossime novità che non tarderanno ad arrivare, che altro dire se non BUON DOWNLOAD!

Command Query Responsibility Segregation

Sun, 26 Feb 2012 16:17:27 GMT

Nel precedente post vi ho proposto una rapida comparativa tra SQL Azure e l'Azure Table Storage, tentando di analizzare punti di forza e di debolezza di entrambe queste tecnologie destinate prevalentemente a cui sviluppa sistemi cloud based su Windows Azure.

Quest'oggi vi parlerò di un design pattern denominato Command Query Responsibility Segregation che si sposa ottimamente con le caratteristiche del cloud, in particolare per lo sviluppo di sistemi che richiedano una scalabilità orizzontale elevatissima (diciamo potenzialmente infinita). Per analizzare questo design pattern partiamo da un esempio di classica architettura client-server.

Si tratta della classica architettura che abbiamo spesso di fronte ai nostri occhi quando lavoriamo ad un gestionale. Il tutto si traduce nei seguenti passaggi: il client richiede al server un DTO, cioè in sostanza dati, li manipola e li reinvia al server il quale non dovrà far altro che identificare le modifiche fatte al DTO originario e tradurle in aggiornamenti nella base dati. I domain object, con l'avvento degli ORM, possono essere solitamente identificati negli EntityObject, nelle Tracking Instances, nei POCO o una qualsiasi altra forma supportata dall'ORM stesso. I DTO vengono spesso mappati 1-1 sul modello sottostante.

Questa architettura è stata fortemente incentivata da Microsoft con tecnologie come l'Entity Framework ed i WCF RIA Services/ADO.NET Data Services e, contrariamente a quanto si possa pensare, non ha nulla a che fare con un design di tipo Domain Driven. Qualcuno potrebbe obiettare che il modello dei dati è fortemente basato sul dominio applicativo, ma questo non è esatto per almeno due ragioni. Innanzitutto modellare le entità e lo schema del database sulla base del dominio applicativo è una conseguenza della semplicità nell'eseguire questo tipo di operazione messa a disposizione dagli ORM e non una conseguenza del voler adottare un design Domain Driven. In secondo luogo, un'architettura Domain Driven non ha nulla a che fare con le classiche operazioni di CRUD gestite dall'architettura che vi ho proposto, ma piuttosto è di tipo Task Driven, cioè espone nella UI le operazioni logiche del dominio applicativo e non quelle fisiche di persistenza sul database.

Chiaramente è possibile che Create, Update e Delete corrispondano anche ad operazioni logiche del dominio applicativo, ma di fatto normalmente quello che ci si limita a fare è recuperare i dati lato client, modificarli e lanciare una SaveChanges. Questo approccio non è un design di tipo Domain Driven ed è fatto per semplificare la vita dello sviluppatore, non per semplificare la vita dell'utente finale dell'applicazione. Volete un esempio? Pensate che, in un rubrica, recuperare dal database la riga di un contatto, esporre tutti i campi in una form, cambiare il campo "Indirizzo" e cliccare su "Salva" sia un'operazione intuitiva per chi non sa che significhi fare una INSERT, UPDATE e DELETE? E' comodo per noi sviluppatori, ma per l'utente forse sarebbe più comodo avere un pulsante denominato "Cambia indirizzo", una maschera che mostra solo l'indirizzo e un pulsante "Ok".

Al di là del voler adottare o meno un design di tipo Domain Driven, scelta più che lecita in molteplici ambiti applicativi, il problema più grande dell'architettura sopra esposta è la assoluta centralità del database nel corso della normale operatività. In tutti i casi è necessario tradurre i dati che vogliamo recuperare in una query SQL, dobbiamo quindi risolvere il problema dell'Impedance Mismatch (lo fanno per noi gli ORM, ma ha comunque un costo), tradurre il tutto in DTO, tracciare le modifiche effettuate e ritradurle un query SQL per aggiornare la base di dati. In tutto questo giro gli RDBMS devono rispettare le ACID (Atomicity, Consistency, Isolation, e Durability) e questo rappresenta un collo di bottiglia non indifferente. Sappiate, infatti, che potete anche avere due processori da 4 core l'uno e 64 GB di RAM sul vostro server, ma se vengono lanciate in parallelo tante operazioni sui medesimi dati, entreranno in gioco i meccanismi di ROW LOCK, RANGE LOCK o, peggio, TABLE LOCK, che metteranno tutte le operazioni in fila rendendo vano il vostro sforzo economico per la scalabilità verticale.

Come se ne esce dunque? Beh la Command Query Responsibility Segregation propone un diverso approccio all'architettura di un sistema al fine di risolvere questi problemi. Il concetto fondamentale è quello della separazione delle operazioni di lettura da quelle di scrittura. Questa separazione ci permette di separare anche i rispettivi modelli: se in lettura nella UI ho bisogno di denormalizzare i miei dati, cioè di unire due informazioni che nel database sono normalizzate, ma che in visualizzazione mostro insieme, per quale ragione devo forzare il sistema ogni volta che ho bisogno di questi dati in lettura ad eseguire LOCK e JOIN? La soluzione, quindi, è di separare le letture dalle scritture sia dal punto di vista del modello, che della persistenza. Ecco, quindi, che il modello concettuale, che nell'architettura classica è mappato il più possibile sul database (o, se preferite, il contrario con un approccio Code First), si scinde in due distinti modelli: il command model ed il query model. Il primo è utilizzato per invocare da parte della UI operazioni sui dati, mentre il secondo ha il solo scopo di modellare i dati nel modo più vicino possibile ai DTO richiesti dalla UI.

Non mi dilungherò eccessivamente nelle modalità operative con le quali è possibile implementare questo approccio, ma vi faccio un esempio di come adottarlo sulla piattaforma Azure: potremmo utilizzare SQL Azure come database sul quale lanciare i comandi di scrittura definiti nei vari command model inviati dal client, mentre l'Azure Table Storage è un eccellente candidato per persistere le informazioni opportunamente denormalizzate. In base all'analisi del software, potrebbe essere necessario replicare un dato presente una volta su SQL Azure, più volte nell'Azure Table Storage. Per esempio, si potrebbe voler avere uno stesso dato replicato N volte, una per ogni forma denormalizzata (o, se vogliamo, vista) richiesta dal client per accedere in lettura a quel dato. A tal proposito vi invito a non preoccuparvi eccessivamente dei costi di storage: il costo di 5 GB su SQL Azure corrisponde a 175 GB sul Table Storage.

Come qualcuno avrà certamente intuito l'implementazione di quest'architettura richiede la risoluzione di un problema: mantenere opportunamente sincronizzati i dati su SQL Azure e sull'Azure Table Storage, ma la criticità di questa problematica dipende fortemente dall'ambito applicativo. Anche se aggiornare entrambe le basi di dati (indipendentemente dalla tecnica utilizzata) è sicuramente più oneroso rispetto ad aggiornarne solo una, se per ogni scrittura di un dato, vengono effettuate più letture, ecco che il costo pagato in fase di aggiornamento sarà ampiamente controbilanciato dalla scalabilità in lettura offerta dall'Azure Table Storage.

In sostanza, maggiore è il rapporto tra le letture e le scritture, maggiore sarà il vantaggio in scalabilità potenzialmente perseguibile. Questo è sicuramente il caso dei portali web e dei social network: il numero di letture è certamente superiore, e non di poco, a quello delle scritture. Va, inoltre, considerato che non sempre è necessario un aggiornamento del dato in tempo reale. Pertanto, se è tollerabile un piccolo lasso di tempo nel quale le informazioni tra le due basi di dati non sono sincronizzate, la fase di sincronizzazione potrebbe anche essere eseguita asincronamente rispetto all'aggiornamento, rendendo quest'ultimo più rapido e non bloccante.

SQL Azure vs Azure Table Storage

Sun, 12 Feb 2012 15:40:39 GMT

Una delle diatribe più interessanti alle quali si assiste nel momento in cui ci si approccia alle tecnologie per il cloud messe a disposizione da Microsoft è quella che mette in contrapposizione SQL Azure e l'Azure Table Storage.

SQL Azure è il database relazionale marchiato Microsoft per il cloud ed essenzialmente è una versione di SQL Server che gira nei datacenter in maniera analoga alle compute instance di Windows Azure.

Trattandosi di un database relazionale, le applicazioni che si basano su SQL Server non avranno, teoricamente, grandi difficoltà nell'utilizzare SQL Azure come database. Esistono ad oggi alcune limitazioni in questa piattaforma rispetto ad un'installazione Standard o Enterprise di SQL Server, ma nel tempo molte di queste limitazioni sono state risolte. Per esempio in SQL Azure non è disponibile la ricerca fulltext, gli Analysis Services, così come le reference cross-database (cioè la possibilità di coinvolgere in una query tabelle appartenenti a database distinti), tuttavia altre deficienze presenti nel passato sono state implementate ed un esempio è rappresentato dai Reporting Services. Per maggior informazioni in merito alle funzionalità che ci piacerebbe vedere in SQL Azure vi consiglio di fare riferimento al sito dedicato.

L'Azure Table Storage, invece, fa parte, insieme ai Blob e Queue Storage, dei Windows Azure Storage Services, cioè di servizi di immagazinamento dei dati messi a disposizione da Microsoft nell'ambito della piattaforma cloud Windows Azure. Il Table Storage può essere considerato un database NoSQL. Cosa contraddistingue questo tipo di database? Beh contrariamente ai RDBMS che si basano sull'ormai robusto e collaudato modello relazionale e sul rispetto delle ACID (Atomicity, Consistency, Isolation, e Durability), i database NoSQL nascono per risolvere problematiche differenti e, in particolare, il loro focus è spesso la scalabilità orizzontale.

Supponiamo di avere un server con un'istanza di database e di renderci conto che è arrivato al suo limite massimo di prestazioni a causa del carico di lavoro. Scalare verticalmente significa aumentare la potenza di calcolo del server attraverso un aggiornamento di CPU, RAM e quant'altro contribuisca a migliorarne le prestazioni. Quest'ultimo è il classico approccio che si adotta, ma non è di certo il migliore per svariante ragioni:

Limiti: per quanto si possano aggiornare le componenti di un server, prima o poi si raggiungerà il limite massimo della piattaforma hardware
Costi: il prezzo dell'hardware non scala linearmente alla sua potenza, ma spesso le componenti migliori costano svarianti ordini di grandezza più delle controparti meno prestanti
Scarso equilibrio: aggiornando l'hardware del proprio server si rischia di dimensionarlo sulla base di carichi di lavoro che possono rappresentare semplicemente dei picchi rispetto al carico standard. Chiaramente questa considerazione è fortemente dipendente del dominio applicativo, ma in linea di principio è pur sempre valida

Scalare orizzontalmente significa poter affiancare all'istanza applicativa in difficoltà, una seconda, magari su un server virtuale o fisico diverso, e vederne raddoppiare il carico di lavoro sostenibile.

I database relazionali storicamente non hanno una enorme capacità di scalare orizzontalmente, soprattutto se i dati sottoposti maggiormente agli accessi sono concentrati in alcune specifiche tabelle relazionate tra loro. Il dover sottostare al rispetto delle ACID, comporta il lock dei dati alla loro modifica al fine di conservare la consistenza del dato. La problematica diventa ancor più stringente nel momento in cui si fanno uso di transazioni che coinvolgono parecchie righe e tabelle.

SQL Azure mette a disposizione alcune funzionalità per migliorare la scalabilità:

Distribuire i dati su più database ne garantisce la scalabilità orizzonale perché database SQL Azure distinti possono essere distribuiti su server differenti. Chiaramente ciò limita la possibilità di fare
Database Sharding: è una tecnica che consente in sostanza di partizionare i propri dati in base ad una serie di criteri (ID, Range di ID, ecc...) al fine di distribuirli automaticamente su più database e, quindi, ottenere la scalabilità orizzonale nel caso in cui le query siano distribuite più o meno equamente su tutti i database

Con queste tecniche si può ottenere la scalabilità anche su un database relazionale on the cloud come SQL Azure, ma è possibile che ciò non sia sufficiente. Supponiamo di avere a che fare con un ambito applicativo nel quale abbiamo tantissimi dati in tabelle per le quali non è possibile effettuare lo sharding, cioè distribuirle su più database in base ad una chiave o ad una range di chiavi o che comunque, anche se possibile, non trarrebbe alcun beneficio da questa soluzione perché magari a livello di SELECT si deve accedere quasi sempre ai dati in maniera globale.

Un altra situazione nel quale la scalabilità orizzontale di SQL Azure può comunque non essere sufficiente è rappresentata dai costi: 5 GB su SQL Azure costano circa € 35, mentre con la medesima cifra è possibile ottenere 325 GB su Table Storage con 4 milioni di transazioni al mese.

Esistono svariati tipi di database NoSQL e il Table Storage di Windows Azure può essere considerato di tipo "Key-Value". In pratica è possibile definire tabelle in ognuna delle quali ogni riga è univocamente identificata da una RowKey ed una PartitionKey, la cui coppia essenzialmente è la chiave primaria. Ogni riga può avere fino a 255 proprietà o colonne e non può contenere complessivamente più di 1 MB di dati.

Nel processo di ingegnerizzazione di un software destinato ad usare il Table Storage è fondamentale scegliere accuratamente la RowKey e la PartitionKey. Quest'ultima in particolare rappresenta il partizionamento dei dati: tutti i dati di una partizione si trovano sul medesimo server e, quindi, sarebbe opportuno sceglierla in maniera che le interrogazioni del software siano uniformemente distribuite su tutte le partition key per massimizzarne le performance.

Un altro aspetto interessante è la replicazione automatica dai dati in tre copie nel medesimo datacenter e in due datacenter del medesimo continente. Questa caratteristica garantisce sia una maggiore fault tolerance, sia maggiori performance di accesso in lettura ai dati stessi.

Non è obiettivo di questo post fornire un HOW-TO delle operazioni di interrogazione su Table Storage, ma vi posso anticipare che è possibile sia farlo mediante banali richieste HTTP REST, che attraverso le comodissime API WCF Data Services che consentono di eseguire query anche mediante LINQ.

Chiaramente non sono tutte rose e fiori: il servizio di Table Storage, infatti, non è un database relazionale e, pertanto, non vi consente di eseguire query mettendo in join più tabelle. Questa operazione è possibile eseguirla solo client side, cioè scaricando sul client i contenuti di entrambe le tabelle e mettendole in join con LINQ to Objects, ma chiaramente questa non è una soluzione ottimale da nessun punto di vista. La realtà è che se si intende far lavorare questo tipo di servizio come se fosse un database relazionale, si otterranno risultati molto poco soddisfacenti.

Le interrogazioni su Table Storage sono molto efficienti a patto che il filtro coinvolga prevalentemente la RowKey e la PartitionKey. Qualsiasi altro uso comporterà quello che in ambito RDBMS chiameremmo un FULL SCAN e cioè qualcosa da evitare assolutamente.

Limitazioni esistono anche nell'uso delle transazioni: queste sono supportate solo se coinvolgono non solo righe appartenenti da una sola tabella, ma devono far riferimento ad una stessa partizione di quella tabella.

E' chiaro, quindi, che non è possibile pensare di migrare un sistema da SQL Server al Table Storage senza dover riprogettare interamente lo strato di accesso ai dati. E' necessario progettare l'architettura del software con l'obiettivo di sfruttare tutti i punti di forza del Table Storage, chiaramente laddove l'ambito applicativo lo consenta e, soprattutto, ne tragga beneficio.

I più scettici e i più grandi sostenitori del modello relazionale sicuramente avranno già cestinato l'idea di utilizzare il servizio di Table Storage, ma vi posso assicurare che è possibile sfruttare un database non relazionale con successo e grandi soddisfazioni e social network come Facebook e Twitter sono esempi evidenti dell'uso di database NoSQL in ambiti applicativi dove la scalabilità ha la priorità su tutto, scalabilità che non si sarebbe mai raggiunta affidandosi solo ai cari vecchi database relazionali.

Il prossimo post vi parlerò di un'architettura ideata proprio con l'obiettivo di trarre il massimo beneficio da database come il Table Storage.

Orario Treni per Windows Phone è qui

Tue, 24 Jan 2012 08:41:56 GMT

Infine è arrivato, Orario Treni per Windows Phone fa la sua comparsa nel Marketplace di Microsoft. Tutte le funzionalità disponibili per la versione Apple iOS, sono ora a fruibili da coloro che hanno scelto il sistema operativo mobile di Redmond per il proprio smartphone.

Dal punto di vista dello sviluppo, Orario Treni può vantare le seguenti chicche:

design pattern Model View ViewModel per la separazione della logica applicativa dalla definizione dell'interfaccia grafica
uso di SQL Server CE 4, per lo storage dei dati sul telefono
chiamate WCF a servizi SOAP per il download di tutti i dati consultabili sui treni

Per coloro che non conoscessero l'applicazione, riassumo brevemente le funzionalità salienti:

Soluzioni di viaggio dirette e con cambi, indicando una stazione di partenza e di arrivo
Treni in arrivo ed in partenza data una stazione, completo di segnalazione dell'eventuale ritardo
Dettaglio di un treno a partire dal suo numero o dalle funzionalità precedenti, che consente di monitorare il percorso del treno, completo di numero di binario e minuti di ritardo per ogni sua fermata
Consultazione degli scioperi in atto e previsti su tutto il territorio nazionale nel settore dei trasporti (treni, aerei, trasporto pubblico locale, ecc...)

Maggiori informazioni sono disponibili nella pagina dedicata del sito.

Orario Treni richiede necessariamente che il proprio Windows Phone sia stato aggiornato alla versione Mango. Buon diverimento e mi raccomando, se avete consigli e/o critiche costruttive, io sono qua :)

DateTime.Kind e ADO.NET

Tue, 10 Jan 2012 12:08:17 GMT

Nell'ambito della realizzazione di un sistema cloud based è necessario prestare particolare attenzione alla gestione dei DateTime. Se, infatti, nel deployment di soluzioni on premise è possibile controllare (non sempre, ma spesso si) le impostazioni relative al timezone del server e del client, quando un'applicazione gira dei datacenter di Microsoft, tale controllo non c'è. Potete chiaramente ben intuire quale problema si ponga nel momento in cui il timezone del client sia diverso da quello del server: poiché ADO.NET, quando recupera un DateTime dal database, di default gli imposta la proprietà Kind su Unspecified che, in sostanza, viene trattato lato client come se si trattasse di un valore locale, supponendo che il valore sia stato generato lato server con la chiamata DateTime.Now, capite bene che il rischio di ritrovarsi sul client date locali del server è molto elevato. Per risolvere questo problema esistono vari approcci, ma quello che preferisco è il seguente:

Lato server è necessario bandire la chiamata DateTime.Now ed utilizzare piuttosto DateTime.UtcNow
Lato server, nel momento in cui si recuperano i dati, è necessario assicurarsi che le date siano DateTime con la proprietà Kind impostata su DateTimeKind.Utc. Se si utilizzano le care vecchie DataTable, vi renderete conto che queste vi restituiscono sempre DateTime con Kind impostato un Unspecified. Per risolvere questo problema è necessario impostare la proprietà DataColumn.DateTimeMode su DataSetDataTime.Utc
Lato client, prima di visualizzare o inserire i dati, sarà necessario convertirli da e verso il formato Utc nel formato locale. Il tutto può essere fatto mediante converter in WPF/Silverlight e con apposite formattazioni in ASP.NET

Windows Azure Table Storage InsertOrUpdate

Wed, 14 Dec 2011 15:02:57 GMT

E' ormai da diverse settimane che mi cimento nello sviluppo di un sistema destinato a girare nell'infrastruttura Cloud di Microsoft e, in particolare, le tecnologie che sto impiegando sono Windows Azure, SQL Azure, Windows Azure Table Storage, Windows Azure Blob Storage e AppFabric Cache. Una delle più grandi sfide quando si utilizza lo storage di Windows Azure è l'abbattimento del numero di accessi ad esso. Come probabilmente saprete, accedere agli storage di Windows Azure ha un costo calcolato sia sulla base della quantità di spazio occupata, sia sul numero di transazioni, cioè di operazioni di lettura/scrittura.

Supponiamo di dover eseguire la classica Insert Or Update di un dato all'interno del Table Storage. Avendo sempre ben in mente che stiamo parlando di un database NoSQL nel quale, quindi, il concetto di transazione non esiste, per implementare questo tipo di operazione è necessario scrivere qualcosa del genere:

CloudTableClient tableClient = GetTableClient();
TableServiceContext context = tableClient.GetDataServiceContext();
context.IgnoreResourceNotFoundException = true;
var item = context.CreateQuery<cacheentity>(tableName)
           .Where(p => p.PartitionKey == partitionName && p.RowKey == storageKey)
           .FirstOrDefault();
if (item != null) 
{ 
   context.DeleteObject(item); 
} 
context.AddObject(tableName, newItem); 
context.SaveChangesWithRetries();

Il problema di questo approccio è che il numero di operazioni effettuate è, nel caso peggiore, pari a tre (in realtà si potrebbe fare la delete e la insert in batch, ma non è importante), mentre nel caso migliore è pari a due.

Grazie all'Insert-Or-Update Entity introdotto da qualche mese è possibile ridurre il numero di accessi nel modo seguente:

CloudTableClient tableClient = GetTableClient();
TableServiceContext context = tableClient.GetDataServiceContext();
context.AttachTo(tableName, newItem);
context.UpdateObject(tableName, newItem);
context.SaveChangesWithRetries(SaveChangesOptions.ReplaceOnUpdate);

Questo codice esegue la Insert o, eventualmente, l'update dell'elemento in tabella grazie all'uso dell'opzione ReplaceOnUpdate. Naturalmente non poteva essere tutto così semplice: se provate quest'ultimo codice in locale vi renderete conto che non funziona. Il problema è che la Insert-Or-Update Entity non è disponibile per il local storage, compreso quindi il vostro storage emulato. Per risolvere questo problema potete affidavi alla propria booleana statica RoleEnvironment.IsEmulated ed implementare, quindi, nel caso in cui sia true la soluzione meno efficiente che però verrà eseguita solo in ambiente di sviluppo, il che è assolutamente accettabile.

WPC 2011: WinRT e Cloud

Tue, 29 Nov 2011 00:30:00 GMT

E' ormai il terzo anno di fila che frequento il WPC 2011: da quando il mio ex responsabile me lo fece conoscere nell'apparentemente vicino, ma incredibilmente lontano 2008, ho fatto di tutto per convincere, dapprima i miei datori di lavoro, ed oggi i miei soci, che partecipare a quest'evento è importante.

Non è importante perché ciò di cui si parla al WPC è impossibile apprendere in altro modo, anzi mi è capitato più di una volta di seguire sessioni i cui contenuti mi erano già noti anche al 90%, ma è importante perché si tratta di un full immersion formativo e di confronto con altri professionisti del settore che, sia per mancanza di tempo, che di opportunità, è a dir poco impossibile replicare. Insomma, pensateci bene: quante volte vi è capitato di ascoltare per tre giorni di fila sessioni tecniche dalla mattina alla sera? Se escludiamo i pochi di voi che hanno avuto la fortuna di fare qualche corso di formazione, probabilmente la risposta è mai.

Volendo fare un sunto degli argomenti trattati in questo WPC, posso dire che il 2012 è sicuramente l'anno del cloud e di Windows 8, un anno ricco di novità quindi, sia per quanto concerne lo sviluppo lato server, che lato client.

Lato server sono ormai parecchi mesi che gli addetti al settore avvertono che la direzione intrapresa è quella del cloud e ne è una prova anche la nascita di diversi provider di servizi di cloud computing, non necessariamente legate al mondo Microsoft. E' chiaro che per chi, come il sottoscritto, si è specializzato nelle tecnologie Microsoft, Windows Azure rappresenta la naturale piattaforma di riferimento ed è curioso vedere come le cose stiano evolvendo rapidamente: un anno fa Windows Azure era quasi un'entità astratta, oggi c'è un SDK maturo ed un'integrazione con Visual Studio 2010 davvero notevole.

Oltre a Windows Azure, ho seguito alcune sessioni anche sullo sviluppo lato client e, in particolare, su HTML5 e WinRT. Può sembrare curioso che io, che ho tenuto una sessione su HTML5 al Workshop Future Development, ne vada a seguire altre, ma nel campo dell'informatica, al di là degli appellativi attribuiti e/o guadagnati (junion, senior, technical lead, ecc....), non bisogna mai perdere l'umiltà e la voglia di apprendere e confrontarsi. Ed è proprio a tal proposito che vi racconto l'impressione che ho avuto seguendo le sessioni su WinRT e HTML5.

Osservando le reazioni delle persone e discutendo con alcuni miei collegi ed amici, penso che si sia creata parecchia confusione in merito a questi due argomenti. Alcuni pensano che .NET sia destinato al macero e che HTML5 rappresenti il futuro dello sviluppo per Windows 8, beh non è così e vi invito a leggere con attenzione la seguente frase.

WinRT è un'API nativa implementata in Windows 8 attraverso la quale è possibile sviluppare applicazioni Metro Style utilizzando come linguaggio di programmazione C++, C#, VB.NET e javascript e come linguaggio per la definizione della UI HTML5 e XAML.

Ho evidenziato la frase precedente perché mettere in risalto l'errore che commettono coloro che accostano WinRT a HTML5 come modello di programmazione primario. In particolare mi permetto di sottolineare i seguenti aspetti

WinRT nasce per lo sviluppo di applicazioni Metro Style, quelle che, quindi, saranno accessibili dall'interfaccia Metro introdotta da Windows Phone e che sarà adottata anche in Windows 8. Quest'ultimo, tuttavia, consente di utilizzare anche la classica interfaccia di Explorer il che significa che si possono continuare a sviluppare applicazioni "vecchia maniera" senza problemi
Le applicazioni Metro Style sono simili alle App dei dispositivi mobile: sono installabili solo mediante il Market Place, funzionano in una sandbox e nascono con l'obiettivo di facilitare l'uso di Windows specie su dispositivi touch come i tablet
Programmare usando HTML5 e Javascript con le API WinRT, cioè per sviluppare applicazioni Metro Style, non consente nel modo più assoluto di poter riutilizzare lo stesso codice sia di markup, che javascript per fare un'applicazione web. Nel momento in cui si accede alle librerie WinRT (e lo si deve fare per forza perché altrimenti non si sta sviluppando un'applicazione Metro Style) l'applicazione risultante resta confinata al mondo WinRT
Analogamente all'accoppiata HTML5/javascript, programmare usando C++/C#/VB.NET e XAML non significa avere la medesima applicazione disponibile, sia in versione Metro Style, che classica perché cambia il target di compilazione e cambiano i namespace di moltissime classi (ad esempio quelle della UI rispetto a WPF), oltre al fatto che WinRT espone un subset del .NET Framework e non il framework completo

.NET è, quindi, vivo e vegeto e nel 2012 uscirà la versione 4.5 che, tra le altre cose, porterà miglioramenti significativi proprio nello sviluppo di applicazioni WPF, oltre a tante altre novità che ne aumenteranno notevolmente la produttività (ad esempio la nuova gestione dei task asincroni).

A mio parere con WinRT Microsoft ha semplicemente voluto mettere a disposizione del più ampio parco di programmatori possibile (C++, .NET e Javascript) uno strumento per lo sviluppo delle applicazioni Metro Style probabilmente con la speranza che in ambito desktop/notebook/tablet accada ciò a cui assistiamo ormai da qualche anno in ambito mobile: un market place, specie quello di Apple, con migliaia di applicazioni disponibili e migliaia di acquisti effettuati grazie ai bassi costi che mediante queste anno.

Insomma, come avrete intuito, il tutto non ha la finalità di ottenere la pace nel mondo, ma le aspettative probabilmente sono quelle lecite di sempre: abbattimento della pirateria ed incremento dei profitti. E per noi programmatori cosa cambia? Fondamentalmente abbiamo l'occasione di sviluppare questo nuovo tipo di applicazioni, affrontando le sfide che esse ci porranno senza rinunciare al nostro linguaggio di programmazione preferito. Cosa possiamo chiedere di più? :-)

Vifani 3.0: si passa ad Orchard

Thu, 10 Nov 2011 08:48:52 GMT

Prima o poi doveva accadere, era solo una questione di tempo. Chi mi conosce lo sa, ho un incontenibile passione per il mio lavoro, lo sviluppatore software, ma poiché in linea di principio è sempre bene allargare i propri orizzonti e non fossilizzarsi sempre sugli stessi aspetti, ho deciso di far evolvere il mio sito che, per la prima volta, invece di essere realizzato in toto dal sottoscritto, è basato su Orchard.

Per chi non lo conoscesse Orchard è un CMS opensource basato su ASP.NET MVC 3 che sta riscutendo un discreto successo, sia perché è uno dei pochissimi CMS opensource basato su tecnologie .NET all'avanguardia, sia perché rispetto ad altri CMS analoghi (vedi DotNetNuke), non risulta essere legato ad un pesante passato fatto di plugin e moduli più o meno pesanti e basati su ASP.NET Web Form, ma utilizza le più recenti ed efficienti tecnologie web Microsoft. A dirla tutta mi risulta che DotNetNuke recentemente con la versione 6 si sia anch'esso svecchiato, ma, come spesso faccio, al faticosamente evoluto ho preferito scegliere il totalmente nuovo.

Non posso chiaramente sottrarmi al classico confronto CMS vs "sito fatto a mano". Personalmente trovo che Orchard sia un CMS molto ordinato e preciso, ma è bene subito chiarire che l'idea secondo la quale affidarsi ad un CMS consenta di concentrarsi esclusivamente sui contenuti è una balla spaziale. Ho dedicato non poco tempo alla configurazione di Orchard, specie per quanto concerne l'aspetto grafico. Chiaramente esistono una serie di temi già preconfezionati, ma se uno ha un'idea ben precisa e vuole realizzarla, allora deve inevitabilmente mettere mano alle sue doti di programmatore o, se vogliamo, web designer per realizzare layout, stili CSS e quant'altro serva per dare corpo ad un tema di Orchard in maniera non molto dissimile da quanto ho già fatto con i miei siti web.

In particolare la mia idea era quella di migrare ad Orchard conservando il tema precedente non perché mi faccia particolarmente impazzire, ma perché rappresentava per me una sfida. Nel complesso penso di esserci riuscito e di essere andato oltre: non solo ho fatto in modo di ottenere un tema il più possibile simile al prevedente sito, ma ho inoltre utilizzato alcune funzionalità tipiche del nuovo standard HTML5: i tag semantici e il border radius. Il tutto dovrebbe sia migliorare l'indicizzazione sui motori di ricerca (sperando che Google e company utilizzino effettivamente i tag semantici per meglio comprendere la struttura dei contenuti di un sito web), che ridurre la quantità di codice HTML presente nella pagina e, in particolare, tutta la sfilza di div e micro div necessari per realizzare bordi arrotondati alla vecchia maniera. Lo scotto da pagare è di aver definitivamente buttato nel cesso la retrocompatibilità con i browser più datati: Internet Explorer 6 e 7 potrebbero avere qualche problema nella visualizzazione della barra di navigazione e di ricerca, mentre tutti i browser che non supportano semplicemente il border radius dello standard CSS 3, vedranno le varie sezioni squadrate.

Esistono chiaramente soluzioni per non imporsi tali limitazioni, ma innovare spesso significa anche tagliare i ponti col passato e questa è stata la mia scelta. Tra le nuove funzionalità del sito troverete il supporto all'open authentication e questo vi consentirà di accedere al mio sito ed utilizzare i vostri account di Facebook, Tweeter, ecc..., per autenticarvi e commentare il blog.

DotNetSide Workshop "Future Development"

Sat, 15 Oct 2011 10:24:23 GMT

L'estate ormai è alle spalle, benché il meteo fino a qualche giorno fa poteva far pensare il contrario (almeno qui in Puglia), ed ecco che anche la comminity di DotNetSide si è risvegliata proponendovi il nuovo workshop "Future Development".

E' stata un'occasione molto interessante per toccare con mano alcune delle tecnologie che saranno alla base dello sviluppo software web e non, nei prossimi anni. In particolare il sottoscritto vi ha proposto una sessione su HTML5, il nuovo standard in via di definizione, spinto molto da Microsoft non solo attraverso le nuove versioni di Internet Explorer, ma anche come piattaforma di sviluppo per le applicazioni Metro Style di Windows 8.

Estremamente piacevoli ed interessanti sono state anche le sessioni tenute da Vito Arconzo, Giuseppe Dimauro e Stefano Fio. Il primo ha mostrato uno sviluppo diverso dal solito, basato sul SDK di Kinect, mentre gli altri due ci hanno deliziato con le ultimissime tecnologie Microsoft in termini di sistemi operativi server, desktop e relativi strumenti di sviluppo.

Al seguente link potete scaricare il file contenente sia le slide che la demo mostrata nel corso della mia sessione.

Download Slide e Demo

Orario Treni 1.2 per iOS e beta per WP7 Mango

Wed, 21 Sep 2011 10:16:35 GMT

Ieri è stata pubblicata sull'Apple Store la nuova versione di Orario Treni che introduce le seguenti novità:

E' stata aggiunta nella maschera di ricerca delle soluzioni di viaggio la visualizzazione degli scioperi nazionali nel settore dei trasporti, utile per evitare spiacevoli sorprese. La nuova funzionalità è accessibile attraverso il tasto "i" presente in alto a destra
Luca ha lavorato molto per migliorare il supporto allo Screen Reader Voice Over di iOS, grazie al quale Orario Treni è diventato un'applicazione meglio accessibile da coloro che hanno difficoltà e che per questo motivo si affidano a tale tecnologia per utilizzare un iPhone
In generale sono stati adottati una serie di trucchi per migliorare le performance nella ricerca e nella visualizzazione dei risultati
Abbiamo risolto, inoltre, una serie di bug segnalati dagli attuali utilizzatori dell'app

Vi mostro, inoltre, un work in progress della versione per Windows Phone 7

Devo ammettere di trovare la programmazione su Windows Phone 7 molto più semplice e rapida rispetto a quanto accade con iOS, nonostante l'uso di Monotouch. In ogni caso immagino che queste sensazioni siano normali: grazie al mio lavoro, .NET e Silverlight li conosco in maniera molto approfondita, mentre Monotouch (e le API delle quali fa il binding) è stato tutto da scoprire.

Se dovessi fare un paragone tra le API messe a disposizione da Microsoft e Apple, ritengo lampante la differenza: lavorare con iOS equivale a lavorare a più basso livello, dove concetti come il data binding sono molto lontani. Questo non significa che non ci sia spazio per l'applicazione di pattern e, anzi, l'infrastruttura di iOS è stata per me un ottimo esempio di implementazione del pattern MVC su una piattaforma non managed. Tuttavia è evidente che con linguaggi come lo XAML ed il portentoso motore di binding messo in piedi con WPF e Silverlight, la piattaforma Microsoft risulta essere molto più evoluta, oltre a permettere l'applicazione di pattern come il MVVM del quale sono diventato uno scrupoloso adepto.

Microsoft .NET Framework 4 Platform Update 1

Fri, 15 Jul 2011 23:46:22 GMT

Forse non tutti sanno che nel mese di Aprile di quest'anno Microsoft ha rilasciato un aggiornamento del .NET Framework 4 particolarmente importante e che a mio avviso avrebbe dovuto ricevere maggiore attenzione dalla community online di sviluppatori .NET, ma che per ragioni poco comprensibili è passato quasi inosservato.

Sto parlando del Platform Update 1, un aggiornamento che si compone di tre diversi pacchetti:

Microsoft .NET Framework 4 Platform Update 1 (KB2478063)
Multi-Targeting Pack for Microsoft .NET Framework 4 Platform Update 1 (KB2495638)
Microsoft .NET Framework 4 Platform Update 1 – Design-time Package for Visual Studio 2010 SP1 (KB2495593)

Il Platform Update 1 porta una interessantissima novità in Windows Workflow Foundation 4: le macchine a stati. Chi di voi ha seguito questa API, sa bene che una delle sue deficienze, anzi probabilmente l'unica sua pecca, è rappresentata dall'impossibità di realizzare workflow a stati in maniera esplicita.

Il Platform Update 1 colma questa lacuna e l'importanza di questo aggiornamento è tale da farlo quasi sembrare una sorta di Service Pack 1 del .NET Framework 4 in quanto per utilizzare le nuove funzionalità è necessario installare il runtime (il primo dei tre pacchetti che vi ho citato), aggiungere il supporto al multi-targeting (secondo pacchetto) ed aggiungere un pacchetto dedicato al designer dei workflow di Visual Studio 2010 SP1.

Installati tutti e tre i pacchetti è necessario cambiare il target del progetto .NET impostandolo esplicitamente a ".NET Framework 4 Platform Update 1 (KB2478063)". Senza effettuare questa operazione non è possibile utilizzare i nuovi workflow a stati.

Ho già testato questi nuovi workflow e non ho riscontrato particolari problemi, anzi consentono di modellare in maniera abbastanza esauriente un flusso a stati. Consiglio a chi fosse interessato ad approfondirli, di dare un'occhiata ad un articolo pubblicato nei blog MSDN che effettua una panoramica sulle novità introdotte.

L'unico elemento negativo che mi sento di sottoporre alla vostra attenzione è la modalità con cui Microsoft ha rilasciato tale aggiornamento. Chi credeva che con il .NET Framework 4 fossero finite le incongruenze nelle modalità con il quale il framework è stato versionato in passato (3.0, 3.5, 3.5 SP1, ecc...), dovrà ricredersi visto che, invece di chiamare questo aggiornamento 4.1 (come saggiamente fatto dal team dell'Entity Framework), hanno deciso di adottare il termine Platform Update 1 che vi ritrovare addirittura nel menu a tendina del target completo di numero della knowledge base. Una scelta che certamente non va nella direzione della massima chiarezza.

Orario Treni si aggiorna alla versione 1.1.1

Sat, 11 Jun 2011 03:34:34 GMT

Quest'oggi vi segnalo che Orario Treni è stata aggiornata alla versione 1.1.1 che introduce molteplici novità:

Ferrovie locali: è stato aggiunto il supporto alle ferrovie locali Trenord (ex Lenord), integrate in Trenitalia, e alle Ferrovie Sud Est, supporto che fa di Orario Treni l'unica applicazione nel suo genere a proporre soluzioni di viaggio che vanno oltre le classiche tratte di Trenitalia
Orario Treni è già pronto per le CPU dual core alla base dei prossimi iPhone: una serie di operazioni, tra cui la ricerca contemporanea su più linee ferroviarie, è stata parallelizzata in modo da sfruttare al meglio la prossima generazione di processori
Accessibilità: è stato migliorato notevolmente il supporto alla tecnologia Screen Reader Voice Over di iOS per consentire la massima fruibilità anche a persone con difficoltà nell'uso dei dispositivi touchscreen
Performance: oltre alle migliori performance dovute alla parallelizzazione di alcune operazioni, anche sulle attuali generazioni di iPhone è stata ottimizzata la visualizzazione dei risultati delle ricerche
Bug: una serie di bug che ci sono stati segnalati sono stati risolti

Ma le novità non finiscono qui. Ben presto presenterò un nuovo progetto sempre per iPhone/iPad e nel frattempo ho intenzione di preparare un post sull'Entity Framework. Stay tuned!