Tocca vedere Node.js

Dopo aver registrato il podcast con Ugo Lattanzi su Node.js, ho cominciato a cconsiderare l’idea di approfondire di più le mie conoscenze su questo framework, veramente molto diffuso nel mondo dello sviluppo web.

Devo dire, usando le parole di Ugo, che si tratta di “tanta roba”, ma probabilmente ne vale la pena, se vogliamo “allargare” gli orizzonti delle nostre competenze in ambito “cross-platform”, in attesa che .NET Core 1.0 venga completato e supporti completamente questo scenario.

Nei prossimi giorni quindi proverò a capirci qualcosa in più e condividerò quello che avrò capito, nel frattempo ascoltatevi la puntata del podcast che Ugo che è veramente molto istruttiva.

Annunci
Tocca vedere Node.js

Agganciare Application Insights ad un progetto esistente in ASP.NET MVC

In un precedente post avevo illustrato come fare per utilizzare Application Insights in un progetto ex-novo basato su tecnologia ASP.NET MVC.

In questo post andremo invece a vedere come possiamo utilizzare Application Insights in un progetto già esistente, sempre basato su ASP.NET MVC.

Ricordo che per usare le comode funzionalità presenti in maniera integrata in Visual Studio è necessario usare la versione 2013 Update 3 o la versione 2015.

Andiamo quindi su un progetto già esistente, basato su ASP.NET MVC in Visual Studio 2015.

Anche in questa situazione si può aggiungere velocemente e con pochi click Application Insights al progetto, facendo semplicemente tasto destro all’interno del Solution Explorer sul nodo che rappresenta il nostro progetto, e quindi utilizzare la voce “Add Application Insights Telemetry…” che troveremo nel menù contestuale:

IMG08

Ci verrà proposta una dialog in cui verranno richieste le informazioni da utilizzare per creare una nuova risorsa Application Insights su Azure, o per utilizzarne una che abbiamo già creata, alla stregua di quanto avviene nel caso in cui partivamo con un progetto da zero:

IMG09.png

Una volta creata la nuova risorsa Application Insights (o agganciata una già esistente) saremo nella stessa situazione del post in cui partivamo da un progetto ex-novo, quindi dovremo inserire lo script JavaScript della nostra risorsa Application Insights nella “master page” di MVC, ovvero nel file _Layout.cshtml.

Nel prossimo post mostrerò come utilizzare risorse Application Insights distinte per separare l’ambiente di sviluppo e debug da quello di produzione.

Agganciare Application Insights ad un progetto esistente in ASP.NET MVC

Utilizzare Application Insights in un nuovo progetto ASP.NET MVC

Ore che stiamo cominciando a conoscere Microsoft Application Insights, e dopo che ne abbiamo cominciato a vedere le prime nozioni di base, possiamo parlare di sviluppo.

In questo post voglio far vedere la semplicità con cui possiamo usare Application Insights in un progetto ASP.NET MVC nel caso di un nuovo progetto, nel successivo post mostrerò anche il caso di un progetto già esistente in cui la telemetria di Microsoft non era stata prevista sin dall’inizio.

Ricordo che per usare Application Insights non è necessario per forza usare Visual Studio e pensare allo sviluppo con il .NET framework, dato che l’elenco di SDK , per vari linguaggi e piattaforme, è molto variegato.
Nel nostro esempio, per semplicità andremo sugli ambienti a me più familiari. Infatti con Visual Studio 2013 (service pack 3) o Visual Studio 2015, la piattaforma di Application Insights si può trovare già integrata e pronta all’uso (in termini di librerie per lo sviluppo).

Prima di proseguire, accertatevi di avere una subscription attiva su Azure, come vi avevo già spiegato.

Partiamo quindi con un progetto ex-novo, basato su ASP.NET MVC su Visual Studio 2015.

Da Visual Studio 2015 facciamo, come sempre, File > New > Project… > Web > ASP.NET Web Application per partire con un nuovo progetto ASP.NET MVC.

IMG01

Come potete notare dall’immagine sopra, sul lato destro della dialog di creazione di un nuovo progetto trovate già un check che ci consente l’utilizzo di Application Insights all’interno del progetto che stiamo andando a creare.
Chiaramente se non vogliamo che il nostro progetto usi la telemetria si può anche deselezionare.

Nel nostro caso lo lasciamo selezionato e subito sotto andiamo a configurare l’account, sottoscrizione e risorsa di Azure da usare per la creazione di questa telemetria.
Lascio a voi le prove per la configurazione, magari utilizzando anche la voce “Configure settings…” presente sempre tra i parametri, è talmente semplice da fare in autonomia che spiegarlo nel dettaglio non serve.

L’unica cosa da fare è scegliere il tipo di progetto web e attendere quei 20-30 secondi necessari per la configurazione automatica.

Importante sapere che se avevate già creato su Azure una risorsa Application Insights e volete utilizzare quella per la telemetria, potete sempre selezionarla nel menù a tendina che trovate in questa dialog.

Nel caso più comune, possiamo crearne una nuova e lasciare a questo wizard il compito di generare tutta l’infrastruttura necessaria sul cloud, operazione che richiede in genere circa 20-30 secondi, quindi sicuramente più veloce di quello che impiegheremmo noi a crearla dal portale di Azure.

Al termine di questa operazione avremo il nostro progetto creato e la risorsa Application Insights creata e pronta all’uso.

All’interno del nostro progetto troveremo un file ApplicationInsights.config, che di fatto è un xml così come lo è il classico web.config, in cui troveremo tutte e sole le informazioni relative alla risorsa Application Insights che utilizziamo nel nostro progetto.

IMG02

All’interno di questo file troveremo una serie di informazioni che andremo ad analizzare in un post successivo.

Intanto la cosa che ci serve subito indicare è la Instrumentation Key, che è di fatto la “chiave” identificativa univoca della nostra risorsa Application Insights:

 IMG03.png

Se volessimo quindi un giorno cambiare la risorsa Application Insights da utilizzare per la nostra telemetria, sarebbe qui che dovremmo intervenire una volta creata una nuova risorsa sulla nostra sottoscrizione Azure.

Passo successivo: importazione dello script JavaScript di Application Insights.

A questo punto la nostra applicazione web è “quasi” pronta, nel senso che adesso sa “dove” inviare le informazioni che verranno raccolte e catalogate, ma non sa ancora “quali” informazioni inviare.

Si, perchè se non l’avete ancora capito, le informazioni che troverete su Application Insights sono inviate dalla vostra applicazione, e non si generano in automatico per magia…

Per quanto riguarda i sistemi di telemetria, o Web Analytics, come lo è appunto Application Insights (e come lo è, giusto per fare un esempio magari più noto, Google Analytics), la prima cosa che fanno nella maniera più semplice del mondo, è quella di raccogliere informazioni sulle pagine visitate e altre info quali, ad esempio, la provenienza delle chiamate, il tipo di dispositivo, ecc.

Questa è la prima cosa che si fa in questi sistemi di telemetria, di solito usando un semplice script JavaScript da inserire nelle pagine da monitorare.
E infatti lo possiamo fare anche con Application Insights.

Questa operazione non avviene in automatico ed è una delle poche cose da fare subito da soli una volta impostato il nostro progetto.

Per copiare il nostro script a questo punto dobbiamo andare sul portale di Azure all’indirizzo:

https://portal.azure.com

IMG04.png

Selezionando dall’elenco a sinistra la voce “Application Insights”, vi verranno mostrate le risorse di telemetria che avete nella vostra sottoscrizione, selezionando quella che riguarda il progetto appena creato avremo una vista del genere:

IMG05.png

Come potete vedere nell’immagine sopra, vi verranno mostrate tutta una serie di informazioni relative alla risorsa Application Insights che avete utilizzato.
La semplicità di utilizzo della dashboard di Azure vi aiuterà moltissimo a trovare tutto quello che vi serve per la telemetria, di questo aspetto ne parleremo in seguito.

Per i nostri scopi, ovvero trovare lo script JavaScript da utilizzare, possiamo andare alla sezione dei settings (tramite la label “Settings and Diagnostics” che trovate nel “blade” centrale (ricordo che i “blade” in Azure sono le “sezioni” che man mano si aprono a destra dell’item che selezioniamo), e una volta selezionato quello, a destra andate nella sezione “Getting started”, quindi scegliere “MONITOR AND DIAGNOSE CLIENT SIDE APPLICATION” e arriveremo a trovare lo script che vediamo di seguito:

IMG06.png

Come vedete dall’immagine, si tratta di uno script JavaScript che possiamo copiare velocemente nella nostra clipboard utilizzando il tastino sopra evidenziato, a quel punto possiamo copiarlo nelle pagine del nostro progetto ASP.NET MVC che stavamo preparando.

La cosa più veloce da fare, di solito, è quella di mettere lo script nella “master page” del progetto, per far si che ogni pagina venga tracciata senza doversi preoccupare di ripetere lo script in ogni nuova pagina della nostra applicazione.

Per quanto riguarda ASP.NET MVC, la “master page” è rappresentata dalla pagina (o view) _Layout.cshtml, in cui a questo punto possiamo posizionare il codice appena copiato:

IMG07

Da questo momento in poi, le visite alle nostre pagine verranno tracciate su Application Insights, e potremo sempre verificare quali tipo di device o browser ha visitato la pagina e quando lo ha fatto ed altre informazioni a riguardo.

Personalmente sono solito mettere lo script in una partial view ad hoc (ad esempio chiamandola “_ApplicationInsights.cshtml”) e aggiungere la partial view nella _Layout.cshtml, ma è solo una questione di “leggibilità” del codice, non c’è nessun vantaggio pratico nel farlo.

Un paio di cose da ricordare prima di chiudere:

  • con la situazione appena descritta, qualora dovessimo cambiare la risorsa Application Insights da utilizzare, si dovrebbe cambiare la Instrumentation Key sia nel file ApplicationInsights.config che nella _Layout.cshtml, a meno di far si che da quest’ultimo file la chiave venga passata tramite Razor
  • i dati inviati in fase di sviluppo e debug saranno “fasulli”, quindi allo scopo del nostro business non saranno dati utili, è quindi molto più saggio (e direi necessario) usare due risorse distinte di Application Insights, una per lo sviluppo, e una per la produzione

Per entrambi i punti sopra descritti, scriverò un post apposito per la gestione di più environment applicativi, in cui entrambi i punti saranno risolti. Ma abbiate pazienza ancora qualche giorno per leggerlo…

Intanto cominciate a dare un’occhiata a quello che vi ho detto, probabilmente troverete tutto ancora più semplice anche di come ve l’ho descritto io… 😉

 

Utilizzare Application Insights in un nuovo progetto ASP.NET MVC

Podcast su TypeScript

Torno a scrivere dopo un “letargo” considerevole (causa lavoro, straordinari, community, ferie, tanto cibo, dieta, lavoro, ecc.)…

Oggi voglio segnalare un interessante podcast su dotNET{podcast} che abbiamo registrato con Alessandro Giorgetti e in cui parliamo di TypeScript.

Sulla scheda della puntata ci sono anche dei link interessanti per approfondire l’argomento.

Nella promessa che tornerò a scrivere altri post su TypeScript, nel frattempo ascoltate questo podcast e se avete commenti da fare segnalateceli sempre sulla pagina della puntata.

Podcast su TypeScript

Typescript, questo sconosciuto

Ultimamente ho cambiato nuovamente lavoro, e nella nuova azienda dove lavoro adesso sto facendo una interessante esperienza con Typescript.

Molti di voi (come me fino a qualche settimana fa), non sa cosa sia Typescript, e siccome sto ancora cercando di capirne qualcosa, ho pensato di condividere con voi questa mia recente esperienza, magari potrà tornare utile a qualcuno.

Cos’è Typescript

Innanzitutto, spieghiamo a grandi linee di cosa si tratta.

Typescript è un “metalinguaggio” creato da Microsoft, e reso disponibile in open source, per scrivere codice javascript avanzato e soprattutto “compilabile”.

Questa mia personalissima definizione racchiude in una sola riga un concetto di linguaggio che, una volta assimilato, si potrebbe rivelare utile in moltissime situazioni.

Ovviamente non voglio riscrivere quello che trovate sul web, che non è tantissimo (a mio modesto parere) ma è sufficiente per iniziare a studiare questo linguaggio, per cui cercherò di sintetizzare le basi “principali” su cui si fonda in pochi bullet:

  • Supporto per interfacce, classi e enum
  • Supporto per ECMAScript 6
  • Compilazione a design time
  • Tradotto in javascript standard alla compilazione

Si, lo so che qualcuno che l’ha già studiato sa che ci sono altri punti, ma per me questi sono i primi punti di forza da cui vorrei partire.

Ho sentito qualcuno definire Typescript una sorta di “C# portato nel mondo Javascript”, personalmente questa definizione non mi piace, preferisco pensare a Typescript come ad una naturale evoluzione di Javascript per scenari enterprise, ovvero la necessità primaria per cui è nato questo linguaggio.

In che scenari usare Typescript

Quanti di voi hanno perso ore ed ore nel “debuggare” javascript malfunzionanti per poi scoprire che mancava una maledetta virgola o un apice, insomma qualcosa che impediva al browser di eseguire correttamente quel blocco di codice, di cui l’ambiente di sviluppo non aveva dato alcuna notizia a design time?

E quanti di voi si sono trovati quintalate di script mischiati e ricaricati senza ritegno in ogni pagina della vostra applicazione?

Beh, è chiaro che Typescript non annullerà tutta la complessità dello sviluppo frontend, ma di sicuro allevierà buona parte delle problematiche, fosse solo per il fatto che possiamo “compilarlo” e quindi sapere subito prima dell’esecuzione se qualcosa che abbiamo scritto è formalmente sbagliato.

Come già detto, una delle necessità per cui si è pensato a Typescript è lo sviluppo in scenari “Enterprise“, in cui applicazioni molto complesse e/o basate su architetture che necessitano di una forte dose di scalabilità, spesso devono fare i conti con Javascript, che porta la sua bella dose di entropia.

Per esempio, io lo sto usando in una soluzione (o meglio, una serie di soluzioni) mirate al rifacimento dello sportello bancario di un grosso istituto di credito italiano. In questo scenario una applicazione SPA (Single Page Application) fa da frontend verso altre componenti della soluzione, e questo frontend è a sua volta molto complesso a livello architetturale.

Nella soluzione che ho io, i datacontract che vengono esposti da servizi vengono poi rimappati in Typescript per la gestione di un viewmodel con Knockout.js.

Oltre alla scalabilità, anche la manutenibilità, la testabilità e la leggibilità beneficiano di questo linguaggio, presentato ormai già da cinque anni.

Da dove partire

Sicuramente dal sito Typescriptlang.org dove tutto è spiegato e dettagliato. Ci sono tutorial, esempi, e c’è anche una sezione “play” dove si può appunto “giocare” con il codice, provando subito porzioni di script senza dover avere un progetto Visual Studio aperto.
Per chi ha delle sottoscrizioni Pluralsight, ci sono un paio di corsi online, per chi non ce l’ha, segua dotNET{podcast}, perché metteremo “in palio” anche questo tipo di regalo.

Prossimi post

Per adesso mi fermo, volontariamente, per non fare un post troppo lungo. Preferisco scriverne altri, magari meglio focalizzati su Typescript, perché può tornare molto utile, anche su progetti di dimensioni più piccole. E mentre lo imparerò (o proverò a farlo) condividerò quanto ho capito di questa “evoluzione” del linguaggio di scripting più usato per lo sviluppo web.

Typescript, questo sconosciuto