Aurelia e ASP.NET Core: hello Aurelia!

Questo post fa parte di una serie dedicata ad Aurelia e ASP.NET Core:

Quando ormai il morale della ciurma cominciava a vacillare, ecco finalmente un urlo straziato dalla coffa: Aurelia!!!

Ebbene sì, siamo giunti finalmente al punto in cui siamo pronti ad aggiungere Aurelia al nostro progetto utilizzando ovviamente NPM e JSPM.

Aggiungere NPM

Per prima cosa dobbiamo quindi aggiungere NPM e, con il supporto fornito da Visual Studio, la cosa è estremamente facile. Ci è sufficiente aggiungere un nuovo npm Configuration File al progetto, di tutto il resto si occupa l'ambiente di sviluppo:

Il file – package.json - è di per se stesso abbastanza scarno e possiamo per ora concentrare la nostra attenzione sulla sezione devDependencies dove è possibile specificare le dipendenze da quei pacchetti che sono utili nella fase di sviluppo del progetto, esattamente il caso di JSPM:

Aggiungere JSPM

L'aggiunta di JSPM è infatti ancora più semplice: come abbiamo visto qualche post fa per il nuovo project.json – che contiene le dipendenze NuGet (ma non vi abituate troppo, in Visual Studio 2017 andrà purtroppo in pensione prematura) – anche package.json supporta l'editing manuale con Intellisense, per cui tutto quello che dobbiamo fare è digitare "jspm" all'interno della sezione devDependencies e selezionare la versione che ci interessa referenziare (al momento la 0.16.48). In seguito al salvataggio del file, Visual Studio si occuperà di scaricare il pacchetto e le eventuali relative dipendenze:

Con un po' di pazienza avremo alla fine JSPM elencato tra le dipendenze del progetto. Al momento vi sconsiglio di cliccare sulla freccia accanto al pacchetto JSPM, perché è come aprire il vaso di Pandora (e non fate come Julia Roberts in Nothing Hill… non aprite quella porta):

Aggiungere Aurelia

JSPM deve essere configurato prima di poter essere usato, ma tale inizializzazione può essere fatta congiuntamente con il download del primo pacchetto, ed è esattamente ciò che faremo.

Visual Studio non dispone (ad oggi) di un supporto nativo per JSPM come per NPM o Bower. Come conseguenza, l'installazione dei vari pacchetti dovrebbe essere fatta a riga di comando. In alternativa vi suggerisco di scaricare la comodissima estensione partorita dalla mente sempre viva di Mads Kristensen: si tratta in un Package Installer che consente di installare pacchetti da diverse fonti, wrappando in pratica le chiamate a riga di comando in una maschera semplice ma efficacie:

A seguito dell'installazione dell'estensione avremo disponibile una nuova voce Quick Install Package… nel menu contestuale del progetto (attivabile anche con lo shortcut Shift+Alt+0):

Clicchiamo sulla voce e nella maschera risultante selezioniamo JSPM come fonte, digitiamo "aurelia-framework" come pacchetto e clicchiamo infine su Install:

Come detto alla prima installazione sarà necessario configurare JSPM rispondendo ad una serie di semplici domande:

  • La prima domanda ci chiede se vogliamo registrare le proprietà di JSPM che saranno aggiunte al file package.json di NPM all'interno di un nodo jspm. Confermiamo l'impostazione di default ;
  • La seconda domanda ci chiede di indicare quale sia la web root del nostro progetto. Per quanto abbiamo detto in un precedente post è ovvio che per i progetti ASP.NET Core dobbiamo impostare ./wwwroot;
  • È la volta di configurare la cartella in cui JPSM scaricherà i pacchetti che aggiungeremo al progetto (come ad esempio in questo caso Aurelia). Il default è wwwroot/jspm_packages. Potete scegliere questa cartella secondo le vostre preferenze, io per ora imposterò wwwroot/_libs;
  • È ora il momento della posizione del file config.js che servirà a JSPM per gestire i pacchetti scaricati. Confermiamo il default wwwroot/config.js (e confermiamo anche la sua successiva creazione in automatico);
  • La sesta domanda ci chiede di indicare la URL con cui il nostro sito è esposto pubblicamente. Confermiamo il default /;
  • Siamo alla fine ed è sufficiente confermare il default anche per le ultime due domande: , vogliamo usare un transpiler (cioè un meccanismo per "invecchiare" il codice JavaScript in modo da renderlo compatibile con i browser più anziani) e in particolare vogliamo usare Babel.

Al termine della configurazione il download del pacchetto aurelia-framework (e di tutti i pacchetti da cui esso dipende, Aurelia è strutturato in maniera molto granulare, come ASP.NET Core) inizierà automaticamente:

Al termine del download, nella cartella _libs o in qualunque altra cartella voi abbiate scelto in fase di configurazione, potremo trovare i file JavaScript che compongono il cuore del framework Aurelia (un secondo vaso di Pandora che per ora ignoriamo come il primo).

Se vi accorgete che qualcosa non vi convince nel modo in cui avete impostato JSPM non è mai troppo tardi per tornare indietro. La configurazione è infatti disponibile in parte del file package.json di NPM e in parte nel file config.js di JSPM (che potrebbe ovviamente chiamarsi diversamente che avete scelto di modificare il nome di default).

Prima di poter vedere Aurelia in azione abbiamo bisogno di installare un secondo pacchetto chiamato aurelia-bootstrapper del quale avremo modo di parlare meglio in un prossimo post. Ormai sappiamo come fare: Shift+Alt+0 e via:

Hello Aurelia!

I preliminari sono finiti (il che vuol dire che tempo 5 minuti e saremo giunti alla conclusione): possiamo mettere in piedi la nostra demo. Come tutti i framework SPA, Aurelia ha bisogno di un punto di ingresso, una URL che venga servita da ASP.NET Core come una qualunque risorsa "server" e che contenga al suo interno il codice necessario al framework per mettersi in azione e prendersi carico delle successive richieste sul "client". Per il nostro esempio riutilizzeremo il file index.html, modificando il body per aggiungere il codice necessario ad attivare Aurelia:

Ci sono un po' di cose da notare in questo frammento di codice:

  1. Il primo tag script serve ad importare la libreria SystemJS che si occupa del caricamento asincrono on-demand dei vari moduli che comporranno la nostra applicazione (quelli di Aurelia, di altre librerie che potremmo voler usare come ad esempio Bootstrap e ovviamente quelli che scriveremo noi stessi per implementare la logica applicativa). Come detto in un precedente post, JSPM integra infatti le funzionalità di un package manager con quelle di un module loader per fornire una soluzione completa;
  2. Il secondo tag script serve ad importate il file di configurazione di JSPM che contiene alcune delle impostazioni che abbiamo selezionato in fase di inizializzazione e, soprattutto, l'elenco dei pacchetti aggiunti all'applicazione con il rispettivo albero di dipendenze;
  3. Il terzo tag script utilizza SystemJS per caricare il bootstrapper di Aurelia che si occuperà di caricare e attivare il framework;
  4. L'attributo aurelia-app con cui abbiano decorato il body serve infine ad indicare ad Aurelia in quale parte della pagina vogliamo caricare la nostra SPA.

Abbiamo già accennato nel post precedente che Aurelia è basato su MVVM. Non ci sorprende quindi che una "pagina" di Aurelia è composta da una View (un file HTML) e da un ViewModel (un file JavaScript). Come vedremo nei prossimi post questa coppia di elementi deve rispettare alcune semplici (e soprattutto logiche) regole nelle quali al momento non voglio addentrarmi perché dovremmo altrimenti ulteriormente rimandare il nostro F5 e finirei col perdere una certa scommessa con un certo personaggio.

Al momento limitiamoci a creare un nuovo file JavaScript app.js sotto wwwroot che funga da ViewModel con il seguente contenuto:

Anche la View (il file HTML app.html) sarà decisamente minimale:

In definitiva il nostro progetto dovrebbe alla fine essere strutturato più o meno così:

Siamo pronti! F5 e via:

Indubbiamente il risultato è quello atteso, ma è evidente che qualcosa di magico deve essere successo dietro le quinte perché quello che abbiamo scritto in index.html, app.js e app.html non è assolutamente sufficiente a garantire quello che vediamo. Se apriamo il DOM Explorer ecco come risulta l'HTML ricevuto dal browser:

Un bel po' di cose sono successe e alcune domande richiedono una risposta:

  • Come ha fatto Aurelia a capire che volevamo mostrare il contenuto della pagina app?
  • Che fine ha fatto il tag template che era nel file app.html?
  • Cos'è la strana sintassi che abbiamo usato nel file app.js?

Le risposte a queste domande si possono sintetizzare in tre concetti – convention-over-configuration, HTML5 standard e ES2016 – che saranno l'argomento principale dei prossimi post.

Happy coding!

 

P.S. Il codice sorgente è disponibile su GitHub, basta scaricare la release con lo stesso nome del post (Hello Aurelia! in questo caso).

Aurelia e ASP.NET Core: hello ASP.NET Core!

Questo post fa parte di una serie dedicata ad Aurelia e ASP.NET Core:

  1. la strana coppia;
  2. lo scheletro del progetto;
  3. NPM e i suoi fratelli;
  4. hello ASP.NET Core! (questo post);
  5. hello Aurelia!.

Ora che tutte le questioni legate alla maniera di referenziare le dipendenze lato client in un progetto ASP.NET Core sono chiare, possiamo finalmente cominciare a scrivere un po’ di codice nel nostro progetto.

Come tutti i progetti basati su framework SPA, un’applicazione web basata su Aurelia si realizza scrivendo pagine HTML e moduli JavaScript. Seguendo l’approccio MVVM (che è alle fondamenta di Aurelia e di cui parleremo in un prossimo post), le pagine HTML saranno le nostre View (conterranno cioè gli elementi grafici che saranno mostrati all’utente), i moduli JavaScript i nostri ViewModel (conterranno cioè i dati con i quali le viste saranno popolate con le informazioni utili all’utente).

Per ingraziarci i favori degli dei della programmazione, non possiamo che partire dal solito classico esempio: Hello World! Ovviamente nel nostro caso, pur usando ASP.NET Core, sarà un esempio in puro HTML.

Ripartiamo dal progetto creato un paio di post fa, e aggiungiamo il file index.html che, memori di quanto detto nello stesso post, salveremo nella cartella wwwroot e non in quella principale del progetto. Vogliamo infatti che questo file sia servito direttamente al client con una chiamata tipo http://hostname/index.html.

image

Ok, tutto sembra a posto, incrociamo le dita e premiamo F5. Visual Studio compila il progetto e apre il browser puntando alla root dello stesso (http://localhost:18156/). Ci aspetteremmo di vedere il nostro file caricato nel browser ma in realtà quello che otteniamo è la pagina seguente:

image

Potremmo pensare che si tratti di un problema di pagina di default: forse http://localhost:18156/ non viene risolto in http://localhost:18156/index.html per qualche problema di configurazione. Se però scriviamo nella barra degli indirizzi espressamente http://localhost:18156/index.html il risultato non cambia. In ogni caso non si capisce perché il server non ci restituisca un errore 404 (dando quindi l’impressione di trovare il file) ma ci serva poi un contenuto dalla provenienza ignota.

Niente panico, è tutto normale e corretto: nel mondo di ASP.NET Core, out-of-the-box abbiamo poco o nulla. Tutto quello che ci serve va aggiunto e configurato, compreso il fatto che l’applicazione serva i file statici presenti nella cartella wwwroot. ASP.NET Core non ci sta quindi servendo il file index.html (di base non sa come farlo) e questo è il motivo per cui i contenuto è diverso dalle aspettative.

Da dove viene allora il contenuto di cui sopra? Per trovare la soluzione facciamo un piccolo passo indietro e analizziamo un paio di file chiave in un progetto ASP.NET Core, che rappresentano quel poco che abbiamo out-of-the-box nel nostro progetto creato con il layout Empty.

Come prima cosa dobbiamo dire che in ASP.NET Core tutta la parte nascosta alla vista del programmatore che di fatto consentiva alla nostra applicazione di funzionare è – fortunatamente – sparita. Quando nel precedente post abbiamo descritto brevemente le novità di ASP.NET Core, ci siamo soffermati esclusivamente su quanto c’è di nuovo nel nostro progetto vuoto. In realtà chi è abituato a lavorare con ASP.NET avrà senza dubbio notato anche un’assenza abbastanza importante: in ASP.NET Core il file Global.asax è sparito e la parte di configurazione e inizializzazione che eravamo soliti scrivere nei quattro metodi di quella classe si trova ora nei file Program.cs e Startup.cs.

Il primo file, almeno nel nome, ha qualcosa di familiare. Se lo apriamo ci accorgiamo che non ci siamo sbagliati: sembra praticamente identico al file omonimo che viene creato in un’applicazione Console, con tanto di metodo static void Main. Se nelle precedenti versioni di ASP.NET qualcosa di magico consentiva ad un richiesta HTTP indirizzata ad IIS di essere veicolata verso la nostra applicazione, con ASP.NET Core tutto è nelle nostre mani. L’applicazione viene inizialmente lanciata come una “normale” applicazione Console per mezzo del suo classi entry point Main. Ed è proprio all’interno di tale metodo che possiamo definire il modo in cui dovrà funzionare, istanziando e configurando un oggetto di classe WebHostBuilder. Una configurazione di base viene preparata per noi dal template di progetto e per ora non abbiamo necessità di modificarla. Se volete addentrarvi nei dettagli trovate diversi post esplicativi a riguardo. Quello che ci interessa evidenziare è la chiamata UseStartup<T> che istruisce il WebHostBuilder sulla classe che si occuperà della configurazione dell’applicazione. Per default tale classe si chiama Startup:

image

Cioè detto, è chiaro che il successivo posto cui dare un’occhiata è il file Startup.cs che definisce la classe Startup cui fa riferimento il WebHostBuilder come punto di ingresso della nostra applicazione. Questa classe, che come noterete non deriva da alcuna classe base e non implementa alcuna interfaccia, è provvista di due metodi fondamentali: ConfigureServices e Configure.

Sorvolo sulla scelta dei nomi, in ogni caso il primo metodo serve a configurare lo IoC container built-in in ASP.NET Core con tutti i servizi che contiamo di usare nella nostra applicazione, compresi eventualmente quelli di “sistema” come MVC. ASP.NET Core è infatti (finalmente) dotato di un meccanismo di dependency injection intrinseco e integrato nel framework. Visto che in una prima fase non avremo bisogno di utilizzarlo e non voglio divagare inutilmente, per ora ignoreremo cosa sia la dependency injection, cosa sia uno IoC container e come si debba usare il metodo ConfigureServices. Limitiamoci semplicemente ad ignorarlo, lasciamolo desolantemente vuoto come è adesso e andiamo avanti.

Il metodo che più ci interessa è il metodo Configure, che serve a configurare i middleware che comporranno la pipeline di ASP.NET Core. Chi ha avuto modo di arrivare ad ASP.NET Core transitando per OWIN si troverà più a suo agio con questi “strani” termini. Per tutti gli altri cerchiamo di fare un po’ di chiarezza.

Quando il processo che ospita la nostra applicazione riceve una richiesta HTTP, questa viene presa in carico e incanalata come fosse su una catena di montaggio o se scorresse lungo una tubatura petrolifera (detta in inglese pipeline). Nel nostro caso i vari pezzi di questa condotta sono ovviamente componenti software (detti middleware) che, uno dopo l’altro vengono chiamati in causa per esaminare la richiesta e valutare le opportune operazioni necessarie a gestirla. Quando un middleware ritiene di poter fornire una risposta, il processo si arresta e la stessa viene incanalata nel verso opposto, ripassando per tutte le componenti precedentemente visitate, fino a giungere all’utente finale. In caso contrario il middleware è responsabile di passare il controllo al componente successivo:

Questo consente ad ogni middleware di poter agire in diversi modi e momenti:

  • un middleware dedicato all’autorizzazione agirà tipicamente nella fase di ricezione delle richiesta, verificando le credenziali dell’utente e rigettandola nel caso non sia sufficienti o consentendo che questa passi ai componenti successivi in caso contrario;
  • un middleware dedicato al logging agirà molto probabilmente in entrambe le direzioni, prima tracciando le informazioni sulla richiesta in ingresso e poi quelle sulla risposta in uscita;
  • un middleware dedicato a fornire risposte (come ad esempio un framework tipo MVC) agirà infine come “terminale” della “pipeline”, interpretando la richiesta e esaudendola.

image

L’esatto funzionamento di questa architettura esula dai nostri scopi, ma trovate una ricca documentazione in materia, partendo ad esempio dalla documentazione di ASP.NET Core.

Aggiungendo uno o più middleware alla pipeline di ASP.NET Core è quindi possibile configurare l’applicazione affinché si comporti esattamente come desiderato, senza che ulteriori processi non necessari rallentino le operazioni compromettendo le performance.

Aggiungere un middleware è in genere molto semplice. Il metodo Configure prevede infatti un parametro in ingresso di tipo IApplicationBuilder che è fornito di un conveniente metodo UseMiddleware<T> atto appunto all’uopo.

In realtà quasi mai avremo bisogno di ricorrere a tale metodo. Ogni middleware è infatti generalmente fornito di un metodo di estensione che si applica direttamente all’interfaccia IApplicationBuilder, consentendo di scrivere ad esempio direttamente UseRouter invece che UseMiddleware<RouterMiddleware> con il non trascurabile beneficio di poter passare dei parametri opzionali di configurazione “strongly typed”.

Ora che la teoria è un po’ più chiara, torniamo alla pratica ed esaminiamo il metodo Configure. Come si vede il template Empty aggiunge ben poco alla pipeline e la parte che ci interessa maggiormente al momento è l’istruzione app.Run(…) che serve a configurare un particolare middleware che funge sempre da anello terminale della catena e che per tale motivo ha una sintassi leggermente diversa. Il template Empty lo configura usando un anonymous method che, senza prestare attenzione al contenuto della richiesta, si limita a restituire come risposta sempre e comunque il testo “Hello World!”:

image

Ecco dunque da dove arriva il risultato che avevamo ottenuto in precedenza. Ed ecco dove dobbiamo mettere le mani per fare in modo che al posto di questo testo statico ci venga servito il nostro file index.html.

Quello che ci serve è aggiungere alla nostra pipeline un middleware che intercetti la chiamata, si accorga che esiste un file in wwwroot che corrisponde al percorso della richiesta e lo serva al browser direttamente dal file system. Fortunatamente per noi, questioni come questa (ed altre tipiche delle sviluppo di applicazioni web) sono state già risolte e codificate in ASP.NET Core. Si tratta solo di attivare la funzionalità in maniera appropriata perché, come già detto, out-of-the-box la pipeline è completamente vuota per non appesantirla con operazioni superflue che comporterebbero un inutile degrado delle prestazioni.

Posizioniamoci quindi dentro al metodo Configure e modifichiamolo in modo che appaia come segue:

image

In questo modo stiamo chiedendo al framework di intercettare le chiamate ai file statici e servirle direttamente (UseStaticFiles) e di fare in modo che le chiamate alla root sia reindirizzate verso un file di default (UseDefaultFiles). Come si vede dal tratteggio rosso però, il due metodi non vengono riconosciuti dal compilatore e, per quanto ci siamo detti finora, la cosa non ci meraviglia affatto: ASP.NET Core è una federazione di NuGet package e ovviamente il middleware di gestione dei file statici si trova in un package dedicato (sempre al fine di alleggerire il prodotto finale) che per ora non abbiamo referenziato nel progetto.

Cogliamo l’occasione per sfruttare una funzionalità di Visual Studio 2015 che semplifica questo genere di situazioni: come si vede nello screenshot, in corrispondenza della riga di codice che riporta la chiamata a UseStaticFiles, Visual Studio mostra una lampadina accesa; è il segnale che è in grado di suggerirci un modo per risolvere il problema. Se in passato ciò che l’ambiente di sviluppo era in grado di fare era solo proporci l’aggiunta della clausola using al file corrente, oggi è anche in grado di individuare la necessità di aggiungere un nuovo NuGet package e di prendersi carico dell’operazione in totale autonomia:

image

A questo punto siamo pronti a lanciare nuovamente l’applicazione e questa volta il risultato dovrebbe essere quello atteso:

image

Attenzione perché il middleware aggiunto da UseDefaultFiles si limita ad analizzare la richiesta ed eventualmente modificarla: se la URL richiesta è la root del progetto, questa viene sostituita con una URL che fa riferimento al primo dei default file ("default.htm", "default.html", "index.htm", "index.html") rintracciati nella cartella wwwroot. Il middleware non si occupa di servire il file stesso, ragion per cui è sempre necessario aggiungere la chiamata a UseStaticFiles ed è sempre necessario che tale chiamata sia successiva a quella ad UseDefaultFiles per assicurarsi che il middleware che serve effettivamente il file possa lavorare sulla URL già opportunamente modificata. In alternativa è possibile usare il metodo UseFileServer che integra i due precedenti nella giusta sequenza.

Happy coding!

 

P.S. Il codice sorgente è disponibile su GitHub, basta scaricare la release con lo stesso nome del post (Hello ASP.NET Core! in questo caso).

Aurelia e ASP.NET Core: NPM e i suoi fratelli

Questo post fa parte di una serie dedicata ad Aurelia e ASP.NET Core:

  1. la strana coppia;
  2. lo scheletro del progetto;
  3. NPM e i suoi fratelli (questo post);
  4. hello ASP.NET Core!;
  5. hello Aurelia!.

Nel precedente post ci siamo lasciati parlando di un nuovo approccio per la gestione delle dipendenze lato client: non più NuGet (che rimane lo strumento ideale per la gestione di quelle lato server e anzi risulta notevolmente potenziato dall’approccio a pacchetti intrinseco nel framework .NET Core stesso) ma NPM. Anzi no, Bower.

Cosa sono NPM e Bower?

Anche se vi sembra di averci capito poco, in realtà la confusione è solo teorica. Non vi preoccupate, avrà modo di diventare pratica nel corso di questo post.

Abbiamo già detto che NPM è l’acronimo di Node Package Manager, cioè l’equivalente NuGet per il mondo Node.js.

Cosa c’è che non va con NuGet? Perché cambiare? Per diversi motivi, meravigliosamente espressi da Gianluca Carucci nella sua sessione dello scorso anno ai Community Days. In breve:

  • mischiare dipendenze lato client e lato server nello stesso strumento contribuisce a creare un’entropia che è crescente all’aumentare delle dimensioni e della complessità del progetto;
  • i pacchetti NuGet delle librerie client-side non sono sempre “ufficiali” e sono comunque il porting degli equivalenti pacchetti Node.js, quindi ha molto più senso andare direttamente alla fonte per ottenere le risorse più aggiornate e consistenti;
  • usando NuGet una serie di fondamentali operazioni – come ad esempio Bundling e Minification, o la trasformazione di file Less in CSS – devono essere svolte con strumenti dedicati di .NET o di Visual Studio che potrebbero non essere disponibili in altri contesti (ricordiamoci sempre che ASP.NET Core è multi-piattaforma).

Ok, abbiamo capito (forse) che affiancare NPM a NuGet può essere una buona idea. Ma perché allora Visual Studio ci suggerisce di usare Bower per installare jQuery? Per capirlo (forse) non dobbiamo dimenticare che Node è un framework per la realizzazione di applicazioni web in JavaScript. In quanto tale, un progetto Node avrà tipicamente bisogno sia delle risorse da utilizzare sul server che di quelle da consumare sul client. Per quanto attiene al codice, tali risorse saranno JavaScript in entrambi i casi, ma per il resto la dicotomia è la stessa che abbiamo appena descritto per i progetti ASP.NET e anche la confusione potrebbe essere la stessa.

E allora se NuGet e NPM sono package manager da utilizzare per gestire le dipendenze lato server (rispettivamente in un progetto ASP.NET e Node), è bene usare qualcosa di specifico – nella fattispecie Bower – per gestire quelle lato client. Bower è un package disponibile su NPM (quindi può essere scaricato e aggiunto al progetto usando NPM) ed è a sua volta un package manager espressamente dedicato alla gestione di risorse lato client – con tutte le loro specificità – che in un progetto web sono tipicamente HTML, CSS, JavaScript. Vista la strada intrapresa da Microsoft per ASP.NET Core, non sorprende che il supporto tanto per NPM quanto per Bower sia decisamente buono in Visual Studio e questo ci semplificherà il compito se non siamo amanti della riga di comando.

A questo punto sembrerebbe tutto chiaro: per procedere nel nostro cammino prima aggiungiamo NPM al nostro progetto ASP.NET Core, quindi lo usiamo per aggiungere Bower, infine usiamo quest’ultimo per installare i package relativi ad Aurelia: il gioco è fatto.

Il terzo incomodo: JSPM

In realtà seguiremo (almeno inizialmente) un percorso leggermente diverso, per rimanere più aderenti all’approccio utilizzato dal team di Aurelia. E qui comincia la parte pratica della confusione.

Il team ho scelto infatti di basare lo sviluppo del framework non su Bower ma su JSPM che altri non è se non “yet another package manager” con qualcosa in più.

Un altro? Sì, un altro! Come mi ha fatto notare Nicolò durante il viaggio verso Future Decoded, usare JavaScript nel 2016 può essere una questione non propriamente immediata da approcciare. Il paradiso dei Geek può rapidamente trasformarsi in un inferno per un “ingenuo” programmatore web che magari proviene da un background ASP.NET. D’altra parte è abbastanza naturale che in un ambiente in cui domina l’open source ogni mattina qualcuno si svegli con in testa “il” nuovo framework che rivoluzionerà (in meglio) il modo di sviluppare software sul pianeta, o anche soltanto con un fork di un framework esistente per meglio adattarlo alle proprie esigenze. I package manager, con la loro pesante influenza sul modo in cui il progetto viene progettato e strutturato, non sfuggono a questa logica.

In definitiva non abbiamo fatto in tempo a scoprire che esiste un package manager specifico per JavaScript, che subito dobbiamo affrontare il fatto che ne esistono in realtà molteplici, ciascuno con caratteristiche leggermente diverse. Tra questi, come detto, il team di Aurelia ha deciso di preferire JSPM.

Visto che non vogliamo deviare troppo dalla nostra rotta, mi limito a dire che JSPM combina le caratteristiche classiche di un package manager (tipo Bower) con l’infrastruttura di caricamento modulare (che permette di caricare i file JavaScript dinamicamente man mano che sono necessari) e con le funzionalità di transpling (che consentono a moduli scritti in ES2015 nativo di essere “convertiti” dietro le quinte in codice JavaScript compatibile con i browser che non lo supportano). In particolare, JSPM usa SystemJS come module loader universale: in questa maniera è possibile caricare moduli di diversi formati (ES2015, AMD, CommonJS, …) da diverse fonti (NPM, GitHub, …). In fase di sviluppo i diversi moduli sono caricati come file separati in modalità asincrona, per il passaggio in produzione è invece possibile ottimizzarli in uno o più bundle con un semplice comando.

La scelta del team non è vincolante: Aurelia è disponibile anche come pacchetto Bower, ed è provvisto anche di un buon supporto per webpack; tuttavia in una prima fase useremo l’approccio consigliato per non mettere troppa carne al fuoco (cosa che nella vita reale mi piace invece fare parecchio).

Happy coding!

Aurelia e ASP.NET Core: lo scheletro del progetto

Questo post fa parte di una serie dedicata ad Aurelia e ASP.NET Core:

  1. la strana coppia;
  2. lo scheletro del progetto (questo post);
  3. NPM e i suoi fratelli;
  4. hello ASP.NET Core!;
  5. hello Aurelia!.

Avendo “chiacchierato” abbastanza nel primo post, è ora di mettere le mani su un po’ di codice. Io utilizzerò Visual Studio 2015 Enterprise (Update 3) ma non ho motivo di dubitare che sia possibile fare lo stesso sulla versione Community, su Visual Studio Code o anche utilizzando un qualsiasi editor testuale.

Nel momento in cui scrivo sto utilizzando i Microsoft .NET Core Tools (Preview 2) per Visual Studio.

Apriamo quindi Visual Studio e selezioniamo File > New > Project… e dalla categoria Visual C# > Web selezioniamo il template ASP.NET Core Web Application (.NET Core).

La consueta maschera di creazione del progetto consente di scegliere tra tre diversi template, che al solito aggiungono un po’ di codice di esempio al progetto vuoto. Non ho mai amato troppo queste aggiunte, non tanto perché riempiono il progetto di codice di dubbia utilità, quanto perché proponendo soluzioni preconfezionate fanno perdere di vista il funzionamento di quello che c’è “sotto il cofano”. Scegliamo quindi il template Empty e per ora ignoriamo la sezione relativa ad Azure su cui torneremo magari più avanti:

clip_image001

Dopo aver macinato un po’ l’hard disk, Visual Studio ci propone la struttura di base di una web application basata su ASP.NET Core (in realtà il risultato è leggermente diverso da quello dello screenshot seguente perché io preferisco prima creare una solution vuota, poi aggiungerci il project, spesso facendo anche un po’ di modifiche manuali alla struttura di base delle cartelle che non mi piace). Tanto per non farmi mancare nulla ho deciso di salvare il progetto su un repository Git che si trova sul mio account Visual Studio Team Services (VTST). Al momento non vedo implicazioni tra questo e la nostra “rotta”, quindi andremo avanti facendo finta che si tratti un progetto salvato in locale per poi magari tornare sull’argomento se ci sarà da pubblicare il sito su Azure sfruttando le funzioni di deploy e release management di VSTS:

clip_image002

Ci sono diverse differenze da notare in questa struttura rispetto a quella di un “vecchio” progetto ASP.NET ma non mi dilungherò ad analizzarle tutte in dettaglio visto che ci sono già svariati post su diversi blog che lo fanno egregiamente. Mi limiterò ad evidenziare brevemente quattro aspetti che a parer mio meritano la nostra attenzione.

Tutto è un pacchetto NuGet

Come accennato nel precedente post, ASP.NET Core è distribuito come federazione di pacchetti NuGet. Come conseguenza il nostro progetto non ha più dipendenze dirette con librerie del framework installate sulla nostra macchina, ma solo con quei pacchetti che implementano le funzionalità che ci servono.

Questo è immediatamente evidente aprendo il nodo References e confrontando un progetto basato sul .NET Framework completo con uno basato su .NET Core:

clip_image004

I pacchetti chiave di .NET Core sono i seguenti:

  • System.Runtime: è il nucleo di.NET Core e include ad esempio la definizione dei tipi Object, String, Array, Action e IList<T>;
  • System.Collections: contiene una serie di generic collections di base, come List<T> e Dictionary<K,V>;
  • System.Net.Http: include una serie di classi per le comunicazioni di rete via HTTP, tra cui HttpClient e HttpResponseMessage;
  • System.IO.FileSystem: è un insieme di classi per leggere e scrivere da storage locali o di rete, come File e Directory;
  • System.Linq: include una serie classi per interrogare oggetti, tra cui Enumerable e ILookup<TKey, TElement>;
  • System.Reflection: contiene le note classi per caricare, ispezionare e manipolare i tipi da codice a runtime, come Assembly, TypeInfo e MethodInfo.

È facile capire che il numero di pacchetti da cui un progetto mediamente può dipendere è cresciuto in modo esponenziale rispetto al vecchio approccio. Per fortuna è stata contemporaneamente migliora la gestione dei pacchetti ed è cambiata anche la modalità di visualizzazione sia sotto il nodo References che nella maschera di gestione dei pacchetti.

In un progetto .NET Core ci troveremo generalmente a non referenziare direttamente pacchetti di sistema, ma ad utilizzare invece dei metapackages. Questi ultimi sono pacchetti fittizi che non contengono alcuna funzionalità specifica (praticamente non hanno codice proprio) ma che servono solo per referenziare rapidamente una serie di altri pacchetti definiti come loro dipendenze.

In questo modo da un lato si semplifica l’acquisizione dei diversi pacchetti necessari per un comune progetto, d’altro ci si assicura che le varie versioni dei pacchetti siano tra loro coerenti.

Per il tipo di applicazione che abbiamo in mente, utilizzeremo il Microsoft.NETCore.App metapackage (attualmente alla versione 1.0.0) che include tutte le librerie che fanno parte della distribuzione di .NET Core e definisce inoltre il framework netcoreapp1.0. Approfondire quest’ultimo concetto esula dai miei scopi in questo momento, perché a parer mio non farebbe altro che aggiungere confusione. Se vi interessa potete consultare la documentazione ufficiale.

Come detto, e come si vede qui sopra, anche la modalità di visualizzazione è stata allineata a questo nuovo approccio e per default vengono riportati nella vista solo i pacchetti con dipendenza diretta, dai quali è sempre possibile navigare ad albero per scoprire le eventuali ulteriori dipendenze.

Dulcis in fundo, il nuovo file che contiene la lista dei pacchetti scaricati (il file project.json nella root di progetto) a differenza del precedente è manipolabile direttamente. È possibile digitare nella sezione dependencies il nome di un pacchetto che si vuole aggiungere (con tanto di intellisense) per ottenere lo stesso risultato del menu Manage NuGet Packages… e della Package Manager Console.

b6

Semplice come un file system

In un progetto.NET Core, il Solution Explorer mostra tutti i file presenti nella cartella del progetto: la “vecchia” lista di file inclusi nel progetto elencata nel file .csproj è stata finalmente abbandonata e questo rende molto più facile non solo aggiungere e rimuove file – è sufficiente copiare o cancellare un file nella cartella direttamente dal File Explorer di Windows – ma anche gestire il progetto su repository di codice sorgente quale ad esempio Team Foundation Server (TFS) o la sua controparte su cloud Visual Studio Team Service (VSTS).

clip_image005

Pubblicare solo il necessario

Ad una prima occhiata nel Solution Explorer, la cosa che più di altre salta agli occhi è la presenza di una cartella “particolare” chiamata wwwroot. Ricorda un po’ quella presente in IIS e rappresenta una svolta importante nella gestione delle applicazioni web con ASP.NET.

Fino ad oggi siamo stati abituati al fatto che tutto ciò che era presente nella cartella principale poteva di fatto essere servito al browser dal nostro server web. In un progetto MVC convivevano in maniera promiscua nella root del progetto sia elementi destinati direttamente al client – come ad esempio le immagini contenute nella cartella Images o i file JavaScript contenuti della cartella Scripts – che elementi inerenti il funzionamento lato server dell’applicazione – come i sorgenti presenti nelle cartelle Controllers, Models and Views o ancora il file di configurazione Web.config.

Questi ultimi erano progettati per essere processati all’interno del workflow di MVC ed emettere codice HTML e non per essere serviti direttamente al client (per intenderci con una richiesta HTTP verso la URL http://myapplication/Controllers/HomeController.cs ad esempio). Per evitare che ciò avvenisse, il motore di routing era dotato di una serie di regole che impedivano che certi file fossero raggiungibili direttamente dall’esterno con un meccanismo di blacklist.

In ASP.NET Core questo problema è stato risolto con un approccio radicalmente differente. Tutti, e soli, gli elementi presenti nella cartella wwwroot fanno parte di una whitelist che può essere servita al client direttamente (in altre parole come risorse statiche dotate di specifica URL). Se un file non si trova in wwwroot avete la sicurezza che non sarà possibile raggiungerlo e scaricarlo.

Non tutto è un pacchetto NuGet

L’altra novità rilevante nella lista presentata dal Solution Explorer è il nodo Dependencies che a prima vista sembra un duplicato di quello References di cui abbiamo già parlato, ma in realtà serve a distinguere le dipendenze lato server da quelle lato client, non tanto dal punto di vista logico ma soprattutto da quello dello strumento utilizzato per ottenerle.

Pare infatti che, mentre noi dormivamo beati tra i guanciali di ASP.NET, larga parte del mondo dello sviluppo web procedeva spedito in tutt’altra direzione, appoggiandosi a Node.js per sviluppare in JavaScript anche la parte server delle applicazioni. Anche in questo caso è inutile addentrarsi in un universo enorme e misterioso, sul quale tonnellate di materiale ben più qualificato di quello che potrei scrivere io è già disponibile.

Quello che ci interessa è che attorno a Node è fiorito un ecosistema di librerie e strumenti open source, facilmente accessibili tramite il suo package manager dedicato, NPM. Per chi viene da ASP.NET e sente parlare di NPM per la prima volta, il paragone più immediato è con NuGet. Se fino a ieri eravamo abituati ad usare NuGet per ottenere tanto una libreria .NET da usare nel codice lato server (come ad esempio Json.NET) quanto una JavaScript da usare nelle pagine lato client (vedi jQuery), da oggi Microsoft ha finalmente deciso di essere stanca di reinventare la ruota. NuGet rimane vivo e vegeto per il primo tipo di librerie, mentre per tutto ciò che attiene al client ASP.NET Core e Visual Studio fanno riferimento a NPM, cioè come detto al package manager di Node, in definitiva il più grande contenitore di librerie open source al mondo.

A riprova, se proviamo a cercare jQuery dal Manage NuGet Packages… otteniamo un avvertimento che ci invita ad usare Bower invece che NuGet (ad oggi è solo un avvertimento, non un divieto):

clip_image006

Come Bower? Ma non abbiamo appena detto che saremmo passati da NuGet a NPM? Sì e no; il mondo open source è pieno di sorprese e poi un solo package manager non sarebbe abbastanza nerd.

Ne sapremo di più al prossimo post.

Happy coding!

 

P.S. Il codice sorgente è disponibile su GitHub, basta scaricare la release con lo stesso nome del post (Lo scheletro del progetto in questo caso).

Aurelia e ASP.NET Core: la strana coppia

Questo post fa parte di una serie dedicata ad Aurelia e ASP.NET Core:

  1. la strana coppia (questo post);
  2. lo scheletro del progetto;
  3. NPM e i suoi fratelli;
  4. hello ASP.NET Core!;
  5. hello Aurelia!.

Per chi, come me, ha da sempre come pane quotidiano la realizzazione di applicazioni web, in particolare applicazioni con una forte interazione lato client, questi mesi estivi sono stati forieri di entusiasmanti novità.

Nel giro di poche settimane abbiamo infatti assistito al rilascio della RTM di ASP.NET Core (a fine giugno) e di Aurelia (a fine luglio). Mentre sfido chiunque a non aver mai sentito parlare della nuova piattaforma Microsoft per lo sviluppo di applicazione web, molto probabilmente il nuovo framework per realizzare Single Page Application potrebbe essere argomento sconosciuto ai più.

Tanta è l’eccitazione che ho deciso di imbarcarmi in un “viaggio” tra le caratteristiche di questa strana coppia per capire come sfruttarne i rispettivi punti di forza nello sviluppo di un’applicazione web. Premetto subito che non ho alcuna pretesa didattica, non so quale sarà in porto finale di approdo (o lo scoglio di naufragio), non voglio rivelarvi verità clamorose, non so neanche quale rotta seguire e quanto a lungo navigare. In ogni caso, se volete saltare sulla barca, c’è posto.

Prima di levare l’ancora, cerchiamo di capire meglio di cosa (secondo me) stiamo parlando. Come detto, ritengo ASP.NET Core patrimonio di tutti quindi ne farò solo un breve accenno, riservando qualche parola in più ad Aurelia e alla sua storia.

Cos’è ASP.NET Core?

ASP.NET Core è un nuovo framework per realizzare applicazioni web moderne. Rispetto al già noto e strautilizzato ASP.NET, si caratterizza per essere open‑source (sì avete letto bene), cross‑platform (sì avete riletto bene) e fortemente orientato al cloud (e qui non c’è alcuna sorpresa).

ASP.NET Core può girare sia sul .NET Framework “completo” sia sul nuovo .NET Core (da cui in tal caso eredita le caratteristiche di portabilità di cui sopra).

Una particolarità rispetto al passato consiste nel suo design modulare notevolmente granulare. A differenza di come eravamo abituati in ASP.NET “classico” (fa un po’ specie utilizzare questo termine che anni fa abbiamo usato per distinguere il “vecchio” ASP 3 dall’allora innovativo ASP.NET 1.0), con ASP.NET Core possiamo scegliere con estrema flessibilità quali funzionalità includere e quali escludere dalla nostra soluzione, rendendo ovviamente il risultato finale assai più snello e performante.

Se fino a ieri eravamo abituati a partire dal nutrito pacchetto di funzionalità messe a disposizione monoliticamente da ASP.NET, aggiungendoci sopra quelle fornite da librerie di terze parti tramite pacchetti NuGet, oggi le stesse parti di cui il framowork è composto sono distribuite tramite NuGet e possono essere assemblate a piacimento in una specie di federazione di pacchetti.

In tutto ciò, non guastano la nuova modalità di hosting, slegata da IIS, e alcune nuove feature build‑in, come ad esempio un Inversion of Control container per gestire la Dependency Injection.

Cos’è Aurelia?

Aurelia è un framework JavaScript per la realizzazione di UI di nuova generazione.

È l’ultima creazione di Rob Eisenberg, che ci ha già regalato framework come Caliburn.Micro (per lo sviluppo WPF/XAML) e Durandal (per lo sviluppo web).

Un po’ di storia può aiutarci a capire meglio in che contesto ci muoveremo.

Un paio di anni fa, dopo aver ideato Durandal vNext ed aver cercato senza successo di raccogliere fondi su KickStarter per portare avanti il progetto, Rob aveva deciso di abbracciare il lato oscuro, unendosi al team di Angular per contribuire alla realizzazione di Angular 2.

La sua idea era portare la sua competenza ed esperienza nei framework MVVM per realizzare in Angular 2 le idee che aveva ipotizzato per Durandal vNext. Dopo circa dieci mesi di collaborazione le strade di Rob e del team si sono però divise per una differente visione strategica e Rob ha ripreso a lavorare alle idee di Durandal vNext che si sono quindi concretizzate in un nuovo framework: Aurelia.

Come per ogni framework, in rete si trovano decine di definizioni diverse di Aurelia, ognuna con sfumature leggermente diverse, nessuna esatta, nessuna errata. Per me nella sua essenza Aurelia è fondamentalmente un insieme di librerie JavaScript moderne e modulari per realizzare interfacce utente.

Moderne perché sono state scritte dalle fondamenta interamente in ECMAScript 2016 (altrimenti noto come ES7) e supportano quindi nativamente moduli, classi, decoratori e via dicendo, consentendo ovviamente di utilizzare le medesime caratteristiche per scrivere la parte di codice applicativo di nostra competenza.

Modulare perché l’approccio architetturale su cui è basato non è quello che ha caratterizzato tanti giganti monolitici e poco flessibili che abbiamo usato in passato. Aurelia è piuttosto progettato come una rete di librerie che collaborano tra loro per formare un framework potente e solido per sviluppare Single Page Application (SPA). In tal senso i due protagonisti del nostro viaggi si assomigliano parecchio.

Tenendo fede ad un consolidato stile di Rob, anche Aurelia si caratterizza per una notevole facilità d’uso grazie all’approccio convention‑over‑configuration: il framework è dotato di una serie di convenzioni semplici ed immediate che consentono di seguire pattern di programmazione solidi e di ridurre la quantità di codice da scrivere e manutenere. Il che significa potersi focalizzare maggiormente sulla propria applicazione riducendo il tempo speso ad interagire con le API del framework senza perdere però la possibilità di configurare comportamenti diversi ove necessario.

La sua modularità gli consente inoltre di essere facilmente personalizzato ed integrato. Praticamente ogni aspetto di Aurelia è estendibile, il che garantisce di non trovarsi mai di fronte a "scatole chiuse" o di dover "hackerare" il framework per farlo funzionare nel modo desiderato. Ma consente anche di integrare con immediatezza qualsiasi libreria o framework di terze parti, come ad esempio jQuery, React, Polymer o Bootstrap.

Dulcis in fundo, Aurelia è stato progettato attorno alla nuova generazione di JavaScript e ai Web Components, con l'obiettivo di evitare astrazioni superflue che nascondano la tecnologia sottostante, è si propone quindi come il framework che maggiormente rispetta gli attuali standard di programmazione, promettendo di farci scrivere sempre codice JavaScript, senza invasivi costrutti da rispettare.

Direi che siamo pronti per imbarcarci, alla prossima.

Happy coding!

Usare Visual Studio Team Services (VSTS) senza mouse? Si può!

Buone notizie per i patiti (come me) della tastiera. Le modifiche apportate nel corso degli ultimi sprint hanno notevolmente irrobustito l’arsenale di comandi attivabili con la tastiera sia in Visual Studio Team Services (VSTS) che in Team Foundation Server (TFS). Non solo sono aumentati gli shortcut supportati, ma è finalmente disponibile e facilmente accessibile un sommario di quelli disponibili in ogni pagina di VSTS.

E’ infatti sufficente premere il tasto ? in qualsiasi pagina per accedere ad un popup che elenco gli short disponibili in quel contesto. Ad esempio nella home page è possibile utilizzare i seguenti tasti:

image_thumb18

Come vedete VSTS supporta sia tasti singoli (come s per spostare il focus sulla casella di ricerca), sia combinazioni (come g w premuti in sequenza uno dopo l’altro per aprire la schermata di gestione delle attività).

Come detto gli shortcut sono contestuali, quindi se ci troviamo ad esempio nella pagina che visualizza il backlog della nostra applicazione, avremo a disposizione sia gli shortcut globali, sia quelli della sezione attività, sia ancora quelli specifici di gestione del backlog:

image_thumb19

Per chi fosse interessato ad implementare degli shortcut nella propria applicazione web, segnalo che VSTS utilizza la libreria open source MouseTrap, che anch’io sto utilizzando con ottimi risultati nei nuovi progetti di cui mi capita di occuparmi.

Happy coding!

Le novità dell’aggiornamento di Visual Studio Online del 4 settembre

Il lavoro incessante del team di sviluppo di Visual Studio Online non si ferma neanche d'estate e, puntuali come sempre, allo scadere delle tre settimane ecco disponibili le novità portate a termine nel corso del 70esimo sprint.

È uno sprint che presenta parecchie interessanti novità che aiuteranno senza dubbio quelli che utilizzano VSO quotidianamente per i propri progetti di produzione.

Vediamo rapidamente di cosa si tratta, riservandoci di approfondire le funzioni più interessanti in un prossimo post.

  1. Gestione delle query sui Work Item
  • Un nuovo comando consente di inviare direttamente un email con le informazioni sul Work Item;
  • Dopo aver aperto il dettaglio di un Work Item che fa parte di una query, oltre ai pulsanti per navigare sul Work Item precedente o successivo, è ora disponibile un nuovo comando per tornare alla lista. Il comando è attivabile anche con lo shortcut da tastiera ALT+Q e replica il comportamento già garantito dal tasto back del browser. In tutte e tre modalità (comando della toolbar, shortcut e tasto back) il ritorno alla lista avviene con l'elemento corrente (quello di cui stavamo esaminando il dettaglio) che viene automaticamente selezionato;
  • La modalità full screen, che massimizzando lo spazio a disposizione per l'elemento selezionato risulta particolarmente utile ad esempio durante i meeting Scrum, è ora disponibile sia sulle query che su tutti i tipi di Work Item;
  • Nel menu contestuale attivabile sui risultati di una query è ora disponibile un nuovo comando che apre il Work Item in un tab separato. Il nuovo tab ha qualche piccolo difetto di gioventù, ad esempio dalla toolbar manca il comando per attivare la modalità full screen che è però attivabile cambiando "a mano" il querystring.
  1. Ricerca rapida nei controlli ad albero
  • Lavorando con VSO capita spesso, anzi direi sempre, di dover impostare o modificare l'area o l'iterazione a cui un particolare Work Item fa riferimento. Come sapete ciò è possibile per mezzo di un comando ad albero che si apre a tendina e ci consente di navigare nella gerarchia delle iterazioni (o delle aree) fino a selezionare quella desiderata. Fin tanto che "giochiamo" con un progetto di prova tutto funziona a meraviglia. Quando però ci cimentiamo con un progetto "reale", in cui ad esempio il numero di release e di sprint può diventare notevole, utilizzare il controllo non era propriamente agevole. Da oggi è possibile cominciare semplicemente a scrivere nel campo Iteration (o in quello Area) per veder apparire una lista sottostante che presenta gli elementi filtrati in base al testo inserito. Se il valore che vogliamo impostare è univoco e quindi sufficiente premere Invio per selezionarlo. Se ad esempio vogliamo mettere un Work Item nello sprint 70 è sufficiente scrivere 70 e premere Invio (supponendo che non ci siano due iterazioni che contengo il testo 70 nella propria descrizione) con un bel risparmio di tempo.
  1. Nuovi grafici di tendenza
  • Sono disponibili due nuovi intervalli di tempo per i grafici sui Work Item che mostrano i risultati relativi rispettivamente alle ultime 12 settimane e all'ultimo anno. Per i nuovi due intervalli i dati non sono ovviamente mostrati su base giornaliera ma sono invece raggruppati per settimana nel primo caso o per mese nel secondo.
  1. Più elementi nella Kanban board
  • Il limite di 20 elementi visualizzabili nella prima e nell'ultima colonna della Kanban board è stato sostituito con un limite di 999 che è decisamente adeguato anche per progetti più grandi e duraturi. Il valore può essere al solito impostato nella schermata di personalizzazione delle colonne.
  1. Evidenza di tutte le Test Suite a cui un Test Case appartiene
  • Man mano che il progetto cresce è molto probabile che uno stesso Test Case finisca per far parte di più Test Suite. In tal caso prima di apportarvi delle modifiche è bene verificare e ponderare gli eventuali effetti collaterali sulle diverse Test Suite. Una nuova opzione sul pannello dei filtri consente ora di visualizzare immediatamente tutte le Test Suite a cui il Test Case selezionato appartiene.
  1. Preview 2 delle API WIT
    Sulla base dei tanti feedback ricevuti dopo il rilascio della Preview 1, il team di VSO ha rilasciato una nuova preview che include:
  • Modalità più semplice di creazione e modifica dei Work Item;
  • Esecuzione più facile di comandi ad-hoc che utilizzano il Work Item Query Language;
  • Accesso alla lista delle aree e delle iterazioni;
  • Nuove API per elencare i tipi di Work Item e Link, le Categorie e i Campi;
  • Oggetti di ritorno JSON meno prolissi.

È comunque possibile configurare quale versione delle API si intende utilizzare per mantenere compatibilità con integrazioni già realizzate.

  1. Supporto per Hubot
  • Le Team Room di Visual Studio Online possono ora essere collegate alla chat open source Hubot. L'integrazione consente di migliorare la produttività semplificando ad esempio la creazione di Work Item, la pianificazione di una Build o la visualizzazione del proprio lavoro recente direttamente dalla Team Room.

Happy coding!

Associare il proprio Microsoft Account con l’account aziendale per condividere i benefici dell’abbonamento MSDN su Visual Studio Online

In un precedente post avevo parlato del funzionamento del piano Basic gratuito di Visual Studio Online e della possibilità di superare il numero di 5 utenti a patto che gli eccedenti siano in possesso di un abbonamento MSDN.

Con l'attuale possibilità di utilizzare Visual Studio Online sia con il proprio Microsoft Account che con l'account aziendale, per qualcuno si potrebbe porre il problema di riuscire a condividere i benefici dell'abbonamento su entrambi gli account, potendo quindi partecipare sia a progetti aziendali che extra-aziendali senza essere in entrambi i casi contati come utenti Basic.

Fortunatamente il problema è facilmente risolvibile associando i due account dalla propria sottoscrizione MSDN.

Apriamo quindi il nostro browser preferito e navighiamo su http://msdn.microsoft.com accedendo se necessario con il nostro Microsoft Account. Selezioniamo quindi in alto a destra il link Abbonamenti MSDN.

Nella sezione Visual Studio Online selezioniamo il link Collegamento all'account aziendale.

Nel dialog box Link to your Organizational Account impostiamo il nostro Account aziendale e clicchiamo sul pulsante Collega.

I due account risultano ora collegati (collegamento che è sempre possibile modificare o rimuovere utilizzando i link opportuni) ed è quindi possibile utilizzare i privilegi della propria sottoscrizione MSDN su entrambi.

Happy coding!

CLOUD OS - La nuova visione dell'IT a Roma il 31 marzo

Se siete interessati a conoscere meglio la nuova visione Microsoft dell'IT, basata fortemente sul Cloud, vi aspetto Lunedì 31 marzo presso la sede Microsoft di Roma in viale Avignone 10 per vivere insieme l'evento CLOUD OS - La nuova visione dell'IT organizzato da Proge-Software e Microsoft.

Come recita la presentazione dell'evento, "è una nuova era per l'IT. Oggi i dati, le applicazioni ed i dispositivi evolvono ad un ritmo mai visto prima e le nuove sfide introdotte dalle tecnologie Cloud richiedono differenti paradigmi di gestione, efficienza e stabilità dell'IT aziendale.

Il Cloud OS di Microsoft consente di fronteggiare e vincere queste sfide, fornendo gli strumenti necessari ad ottenere tutti i benefici di scalabilità, velocità e agilità, salvaguardando gli investimenti effettuati".

Avrò l'onore di parlare, insieme a Pierpaolo Boccadamo di Microsoft e a Giancarlo D'Antoni – che come me lavora per Proge-Software –per raccontarvi come Realizzare e gestire applicazioni aziendali moderne.

Trovate maggiori informazioni e il link per la registrazione nella pagina dell'evento sul sito di Proge-Software.

L'appuntamento è per le ore 10, non mancate.

Happy coding!

La fine del Early Adopter di Visual Studio Online non è la fine del mondo

In questi giorni Microsoft ha confermato che il programma Early Adopter di Visual Studio Online terminerà il 7 maggio. I benefici Early Adopter consentivano agli utenti che si erano registrati su VSO nella fase di lancio della piattaforma di poter usufruire di tutti i servizi della stessa gratuitamente. Il termine di tale opzione era previsto inizialmente per il 13 marzo ma era stato successivamente posticipato per una serie di problemi che hanno ritardato la disponibilità delle modalità di migrazione.

Gli utenti di VSO che preferissero optare per una soluzione on-premises piuttosto che per la versione a cloud a pagamento riceveranno infatti da Microsoft tutto il dovuto supporto per l'esportazione dei dati da VSO e l'importazione degli stessi sul proprio TFS.

In questo post non vorrei però parlare di migrazione, ma approfittare invece per capire un po' meglio quali saranno le opzioni gratuite offerte dalla piattaforma per gli Early Adopter dopo tale data, che poi altro non sono se non quelle già garantite a un qualunque utente che si iscriva oggi su VSO.

Il piano entry level disponibile su Visual Studio Online è il Basic ed è su questo che saranno convertiti tutti gli attuali Early Adopter a meno di non sottoscrivere un piano a pagamento. Il piano consente di utilizzare il servizio cloud di Microsoft per gestire i propri progetti sia dal punto di vista del codice che delle attività, con la possibilità di condividere i progetti in team fino a 5 persone senza costi aggiuntivi.

Ciò vuol dire un repository di codice sorgente con tutte le caratteristiche di TFS che ben conosciamo e con la possibilità di utilizzare sia lo storico Team Foundation Version Control (TFVC) centralizzato che Git, un sistema di Version Control distribuito (DVCS). Ma vuole anche dire poter sfruttare VSO per la gestione dei requisiti e delle attività di sviluppo, potendo optare tanto per un approccio tradizionale (usando il Process Template MSF for CMMI Process Improvement 2013) quanto per uno Agile (scegliendo il template generico MSF for Agile Software Development 2013 o quello Microsoft Visual Studio Scrum 2013 specifico per Scrum di cui una la peculiare terminologia).

Il piano prevede inoltre fino a 60 minuti mensili di Build e 15.000 minuti di Load Testing.

La possibilità di lavorare in team su un progetto condiviso su VSO è ancora più interessante se analizziamo meglio la limitazione delle 5 persone gratuite. La limitazione è infatti relativa alla possibilità di aggiungere fino a 5 utenti in possesso a loro volta di un piano Basic. Non vi è invece alcuna limitazione relativa agli utenti in possesso di un abbonamento MSDN ed è quindi possibile, da un piano Basic, gestire un progetto con anche più di 5 membri a patto che quelli eccedenti siano tutti in possesso di un abbonamento MSDN.

Per verificare quale sia la situazione del nostro piano possiamo cliccare sul tab Users a partire dalla Home page del nostro account.

All'interno del tab è riassunta la situazione relativa alle licenze di tutti gli utenti accreditati sul nostro account di VSO. Nel nostro esempio l'account prevede l'accesso per 6 utenti in possesso del piano Early Adopter. In questo caso alla data di scadenza del 7 maggio gli utenti saranno migrati sul piano Basic e questo poterebbe l'account a sforare il limite di 5 account Basic gratuiti.

È quindi necessario acquistare licenze aggiuntive per gli utenti oltre il quinto, oppure specificare che uno o più utenti sono in possesso di un abbonamento MSDN e non vanno quindi conteggiati nel novero di quelli Basic. Per farlo selezioniamo l'utente e clicchiamo sul tasto Edit.

Possiamo ora scegliere il tipo di licenza impostando ad esempio Eligible MSDN Subscriber e cliccando su Save. In tal modo comunichiamo a VSO che l'utente selezionato gode, a parer nostro, dei privilegi riservati agli utenti in possesso di un abbonamento MSDN.

La nostra indicazione viene registrata e sarà confermata al successivo login dell'utente su Visual Studio Online.

Quando ciò avviene il cruscotto degli utenti riporta l'indicazione corretta sulla licenza in uso. È possibile anche anticipare il momento in cui i piani Early Adopter saranno convertiti in Basic, impostando per uno o più utenti il piano Basic con la stessa procedura appena descritta. Gli utenti con licenza Basic vanno ovviamente a riempire i 5 spazi gratuiti a disposizione.

I vantaggi degli utenti in possesso di un abbonamento MSDN non si esauriscono nel fatto di poter partecipare a progetti su account Basic senza consumare gli slot gratuiti previsti. Tali utenti infatti non sono soggetti alle limitazioni previste per gli utenti Basic a livello di Team Rooms, Features, Test, Feedback, ecc.

Happy coding!

«dicembre»
domlunmarmergiovensab
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567