App design for Windows 10 Universal Windows Platform.
Manage different devices and screen sizes (phones, tablet, pc, xbox, Hololens Surface Hub, IOT)
Scaling algorithm, converged control set, navigation patterns.
ARCHITETTURA DI UN'APPLICAZIONE SCALABILEDotNetCampus
Questa sessione tratterà delle implementazioni di architetture robuste e scalabili, in scenari di sviluppo applicativi rientranti nella tipologia dei Software as a Service. In particolare vedremo come accopiare le feature e le necessità del SaaS con servizi propri presenti su Azure; con focus su web, servizi mobili, data, e notification.
Slide Tesi di laurea:
Separazione dei ruoli tra Designer e Developer nello sviluppo di applicazioni Desktop: uso di WPF e del pattern Model-View-ViewModel
App design for Windows 10 Universal Windows Platform.
Manage different devices and screen sizes (phones, tablet, pc, xbox, Hololens Surface Hub, IOT)
Scaling algorithm, converged control set, navigation patterns.
ARCHITETTURA DI UN'APPLICAZIONE SCALABILEDotNetCampus
Questa sessione tratterà delle implementazioni di architetture robuste e scalabili, in scenari di sviluppo applicativi rientranti nella tipologia dei Software as a Service. In particolare vedremo come accopiare le feature e le necessità del SaaS con servizi propri presenti su Azure; con focus su web, servizi mobili, data, e notification.
Slide Tesi di laurea:
Separazione dei ruoli tra Designer e Developer nello sviluppo di applicazioni Desktop: uso di WPF e del pattern Model-View-ViewModel
Cos'è la UI Composition e che problemi può risolvere
Perchè MVVM e WPF sono importanti per la UI Composition
Il concetto di 'region' e 'UI Injection'
Analisi del toolkit PRISM di Microsoft e cosa comporta realizzarsene uno in proprio.
TYPESCRIPT, ANGULAR E BOOTSTRAP ASSIEME PER APPLICAZIONI REAL WORLDDotNetCampus
La recente affermazione in ambito web delle applicazioni rich basate su HTML5 e Javascript è diventato sorgente di una serie di librerie innovative e di strumenti che, se usati correttamente, possono semplificare enormemente lo sviluppo. In questa sessione sarà illustrato come sfruttare Typescript, in concomitanza con Angular e Bootstrap per realizzare applicazioni che sfruttino al massimo le possibilità dei browser e diano un feedback il più possibile simile alle applicazioni desktop.
OVERVIEW: Java secondo Microsoft
STRUMENTI:Java nel cloud
MODALITA’: Il Development life cycle secondo Microsoft
APPROCCIO: Stack cloud native basato su JAVA ed Azure
CAMBIAMENTO: Know how necessario per lo sviluppo su AZURE con Java
OPPORTUNITA: Use case di implementazione «first approach»
ASP.NET MVC è una piattaforma aperta costruita come un puzzle di componenti. Per personalizzare il comportamento dei componenti interni del sistema è quindi sufficiente rimuovere uno dei tasselli e sostituirlo con uno scritto da noi. Un'operazione resa semplice ed immediata dall'interfaccia Dependency Resolver.
Slide per l'ausilio alla presentazione od ad un corso veloce per lo sviluppo di Angular 2.
Comprende la struttura principale delle applicazioni di Angular, i componenti, le direttive, i servizi e pipes.
Breve panoramica sul typescript e sulle principali librerie.
Welcome to the (state) machine @ ExploreDDD 2019Mauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long running business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb.
This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind.
(It’s all right, I know where you’ve been)
Designing a ui for microservices @ .NET Day Switzerland 2019Mauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Welcome to the (state) machine @ Xe One Day Enterprise ApplicationsMauro Servienti
Ultimamente ci hanno stressato come non mai che stateful è il male. Tutto deve essere stateless, altrimenti non scala, non può essere altamente disponibile, ed è complesso da manutenere ed evolvere. Nonostante questo i sistemi software complessi, essendo basati su processi collaborativi, sono per natura stateful. I processi collaborativi, noti anche come long running business transactions, necessitano di interagiscono con risorse distribuite. L’approccio tradizionale basato su transazioni distribuite, anche se allettante, è una bomba pronta ad esplodere.
Pane quotidiano per le Saghe. Le Saghe consentono di modellare sistemi complessi senza la necessità di transazioni distribuite e coordinamento esterno. Vedremo cosa sono le Saghe, come possono essere usate per modellare domini complessi, e che ruolo giocano quando progettiamo sistemi basati sui concetti di “design for failures” e “eventual consistency”
(It’s all right, I know where you’ve been)
All our aggregates are wrong @ NDC Copenhagen 2019Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule.
In this talk, we’ll analyze what appears to be a straightforward e-commerce shopping cart. We’ll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we’ll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
Be like water, my friend @ Agile for Innovation 2019Mauro Servienti
L’acqua è quasi inarrestabile, basta un pertugio e si propaga. Basta un po’ di pressione e con facilità il pertugio diventa una voragine e lascia spazio ad una piena. La conoscenza e l’esperienza in un team possono essere come l’acqua. Il sapere deve poter scorrere senza freni, con solo degli argini che lo guidino al fine di evitare un’inondazione.
È possibile strutturare un’organizzazione al fine di garantire la diffusione del sapere? Quali sono i processi e gli strumenti che possiamo mettere in campo per essere certi che conoscenza ed esperienza siano diffuse, ma anche che non vi sia un’inondazione?
Lasciatevi trasportare da Mauro nei meandri di Particular Software, per scoprire come una realtà “dispersa” su 17 time zone gestisce collaborazione e condivisione del sapere. Analizzeremo sia i processi, che ci siamo creati, che gli strumenti digitali che usiamo quotidianamente.
Microservices architecture is it the right choice to design long-living syste...Mauro Servienti
Microservices all the thing! they say. Nowadays it seems that if architectures are not microservices based they are not worth the name. Is it really true? Do we really need a (micro)services based architecture?
We should design our systems with longevity, manutenability, and evolution simplicity in mind. Not hype. Long living systems are our primary goal. We'll analyze most common errors and we'll see how architecture can be a game changer in systems design.
Join Mauro in a journey that aims to disclose what it means to build a distributed system based on a (micro)services oriented architecture.
Titles, abstracts, and bio matter... oh my! @ Global Diversity CFP Day 2019Mauro Servienti
Sei uno studente che deve presentare una tesi? Un manager che deve presentare un report ai colleghi? Un esperto che deve presentare i risultati di uno studio ad una conferenza? O semplicemente avresti voglia di parlare al mondo di ciò che ti appassiona ma non sai da dove cominciare?
Living organizations, particular software @ do IT Better ParmaMauro Servienti
Siamo così abituati ad organizzazioni basate sul tradizionale organigramma che diamo per scontato che sia l'unica opzione.
Un approccio differente è possibile?
Quando sono entrato in Particular, era un'organizzazione tradizionale, sebbene distribuita. Avevamo manager e una gerarchia. Un anno dopo la decisione di rivoluzionare tutto. La miglior decisione di sempre. Intraprenderemo un viaggio che ci permetterà di scoprire che un modello organizzativo diverso è possibile, che un processo decisionale dall'alto verso il basso non è l'unica opzione e che possiamo organizzare la vita lavorativa intorno a quella privata in funzione di un ottimo life-work balance.
Welcome to the (state) machine @ Crafted SoftwareMauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb. This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind. (It’s all right, I know we’re you’ve been)
PO is dead, long live the PO - Italian Agile Day 2018Mauro Servienti
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Design a UI for your Microservices @ Do IT BetterMauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Microservices and pineapple on pizza what do they have in common - dos and ...Mauro Servienti
Microservices è una delle buzzword del momento. Sembra quasi che un'architettura a microservices sia fondamentale. È veramente così? Faremo un tortuoso viaggio tra le buzzword del momento cercando di districarci tra cosa è bene e cosa è meno bene, ma soprattutto perché. Obiettivo è quello di comprendere quali sono i limiti di certe scelte architetturali e quali gli errori da non commettere. Il tutto nell'ottica di garantire ai nostri sistemi 'lunga vita e prosperità' (cit.)
All our aggregates are wrong (ExploreDDD 2018)Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule. In this talk, we'll analyze what appears to be a straightforward e-commerce shopping cart. We'll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we'll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Shipping code is not the problem, deciding what to ship it is!Mauro Servienti
This document discusses an organization's approach to prioritizing work and developing software. It emphasizes focusing on solving clear problems rather than executing on estimates or deadlines. Work is organized into buckets or strategies, each with a dedicated squad prioritizing issues. Issues go through an intake process to clearly define the problem before being selected for a cross-functional task force to implement a solution. The goal is for squads to proactively address problems rather than reactively execute work.
GraphQL - Where are you from? Where are you going?Mauro Servienti
GraphQL, inventato da Facebook per risolvere un problema molto specifico, è diventato uno standard. Le applicazioni client lo utilizzano per leggere e manipolare i dati esposti dai server back-end. È così flessibile che recentemente GitHub l'ha adottata per tutte le sue API. Il paradigma è semplice e tuttavia potente tale da consentire la manipolazione flessibile e la loro composizione da molte fonti diverse. Mauro offre in questo intervento un'introduzione a GraphQL, partendo da una breve storia e poi analizzando come GraphQL risolva i tipici problemi in cui i progettisti API e i loro consumer si possono imbattere.
Dall'idea al deploy un lungo viaggio che passa per git flow e semverMauro Servienti
Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps è principalmente una metodologia. Lo scopo è rendere l'intera filiera il più fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi.
Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog?
Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.
This document discusses different approaches to designing a user interface for a microservices architecture. It begins by proposing a domain model decomposition with individual services owning pieces of product data. However, this poses issues for users who need an aggregated view. An alternative presented is to have individual services cache normalized data and compose a view model at the edge. Later approaches incorporate client-side messaging, hosting the composition engine in MVC, and using view components to give services more ownership over vertical slices of the UI. The key takeaways are that the UI structure can be defined at the edge while still keeping domain responsibilities clear across services.
The road to a Service Oriented Architecture is paved with messagesMauro Servienti
One of the options on the table when implementing a Service Oriented Architecture (SOA), or the communication style across multiple microservices, is based on messages and a service bus. This talk will drive you through the basic SOA building blocks, introduce message based architectures, and will connect the dots between technology and architectural principles through some samples using NServiceBus.
4. Distribuzione geografica
• Necessità di supportare un ambiente geograficamente
distribuito;
• Possibilità di supportare scalabilità orizzontale;
• Possibilità di supportare idempotenza;
• Possibilità di supportare versioning di client e server non sincroni;
5. Atomicità
• Necessità di poter decidere il «livello di atomicità» della
comunicazione in fase di inizio della stessa;
• Possibilità di parallelizzare un set di chiamate;
• Possibilità di serializzare un set di chiamate;
• Conseguente possibilità di gestire la transazionalità di un set di
chiamate;
6. Logica di business
• Necessità di introdurre nuovi scenari di comunicazione
post deploy senza dover apportare modifiche strutturali al
backend dei servizi;
• Possibilità di cambiare la logica di gestione server-side a caldo;
• Possibilità di cambiare il livello di «composition» server-side;
• Possibilità di gestire dei workflow server-side;
7. The big picture
Somewhere
Client in time... Service
• Sappiamo molto poco: mondi separati dove la connettività
non è cosa certa;
8. «high level» information flow
Client
Somewhere
Operation in time... Service
Request(s)
Operation
• Un’operazione è atomica: certo…è una :-) Handler
• Un’operazione può portare con se più
richieste e più risposte: è una e «trina» ;-) Request
• Il servizio non conosce gli handler; Handler(s)
• Gli handler non conoscono il servizio;
• Gli handler (msg) possono conoscersi:
workflow;
10. Technical problems
• Siamo abituati ad una comunicazione con i servizi
«strongly typed at method level»;
• Il proxy è generato da Visual Studio;
• Svcutil.exe genera dei proxy/dto per ogni tipo ma
vedremo che a noi non va sempre bene...;
• In realtà Wcf non sa nulla di «metodi» e «classi» ragiona
solo in termini di messaggi e azioni (e non solo...);
• Ma il messaggio di Wcf è troppo «raw» per i nostri gusti;
• Abbiamo quindi la necessità di essere strongly-typed ma
anche generici… che simpatico…;
17. Recap
• Ad alto livello è tutto molto semplice:
• «banale» servizio Wcf, senza codice;
• Messaggi;
• Handlers;
• Se è tutto staticamente noto a compile time
possiamo anche usare svcutil.exe;
• La chiamata è una normale chiamata a Wcf;
• Un «blobbone» di reference giusto per
semplificare il deploy;
18. Tutto facilissimo, non trovate?
• L’infrastruttura (Caronte) vi
offre:
• Il trasporto: lo stige;
• la forma delle cose da
trasportare: le anime;
• A vostro carico c’è:
• La gestione delle anime ;-)
• Il client…ovviamente :-)
20. Oh my God… <cit.>
• Perchè tutto ciò?
• Abbiamo bisogno di Inversion of Control @ Service Instance
Level;
• e… ServiceLocator è il male :-)
• A questo punto è tutto facile:
21. Non proprio tutto facilissimo…
• Ma… gli attributi di Wcf per il DataContractSerializer?
• «ServiceKnownType» & «ServiceKnownTypesProvider»
26. Client Agenda :-)
• I’m the client and this is my language:
• Client comunication approach;
• Adapt yourself:
• Server model – dto – client model;
• Compose your world :-)
• UI Composition;
• Module Composition;
• A lap around Model-View-ViewModel:
• Client side brokering;
27. Il client e la comunicazione
• Operations & Messages;
• Errori a livello di «Operation»;
• Errori a livello di singolo
«Message»
28. Il client e la comunicazione
• CorrelationId:
• Gestione del Tracking;
• Discard, analisi e valutazione degli errori a livello di singolo
messaggio;
• Idempotenza;
• È impostabile o «auto-generato»;
29. «low level» information flow /1
• Un Model per rappresentarli:
• Creazione di un modello server-side per la gestione dell’informazione;
• un Adapter per trasformarli:
• Realizzazione di un grafo di adapter per la trasformazione del dato in
qualcosa di adatto al trasporto (aka serializzabile)
• un DTO per spedirli:
• Definizione di un grafo di Data Transfer Object adatto a viaggiare «on the
wire»;
• un Client Model per gestirli:
• Un modello client side che «copia» il modello server side finalizzato a
riprodurre e garantire la stessa «development experience»;
• un ViewModel per mostrarli:
• Esposizione del modello client alle View attraverso un set di ViewModel in
perfetto stile Model-View-ViewModel;
30. «low level» information flow /2
NH
Server-Model Adapter(s) DTO Adapter(s)
• Flusso bi-direzionale identico; Client-Model
• Il Client-Model e il Server-Model:
• Garantiscono consistenza;
• Potrebbero essere shared;
ViewModel
• I processo di adapting conosce +
intimamente il modello: View
• EmitMapper (server-side) rulez :-)
31. Compose your module(s)
• La necessità di rendere l’applicazione estendibile ci porta
verso:
• Partizionamento dell’applicazione in «moduli»;
• «on demand loading» al fine di minimizzare il traffico fino all’effetiva
richiesta della funzionalità;
• «ModuleLoader»:
• Discovery;
• Modules on demand loading;
• «EventDrivenModuleManager»:
• Module async download service for PRISM v3;
32. Intermezzo: il solito guastafeste…
• Abbiamo dei moduli scaricati on-demand;
• I tipi disponibili cambiano a runtime:
• Non possiamo usare svcutil.exe;
• Dobbiamo avere per forza i tipi shared tra client e server;
• Ma alcuni tipi shared arrivano dopo…
• Anche client-side possiamo usare il concetto di
ServiceKnownType(s);
• Ma simpatia Wcf li «cacha» e se ne frega se cambiano;
• Client EndPoint «Hack» per invalidare la «cache»:
• ClientConfiguration «depends» on IClientProxyFactory;
33. Client Type Sharing «gems»
• Abbiamo lato server il Framework 4.0 e lato client Silverlight
4.0
• «duplichiamo» i progetti:
• E…:
• «Linkiamo» i file tra i progetti;
• Definiamo gli stessi namspace di base;
• Definiamo lo stesso nome dell’assembly:
• okkio alle TeamBuild… Gian Maria vi picchia;
• Usiamo le post build action per portare quello che ci serve dove ci serve;
34. Compose your View(s)
• La modularizzazione server-side porta in maniera naturale alla
modularizzazione client-side:
• I «moduli» rappresentano parti del un servizio;
• Parti di un servizio sono consumate da un modulo non noto
upfront;
• In fase di design/protipizzazione è importante definire tutti
insieme la struttura delle region, il loro ruolo e il loro
comportamento (RegionAdapters);
• E’ evidente che applicare in un contesto del genere Model-
View-ViewModel in maniera quasi religiosa rende
estremamente semplice rimpiazzare la rappresentazione
visuale;
• Ma…
35. Client side brokering…
• I ViewModel hanno bisogno di parlare tra loro…
• …ma non si conoscono, condividono solo lo stesso
«postino» e conoscono il tipo di messaggio;
38. ma siete pazzi…Perché tutto ciò?
• La stessa cosa si può fare con un set di servizi ad hoc?
• Certo che si…
• Quindi siete definitivamente pazzi…
• Framework riutilizzabile che abbatte la complessità di approccio ad
un modello basato su servizi;
• Elevatissima flessibilità:
• Pluggabilità a caldo;
• Pluggabile/Estendibile:
• Workflow di messaggi a livello di singola Operazione;
• Cache (ad es. sul singolo messaggio);
• Etc.. etc…
• Non c’è WCF... quindi se cambia l’architettura non cambia il codice;
39. «Forse» un po’ si…
Scenario: Video conference con Alessio e Marco