Chi ha partecipato all’evento DotNetUmbria che Innovactive ha organizzato lo scorso 15 Gennaio ricorda che una delle applicazioni più complete che abbiamo presentato (.NET MicroFramework ‘onboard’) consiste in una serra domestica il cui microclima può essere impostato a distanza, controllando parametri quali la temperatura, la luminosità e l’umidità del terreno.
In questi giorni abbiamo continuato a lavorare sul nostro prototipo portandolo a rappresentare, a nostro avviso, un sistema completo di monitoraggio remoto della serra; con questo post pertanto, a vantaggio di tutti, presentiamo schematicamente e illustriamo la soluzione completa, lo stato dell’arte del nostro MicroGardener.

Come potete osservare nello schema sopra riportato la serra è dotata di sensori per rilevare costantemente il grado di umidità del terreno, la temperatura in prossimità delle piante e la luminosità ambientale. Tali dati vengono trasmessi wireless ad un modulo Tahoe (una scheda di sviluppo, tra le prime sul mercato che ci ha consentito di programmare e sperimentare con il MicroFramework) grazie ad una coppia di moduli XBee. Molto ci sarebbe da dire su questi dispositivi, ma allo scopo del nostro post basta dire che utilizziamo la ‘API Mode’ per configurare il modulo posto presso la serra come dispositivo che autonomamente trasmette i dati letti dai sensori e occasionalmente riceve un comando di attivazione/disattivazione di un attuatore, mentre il modulo posto presso la scheda di sviluppo Tahoe è in grado, grazie alla libreria Micro Framework Toolkit (http://mftoolkit.codeplex.com/) di interpretare lo stack XBee per le due situazioni di ricezione dei dati dei sensori e di invio dei comandi di attuazione.
Il dispositivo che abbiamo presentato nell’ambito del citato evento si fermava appunto al modulo Tahoe, che è dotato di un display LCD e di una serie di tasti per l’interazione con l’utente; il programma MicroFramework realizzato consente di leggere i valori che giungono dai sensori, visualizzarne graficamente l’andamento nel tempo e agire con i comandi sui singoli attuatori (una lampada per la luminosità, una lampada ad infrarossi per la temperatura e la pompa per l’irrigazione del terreno) oppure selezionando una modalità automatica, nella quale il software provvede al mantenimento dei parametri entro i range impostati per il microclima voluto, azionando in totale autonomia gli attuatori.
Un sistema come quello fin qui presentato, ovviamente, si limita a remotizzare il controllo della serra su distanze compatibili con la portata dei moduli XBee e può essere pensato comunque per l’applicazione domestica (o di vivaio) comunque locale. Come rendere il tutto veramente delocalizzato? Utilizzando il web, ovviamente!
Ecco in quale direzione abbiamo esteso il sistema: utilizzando come server web un modulo aggiuntivo ethernet per il Tahoe (prodotto, come il Tahoe, da Device Solutions; oggi nel loro catalogo si trova il modulo Tahoe-II, che già implementa funzionalità ethernet) abbiamo implementato una API REST che espone quanto ci serve per interagire con la serra in termini di lettura dati e impartizione dei comandi; un servizio WCF si occupa di interrogare periodicamente (polling) il server web per tenersi in memoria i dati dei sensori aggiornati; a questo punto sul web abbiamo pensato la possibilità per l’utente di poter controllare la serra con un semplice browser e, per rendere il tutto un po’ più accattivante, un client Silverlight.
I vantaggi di questa architettura sono molteplici in termini di scalabilità e di prestazioni: infatti pensando al servizio in rete locale con il modulo Tahoe l’attività di polling non viene effettuata su web; poi il tutto può essere implementato per più serre, ovvero per molti sistemi serra + XBee + Modulo MicroFramework; in fase di configurazione del servizio WCF impostiamo quali serre gestire (essenzialmente quali indirizzi interrogare con chiamate REST) e, all’atto di chiamata del servizio da parte di un client, il servizio fornirà all’utente la lista delle serre controllate per operare una scelta.
Completa il tutto un sottosistema che renderà felici gli scettici da una parte (se non vedo non credo!) e coloro che comunque vogliono gustarsi anche ‘a vista’ le loro piante o fiori: abbiamo munito la serra di webcam e instradato il segnale proveniente da essa tramite Microsoft Expression Encoder, esponendolo in streaming su server apposito; il client silverlight è stato munito dell’apposito controllo per la fruizione del flusso video in streaming e…
…eccovi il risultato finale!

Per vedere il sistema funzionante (con la sola avvertenza che attualmente la pompa per l’irrigazione è sostituita da una semplice lampadina per motivi di sicurezza) e provare ‘live’ a controllare la nostra piccola serra collegatevi alla dashboard di test, quindi selezionate ‘Innovactive Garden’ e cliccate su ‘Connect’…
…solo per utenti con il ‘pollice verde’!

Dopo una ‘onerosa’ elaborazione statistica eccovi tre grafici che sintetizzano i pareri che i partecipanti hanno dato in merito a vari aspetti dell’evento.
Ogni parere richiesto doveva essere espresso su una scala da 0 a 5; per ogni aspetto abbiamo riportato il valore medio su tutti i questionari compilati e il valore della deviazione standard dal valore medio. Noi stiamo già facendo le nostre considerazioni, e voi?

Iniziando con un doveroso ringraziamento a tutti i partecipanti e a tutti coloro che hanno reso possibile questo evento, pubblico qualche foto a beneficio di chi non c'era (perdonato solo se impossibilitato a venire da cause di forza molto maggiore) e con l'occasione cerco di sintetizzare quelle che secondo la mia personale percezione sono le impressioni emerse intorno a questa iniziativa:

• I nostri timori di essere i soli sulla terra cui interessi l'argomento dello sviluppo di software .NET che interagisca con il mondo reale sono svaniti
• Il fermento dei partecipanti si è effettivamente diviso tra chi è più affascinato dalla possibilità di realizzare software per PC che interagisca con il mondo esterno e chi invece è più attratto dallo sviluppo di software .NET finalizzato ad essere eseguito direttamente su dispositivi embedded (tramite .NET MicroFramework)
• Il feedback che abbiamo ricevuto ci ha dimostrato che in molti pensano come noi che studiare le metodologie e le tecnologie relative allo sviluppo di un'applicazione embedded (pura o ibrida che sia) aiuti ad essere degli sviluppatori migliori e dei professionisti più completi
• La robotica piace più della domotica (anche se probabilmente in assoluto la prima fatturerà un milionesimo della seconda)
• Il cruscottone WPF che mostrava in real-time i dati provenienti dai sensori è piaciuto probabilmente più della mini-serra automatica remotizzata programmabile con .NET, nonostante quest'ultima abbia richiesto almeno il decuplo in termini di ore/uomo
• La maggioranza dei partecipanti avrebbe voluto vedere probabilmente più codice ed è per questo che spero che i nostri prossimi post tecnici di "dissecting" di quanto visto all'evento siano letti, commentati e, perché no, diventino lo spunto per proporre soluzioni, progetti ed iniziative che alimentino la passione dei membri della community su questi temi

Basta chiacchiere, ecco alcune foto:

Come già anticipato con qualche immagine da Fabrizio qualche giorno fa, i preparativi per i "giocattoli hardware" da mostrare al Develop Reality 2010 in programma la settimana prossima.

Ecco qualche altro scatto di quello che (tempo permettendo) vedremo venerdì 15 come esempi di possibili realizzazioni:

Non resta che venire per vedere tutto il resto :D

Ecco il link diretto alla pagina per la registrazione!

Come sicuramente oramai avrete appreso dai numerosissimi blog e siti web che ne hanno dato notizia, nelle scorse settimane è stato reso disponibile il download di una nuova versione beta dell’ambiente di sviluppo di riferimento su piattaforma Microsoft.

Il nuovo aggiornamento di Visual Studio farà parte di un salto generazionale di gran lunga più consistente di quanto è avvenuto con il rilascio della versione 2008, in quanto per la prima volta da 5 anni a questa parte assisteremo alla pubblicazione di una nuova runtime (la versione 3.5 del Framework utilizza infatti i componenti “core” di .NET 2.0), denominata con ammirevole fantasia .NET 4.0.

Sono moltissime le novità introdotte, letteralmente a 360 gradi, da Microsoft con questa nuova “sessione” di rilasci che avrà luogo molto probabilmente nel mese di Marzo 2010, ed è quindi molto difficile orientarsi nel tentativo di distinguere quello che effettivamente cambierà il modo di sviluppare applicazioni per chi fa questo come attività professionale rispetto alle novità che invece dimenticheremo dopo i primi minuti di utilizzo (qualcuno si ricorda dell’eco data dalle prime recensioni di Visual Studio 2005 alla funzionalità che evidenziava in giallo e verde le righe modificate o aggiunte ad un sorgente tra un salvataggio ed il successivo?).

Ad ogni modo, da qualche parte bisognava pure iniziare e noi abbiamo installato il nuovo Visual Studio all’interno di una macchina virtuale VirtualBox con sistema operativo Windows 7 Starter Edition (il tutto all’interno di una macchina fisica Vista 64 con 4Gb di ram).

Le prime impressioni, che vogliamo condividere attraverso qualche screenshot, non possono non tenere conto della completa riscrittura dell’IDE, che ora utilizza WPF, che ora vanta un’interfaccia utente molto più ricca ma, a dire il vero, anche sensibilmente più lenta, anche se su questo punto converrà esprimersi solo una volta valutata la versione definitiva e in un ambiente non virtualizzato.

Il primo screenshot si riferisce ad una panoramica dell’editor testuale (C# e XAML nell’esempio riportato) che grazie alla versione di WPF contenuta in .NET 4 raggiunge dei livelli di leggibilità del testo su LCD veramente notevoli, anche a dimensioni relativamente piccole (8 e inferiori).

Nella seconda immagine abbiamo riportato una piccola testimonianza di quello che crediamo migliorerà la vita di chi come noi spende molte ore del proprio tempo facendo debugging (non perché il software scritto sia buggato, sia ben chiaro…), ossia la possibilità di “ancorare” un quickwatch alla riga contenente l’espressione sotto controllo, come il contenuto di textbox1.Text ed il parametro “e” nell’esempio sotto (notate il piccolo pushpin nel tooltip/quickwatch).

Da non trascurare poi la nuova suite di designer per la modellazione, in grado di produrre diagrammi UML quali Sequence, Class Diagram, grafi di dipendenza tra classi, namespace, assembly e molto altro.

Sono state integrate inoltre le funzionalità di editing T-SQL di SQL Server Management Studio 2008, come illustrato nell’immagine seguente:

Ultimo ma non ultimo, non è da trascurare che ogni nuova release di Visual Studio accorpa di fatto tutte le estensioni (o almeno quelle ufficiali) rilasciate successivamente all’ambiente di sviluppo, quali ad es. ASP.NET MVC e ASP.NET MVC 2, Silverlight 3, Azure SDK, ecc.

La lista dei template di progetto built-in è infatti molto nutrita:

Quante volte ci è capitato di rimpiangere di non aver debitamente “instrumentato” un’applicazione per far sì che fossero loggate le chiamate ai vari metodi (ed i relativi parametri) nel momento in cui si presenta un problema in produzione?

Lo scenario tipico è rappresentato dalla telefonata del cliente che vi dice “ho fatto questa cosa e l’applicazione si è bloccata e l’ho dovuta chiudere da Task Manager”, oppure “ho cliccato sul tasto stampa ma il programma non ha fatto niente”, oppure ancora “per l’operazione che fino a ieri mi ci metteva pochi secondi oggi il programma mi fa aspettare qualche minuto”, e così via…

Bene, oggi abbiamo testato due prodotti free della EQATEC (http://www.eqatec.com/) che saranno di grande aiuto per risolvere le situazioni di cui sopra.

Il Tracer consente di “instrumentare” un insieme di assembly .NET contenuti (necessariamente) nella cartella specificata (con tanto di drag&drop), di cui verrà creata una copia allo scopo. Verrà quindi popolato un treeview con la struttura degli assembly e dei metodi singolarmente tracciabili. Ad ogni esecuzione di uno dei metodi selezionati il tracer visualizzerà il nome del metodo chiamato ed il valore dei parametri in ingresso (solo per i tipi base, però).

Notevole, veramente.

Il Profiler funziona in maneira analoga, ma traccia anche le durate della chiamata di ciascun metodo, oltre a diverse altre informazioni utili.

Alcune di osservazioni:

• il tracing e/o il profiling può avvenire addirittura via rete TCP/IP, permettendovi di fare diagnostica sulla macchina del cliente rimanendo comodamente seduti dietro la vostra scrivania (VPN permettendo)
• i tool della EQATEC sono realizzati come applicazioni WPF
• in fase di compilazione, l’approccio migliore per l’instrumentazione automatica del proprio codice resta a nostro avviso PostSharp + Laos

Quei mattacchioni di XDA-Developers hanno estratto l’emulatore Android dall’SDK, rendendolo disponibile come download stand-alone.

Se volete cimentarvi nella sperimentazione del nuovo OS di Google trovate una guida qui.

…dei nuovi strumenti per il design presenti in Visual Studio 2010?

Vi segnalo questo interessante dddstepbystep.com per chiunque sia desideroso di approcciare il DDD in maniera pratica e razionale. Particolarmente degno di nota l’ebook e il wiki relativo all’applicazione di esempio (DDD Parcel Service).

Nonostante l’autore, il solito Ayende, confessi che il titolo originale del post dovesse essere “Stupid Performance Tricks”, quella che trovate qui è una piccola guida tutt’altro che stupida ad alcuni semplici accorgimenti che velocizzano una procedura di inserimento di test di 500.000 record portandola da 400 record/secondo a 3.200 record/secondo.

Quello che sorprende ancora di più è che il risultato ottenuto attraverso l’uso di un ORM è più o meno collocato al 30% della massima velocità ottenibile (attraverso SqlBulkCopy), in un “terreno” (quello delle operazioni bulk) tradizionalmente molto sfavorevole agli ORM.