Welcome

This is the generic homepage (aka Aggregate Blog) for a Subtext community website. It aggregates posts from every blog installed in this server. To modify this page, edit the default.aspx page in your Subtext installation.

To learn more about the application, check out the Subtext Project Website.

Powered By:

Blog Stats

  • Blogs - 715
  • Posts - 31231
  • Articles - 309
  • Comments - 90050
  • Trackbacks - 241480

Bloggers (posts, last update)

Latest Posts

placeit.net

https://placeit.net/

posted @ 05/12/2016 21.46 by Alessandro Gervasoni

L’incubo della chat del portale Trenitalia.

Ma questi sono fuori. Sul portale c’è una chat, che sembra essere l’unico modo per contattarli con mezzi moderni, visto che su Twitter vi rimbalzano li:

image

Solo che la chat funziona allo stesso modo di un call center, e se non sei veloce a scrivere e pigiare invio il tuto bel messaggio viene cancellato appena qualcuno è più veloce di te.

Poveri noi :-(

posted @ 05/12/2016 8.28 by Mauro Servienti

Aggiunta di un tipo di Work Item in VSTS

Precedenti post sulla personalizzazione Work Item in TFS

1 – Tfs e customizzazione del process template
2 – Customizzare il Process Template, le basi
3 – Customizzare il process Template, aggiungere un campo ad un Work Item
4 – Customizzare il process template, regole per i campi aggiuntivi dei WI
5 – Personalizzare i Work Item di TFS, ancora qualche regola interessante
6 – Stati e transizioni
7 – Approfondiamo stati e transizioni

Post su personalizzazione VSTS

1 – Personalizzare il process template in VSTS
2 – Process template Ereditati in VSTS
3 – Aggiungere ad un Work Item un campo esistente in un altro template
4 – Creazione di un campo custom
5 – Modificare gli stati di un Work Item

Sicuramente la personalizzazione più interessante che può essere fatta su un Process Template è aggiungere un nuovo tipo di Work Item. In ogni team infatti esiste la necessità di tracciare informazioni concettualmente non mappabili su uno dei tipi di Work Item Tradizionali. Ad esempio potreste voler tracciare le sessioni di Event Storming da fare con il cliente e poterle schedulare. In questo caso un normale PBI nel process template SCRUM potrebbe fare al caso vostro, ma sicuramente avere un Work Item personalizzato permette di tracciare l’informazione in maniera più corretta. Per chi fa SCRUM infatti può essere interessante creare un Work Item Type per ogni tipologia di attività che sia pianificabile nello sprint.

Come possibile esempio mostrerò una personalizzazione fatta sul process template dell’account VSTS di GetLatestVersion, creata per per supportare un processo particolare, la pubblicazione di video-pillole sull’argomento ALM.

Di base con il processo SCRUM , sarebbe possibile utilizzare i PBI per rappresentare i Video che vogliamo realizzare ed utilizzare le features per categorizzare i video, ma è in qualche modo una forzatura. Sicuramente il poter creare dei Work Item personalizzati permettono di rappresentare in maniera più personalizzata e corretta queste iniziativa.

Navigando nella sezione dei Work Item Types nella pagina di personalizzazione del Process Template, si può notare il link che permette la creazione di un nuovo Work Item Type.

image

Per cominciare inizio creando un Work Item chiamato Video Pill, che deve rappresentare un video di massimo 7 minuti che focalizzerà l’attenzione su un punto ben preciso. Come si può vedere dalla figura sottostante è sufficiente dare un nome, una descrizione ed un colore ed il nuovo Work Item è creato.

image 

Alla pressione del bottone “Create” viene creato il nuovo Work Item che appare immediatamente nella lista a sinistra.

image

A questo punto la prima modifica che solitamente viene effettuata è quella di decidere se e dove questo nuovo Work Item apparirà nei backlog, ovvero nella pianificazione agile (Portfolio Management).

image

Di base si deve quindi decidere a che livello del backlog verrà visualizzato il nostro Work Item Type, oppure decidere di non farlo apparire per nulla. Nel caso della pillola video si è deciso per il livello del PBI, ovvero, banalmente, una User Story. In questo modo è possibile dare una “categoria” all’informazione. Tutti i Work Item a livello Task sono attività dello sprint / iterazione figlie di un elemento del backlog, mentre i livelli superiori (features ed epics) sono contenitori più generali per gestire il Portfolio Management.

Per quanto riguarda le opzioni di Overview è possibile modificare la descrizione, sia distruggere il tipo di Work Item, opzione che non è chiaramente possibile per i Work Item base del processo. Anche in questo caso si può vedere come il sistema previene operazioni (come la cancellazione di tipi già presenti) che possono andare ad inficiare un eventuale aggiornamento del Process Template.

image

Ricordate che cancellare un Work Item Type custom provocherà la cancellazione di tutti i Work Item creati sulla base di quel tipo, cosi come tutti i dati storici, ed è quindi una operazione che deve essere ponderata con molta attenzione.

Dopo avere selezionato la posizione del Backlog è consigliabile andare ad editare gli stati disponibili, in questo caso si è scelto di utilizzare gli stessi stati del PBI. Questo non è strettamente necessario, ma dato che il nuovo tipo di Work Item condivide lo stesso livello di Backlog, il processo sarà molto più chiaro se la nostra Video Pill contiene gli stessi stati dei Work Item Type che sono presenti allo stesso livello.

image

Anche in questo caso è interessante vedere le differenze che vi sono tra i menù contestuali presenti nella lista di stati di un PBI (1) e quelli presenti nella lista di stati del nostro nuovo Work Item (2).

image

Mentre per il PBI le uniche opzioni che possiamo avere per gli stati base sono View e Hide, nel nostro nuovo Work Item tutti gli stati possono essere sia Editati che Rimossi. Mentre, come visto nell’articolo precedente, non è possibile rimuovere uno stato per uno dei Work Item base, per quelli personalizzati non esiste nessuna limitazione e si possono aggiungere e rimuovere tutti gli stati che si preferisce.

A questo punto non rimane altro da fare che andare a inserire nel Work Item Type i campi desiderati e modificare il layout in modo che sia aderente alle nostre necessità.

Anche in questo caso si può notare come con veramente pochi click sia stato possibile andare ad aggiungere una nuova tipologia di informazione nel nostro account VSTS, adattandolo alle specifiche esigenze del team e senza il rischio di complicare le procedure di update.

Gian Maria.

posted @ 12/11/2016 11.44 by Gian Maria Ricci

Services UI Composition: le scritture. In anteprima con @klabcommunity

Ieri a WPC 2016 ho avuto il piacere di parlare di Services UI Composition, tante domande e una bella discussione a seguire.

Ovviamente la domanda più gettonata era:

OK, tutto bello…ma quando devo scrivere?

L’utente in moltissimi casi non deve solo leggere dati, ma ci deve anche interagire, manipolando le informazioni che sono “sparse”sui vari servizi.

Il vero segreto non è la tecnologia ma la conoscenza profonda dei processi di business

È necessario spendere tempo, tanto tempo, per comprendere a fondo come sono modellate le interazioni nella realtà, quali informazioni sono condivise e come, quali sono gli SLA e quali sono i rapporti di downstream/upstream tra le parti in gioco. Una volta che si è padroni di questo, ed è la cosa veramente difficile, l’implementazione è veramente un dettaglio e spesso un gioco da ragazzi.

Faccio sempre un esercizio, che per come sono fatto io funziona molto bene. Dato un processo di business che devo comprendere a modellare, mi chiedo:

Come farebbero un gruppo di umani, senza tecnologia, a risolvere il problema?

Comprensione del dominio

Questo è il tema caldo quando si parla di sistemi distribuiti. Martedì prossimo mi cimenterò nella titanica impresa di mostrare un flusso di manipolazioni di dati in un sistema distribuito. In 40 minuti.
Se volete una live preview di quelli che saranno i prossimi post, ma soprattutto del codice non potete mancare.

Maggiori informazioni: http://www.klabcommunity.org/klab-201606/

Post in questa serie:

posted @ 30/11/2016 8.11 by Mauro Servienti

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).

posted @ 28/11/2016 20.25 by Giorgio Di Nardo

@CodemotionIT una piacevole esperienza.

Sono reduce da quasi 3 intere giornate passate a Codemotion, quasi 3 perché sabato sono stato un po’ latitante :P.

È stata la prima volta e nel complesso devo dire che è stata una priva volta che non dimenticherò. Il workshop è andato molto bene, con tantissima partecipazione attiva, quindi è andato molto bene grazie a voi che avete partecipato. Quello che ho visto della conferenza nel complesso mi è piaciuto, devo dire che la cosa che mi ha colpito di più è stata la quantità di gente. Il mio collega Sean Farmar venerdì mattina è arrivato prima di me e mi manda un SMS:

It is mad here, loads of people.

Che descrive abbastanza bene lo scenario. Ho visto anche qualche sessione, e nel complesso mi sono piaciute. Ho scelto cose molto distanti dal mio background tecnico/tecnologico background che per certi versi un po’ mi ha stufato.Devo dire che il formato 40 minuti mi piace molto.

posted @ 28/11/2016 9.35 by Mauro Servienti

KLab 2016 #6

Martedì 6 dicembre sarò all’evento KLab a Fiorenzuola D’Arda. La serata sarà super DevOps oriented.

Due sessioni con le mani in pasta nella realtà di tutti i giorni

Inizierà il sottoscritto con una sessione di live coding finalizzata a realizzare un piccolo esempio di sistema distribuito basato sui dettami di SOA e usando NServiceBus per l’implementazione.
A seguire Carlo ci farà vedere come usare Octopus Deploy per gestire tutto il ciclo di rilascio.

Fatevi sotto!

L’evento è gratuito ed è l’occasione perfetta per passare una piacevole serata in compagnia e per godere anche di un ottimo buffet piacentino, che male non fa.

Per iscrizioni ed informazioni logistiche: https://www.eventbrite.com/e/biglietti-klab-2016-6-29404493632

posted @ 25/11/2016 12.07 by Mauro Servienti

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).

posted @ 24/11/2016 21.20 by Giorgio Di Nardo

Trenitalia fa peggio di tutti. Ovviamente.

Come CartaSi e Telepass fallisce miseramente nell’esporre la pagina di login su HTTP con POST verso HTTPS, con l’aggravante che lo fa verso un dominio diverso. Ma perché?

image

Il problema del POST da HTTP verso HTTPS è che basta fare tampering della pagina di partenza reindirizzare la POST verso un altro dominio e abbiamo le credenziali dell’utente.

Ma si può fare di peggio

La password è salvata in chiaro, te la mandano allegramente per posta, ed è pure case insensitive. Oh my…

image

Scappate a gambe levate. Qui non ci sono consigli da dare, se non evitate di salvare qualsivoglia dato importante nel profilo di Trenitalia.

posted @ 23/11/2016 6.50 by Mauro Servienti

EditorConfig



EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs
http://editorconfig.org/

posted @ 21/11/2016 22.38 by Alessandro Gervasoni

“Irreperibili e felici” (cit.)

Citando: http://www.internazionale.it/opinione/oliver-burkeman/2015/10/27/irreperibili-felici-stress

È sempre piacevole trovare conferme alle proprie convinzioni:

Non è tutto li.

Ho sempre di più la sensazione, spiacevole sensazione, che la cosa ci stia un po’ sfuggendo di mano. Con Lucia andiamo ogni tanto in un ristorante giapponese a Pavia, e puntualmente incrociamo una coppia (che quindi deduco ci vada molto più spesso di noi) che passa la cena nel seguente modo:

  • Ordinano con il cellulare in mano mentre fanno non si sa bene cosa
  • Fanno foto a tutto quello che arriva
  • Non mollano mai il cellulare per tutta la sera
  • Non spiccicano una parola, ma non si guardano neanche in faccia.

Ora, secondo mia moglie il sottoscritto è un orso che parla poco ma confronto a quei due sono la socialità fatta a persona. Quelli probabilmente sono ad un estremo dello spettro, ma sempre più spesso mi capita di osservare (o di essere coinvolto) situazioni in cui il device interrompe prepotentemente e in maleducatamente una conversazione.

E non è il device quello prepotente e maleducato.

posted @ 21/11/2016 7.34 by Mauro Servienti

Monkey test

https://monkeytest.it

posted @ 18/11/2016 9.41 by Alessandro Gervasoni

Telepass: il reset della password e la security…oh my.

Un po’ come fa CartaSi anche Telepass cade nel falso senso di sicurezza.

image

Praticamente ci manda una “one time password” in chiaro via mail. Questo perché sappiamo tutti che SMTP è un protocollo sicuro per definizione. Ergo qualcuno intercetta la mail, fa login prima di voi, cambia la password e ciaone.

Consiglio: non c’è mezzo di avere un processo di reimpostazione della password sicuro. Assicuratevi di averne una molto complessa e che non usate da nessun’altra parte (cosa che dovrebbe essere il comportamento standard)

posted @ 18/11/2016 7.17 by Mauro Servienti

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!

posted @ 17/11/2016 12.35 by Giorgio Di Nardo

“GitFlow e GitHubFlow” @ WPC 2016 con @OverNetE

Vi ho già detto di “Progettare una UI per Microservices”. A questo il divertimento è doppio:

GitFlow & GitHubFlow: gestire al meglio prodotti e progetti con Git (e non solo)

Un sistema di Source Control è solo uno strumento per conservare, condividere e versionare il codice? O possiamo sfruttare il nostro motore di Source Control per gestire e semplificare il processo di sviluppo? L'obiettivo è comprendere a fondo Semantic Versioning, le differenze tra GitFlow e GitHubFlow, come usare branch e PR per gestire il ciclo di vita e di rilascio e infine capire cosa sia GitVersion. Senza dimenticare che CI e build automatiche dovrebbero essere la norma.

Dettagli: http://milestone.topics.it/events/wpc-2016-milano.html

WPC 2016 mi da l’opportunità anche di raccontare cosa sia GitFlow, come e perché lo usiamo in Particular. La sessione (purtroppo) non sarà così articolata come da abastract perché è stata convertita in una sessione di mezz’ora, invece che i soliti 75 minuti di WPC, ci concentreremo quindi su GitFlow e sull’impatto che ha sul modello di sviluppo, soprattutto in ottica Semantic Versioning.

Ci vediamo a Milano, settimana prossima, il 30/11 alle: 14:30 in Sala Gialla.

posted @ 17/11/2016 7.14 by Mauro Servienti

Services UI Composition: IT/Ops

La domanda di Fabio mi spinge a trattare subito IT/Ops:

image

immagina una ui che vede dal canale di lettura una projection di nome SuperOrder che è un mix di quello che server side avviene a fronte dell'evento dal canale di scrittura di OrderUpdated\Created and CustomerUpdated\Created e dalle quali viene creata una denormalizzazione che confluisce in SuperOrder

tutto chiaro, il “problema” è che se scegliamo Services UI Composition come strada una projection risultato un mix tra quello che succede in servizi diversi non esiste, a meno che non ci sia uno specifico caso d’uso (e ce ne sono, ergo questo post).

A questo punto la UI deve fare un update di SuperORder utilizzando il comando di un BC UpdateOrderCommand e di un'altro BC UpdateCustomerCommand senza aver mai conosciuto la "forma" dell'Order e del Customer del canale di scrittura e magari non avendo tutti i dati a disposizione dal momento che la projection potrebbe non esporli tutti.

In realtà li conosce ma ancora in realtà non è la projection che li conosce.

Usiamo un caso reale

Ad un certo punto del processo gli ordini devono essere spediti, per fortuna direte voi, e per spedirli usiamo un corriere espresso. Il nostro corriere di fiducia oltre a sapere dove spedire vuole anche un paio di informazioni in più:

  • Ingombro dei colli
  • valore della merce
  • eventuali contenuti speciali, come ad esempio roba chimica etc..

Se ci pensate quelle tre informazioni non sono parte dell’ordine e non vengono neanche de-normalizzate all’interno dell’ordine, come ad esempio il prezzo del prodotto acquistato., come facciamo quindi in fase di generazione della spedizione a mandarle al corriere?

IT/Ops

Shipping è responsabile di generare l’ordine di spedizione, diciamo che questo avviene con una chiamata ad un servizio remoto esposto dal corriere di turno, diciamo anche che il servizio remoto si aspetta un payload xml con tutte le informazioni dell’ordine più le informazioni di cui sopra.

image

Come abbiamo detto in questa comunicazione devono in qualche modo partecipare anche Warehose e Sales, o Finance che dir si voglia, ma lo devono fare al solo scopo di arricchire il payload, che se ci pensate è una projection per come lo vede il corriere.

image

Ci sarà qualcuno che media, ACL, la comunicazione, questo qualcuno ospiterà (in termini tecnici farà hosting di assembly) i componenti di Sales e Warehouse che sanno come si fa ad arricchire il payload per quel corriere specifico.

Abbiamo generato una projection, l’abbiamo fatto senza usare fat event, e se proprio ci servisse lo potremmo fare usando messaggi. Se pensate a quello che abbiamo appena detto vi immaginate immediatamente che uno di quei component parli direttamente con il servizio di sua competenza, non c’è nulla di male. Una projection condivisa/mista, o IT/Ops che dir si voglia, genera per forza accoppiamento. È ovvio che al crescere dei component coinvolti l’accoppiamento temporale, o banalmente la rete scadente, fanno si che sia impossibile spedire perché tutti gli attori devono essere in grado di fare il lavoro richiesto nello stesso momento, ma nulla ci impedisce che i componenti in maniera trasparente rispetto all’ACL che li ospita si comportino in maniera più interessante:

image

L’accoppiamento c’è comunque ed è inevitabile in scenari come questo.

C’`e un altro caso, lampante, in cui una projection mista sembra essere l’unica soluzione, ma non è detto che lo sia. Ne parleremo.

Un’ultima considerazione: il fatto che in letteratura non esista il concetto di “projection mista” mi aiuta a pensare che non sia una cosa realmente necessaria.

Post in questa serie:

posted @ 16/11/2016 7.52 by Mauro Servienti

“Progettare una UI per Microservices” @ WPC 2016 con @OverNetE

Onorato, come sempre, di tornare anche quest’anno a WPC 2016. La sessione principale di quest’anno è:

Progettare una UI per Microservices

Come possiamo progettare una UI quando il back-end è composto da decine (se non di più) di Microservices? Abbiamo la giusta separazione e autonomia lato back-end, ma tutto alla fine deve tornare insieme lato front-end. Come evitiamo che si trasformi nel solito caos di spaghetti code? Come evitiamo che operazioni semplici si trasformino in un tornado di web request? Durante questa sessione costruiremo un esempio di UI per Microservices, usando AngularJS, in modo da capire a fondo cosa sia la Services UI Composition e come progettare e implementare con successo una UI per i nostri Microservices.

Dettagli: http://milestone.topics.it/events/wpc-2016-milano.html

L’obiettivo è quello di presentare il lavoro fatto in questi mesi in Particular per analizzare tutto ciò che ricade sotto il grande cappello della “Services UI Composition”, concetti di cui sto parlando da tempo anche su questo blog.

Ci vediamo a Milano, settimana prossima, il 29/11 alle: 15:45 in Sala Gialla.

posted @ 15/11/2016 7.38 by Mauro Servienti

Telepass: Il cambio password e la security, questa sconosciuta

Mi spiace prendermela sempre con gli stessi, ma i signori di Telepass sono molto bravi:

image

Quindi la questione è: per cambiare password non c’è bisogno di quella vecchia.
Questo fa si che chiunque, ad esempio il bimbetto in una famiglia, possa creare un attacco DoS alla famiglia stessa.

Lasciamo perdere il fatto del limite massimo di caratteri che mi fa solo pensare molto, ma molto male.

posted @ 14/11/2016 7.46 by Mauro Servienti

Modificare gli stati di un Work Item

Precedenti post sulla personalizzazione Work Item in TFS

1 – Tfs e customizzazione del process template
2 – Customizzare il Process Template, le basi
3 – Customizzare il process Template, aggiungere un campo ad un Work Item
4 – Customizzare il process template, regole per i campi aggiuntivi dei WI
5 – Personalizzare i Work Item di TFS, ancora qualche regola interessante
6 – Stati e transizioni
7 – Approfondiamo stati e transizioni

Post su personalizzazione VSTS

1 – Personalizzare il process template in VSTS
2 – Process template Ereditati in VSTS
3 – Aggiungere ad un Work Item un campo esistente in un altro template
4 – Creare un campo Custom

Per chi ha personalizzato il Workflow di un Work Item, sicuramente la possibilità di personalizzazione degli stati dei Work Item offerta attualmente da VSTS sembrerà alquanto primitiva. La personalizzazione offerta da VSTS infatti non permette ancora di definire un vero e proprio Worklfow, come invece è possibile fare personalizzando il template di TFS, ma permette solamente di gestire l’anagrafica degli stati.

Nella figura sottostante si può infatti vedere la parte di personalizzazione degli stati (1) di un Work Item (PBI), in cui è possibile aggiungere nuovi stati (2) oppure editare gli stati presenti (3).

image

Come si può vedere dalla figura, gli stati del Work Item sono raggruppati in aree, chiamate: Proposed, In Progress, Completed e Removed. Questi valori rappresentano una sorta di “macro categorie” per gli stati. La regola è che deve esistere almeno uno stato valido per ogni macro categoria. Questo garantisce al motore di poter sempre “ragionare” sulle “macro categorie” per generare le board di default e per tutti i comportamenti di default.

Le limitazioni di personalizzazione ed il concetto di Macro Categorie permette di rendere indolore l’aggiornamento, evitando che l’utente possa andare a modificare qualsiasi aspetto del Workflow. Si paga quindi la limitazione, ma si ottiene di contro un aggiornamento senza sorprese.

Per tutti gli stati già presenti, l’unica opzione possibile è quella di “nasconderli”, con l’opzione hide. Questo significa che lo stato è sempre presente nel template (garantendo quindi la compatibilità degli upgrade), ma non è più possibile associare questo stato ad un Work Item. Tutti i Work Item associati ad uno stato che è messo in Hide sono considerati in uno stato invalido.

image

 

In questo caso nella figura precedente è stato mostrato lo stato Approved messo in “hide”. A questo punto aprendo un Work Item in quello stato la UI forza a cambiarne il valore.

image

Come regola non è possibile mettere in hide tutti gli stati di una “Macro Categoria”, questo garantisce al motore di VSTS che ogni Work Item ha uno stato che al 100% appartiene ad una delle Macro Categorie.

La tecnica di mettere uno stato in Hide, previene una delle personalizzazioni che maggiormente rendono complicati gli upgrade, la rimozione di uno degli stati base.

Si può naturalmente creare un nuovo stato e le uniche opzioni che possono essere configurate sono: il nome, la Macro Categoria ed il colore.

image

A differenza degli stati base, gli stati nuovi aggiunti dall’utente possono essere rimossi. L’effetto è simile a quello che si ha con l’hide degli stati di default. In questo caso però lo stato verrà rimosso completamente dalla lista e potrà chiaramente essere riaggiunto in seguito. Anche se lo stato viene rimosso i valori storici rimarranno, per cui nella storia dei vari Work Item le transizioni da e per quello stato saranno sempre presenti nella storia. Tutti i Work Item che si trovano attualmente in uno stato rimosso sono  in uno stato non valido e debbono essere corretti prima di poter essere salvati nuovamente. (analogamente a quanto succede con l’Hide)

Purtroppo in questa prima versione la personalizzazione si ferma qui e non si  hanno altre opzioni. Di base la mancanza maggiore che si ha rispetto alla personalizzazione completa è l’impossibilità di definire un vero workflow, stabilendo le transazioni tra gli stati. Questo impedisce anche di poter mettere security tra la transazione degli stati, e di fatto è quindi possibile muoversi da qualsiasi stato in qualsiasi altro stato di destinazione.

Sebbene questa personalizzazione sia limitata, permette comunque di poter aggiungere stati e garantire di adeguare la nomenclatura del flusso al proprio processo.

Una volta terminata la personalizzazione degli stati, è necessario aggiornare la configurazione nella Kanban Board. Ad esempio avendo messo in Hide lo stato Approved per il PBI la configurazione di default lamenta questo errore:

image

In questo caso la colonna “Approved” non è più valida perché referenzia lo stato “Approved” del Work Item Type PBI, che invece è stato messo in uno stato Hide.

E’ sufficiente specificare un nuovo stato valido per tutte le colonne della Kanban Board per risolvere l’errore. Ad esempio potremmo voler tracciare il fatto che sia i Bug che i PBI hanno una fase di Valutazione, che concettualmente appartiene alla categoria “In Progress” perché implica che alcune risorse sono al lavoro su di essi. In questo caso è stata aggiunta la colonna “Evaluating” che cataloga i bug in Triage ed i PBI in fase di Analisi.

image

In questo caso la colonna di Evaluating ha un significato differente per Bug e PBI, nel primo caso si sta facendo Triage, mentre nel secondo caso si sta analizzando il PBI, magari producendo gli Storyboard.

Anche in questo caso, sebbene con le dovute limitazioni, è possibile con pochi click adattare il Processo di VSTS al proprio modo di lavorare e non viceversa.

Gian Maria

posted @ 12/11/2016 12.19 by Gian Maria Ricci

Una cosa alla volta, una cosa alla volta.

Nelle piccole realtà o nella solitudine di una Partita IVA la diversificazione tende ad essere controproducente:

La diversificazione è la crescita basata su nuovi mercati e nuovi prodotti. Un'impresa che opera in più settori è, quindi, un'impresa diversificata.

Fonte: https://it.wikipedia.org/wiki/Diversificazione_(strategia)

Concentrarsi su una cosa sola aiuta a mantenere focus e a incanalare le energie dove serve. Internamente siamo soliti dire che avere i piedi in più scarpe è un segno di insicurezza, tende ad evidenziare il bisogno di avere più appoggi o più vie di fuga, solo che una realtà piccola o solitaria non è detto che si possa permettere il costo intrinseco del mantenere i piedi in più scarpe.

Rischiate di fare la fine dei quei sedicenti consulenti che per mantenere un numero di clienti che non si possono permettere abbassano drasticamente la qualità o, peggio, cominciano a mentire qua…e la…e poi ancora qua.
(nessun riferimento implicito a nessuno, ma ne ho visti tanti fare così)

posted @ 11/11/2016 8.22 by Mauro Servienti

Latest Images

From miscellaneous
From miscellaneous
From miscellaneous
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini