Articolo “Introduzione a Microsoft Application Insights” su Windows Azure Italia

Ieri sul network Aspitalia.com e in particolare su WindowsAzureItalia.com è stato pubblicato un mio articolo su Microsoft Application Insights, un servizio che ci consente di effettuare operazioni di telemetria su una web application o un web service (ASP.NET o Java) o su mobile application (Windows Phone o Windows Store app).

E’ un servizio molto interessante sul quale mi piacerà fare degli approfondimenti.

Erano più di quattro anni che non scrivevo per il network Aspitalia, per motivi personali o di lavoro avevo un po’ perso questa sana abitudine, e quando approfondivo un argomento poi non scrivevo nulla.

Ma ho deciso che “approfondire e condividere” sono verbi che devono viaggiare di pari passo.

Trovate l’articolo qui.

Articolo “Introduzione a Microsoft Application Insights” su Windows Azure Italia

Microsoft rende open source il codice del motore di .NET

Un altro pezzo del framework .NET di Microsoft viene rilasciato in open source.

La filosofia adottata dall’azienda di Redmond sembra quella di rilasciare praticamente tutto il codice sorgente del framework .NET, e quindi anche il CoreCLR diventa pubblico.

Quello di cui stiamo parlando è il motore vero e proprio di .NET, quello cioè che si occupa di compilare a run time ed eseguire il codice IL che otteniamo sviluppando con questo framework.

E come è già successo per gli altri rilasci, anche questo finisce su GitHub e non su Codeplex.

Anche questa scelta sembra parte di una vision ben definita, almeno a mio modo di vedere, visto che oltre la significativa differenza dal punto di vista tecnologico di un sistema rispetto all’altro, l’utilizzo di GitHub rappresenta un forte segnale di aggregazione verso il mondo open source, che con le precedenti gestioni del top management di Microsoft sembrava invece una strada mai percorribile.

Microsoft continua quindi nel “cambiamento di pelle”, non nascondo il mio scetticismo iniziale, ma ora pian piano che la “direzione” sembra quasi del tutto chiara, posso dire di condividerla e di esserne entusiasta.

In effetti un mondo che si apre porta sempre ad un maggiore confronto, e questo per chi fa il nostro lavoro è un fatto sempre positivo.

Microsoft rende open source il codice del motore di .NET

Windows 10 per Raspberry PI 2 arriverà presto e sarà gratis

La notizia di ieri è rimbalzata per tutta la rete: Microsoft ha annunciato che entro quest’anno rilascerà una versione del prossimo sistema operativo, Windows 10, capace di girare sulla board Raspberry PI 2.

Tutta la giornata di ieri c’è stato un gran fermento per questa notizia, tutti sono rimasti molto contenti di questa iniziativa, anche per il costo contenuto della board, al momento in cui scrivo di soli 35$.

Ma molti non sapevano cosa fosse la Rapberry PI, e anche io, che pure sono molto felice di questa notizia, non ho mai avuto modo di lavorarci.

Per quello che ne so, la Raspberry PI è di fatto un “microcomputer”, ovvero una singola scheda con caratteristiche proprie di un calcolatore classico, che qualche anno fa neanche un PC costoso aveva, e a cui possiamo demandare varie operazioni di calcolo tra cui, per esempio, quelle in ambito domotica o IoT.

Sviluppato da alcuni anni nel Regno Unito, era nato con l’idea di una scheda da usare per scopi “accademici” ma poi la notevole diffusione ne ha fatto qualcosa di più, questo anche perchè la sua “completezza” (scheda video, porte usb, ecc.) hanno ingolosito gli utenti meno esperti ma anche quelli più smaliziati.

Per capire di cosa stiamo parlando, vi riporto di seguito le caratteristiche specifiche di questa Raspberry PI 2:

  • CPU quad-core ARM Cortex-A7 900MHz
  • 1GB LPDDR2 SDRAM
  • Retrocompatibilità con la Raspberry Pi 1

Per quanto riguarda invece il succo della notizia, ovvero la disponibilità di una versione di Windows 10 per Raspberry PI 2, chi è interessato all’argomento (e magari vuole comprare una scheda per divertirsi un po’) deve andare sul sito di WindowsOnDevices e da lì poi seguire le indicazioni per associarsi al programma “Windows Developer Program for IoT”.
In questo modo si riceveranno tutte le informazioni in merito ai prossimi rilasci del programma (tra cui quello di Windows 10 per Raspberry PI 2).
Sicuramente sarà molto interessante dare un’occhiata a questa versione, anche in virtù del fatto che su di essa sarà possibile far girare le Universal App.

Ultimamente su dotNET{podcast} abbiamo parlato di IoT, ma sicuramente questo sarà uno dei prossimi argomenti che tratteremo.

Il tempo che mi rimane, tra lavoro, podcast e altre attività (famiglia inclusa), è veramente esiguo e per questo a casa ho ferme da un pezzo una Netduino 2 e una Intel Galileo (so che sono cose diverse, ma per me rientrano “ignorantemente” nella stessa categoria), ma questa notizia ha ravvivato l’interesse per un mondo che conosco poco, e che a mio avviso rappresentano il fronte tecnologico che avrà maggior sviluppo nei prossimi anni.

Magari questo post serve a ricordarmi che devo riprendere in mano la situazione :-)

Windows 10 per Raspberry PI 2 arriverà presto e sarà gratis

Differenza tra cast esplicito e uso del comando ‘as’

Per effettuare una conversione da un tipo A ad un tipo B, si può pensare di eseguire un cast esplicito:

 A a = new A();
 B b = (B)a;

oppure si può utilizzare il comando ‘as’:

 A a = new A();
 B b = (a as B);

Tuttavia le due tipologie di conversione sono differenti per comportamento, per valore di ritorno e anche per istruzioni del compilatore utilizzate.

Andiamo a vedere queste differenze:

  1. innanzitutto il cast esplicito ritorna una exception in caso di errori nella conversione, mentre nello stesso caso il comando ‘as’ ritorna semplicemente un valore null
  2. anche in virtù del punto 1, in caso di utilizzo del comando ‘as’ è necessario che il tipo B del nostro esempio sia sempre un reference type o almeno un nullable type (come ad esempio int?), mentre nel caso del cast esplicito questo non è necessario
  3. con il cast esplicito è possibile utilizzare conversioni definite dall’utente nella class (user-defined conversions, per esempio nel caso di due classi senza nessuna relazione tra loro), mentre con il comando ‘as’ questo non è consentito
  4. infine, scendendo al livello dell’Intermediate Language (IL), le istruzioni utilizzate (OpCode) sono diverse, infatti mentre un cast esplicito viene tradotto in IL con l’istruzione ‘castclass’, per il comando ‘as’ si fa ricorso all’istruzione ‘isinst’

Sebbene in alcuni casi l’uso del comando ‘as’ possa risultare leggermente più veloce rispetto al cast esplicito, la scelta dell’uno o dell’altro sistema dipende molto dallo scenario in cui è necessario effettuare la conversione.

Differenza tra cast esplicito e uso del comando ‘as’

dotNET{podcast}

Tra pochi giorni sarà Natale e pensando ai mesi scorsi mi sono ritrovato a ricordare di quando, ai primi di agosto, ero in treno verso il lavoro, ascoltando come spesso accade uno dei podcast in lingua inglese che riguardano le tecnologie Microsoft. In quell’occasione mi chiesi come mai non avessi mai trovato un simile podcast ma italiano. Indagando capii che la motivazione era semplice: non esisteva.

Così, mosso dal mio solito e a volte eccessivo entusiasmo, pensai “beh, se non c’è lo facciamo, qual è il problema?” e così ne parlai con Antonio e con Massimo, due che oltre ad essere miei cari amici condividono con me la passione per lo sviluppo software con le tecnologie Microsoft, e dal loro ulteriore entusiasmo intesi che forse si poteva veramente fare.

Nel giro di un paio di giorni, feci un “sondaggio” tra i possibili ospiti, chiedendo loro telefonicamente o via Skype se gli piacesse l’idea di partecipare ad un podcast del genere, e con mia piacevole sorpresa, furono tutti immediatamente disponibili, qualcuno arrivò addirittura a farci i complimenti per quell’idea.

E così partimmo, incoraggiati dalla quantità e soprattutto dalla qualità delle persone che potevamo intervistare, e cominciammo a studiare come fare, quali tecnologie utilizzare per il sito, quali prodotti per la registrazione ed il montaggio, e tutti e tre eravamo entusiasti dell’idea. Tanto entusiasti da riuscire in un mese e mezzo a mettere su praticamente due siti, il “portale” e “l’amministrazione” dello stesso, progettando nel frattempo anche i loghi, trovando le musiche adatte, imparando a montare, capendo come tracciare tutto, partendo assolutamente da zero.
Attività frenetiche, fatte di tantissime piccole e grandi attività, che solo grazie all’aiuto di un bellissimo strumento per la condivisone delle informazioni, quale è Microsoft OneNote, abbiamo potuto organizzare e portare a termine quotidianamente.

Le prime puntate furono subito molto incoraggianti, e l’entusiasmo dei nostri ospiti ci aiutò tantissimo, perchè credetemi, siamo in tre ma per poter realizzare quell’ora di podcast a settimana lavoriamo veramente sodo, perchè ovviamente si tratta di un “secondo lavoro”, e in certi mesi abbiamo dormito veramente poco per portare avanti questa piccola, grande avventura, e tutto viene fatto con le nostre sole forze.

Abbiamo avuto anche il grandissimo piacere di ricevere il supporto da parte di OverNet, grazie alla quale siamo stati ospiti al WPC del novembre scorso, una delle più grandi conferenze italiane per le tecnologie Microsoft. Il loro grandissimo sostegno, unito a quello degli amici di Microsoft che abbiamo incontrato (e anche intervistato) in quella occasione, ci hanno dato e ci danno grande energia per continuare e fare sempre il meglio possibile per realizzare un prodotto di qualità.

La strada da fare è ancora molto, ma molto lunga, e non sappiamo neanche dove e a cosa, eventualmente, ci porterà. Ma quella che abbiamo fatto finora insieme a tutti i nostri ospiti, ai nostri ascoltatori, agli amici di Microsoft e a tutti quelli che ci stanno accompagnando, è una strada molto affascinante, fatta di condivisione, di conoscenza, di pazienza e di curiosità. Ed è questa la strada che vogliamo fare, è questo il viaggio che ci piace.

La condivisione è alla base delle community, dell’amicizia, e della passione verso questo lavoro, quest’ultima particolarmente difficile da trovare e sempre più da coltivare. E non importa se non ci si guadagna niente e anzi ci si rimette, perché la soddisfazione che ne deriva è tale che ripaga tutto il resto. Come dicevo oggi via Skype ad un nostro prossimo ospite, “tutto quello che facciamo è importante se e solo se è importante per qualcun altro”.

Il sito in questione è dotNET{podcast}, speriamo di potervi vedere sempre più numerosi a interfacciarvi con noi tramite i commenti sul sito, o tramite il gruppo Facebook o anche su Twitter. In futuro i canali potrebbero aumentare, e di sicuro il sito evolverà con nuove sorprese, di cui ovviamente su questo blog non parlerò, almeno per il momento.

In chiusura di questo post vorrei inviare un sincero e profondo “grazie” ad Antonio Giglio e Massimo Bonanni, miei inestimabili amici, soci e (spesso) vittime della mia irruenta voglia di fare.
Lo so, sopportarmi non sempre è facile, ma penso che dovrete rassegnarvi, perché bisognerà farlo ancora (speriamo) per parecchio, parecchio tempo.

Buon Natale.

dotNET{podcast}

Designing APIs for the Web (Mike Amundsen, O’Reilly Media)

I have had the opportunity to follow the course “Designing APIs for the Web” in which the lecturer is Mike Amudsen, who talks about Design Considerations, Tooling, and Implementation Models with SOAP, HTTP, and REST.

It is a really interesting course, more and more interesting that I actually could suppose.

It represent a great journey between the aspects to consider when API layer is required in an organization, even if this is targeted to a product or a service, as for internal as for external use.

Mike Amudsen is a very clear lecturer and his ability to explain complex topics as simple concepts makes this course really impressive.

The course is well structured in chapters, and every one of these are independent and not strictly related to others, so everyone can be viewed and viewed again singularly, and everyone affronts and explains a single slice of the whole cake of arguments.

Mike is able to explain with very simple words, explaining a lot of concepts and behavior to have or to avoid when anyone need to clearly have in mind when implementing APIs.

After listening any chapter, your first impression could be: “but, wait, he’s talking about good sense, he’s talking of organization, all of these things are obvious!” but in second step, when you realize that all of these “obvious” concepts are so easily neglected in every day’s work, at the end you will think: “That’s great!”.

I would recommend this course to designers and architects that are meaning to implement an API layer for their products or services, even if any developer can benefit of this knowledge in every day’s work.

It was really a great experience for me “attending” at this course, and I think I surely will return back to view some chapters from a while to while, because in my opinion these are very well-done lessons!

If you are interested, you can find the course here.

Designing APIs for the Web (Mike Amundsen, O’Reilly Media)

Connettere OneDrive in una Universal App

Con l’Update 2 di Visual Studio 2013 sono state introdotte le Universal App, una nuova tipologia di soluzione che consente di implementare una app sia per Windows Phone 8.1 che per Windows 8.1 contemporaneamente.

Senza entrare nel dettaglio di cosa sono le Universal App (nel caso non sappiate di cosa parliamo potete far riferimento a questo link per una introduzione), nel post di oggi ci focalizzeremo su come implementare al suo interno il collegamento con OneDrive.

Spiegheremo come creare una pagina di “settings” che funzioni sia nel progetto per Windows Phone che nel progetto per Windows Store, centralizzando così il punto di collegamento della soluzione (e degli applicativi) con OneDrive.

Per questo post ho fatto riferimento ad alcuni altri che indicherò di seguito come riferimenti, per poi modificarli e ottenere il risultato voluto.

Componenti da installare

Prima di procedere con la spiegazione, verificate che siano installati i seguenti componenti, necessari per poter eseguire il collegamento:

Ricordatevi che per sviluppare questo tipo di applicazioni, dovete lavorare con il sistema operativo Windows 8.1, altrimenti su altri sistemi (es. Windows Server) non potreste non avere la possibilità di farlo, almeno per il momento.

Nel nostro caso faremo uso della versione Express di Visual Studio 2013, con l’update 2 già installato.

Creazione del progetto

In Visual Studio 2013, bisogna creare una Universal App selezionandola tramite il menù File > New > Projects > Visual C# > Store Apps > Universal Apps > Blank App e dandogli un nome di comodo, ad esempio “OneDriveDemo“. Per la demo la Blank App sarà più che sufficiente.

Associazione del progetto

Per il corretto funzionamento del collegamento, è necessario che la app Windows 8.1 venga “associata” con una app nello Store, in questo modo sarà possibile in alcuni punti accedere alle informazioni dell’utente e del suo Microsoft Account. Del resto questa operazione andrà comunque fatta per poter poi pubblicare la vostra app.
Per eseguire questa associazione è sufficiente che dalla vostra soluzione, facciate Tasto destro sul progetto Windows 8.1 > Store > Associate App with the Store… e seguiate le istruzioni, per utilizzare la vostra app esistente o per farvi riservare il nome per la vostra nuova app.

 

Riferimenti e UI condivisa

Nel progetto shared della nostra soluzione centralizzeremo tutta la logica per poter eseguire il collegamento. In questo stesso progetto creeremo la pagina di settings condivisa tra le app Windows Phone e Windows Store.

Prima di tutto, aggiungiamo le reference al “Live sdk”, dobbiamo farlo sia nel progetto Windows 8.1 che nel progetto Windows Phone 8.1. Nel progetto shared non è possibile referenziare librerie esterne, perchè utilizzerà le reference del progetto per il quale è in esecuzione in quel momento.

Quindi andiamo prima nel progetto Windows 8.1 e poi nel progetto Windows Phone 8.1 e facciamo tasto destro su References > Add Reference > [Windows 8.1 o Windows Phone 8.1] > Extensions > mettiamo il check su Live SDK (version 5.6) > OK


Quindi possiamo procedere con la creazione della porzione di pagina di settings condivisa tra i due progetti. Lo faremo creando, sempre nel progetto shared, uno UserControl che chiameremo OneDriveSettingsUserControl.

Il codice contenuto non è molto complesso, si tratta dello stretto necessario per il login / logout:

 

 

 

 

 

 

 

 

 

 

 

Inizialmente non vedremo nulla nello user control appena creato perchè la label è vuota e i pulsanti sono nello stato Collapsed, il che li nasconde anche nell’editor grafico.

Temporaneamente ci conviene creare, per non avere problemi di compilazione, degli handler per l’evento di click dei bottoni, che dopo sostituiremo con il codice definitivo. Per fare questo andiamo prima sul metodo Click=”SignInClick” e poi sul metodo Click=”SignOutClick” e facciamo su ognuno tasto destro e poi Go To Definition F12, in questo modo Visual Studio creerà per noi degli handler vuoti associati agli eventi di click.

A questo punto possiamo cominciare col codice vero e proprio per la connessione a OneDrive.

Logica di business

Dato che la logica sarà posizionata nel progetto shared, ci conviene creare una classe apposita per contenere la business logic. Nel nostro esempio abbiamo creato una classe OneDriveBL.cs, in cui creeremo i seguenti metodi statici:

  • CheckOrSignIn
    • esegue l’operazione di sign in e/o verifica lo stato di connessione
  • VerifyIfUserCanSignOut
    • verifica se l’utente è connesso e può eseguire il sign out
  • SignOut
    • verifica se l’utente è connesso ed esegue il sign out

Il risultato è quanto segue:

 

 

 

N.B. abbiamo utilizzato in questo esempio il livello di permission “wl_basic”, potete trovare qui i vari livelli disponibili

 

 

A questo punto possiamo cominciare a far funzionare il nostro user control tramite l’utilizzo di questa classe.

Implementiamo nello user control i seguenti metodi:

  • UpdateControls
    • si occupa di gestire lo stato dei control presenti (verrà richiamato da vari punti del codice) ovvero si occupa di visualizzare o nascondere i pulsanti in funzione dello stato di connessione o disconnessione dell’utente
  • ManageStatus
    • si occupa di gestire o verificare lo stato della connessione
    • tramite un parametro Nullable<bool> può eseguire tre azioni differenti:
      • verificare lo stato della connessione
      • avviare il sign in
      • eseguire il sign out
    • richiama proprio il metodo UpdateControls

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Adesso possiamo implementare sul costruttore la verifica dello stato di connessione, e sugli event handlers che prima abbiamo creato vuoti possiamo eseguire le richieste per il sign in e il sign out.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ah, finalmente! Il grosso è fatto (o almeno si spera). Ora “resta solo” da realizzare le pagine di settings. Partiamo con quella per Windows 8.1.

 

Creazione del flyout di settings per Windows 8.1

Dobbiamo aggiungere lo user control creato nei settings della nostra (futura) app per Windows 8.1. Per fare questo creiamo un SettingsFlyout, che altro non è che (banalizzando) una pagina che viene contenuta nel flyout dei settings (ricordiamo che il termine Flyout in Windows 8+ riguarda indica in questo caso un control specifico che viene visualizzato quando eseguiamo lo swipe con il dito dal lato destro dello schermo).

Una volta creata (e registrata opportunamente) questa “pagina”, la ritroveremo tra le “voci” dei settings della nostra applicazione, secondo le linee guida per lo sviluppo di app per Window 8.1.

 

 

Nel SetttingsFlyout dovremo:

  • cambiare il titolo in OneDrive
  • sostituire l’intero contenuto con una istanza dello user control creato

Il risultato sarà questo:

 

 

 

 

 

 

 

 

 

 

 

Ora il flyout va “registrato” nell’elenco di voci da presentare sul settings di Windows, ovviamente per l’app che lo contiene.

Per fare questo dobbiamo agire nella classe App.xaml.cs, ricordandoci una cosa importante riguardante le Universal App cioè che il codice destinato alla sola applicazione Windows 8.1 va incluso in una direttiva di compilazione WINDOWS_APP che indica al compilatore che quel blocco di codice incluso nella parte shared va considerato solo nel momento in cui si compila la Windows 8.1 app. Discorso identico, con la direttiva WINDOWS_PHONE_APP va fatta per le parti di codice che vanno compilate solo per Windows Phone 8.1. Le parti comuni, cioè che vanno considerate sia per la Windows 8.1 app che per la Windows Phone 8.1 app, semplicemente non vanno incluse in alcuna direttiva.

La “registrazione” di cui parlavamo (io uso il termine registrazione solo per convenienza, non è questo un termine della nomenclatura ufficiale) avviene tramite l’override dell’evento OnWindowCreated, tramite il quale indicare che al momento della richiesta dei settings va incluso anche il nostro flyout. Ricordiamoci che, quando necessario, anche le using vanno incluse nelle direttive di compilazione.

Il risultato è quello che segue:

 

 

 

 

 

 

 

 

 

 

 

 

 


Proviamo a lanciare in debug l’app con F5 sulla Local Machine e otterremo quanto segue:

 


 

 

 

 

Creazione della pagina di settings per Windows Phone 8.1

Questa volta ci dobbiamo occupare dei settings per Windows Phone 8.1, in questo caso non è prevista da sistema una modalità di settings specifica, per cui mostreremo come creare una pagina in cui sia presente lo user control che abbiamo realizzato. La decisione sul dove posizionare questa pagina resta al developer dell’app.

Nel nostro esempio utilizzeremo direttamente la pagina iniziale della app per mostrare lo user control che abbiamo creato:

 

 

 

 

 

 

 

 

 

 

 

Il risultato ottenuto sarà questo:

 

 

 

Lanciamo l’app per Windows 8.1

In questo esempio proveremo a lanciare l’app per Windows 8.1, ma lo stesso procedimento vale anche per Windows Phone 8.1.

Andiamo nei settings che abbiamo implementato e premiamo il pulsante di Sign in, ci verranno richieste le credenziali di un Microsoft account:

 

 

 

Una volta completato il sign in, viene mostrata una schermata che mostra le permission richieste per l’accesso a OneDrive:


 

 

 

Ora l’app risulta autenticata con OneDrive e potrà quindi utilizzare le API disponibili per eseguire le azioni disponibili per il livello di permission utilizzato durante il sign in.


 

 

 

A questo link trovate il codice implementato, potrebbe non compilare perchè sono stati rimossi i riferimenti allo store, in ogni caso il codice di questo post c’è tutto.

 

 

 

Riferimenti

 

 

Connettere OneDrive in una Universal App