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 - 714
  • Posts - 31172
  • Articles - 309
  • Comments - 91649
  • Trackbacks - 251078

Bloggers (posts, last update)

Latest Posts

Aurelia e ASP.NET Core: la strana coppia

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!

posted @ 28/09/2016 13.49 by Giorgio Di Nardo

Services UI Composition – materiale

image

In effetti mi sono dimenticato anche questo :-) Di materiale ce ne è già un po’, sparso:

Post in questa serie:

Piccolo spazio pubblicità:

Tratterò di questi temi, e molto altro ancora, in un workshop durante l’edizione milanese di Codemotion 2016: Microservices development deep dive.

posted @ 28/09/2016 9.35 by Mauro Servienti

MVP: So Long, and Thanks for All the Fish

Prima o poi doveva finire, e così è stato. 10 anni, intensi e interessanti.

Grazie :-)

posted @ 28/09/2016 7.13 by Mauro Servienti

"Microservices development deep dive" @CodemotionIT in Milan: Saga

Volete capire come progettare e gestire i cosiddetti “long running busness process”  in un mondo basato su Microservices in maniera affidabile ed efficace?

Workshop: Microservices development deep dive.

codemotion-workshop

Il programma, parte 3: Saga

Il workshop è diviso in 4 macro-blocchi, ogni blocco corredato da esempi ed esercizi. La terza parte evolve dalla sessione precedente introducendo il concetto di “long running business process” o se vogliamo, in maniera più volgare, workflow; affronteremo quindi, dal punto di vista architetturale prima e tecnologico poi, concetti come Saga, Orchestrator e Workflow al fine di comprendere a fondo come coordinare il lavoro quando quest’ultimo è suddiviso ed eseguito da Microservices diversi.

Obiettivi

Il workshop mira a sviscerare dalla A alla Z cosa sono i Microservices, quale sia il loro rapporto con le architetture SOA, come gestire la comunicazione tra Microservices e tutte le problematiche legate al deploy. Ponendo attenzione anche ad un dettaglio spesso dimenticato come la necessità di visualizzare informazioni provenienti da diversi Microservices su una singola UI, coerente e consistente.

La logistica

Il 24 Novembre, durante l’edizione milanese di Codemotion 2016 avrò il piacere e l’onore, oltre che l’onere, di erogare il workshop “Microservices development deep dive”.
Onere, ed onore, perché è la versione italiana del workshop che noi di Particular generalmente facciamo con Udi Dahan, il nostro CEO, in inglese in giro per il mondo.

Per maggiori informazioni e iscrizioni: http://milan2016.codemotionworld.com/workshop/microservices-development-deep-dive/

posted @ 27/09/2016 9.13 by Mauro Servienti

Process template Ereditati 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

Come detto nel precedente post, la personalizzazione dei Process Template in TFS porta con se il rischio di dovere poi effettuare aggiornamenti manuali dopo un upgrade ad una nuova versione di TFS. In VSTS questa situazione è inaccettabile, dato che non è pensabile che ogni tre settimane, dopo che è stato rilasciato il nuovo sprint, qualcuno debba andare ad effettuare operazioni manuali di aggiornamento.

Per ovviare a questo problema Microsoft ha introdotto una struttura di personalizzazione completamente nuova per VSTS e che sarà in futuro disponibile anche per TFS. Il concetto alla base di questa nuova modalità si chiama Process Template Ereditato, che permette di personalizzare un template senza cambiare quello base (evitando il problema degli aggiornamenti) fornendo inoltre una interfaccia di personalizzazione completamente Web.

Il primo passo è aprire la sezione di amministrazione dei processi, raggiungibile dal menu “Process”

image

Da questa pagina si può notare che ogni processo ha un menù contestuale che contiene alcune opzioni ammissibili su quello specifico processo. Di base quindi l’accesso ai process template non si effettua più tramite i vecchi file XML ma si ha pieno supporto tramite una interfaccia grafica che guida l’utente.

image

La voce New team project permette la creazione di un nuovo Team Project basato su questo processo, export permette invece di esportare il processo in uno Zip, esattamente come avviene per TFS, ma in questo caso  è di scarsa utilità perché non è chiaramente presente una funzione di “import”. Non è infatti possibile modificare un process Template base, per evitare appunto problemi durante l’aggiornamento. Su un template base si può solamente

  • Disabilitarlo (non è possibile più creare Team Process con questo template)
  • Impostarlo come default (verrà presentato come processo di default nel Wizard di creazione nuovo Team Project)

Come detto non è possibile andare a modificare un processo base (l’icona del lucchetto è evocativa). Per quanto riguarda la voce “Change team project to use xxxx” purtroppo si intende un cambio di processo tra processi ereditati; non è ancora possibile convertire un Team Project tra CMMI o Agile o SCRUM o viceversa. E’ quindi ancora impossibile convertire un Team Project passando da uno dei processi base ad un altro.

La voce che interessa è la “create inherited process” che permette di creare un nuovo process template basato su un processo base e che può poi essere personalizzato. Il concetto è infatti quello di creare un nuovo progetto che eredita dal base, effettuare su di esso le personalizzazioni per non intaccare il progetto base. In questo modo ogni aggiornamento del processo base con  un upgrade, si rifletterà nel processo ereditato. Inoltre l’engine di VSTS / TFS è a conoscenza di tutte le personalizzazioni fatte nel processo ereditato, e può quindi sempre sapere come comportarsi.

image

Come si può vedere la creazione di un nuovo processo ereditato è molto semplice, basta fornire un nome ed una descrizione ed il gioco è fatto. Una volta che si è creato un nuovo processo ereditato, è possibile creare nuovi Team Project basati su di esso.

image

Se si hanno già invece dei Team Project che sono stati creati sulla base di un Process Template base (in questo caso CMMI) è possibile cambiare process template assegnando un process template ereditato.

image

In questo caso la voce “Change team projects to use Custom CMMI”, che mostrerà una lista di Team Project basati su CMMI che possono essere migrati al nuovo processo “Custom CMMI”. Si ricordi che se un Team Project è stato creato con SCRUM o Agile non può utilizzare un custom process che è ereditato da CMMI e viceversa.

image

Non è possibile gestire processi che ereditano da un processo ereditato, la gerarchia è per ora limitata ad un solo livello. Non è inoltre nemmeno possibile migrare un Team Project direttamente tra due processi ereditati dallo stesso processo padre.

Una nota a parte merita la security, che permette di definire chi può cancellare, editare ed amministrare la sicurezza dei processi ereditati, in questo modo è possibile restringere le utenze che hanno la possibilità di andare a personalizzare i process template.

image

Concludendo, in VSTS non è possibile editare direttamente un Process Template base, ma è possibile creare un Process Template ereditato e creare nuovi Team Project basati su di esso, oppure migrare Team Project esistenti al nuovo processo (solamente se i processi sono stati creati partendo dal processo base).

Nei prossimi post verranno mostrate le personalizzazioni disponibili in per un process template ereditato.

Gian Maria.

posted @ 24/09/2016 11.14 by Gian Maria Ricci

Personalizzare il Process Template in VSTS

Sono passati alcuni anni da quando ho fatto una serie di post sulla personalizzazione dei Process Template in Team Foundation Server. Potete trovare tutti i vecchi post in questa lista:

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

Sebbene questa serie di post non copra in modo esaustivo tutte le personalizzazioni possibili, costituisce una buona introduzione da cui partire per personalizzare la gestione dei Work Item in TFS.

La barriera maggiore che si incontra è pero il rischio di incontrare difficoltà nell’aggiornamento di TFS ad una nuova versione. In realtà si può sempre aggiornare indipendentemente dalla personalizzazione dei processi, ma dopo avere fatto l’aggiornamento del server, è necessario andare ad aggiornare (eventualmente) tutti i processi di tutti i Team Project. Questo accade perchè alcune nuove funzionalità introdotte nelle nuove versioni si basano su novità introdotte nei template. Essendo i template di fatto dei file XML, il sistema può aggiornare in maniera automatica i vecchi processi se essi non sono stati modificati (conosce il vecchio XML sa come portarlo al nuovo XML). Purtroppo invece, in caso di modifica, non è detto che l’aggiornamento automatico riesca, dato che il tool non è più in grado di riconoscere il formato originale. In questo caso l’aggiornamento deve essere fatto manualmente.

In realtà l’intervento manuale non è che sia eccessivamente complicato, se si è lavorato bene si dovrebbe possedere nel source control tutta la storia delle proprie modifiche al process template, e la situazione peggiore che si può presentare è quella in cui voi dobbiate

  • Scaricare il template aggiornato dopo l’aggiornamento di TFS
  • Riapplicare al template tutte le modifiche effettuate.

Ad esempio se siete partiti dalla versione X dello scrum, ed avete effettuato su di esso una serie di modifiche, dopo avere aggiornato TFS all’ultima versione vi trovate nella situazione in cui l’aggiornamento automatico del template non riesce. La soluzione è:

  • scaricate in locale la nuova definizione del template Scrum, ora in versione Y dove Y > X
  • procedete applicando le stesse modifiche che avete fatto al vecchio template (le avete nel source control vero?? :) )

Nel caso abbiate effettuato veramente tante modifiche, potete seguire la strada inversa, ovvero leggere da MSDN i cambiamenti fatti al template e riapplicarli sulla vostra versione personalizzata.

Il processo è descritto qui (https://www.visualstudio.com/en-us/docs/work/customize/update-customized-process-template), ed anche se non difficile, è spesso temuto da molti amministratori di TFS. Il problema principale che si incontra è che, a meno di non essere in una grande realtà, dove si hanno amministratori dedicati del proprio TFS, e che conoscono lo strumento molto approfonditamente, nelle piccole realtà l’amministratore del TFS è “causale” e spesso teme di poter generare problemi nell’upgrade manuale. Da quì deriva sicuramente una reticenza alla personalizzazione del template, perdendo quindi uno dei pregi maggiori di TFS.

Fortunatamente questi problemi stanno per finire, dato che in VSTS è stata già introdotta una differente metodologia di personalizzazione del template effettuabile direttamente da UI e che non impatta gli aggiornamenti. Questa funzionalità, verrà introdotta in una versione successiva (purtroppo ancora non definita) di TFS on-premise, come si può vedere dalla feature timeline.

image

Dato che con l’ultimo aggiornamento è possibile in VSTS andare ad aggiungere i propri Tipi Personalizzati di Work Items, siamo arrivati al punto in cui, per quanto riguarda la personalizzazione del process template, molto probabilmente chi usa VSTS è avvantaggiato rispetto a chi usa TFS on-premise. Dato che per anni la mancanza di personalizzazione del process template è stata probabilmente la maggiore mancanza di VSTS, è giunto il momento di effettuare una serie di post per introdurre il nuovo modello di personalizzazione di VSTS.

I vantaggi maggiori sono indubbiamente

  • Personalizzazione effettuata da UI WEB (Addio editing manuale di file XML)
  • Azzerare le problematiche di aggiornamenti
  • Spostare i Team Project tra differenti tipi di processo (per ora solamente tra processi ereditati come vedremo in seguito)

Stay tuned.

Gian Maria

posted @ 10/09/2016 16.39 by Gian Maria Ricci

Bertelliiii…self-management ne abbiamo?

Parafrasando: https://youtu.be/N6uUeh8IDqo?t=127

Trovo che sia talmente importate che vale un post. Assolutamente da leggere, scettici in particolare: 7 cose (belle) che succedono quando il capo non controlla.

Ma anche:

Se dovessi riassumere i 4 post scegliendo una frase userei questa:

Chi critica un cambiamento di solito non ha speso alcuna energia per realizzarlo.

Cambiare è difficile.

Direi lapalissiano. Meno lapalissiano è che non esiste la ricetta giusta per il cambiamento che vogliamo in un certo contesto.

Se il vostro obiettivo da neopatentati è guidare come un pilota di Formula 1, non c’è una ricetta giusta per voi e non vi basta osservare, anche in maniera super dettagliata il risultato finale per imparare come si fa.

Il percorso da neopatentato a pilota di Formula 1 lo dovete fare tutto, coadiuvati nel vostro cambiamento da linee guida, non una ricetta, e osservazione del risultato finale al fine di carpire dettagli importanti, dettagli che probabilmente saranno sempre più utili più vi avvicinate al risultato finale.

Questo in soldoni vuol dire che il percorso dal punto dove siete oggi alla destinazione scelta lo dovete fare tutto.

La meta può essere fuorviante

Nell’esempio di cui sopra abbiamo in apparenza un obiettivo preciso, in apparenza perché durante il nostro percorso evolutivo potremmo scoprire che il pilota professionista di rally ci attira di più e a fronte di un cambio così radicale, nonostante siano tutti e due piloti professionisti di macchine da corsa, il percorso deve necessariamente cambiare.

Questa cosa è ancora più vera quando parliamo di self-management, provare per credere. Dire a freddo voglio passare da un’azienda tradizionale, fatta di gerarchie rigide e manager (sto iper-semplificando) ad un’azienda auto-gestita è la peggior cosa che potete fare a voi stessi, perché il risultato sarà che tutte le forze punteranno ad un obiettivo noto cercando di seguire una ricetta e osservando e cercando di replicare nel dettaglio quelli che sono i modelli di riferimento.

Non funziona. L’unica cosa che potete dire è: Non voglio più un’azienda tradizionale.

Una volta che il problema è condiviso può iniziare il lungo e faticoso percorso di cambiamento alla ricerca di quella che è la vostra destinazione. Ovvio che osserverete e cercherete di carpire cosa hanno fatto gli altri, ma il tutto dovrà essere filtrato, adattato e infine calato nel vostro contesto.

Lungo, faticoso e lastricato di insidie. È un fatto, non scappate, la ricetta per il successo non esiste.

Adesso vado in vacanza. Ciao.

posted @ 21/09/2016 7.41 by Mauro Servienti

Services UI Composition - tecniche di recupero delle informazioni: Proxy

Abbiamo parlato di IT/Ops e Batching, un ultimo approccio ricade sotto il nome di Proxy.

Quello che abbiamo detto è che a fronte di una domanda è sempre possibile identificare un responsabile per la risposta, parlando di tecnologia potremmo quindi dire che a fronte di una richiesta HTTP identificata da un URI c’è sempre un endpoint che si prenderà carico di gestire/orchestrare la risposta.

Per uno sviluppatore .NET viene quasi istintivo tradurre la frase precedente in “…a fronte di una richiesta HTTP identificata da un URI c’è sempre una Action MVC che si prenderà carico…”.

Ma HTTP non è ASP.Net MVC, nulla ci vieta, ad esempio, di piazzare davanti al nostro bel web server un reverse proxy, come ad esempio nginx, che ci permette di fare una serie di cose alquanto interessanti:

  1. prendere in carico la richiesta HTTP e in base ad una serie di regole decidere chi sia responsabile di gestirla
  2. data la risposta del responsabile, risposta che può contenere una serie di TAG/Attributi custom, applicare altre regole per decidere se ci sono altri attori che devono partecipare a quella risposta
  3. invocare gli altri attori
  4. aggregare le risposte così ottenute per comporre una risposta HTTP completa

È molto semplice e lineare, e se lo volete vedere in azione vi consiglio questa bella sessione del Team di Auto Scout 24.

È ancora più semplice: è tutto oro quel che luccica?

Come al solito non esiste la soluzione definitiva. Un reverse proxy come nginx è ovviamente un approccio interessante, approccio che porta con se tanta semplicità apparente e un paio di insidie nascoste, che il sottoscritto tende ad identificare sotto il termine di Orchestrator. E se a qualcuno si sono rizzati i peli sulla schiena pensando a BizTalk ha pensato bene.

All’aumentare della complessità le regole che abbiamo citato diventano il collo di bottiglia della soluzione di cui sopra, non necessariamente in termini prestazionali, quanto piuttosto in termini di gestione e complessità. Abbiamo cioè un robo che alla lunga diventerà il centro della nostra attenzione, robo in cui sarà concentrata tanta logica di business nonostante il robo non sia assolutamente pensato per gestire logica di business.

Ma anche un reverse proxy resta un possibile approccio che in certi scenari potrebbe rivelarsi semplice e diritto al punto con pochi fronzoli.

Post in questa serie:

Piccolo spazio pubblicità:

Tratterò di questi temi, e molto altro ancora, in un workshop durante l’edizione milanese di Codemotion 2016: Microservices development deep dive.

posted @ 19/09/2016 8.15 by Mauro Servienti

Services UI Composition - tecniche di recupero delle informazioni: Batching

Abbiamo introdotto una prima modalità di recupero dei dati, modalità che abbiamo definito IT/Ops. Vi ricordo che IT/Ops è un termine abbastanza generico nel mondo SOA che tipicamente viene usato per identificare quei componenti prettamente tecnologici il cui scopo è gestire l’aggregazione di dati.

Il problema che vogliamo risolvere credo sia abbastanza chiaro, nel caso nel post precedente ne parliamo in dettaglio.

Batching

Come dicevamo il sogno sarebbe poter dire al client, ma soprattutto al team di sviluppatori che gestiscono il client: fai quello che vuoi come l’hai sempre fatto. Per capirci meglio immaginate uno scenario basato su una Single Page Application, quello che sarebbe bello è evitare di avere per forza il concetto di IT/Ops nel client e lasciare che il client possa emettere tutte le richieste http che vuole e queste vengano in qualche modo raggruppate come meglio possibile.

Si-Può-Fare <cit.>

Come al solito un’immagine vale mille parole:

image

Quello che succede è “abbastanza” semplice:

  1. Ottengo la lista delle chiavi degli elementi che devo visualizzare
  2. Notifico il mondo client che la lista di chiavi è pronta
  3. Ogni componente client emette tutte le richieste http che vuole
  4. Il “client side request tracker”
    1. intercetta, ogni framework per SPA vi permette di farlo, tutte le richieste uscenti
    2. accumula le richieste su base temporale, quindi fintanto che per x millisecondi non c’è una richiesta, accumulo
    3. Sfruttando il supporto di HTTP per il batching emette una richiesta HTTP batch
  5. La risposta che torna indietro è automaticamente gestita da HTTP e spacchettata

È molto, ma molto, più semplice: è tutto oro quel che luccica?

Direi che la semplicità della cosa è evidente, se non altro superficialmente evidente. Ci sono due insidie però che devono essere attentamente valutate prima di scegliere questa strada oppure quella basata sui concetti di IT/Ops:

  1. Nel raggruppare le richieste HTTP uscenti bisogna tener conto della destinazione, ergo non possiamo banalmente raggruppare, ma dobbiamo raggruppare ciò che va verso Shipping con Shipping e Warehouse con Warehouse, non è complesso ma come sappiamo il diavolo sta nei dettagli
  2. Una volta che abbiamo raggruppato client side, abbiamo solo spostato il problema, è questa è una rogna:
    1. La richiesta HTTP Batch arriva al server
    2. Il server in maniera trasparente la “spacchetta” e invoca le risorse come se fossero richieste fisicamente separate
    3. Questo comporta che se stiamo richiedendo 10 descrizioni di prodotti diversi, abbiamo 1 richiesta HTTP uscente, ma 10 diverse esecuzioni server side e una risposta HTTP. Le 10 esecuzioni server side sono nuovamente il select n + 1 da cui stiamo scappano

L’unica vera soluzione è quindi scrivere, se la tecnologia server side lo consente, un “HTTP batch handler” che sappia come gestire questo scenario. Ecco, io personalmente, eviterei anche.

Ci sono ancora due possibili approcci che sono una variazione sul tema IT/Ops o Batching, approcci che per certi versi possiamo raggruppare sotto il cappello Proxy. Un po’ di pazienza e svisceriamo anche quello.

Post in questa serie:

Piccolo spazio pubblicità:

Tratterò di questi temi, e molto altro ancora, in un workshop durante l’edizione milanese di Codemotion 2016: Microservices development deep dive.

posted @ 16/09/2016 8.06 by Mauro Servienti

"Microservices development deep dive" @CodemotionIT in Milan: Pub/Sub

Volete capire come progettare e gestire la comunicazione tra Microservices in maniera affidabile ed efficace?

Workshop: Microservices development deep dive.

codemotion-workshop

Il programma, parte 2: Pub/Sub

Il workshop è diviso in 4 macro-blocchi, ogni blocco corredato da esempi ed esercizi. La seconda parte evolve dalla sessione precedente cominciando ad analizzare quali sono le tecniche di comunicazione intra-Microservices; affronteremo quindi, dal punto di vista architetturale prima e tecnologico poi, concetti come RPC, Pub/Sub e tutto il mondo legato alle code, come ad esempio RabbitMQ, per addentrarci anche nei meandri di DDD parlando di Ownership, Bounded Contexts e Aggregati.

Obiettivi

Il workshop mira a sviscerare dalla A alla Z cosa sono i Microservices, quale sia il loro rapporto con le architetture SOA, come gestire la comunicazione tra Microservices e tutte le problematiche legate al deploy. Ponendo attenzione anche ad un dettaglio spesso dimenticato come la necessità di visualizzare informazioni provenienti da diversi Microservices su una singola UI, coerente e consistente.

La logistica

Il 24 Novembre, durante l’edizione milanese di Codemotion 2016 avrò il piacere e l’onore, oltre che l’onere, di erogare il workshop “Microservices development deep dive”.
Onere, ed onore, perché è la versione italiana del workshop che noi di Particular generalmente facciamo con Udi Dahan, il nostro CEO, in inglese in giro per il mondo.

Per maggiori informazioni e iscrizioni: http://milan2016.codemotionworld.com/workshop/microservices-development-deep-dive/

posted @ 15/09/2016 7.30 by Mauro Servienti

DevOpsHeroes, 29 ottobre, Parma.

Sono felicissimo di poter partecipare a DevOpsHeroes, il 29 ottobre a Parma.

DevOps e scelte architetturali: due scenari reali

DevOps è principalmente cultura aziendale e di team, DevOps è una nuova visione in cui alcune di quelle che sono le barriere tra mondo dello sviluppo e mondo operations vengono abbattute al fine di generare sinergie inimmaginabili prima.

Vorrei raccontare due esperienze vissute in due scenari molto diversi tra loro, due scenari in cui DevOps è stato da un lato il traguardo di un processo evolutivo dal monolite ingestibile a SOA/Microservices e dell'altro invece DevOps è stato il motivo scatenante finalizzato a superare tutta una serie di ostacoli amministrativi e burocratici che rendevano impossibile il deploy in produzione.

Come si evince dall’abstract la sessione verte a raccontare due esperienze di vita vissuta, come direbbero a Pomeriggio Cinque con faccia contrita, esperienze che per motivi diversi hanno portato sia a DevOps che ad implementare un’architettura basata sui dettami di SOA.

O è il contrario? È SOA che ha portato a DevOps? :-)

Vi aspetto.

posted @ 14/09/2016 7.07 by Mauro Servienti

pouchdb.com

https://pouchdb.com


PouchDB is an open-source JavaScript database inspired by Apache CouchDB that is designed to run well within the browser.

posted @ 13/09/2016 16.44 by Alessandro Gervasoni

…e uso AdBlocker.

Ciao mi chiamo Mauro, vivo in pieno Digital Divide e uso un AdBlocker.

In perfetto stile anonima alcolisti ammetto che senza un AdBlocker la mia vita online, in particolare quella da lavoratore remoto, sarebbe ben peggiore di quello che è.

image

Non me ne vogliano quelli di Milano Today, ma loro malgrado sono stati il sito che mi ha fatto saltare all’occhio il problema.

Ebbene si, il 45% (86 in termini assoluti) delle richieste HTTP fatte, per caricare la sola home page, viene “usato” per operazioni relative alla pubblicità e al tracking. Io tendo a comprendere che la pubblicità sia una fonte di guadagno importante però mi sa che stiamo superando il limite.

full-mailbox

La banda è la mia e nella condizione di digital divide che vivo quella banda è preziosissima. Ripeto la pubblicità è probabilmente importante, dico probabilmente perché mi sembra di leggere che l’efficacia sia dubbia, ma forse stiamo esagerando.

posted @ 12/09/2016 8.03 by Mauro Servienti

"Microservices development deep dive" @CodemotionIT in Milan: UI-Composition

Volete scoprire come costruire una UI per Microservices efficace, funzionale e facile da manutenere?

Workshop: Microservices development deep dive

codemotion-workshop

Il programma, parte 1: UI per Microservices

Il workshop è diviso in 4 macro-blocchi, ogni blocco corredato da esempi ed esercizi. La prima parte si focalizza su come costruire una UI per i nostri Microservices, partiamo cioè da quello che in apparenza è il problema finale, che come vedremo non è assolutamente l’ultimo da affrontare, ma anzi uno dei primi.

Obiettivi

Il workshop mira a sviscerare dalla A alla Z cosa sono i Microservices, quale sia il loro rapporto con le architetture SOA, come gestire la comunicazione tra Microservices e tutte le problematiche legate al deploy. Ponendo attenzione anche ad un dettaglio spesso dimenticato come la necessità di visualizzare informazioni provenienti da diversi Microservices su una singola UI, coerente e consistente.

La logistica

Il 24 Novembre, durante l’edizione milanese di Codemotion 2016 avrò il piacere e l’onore, oltre che l’onere, di erogare il workshop “Microservices development deep dive”.
Onere, ed onore, perché è la versione italiana del workshop che noi di Particular generalmente facciamo con Udi Dahan, il nostro CEO, in inglese in giro per il mondo.

Per maggiori informazioni e iscrizioni: http://milan2016.codemotionworld.com/workshop/microservices-development-deep-dive/

posted @ 09/09/2016 10.46 by Mauro Servienti

Services UI Composition: consistenza eventuale

Torniamo a noi e prima di chiudere il discorso tecniche di recupero dei dati cerchiamo di dare una risposta al commento di Raffaele.

Commento che sottolinea che mi sono dimenticato di una cosa di cui ho parlato al compleanno di UGI e evidenzia come sia fondamentale la storia che vogliamo raccontare, storia che nel caso di questi post su UI Composition non è abbastanza ben definita, piuttosto, si sta trasformando mano a mano che li scrivo.

image

Ciao Mauro, leggo con piacere questa serie ma la domanda mi sorge spontanea.
In questo caso, non avrebbe senso esporti in GET una Projection, magari un bel DTO che rappresenta la tua riga template di dati da visualizzare?

Sbagliato?

No. Come ho già detto più volte quando si parla di architettura, in particolare, non ci sono scelte giuste o scelte sbagliate. Le scelte sono da calare in un contesto e in base al contesto possiamo fare valutazioni.

Se ho ben compreso il commento di Raffaele, nel caso sono più che lieto di essere smentito, possiamo rappresentare la cosa in questo modo:

image

Il diagramma li sopra funziona alla perfeziona, ma:

  • Ci obbliga ad introdurre un attore che non ha nulla a che con il business ma ha solo un ruolo tecnico, alla fine è una sorta di enorme cache;
  • Introduce un “single point of failure” obbligandoci a rendere quell’elemento altamente disponibile, cosa non necessariamente semplice;
  • Ci obbliga ad abbracciare il concetto di consistenza eventuale;
  • Ci impone di introdurre nuova infrastruttura per capire come “sincronizzare” i dati;
  • Complica un po’ le cose quando le strutture dati evolvono perché dobbiamo introdurre trasformazioni da qualche parte nel processo di sincronizzazione;

Sono tutti ma che ovviamente non sono bloccanti, dobbiamo però comprenderli e valutarli nel nostro contesto. Non sono a priori sbagliati. Uno solo è particolarmente rognoso a mio modo di vedere.

Consistenza eventuale

La consistenza eventuale è in alcuni scenari probabilmente un male necessario, ma se possiamo evitare il problema tout court è decisamente meglio. Diciamo che abbiamo fatto i compiti a casa e:

Cosa non sappiamo?

Non sappiamo se la sorgente ha un’informazione più aggiornata e se quello che vediamo noi sia quindi l’ultima informazione disponibile o meno. Abbiamo quindi necessariamente a che fare con dati definiti stale con poche, o nessuna, informazioni per aiutarci a gestire lo scenario.

Infine se diamo un’occhiata a come abbiamo ipotizzato i nostri servizi:

  • SAP, interno
  • Interno / API e hosting condivisi (o condivisibili)g
  • terze parti

Ci scontriamo con il dettaglio che tutti i servizi devono poter dialogare con il “robo” centrale, cosa sicuramente fattibile ma anche in questo caso è necessario valutare bene se il gioco vale la candela.

Services UI Composition

Ecco perché in molte realtà si sta cominciando ad affrontare il problema partendo da un angolo diverso, chiedendosi se non sia possibile eliminare in toto i possibili problemi di cui sopra spostandosi verso un approccio come il seguente:

image

Questa serie di post mira a approfondire questo secondo approccio,  evidenziando pro e contro perché ovviamente non è tutto oro quel che luccica. Le realtà che fino ad oggi ho supportato in questo approccio sono “scappate” da quello precedente perché al crescere intrinseco dei sistemi e delle realtà stesse l’approccio di prima stava cominciando a vacillare.

Post in questa serie:

Piccolo spazio pubblicità:

Tratterò di questi temi in un workshop durante l’edizione milanese di Codemotion 2016: Microservices development deep dive.

posted @ 07/09/2016 10.12 by Mauro Servienti

Dimenticavo, un po’ di autostima non fa male.

Allenamento e disciplina sono fondamentali, ma non basta. Ci vogliono anche dei buoni preparatori e un briciolo di autostima di certo non fa male:

image

Quindi vedere che i lettori ci sono è sicuramente uno stimolo per andare avanti ed è anche gratificante. Poi…non cambierò la mia strategia perché non ho come obiettivo finale quello di massimizzare i lettori, altrimenti non bloggherei di lunedì, non bloggherei alle 8 circa, ma dopo le 10.30 e prima delle 14, non bloggherei seguendo vari percorsi spesso casuali e poco organici. Scrivo perché piace a me e in alcuni casi ha un fine simil-peripatetico, scrivere mi aiuta a mettere in fila e razionalizzare.

posted @ 05/09/2016 7.29 by Mauro Servienti

Novità in VSTS nella release del 2 settembre

In questa nuova release le novità sono veramente succose, sintomo che il team lavora sodo anche durante l’estate. Indubbiamente la prima importante novità è la possibilità di creare nuovi tipi di Work Item, funzionalità che va a ridurre sempre più il gap di personalizzazione che si ha in VSTS rispetto ad una installazione TFS on premises.

La novità è cosi succosa che ha un post dedicato dove verrete guidati nella creazione di un nuovo Work Item Type nel vostro account VSTS. L’aspetto interessante è la possibilità di includere il nuovo Work Item Type nelle varie board, dando cosi la possibilità di personalizzare molto il vostro account.

custom wit 5

Proseguiamo invece con le altre novità “minori”, come ad esempio la sezione history dei Work Item completamente ridisegnata per una maggiore leggibilità. Ora le modifiche sono raggruppate per range di date ed hanno una navigabilità decisamente migliore, per cui è possibile scegliere una modifica nella history e vedere il dettaglio in un pannello separato.

 

Redesigned work item history tab

Per quanto riguarda la build, la visualizzazione delle code è stata migliorata, in modo da visualizzare in maniera più chiara le build in coda.

Redesigned Queued Builds page

 

Tra le modifiche interessanti troviamo anche la possibilità di richiedere un feedback direttamente dal menù dei work item di tipo feature o PBI Questo permette in maniera molto veloce di creare una richiesta di feedback verso uno StakeHolder.

The new Request Feedback form

Questo scatenerà una richiesta di feedback, che verrà poi eseguita direttamente con lo strumento di Exploratory Testing presente come addin di Chrome.

Creating a new feedback response

Per chi come me ha usato molto i Database Project per Sql Server abbiamo ora la possibilità di eseguire script di deploy verso Sql Azure.

The enhanced Azure SQL Database deployment task

Come sempre queste non sono tutte le novità, per cui vi rimando al post ufficiale.

Happy TFS.

posted @ 03/09/2016 10.33 by Gian Maria Ricci

Il fatto che non sia facile non significa che debba essere difficile (was: risultati di un interessante esperimento)

Ho iniziato a leggere “Everybody Writes”:

image

Poi per motivi lavorativi mi sono dato ad altro, ma ci tornerò. Ann Handley inizia con un’osservazione interessante, dice (parafrasando) che chiunque può scrivere, chiunque, è solo ed esclusivamente una questione di allenamento.

Cioè, non sei mai andato in biciletta in vita tua, non ti puoi aspettare che al primo tentativo una tappa del giro d’Italia sia alla tua portata, ma ti puoi aspettare che con l’allenamento giusto una tappa del giro d’Italia diventi alla tua portata. C’è poi il problema che il giro d’Italia è fatto di tante tappe, di nuovo allenamento.

Ann sostiene che scrivere sia uguale, e vi dice di provarci.

Ci ho provato.

Mi sono messo d’impegno e ci ho provato, come ogni buon allenamento che si rispetti richiede disciplina, molta disciplina. Verso fine aprile mi sono detto: OK, da settimana prossima 3 post la settimana, lunedì, mercoledì e venerdì. Stessa ora, alle 8.30 del mattino.

Esattamente come se dovessi uscire in bicicletta. Non c’è santo che tenga, il post deve essere pubblicato, unica scusa accettabile è sono in viaggio con la famiglia. inoltre divieto assoluto di pianificare i post, non si fa un allenamento la domenica e lo si spaccia per quello del lunedì.

Il primo mese è stata una fatica bestiale, non avevo idee, se le avevo la frizione all’iniziare a scrivere era elevatissima, quando iniziavo era una fatica bestiale portare a termine il compito.

Ci sono riuscito.

Sono passati 4 mesi, e ho pubblicato 55 post a fine agosto.

Facile a dirsi

image

Nazareno commenta:

Facile a dirsi... i cambi di mindset sono complessi

Ovvietà mi permetto di dire io :-) non usatela come scusa. Se abbiamo un obiettivo e pianifichiamo bene l’allenamento i cambi di mindset sono molto meno complessi di quello che ci si aspetta. Gli errori tipici sono aspettarsi che lo cose siano facili, che le cose cambino da sole e da un giorno con l’altro, che la gente ci aiuti e che noi non dobbiamo fare nulla.

Se penso allo scrivere su un blog, tipicamente le risposte che sento sono:

  • Non so di cosa scrivere. Balle! neanche io sapevo di cosa scrivere a fine aprile, adesso ho una lista di “abstract” infinita che si allunga di giorno in giorno. Allenamento, anche la nostra fantasia, o la nostra capacità di astrazione richiede allenamento;
  • Quello che scrivo non interessa a nessuno. Balle! Quello che voi pensate sia interessante per un pubblico che non conoscete è sicuramente diverso da quello che il potenziale pubblico trova interessate;
  • Ma non ho tempo. Davvero? Non trovi 15 minuti per scrivere un post come questo? Hai un problema molto serio. Molto serio, e non è scrivere.

Non dico che sia facile, dico che si può fare.

E dico che è solo ed esclusivamente una questione di allenamento. L’allenamento vi porta a scrivere alla svelta, a fare meno errori, ad essere più precisi e diretti al punto, con meno fronzoli che richiedono tempo. L’allenamento è quello che vi da la confidenza per dire: si può fare. (cit.)

Questo post non vuole essere un invito a scrivere, vuole semplicemente essere un monito a quelli che “si ma loro…”, vi faccio un altro esempio: pensate che Igor e Alessandro vivano in una torre d’avorio foraggiata dal Gaggi? Pensate che  produrre tutti i sacrosanti giorni DevInPills sia una cosa facile?

O pensate forse che Andrea Benedetti si sia alzato dal divano un giorno e abbia detto domani vado a fare la 4K Alpine Endurance? 350Km e 25.000 metri di dislivello positivo…non scherziamo. Si è fatto un culo infinito per arrivare li.

No, no e no: impegno, allenamento, devozione e disciplina. All’inizio è una fatica pazzesca, poi pian piano la tappa del giro d’Italia diventa sempre più un obiettivo raggiungibile.

Allenamento e disciplina

Due facce della della stessa medaglia, senza disciplina l’allenamento è impossibile, bisogna però allenarsi anche ad essere disciplinati. Importante è scegliere l’obiettivo giusto, significativo, lontano ma raggiungibile. Si può sempre scegliere un nuovo obiettivo raggiunto il primo.

posted @ 02/09/2016 9.20 by Mauro Servienti

I “fat event” non esistono

Nel mio peregrinare nei meandri del mondo SOA e in particolare di Services UI Composition mi sto sempre più convincendo che i così detti “fat events” non hanno ragione di esistere. È un’affermazione forte lo so, e non è ancora una convinzione, ne parleremo ancora magari cercando di sviscerare la questione fino in fondo.

Tipologie di eventi

Se penso alla parola “event” la penso declinata nei seguenti modi:

  • Domain Event
  • Thin Event
  • Fat Event

Abbiamo già detto, e approfondito, che Domain Event è un caso a se, spartisce con gli altri due la parola event e poco altro. Un “thin event” rappresenta il minimo sindacale di informazioni necessarie, quindi:

  • Il nome, ergo cosa è successo
  • Uno o più ID, chiavi, che identificano la/le risorsa/e coinvolte

Un “fat event” porta con se anche informazioni aggiuntive.

Ecco, a parte scenari di integrazione, partendo dal presupposto che il sistema sia architettato bene, non trovo casi d’uso per i “fat event” e in scenari di integrazione non sono eventi ma messaggi. OK, quest’ultima è semantica quasi fastidiosa come la distinzione tra tasse e imposte, perdonatemi :-)

Alla fine della serie su UI Composition spero di trovare una risposta definitiva.

La serie:

posted @ 31/08/2016 9.15 by Mauro Servienti

Questo è un post di test

Questo è un post di test, non consideratelo. :)

posted @ 30/08/2016 19.52 by Gian Maria Ricci

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