Lavoro da remoto, come Solution Architect, per Particular Software. Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team "dispersed" cresce, più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di lungo periodo in un'azienda i cui dipendenti sono “dispersi” su 17 time zone.
Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.
One of the options on the table when implementing a Service Oriented Architecture (SOA) is based on messages and an enterprise service bus (ESB), this talk will introduce messaging basic concepts, drive you through the basic SOA building blocks, and will connect the dots between the technology and the architectural principles, analyzing advantages and issues we may face when choosing this option.
THE ROAD TO A SERVICE ORIENTED ARCHITECTURE (SOA)Mauro Servienti
One of the options on the table when implementing a Service Oriented Architecture (SOA) is based on messages and an enterprise service bus (ESB), this talk will introduce messaging basic concepts, drive you through the basic SOA building blocks, and will connect the dots between the technology and the architectural principles, analyzing advantages and issues we may face when choosing this option.
Un'architettura basata sui comandamenti di SOA genera e guida verso sistemi basati sulla decomposizione dei servizi e sul disaccoppiamento del dominio al fine di creare componenti autonomi. Purtroppo, dato che la UI è il luogo dove aggreghiamo tutte le informazioni per l'utente, ci ritroviamo ad accoppiare nuovamente e spesso velocemente di nuovo tutto. Obiettivo della sessione è di sviscerare il problema fino alle sue radici e proporre alcuni possibili approcci per risolverlo.
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.
Never Mind the Bollocks: here's the Domain Driven DesignAndrea Saltarello
La lettura del Blue Book può generare reazioni che vanno dal "Cargo cult" (a.k.a. "non avrai altro Modello all’infuori di me") a "’sta roba non mi serve: io faccio gestionali, non applicazioni che lanciano i razzi sulla Luna".
Previa una attualizzazione dei concetti del Blue Book, che ha ormai compiuto 10 anni, in questa sessione affronteremo leggende metropolitane e falsi miti e implementeremo DDD mostrando poche slide e tanto codice.
Introduzione alle tecnologie client & server side che possono essere utilizzate epr la realizzazione di applicazioni mobile crossplatform usando HTML5 e Javascript
Lavoro da remoto, come Solution Architect, per Particular Software. Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team "dispersed" cresce, più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di lungo periodo in un'azienda i cui dipendenti sono “dispersi” su 17 time zone.
Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.
One of the options on the table when implementing a Service Oriented Architecture (SOA) is based on messages and an enterprise service bus (ESB), this talk will introduce messaging basic concepts, drive you through the basic SOA building blocks, and will connect the dots between the technology and the architectural principles, analyzing advantages and issues we may face when choosing this option.
THE ROAD TO A SERVICE ORIENTED ARCHITECTURE (SOA)Mauro Servienti
One of the options on the table when implementing a Service Oriented Architecture (SOA) is based on messages and an enterprise service bus (ESB), this talk will introduce messaging basic concepts, drive you through the basic SOA building blocks, and will connect the dots between the technology and the architectural principles, analyzing advantages and issues we may face when choosing this option.
Un'architettura basata sui comandamenti di SOA genera e guida verso sistemi basati sulla decomposizione dei servizi e sul disaccoppiamento del dominio al fine di creare componenti autonomi. Purtroppo, dato che la UI è il luogo dove aggreghiamo tutte le informazioni per l'utente, ci ritroviamo ad accoppiare nuovamente e spesso velocemente di nuovo tutto. Obiettivo della sessione è di sviscerare il problema fino alle sue radici e proporre alcuni possibili approcci per risolverlo.
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.
Never Mind the Bollocks: here's the Domain Driven DesignAndrea Saltarello
La lettura del Blue Book può generare reazioni che vanno dal "Cargo cult" (a.k.a. "non avrai altro Modello all’infuori di me") a "’sta roba non mi serve: io faccio gestionali, non applicazioni che lanciano i razzi sulla Luna".
Previa una attualizzazione dei concetti del Blue Book, che ha ormai compiuto 10 anni, in questa sessione affronteremo leggende metropolitane e falsi miti e implementeremo DDD mostrando poche slide e tanto codice.
Introduzione alle tecnologie client & server side che possono essere utilizzate epr la realizzazione di applicazioni mobile crossplatform usando HTML5 e Javascript
From its birth, the CQRS (along with event sourcing) has been very attractive for the entire developers community but nonetheless still an "hipster" approach to application architecture design, despite many benefit. But when IoT comes in play, it becomes very interesting to apply it in production grade systems. Let's show why...
MySQL Day Roma 2019 - Le architetture a microservizi e MySQLPar-Tec S.p.A.
In occasione del MySQL Day 2019 di Roma il TechAdvisor Michelangelo Uberti e Marco Carlessi - MySQL Principal Sales Consultant di Oracle - hanno fornito una panoramica sui concetti chiave, sui benefici e sulle opportunità offerte dalle architetture a microservizi.
I punti trattati durante la presentazione sono:
- Le architetture a microservizi
- Dai monoliti ai microservizi
- Un esempio concreto: Netflix
- Architetture a microservizi: vantaggi e punti di attenzione
- Dalla virtualizzazione ai container
- Containerizzazione: vantaggi e punti di attenzione
- Come superare i limiti dei container
- MySQL e le architetture a microservizi
- Microservizi e i dati
- Microservizi e database: due approcci
- MySQL può girare dentro i container
- Deploy MySQL 8.0 con Docker
- Oracle MySQL Operator for Kubernetes (Alpha)
- MySQL 8.0: un multi-model DB
- MySQL Enterprise licensing
Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su https://www.par-tec.it/le-architetture-a-microservizi-e-mysql
Introduzione al Domain Driven Design (DDD)DotNetMarche
In questa sessione si approfondirà il concetto di Domain Driven Design, un principio di progettazione che può essere visto come una “forma-mentis” per aiutare a concepire e modellare applicazioni enterprise che fanno un forte uso del Domain Model. Questa metodologia, introdotta da Eric Evans, mette in risalto il dominio applicativo di un progetto, costituendo quindi il collante tra il modello analitico e il modello implementativo e trovando la sua naturale applicazione in ambienti di sviluppo agili come Extreme Programming. Come completamento della sessione verranno esaminate alcune tecniche di Layering e pattern architetturali che ben si sposano con questa tecnica.
IaC - Infrastructure as Code, gestire infrastrutture cloud tramite file di co...Daniele Mondello
Gestire infrastrutture in cloud con la semplicità di scrivere file di configurazione. Tutto ciò grazie a Terraform, soluzione Open Source per gestire infrastrutture cloud indipendentemente dal Cloud.
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.
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.
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 .NET Core, 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.
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.
2. Agenda
• UI Composition
– Ma pecccchè?
– I problemi;
– Le possibili soluzioni;
• Toolkit:
– cosa offre il mercato;
– farselo, è pensabile?
3. È un investimento decisamente onoreso, ne vale la pena?
UI COMPOSITION: PERCHÈ?
4. Bella domanda...
• Cliente: necessità di modularizzare:
– Acquistare in configurazioni diverse;
– Installare in configurazioni diverse;
• Team: necessità di gestire e lavorare:
– Team grande o distribuito;
– Soluzione/i di dimensioni ingestibili in VS;
– Tempi di sviluppo diversi dei “moduli” che non
devono condizionarsi/bloccarsi a vicenda;
• Un esempio per tutti: Visual Studio;
6. Mamma mia...
• ...oltre a tutto quello che M-V-VM si porta
dietro:
– Region management;
– La comunicazione tra attori che non si conoscono;
– Gestione del ciclo di vita del modulo/plugin;
– Obbligatorietà di IoC perchè bisogna avere a che
fare con i contratti... altrimenti ciccia plugin;
7. Semplicità, adesso è tutto così facile...
“Region... perchè sei tu region”
Toolbars e Documents sono
Region in cui poter iniettare
contenuti a runtime
xxxDetails è una Region in cui
poter iniettare contenuti
contestuali a runtime
8. Semplicità...adesso un po’ meno...
Ecco perchè per mettere M-V-VM al centro del
mondo è necessario sporcarsi le mani
9. Region: statiche e dinamiche
• Toolbars e Documents sono region “statiche”;
– Referenziabili per “nome”;
• Ma se avessimo più Window?
CustomerWindow: Instance 1 CustomerWindow: Instance 2
“ContentRegion” “ContentRegion”
• IRegionManager.GetRegion( name ) ?
• svc.RegisterRegion( name, view );
• svc.GetManager( view ).GetRegion( name );
10. RegionService, RegionManager, Region
• Wpf e Xaml vi danno la massima libertà: lunga
vita alle Attached Property;
<ContentPresenter
rg:RegionService.Region="{rg:ContentPresenterRegion 'myRegionName'}"
/>
11. Come comunicano?
Una toolbar contestuale
l’elemento selezionato deve
compare quando visualizziamo
“attivare” un Command nella
contenuti contestuali
toolbar
La variazione di selezione deve
essere intercettata per iniettare
i contenuti contestuali
12. Il postino suona sempre 2 volte
• I vari attori, aka Module, non si conoscono ma
hanno la necessità di comunicare tra loro:
– Dobbiamo definire una lingua nota a tutti;
– Dobbiamo designare qualcuno come postino;
13. Italiani...! La shell si avvia!
• Il nostro postino trasporta messaggi:
ViewModelLoading<IShellViewModel>()
• che contengono informazioni:
var regionManager = this.regionService.GetRegionManager( this.View );
var msg = new ViewModelLoading<IShellViewModel>( this, regionManager );
this.broker.Dispatch( msg );
• che possiamo usare a nostro uso e consumo:
this.broker.Subscribe<ViewModelLoading<IShellViewModel>>( this, msg =>
{
var viewModel = this.provider.GetService( typeof( IMyContentViewModel ) )
msg.RegionManager[ "myRegionName" ].Add( viewModel.View );
} );
14. ... Si ma come è fatto?
ANATOMIA: ...DAL VIVO!
15. Struttura
• Separazione di contratto e implementazione;
– ComponentModel;
– Runtime;
• Ma...qualcuno deve conoscere il tutto:
– Bootstrapper: è l’equivalente del file di
configurazione;
16. Cosa offre il mercato?
TOOLKIT, TOOLKIT E ANCORA
TOOLKIT...
17. Realizzare un toolkit...
• ... Il gioco vale la candela?
• Che requisiti dobbiamo soddisfare:
– Gestione delle region;
– Comunicazione;
– Gestione del ciclo di vita dei moduli;
• Ma anche (ecco perchè forse ha senso):
– Un set di ViewModel di base;
– Un motore di validazione degno del suo nome;
– Localizzazione;
• e... Silverlight?