�ݺ�ߣshows by User: mauroservienti

�ݺ�ߣshows by User: mauroservienti / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: mauroservienti / Sat, 21 Sep 2019 12:35:27 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: mauroservienti Welcome to the (state) machine @ ExploreDDD 2019 /slideshow/welcome-to-the-state-machine-exploreddd-2019/174549134 welcometothestatemachine-190921123527
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)]]>
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)]]> Sat, 21 Sep 2019 12:35:27 GMT /slideshow/welcome-to-the-state-machine-exploreddd-2019/174549134 mauroservienti@slideshare.net(mauroservienti) Welcome to the (state) machine @ ExploreDDD 2019 mauroservienti 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) <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/welcometothestatemachine-190921123527-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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)

Welcome to the (state) machine @ ExploreDDD 2019 from Mauro Servienti

]]> 358 0 https://cdn.slidesharecdn.com/ss_thumbnails/welcometothestatemachine-190921123527-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Designing a ui for microservices @ .NET Day Switzerland 2019 /slideshow/designing-a-ui-for-microservices-net-day-switzerland-2019/148222620 designingauiformicroservices-190530041953
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.]]>
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.]]> Thu, 30 May 2019 04:19:53 GMT /slideshow/designing-a-ui-for-microservices-net-day-switzerland-2019/148222620 mauroservienti@slideshare.net(mauroservienti) Designing a ui for microservices @ .NET Day Switzerland 2019 mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/designingauiformicroservices-190530041953-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Designing a ui for microservices @ .NET Day Switzerland 2019 from Mauro Servienti

]]> 605 2 https://cdn.slidesharecdn.com/ss_thumbnails/designingauiformicroservices-190530041953-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Welcome to the (state) machine @ Xe One Day Enterprise Applications /slideshow/welcome-to-the-state-machine-xe-one-day-enterprise-applications/147557426 welcometothestatemachine-190525135812
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)]]>
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)]]> Sat, 25 May 2019 13:58:12 GMT /slideshow/welcome-to-the-state-machine-xe-one-day-enterprise-applications/147557426 mauroservienti@slideshare.net(mauroservienti) Welcome to the (state) machine @ Xe One Day Enterprise Applications mauroservienti 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) <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/welcometothestatemachine-190525135812-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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)

Welcome to the (state) machine @ Xe One Day Enterprise Applications from Mauro Servienti

]]> 276 1 https://cdn.slidesharecdn.com/ss_thumbnails/welcometothestatemachine-190525135812-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 All our aggregates are wrong @ NDC Copenhagen 2019 /slideshow/all-our-aggregates-are-wrong-ndc-copenhagen-2019/138701095 allouraggregatesarewrong-190329173253
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.]]>
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.]]> Fri, 29 Mar 2019 17:32:53 GMT /slideshow/all-our-aggregates-are-wrong-ndc-copenhagen-2019/138701095 mauroservienti@slideshare.net(mauroservienti) All our aggregates are wrong @ NDC Copenhagen 2019 mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/allouraggregatesarewrong-190329173253-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

All our aggregates are wrong @ NDC Copenhagen 2019 from Mauro Servienti

]]> 694 2 https://cdn.slidesharecdn.com/ss_thumbnails/allouraggregatesarewrong-190329173253-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Be like water, my friend @ Agile for Innovation 2019 /slideshow/be-like-water-my-friend-agile-for-innovation-2019/136514845 belikewatermyfriend-190315043936
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.]]>
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.]]> Fri, 15 Mar 2019 04:39:36 GMT /slideshow/be-like-water-my-friend-agile-for-innovation-2019/136514845 mauroservienti@slideshare.net(mauroservienti) Be like water, my friend @ Agile for Innovation 2019 mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/belikewatermyfriend-190315043936-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Be like water, my friend @ Agile for Innovation 2019 from Mauro Servienti

]]> 189 2 https://cdn.slidesharecdn.com/ss_thumbnails/belikewatermyfriend-190315043936-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Microservices architecture is it the right choice to design long-living systems @ Codemotion Webinar /slideshow/microservices-architecture-is-it-the-right-choice-to-design-longliving-systems-codemotion-webinar/135895851 longliveandprosper-190312162600
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.]]>
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.]]> Tue, 12 Mar 2019 16:26:00 GMT /slideshow/microservices-architecture-is-it-the-right-choice-to-design-longliving-systems-codemotion-webinar/135895851 mauroservienti@slideshare.net(mauroservienti) Microservices architecture is it the right choice to design long-living systems @ Codemotion Webinar mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/longliveandprosper-190312162600-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Microservices architecture is it the right choice to design long-living systems @ Codemotion Webinar from Mauro Servienti

]]> 339 2 https://cdn.slidesharecdn.com/ss_thumbnails/longliveandprosper-190312162600-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Titles, abstracts, and bio matter... oh my! @ Global Diversity CFP Day 2019 /mauroservienti/titles-abstracts-and-bio-matter-oh-my-global-diversity-cfp-day-2019 titlesabstractsandbiomatter-190304060539
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?]]>
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?]]> Mon, 04 Mar 2019 06:05:39 GMT /mauroservienti/titles-abstracts-and-bio-matter-oh-my-global-diversity-cfp-day-2019 mauroservienti@slideshare.net(mauroservienti) Titles, abstracts, and bio matter... oh my! @ Global Diversity CFP Day 2019 mauroservienti 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? <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/titlesabstractsandbiomatter-190304060539-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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?

Titles, abstracts, and bio matter... oh my! @ Global Diversity CFP Day 2019 from Mauro Servienti

]]> 139 1 https://cdn.slidesharecdn.com/ss_thumbnails/titlesabstractsandbiomatter-190304060539-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Living organizations, particular software @ do IT Better Parma /slideshow/living-organizations-particular-software-do-it-better-parma/130702412 livingorganizationsparticularsoftware-190206082758
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.]]>
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.]]> Wed, 06 Feb 2019 08:27:58 GMT /slideshow/living-organizations-particular-software-do-it-better-parma/130702412 mauroservienti@slideshare.net(mauroservienti) Living organizations, particular software @ do IT Better Parma mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/livingorganizationsparticularsoftware-190206082758-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Living organizations, particular software @ do IT Better Parma from Mauro Servienti

]]> 744 1 https://cdn.slidesharecdn.com/ss_thumbnails/livingorganizationsparticularsoftware-190206082758-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Welcome to the (state) machine @ Crafted Software /mauroservienti/welcome-to-the-state-machine-crafted-software welcometothestatemachine-181214141028
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)]]>
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)]]> Fri, 14 Dec 2018 14:10:28 GMT /mauroservienti/welcome-to-the-state-machine-crafted-software mauroservienti@slideshare.net(mauroservienti) Welcome to the (state) machine @ Crafted Software mauroservienti 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) <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/welcometothestatemachine-181214141028-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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)

Welcome to the (state) machine @ Crafted Software from Mauro Servienti

]]> 180 1 https://cdn.slidesharecdn.com/ss_thumbnails/welcometothestatemachine-181214141028-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 PO is dead, long live the PO - Italian Agile Day 2018 /slideshow/po-is-dead-long-live-the-po-italian-agile-day-2018/122706477 poisdeadlonglivethepo-181111061707
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.]]>
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.]]> Sun, 11 Nov 2018 06:17:07 GMT /slideshow/po-is-dead-long-live-the-po-italian-agile-day-2018/122706477 mauroservienti@slideshare.net(mauroservienti) PO is dead, long live the PO - Italian Agile Day 2018 mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/poisdeadlonglivethepo-181111061707-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

PO is dead, long live the PO - Italian Agile Day 2018 from Mauro Servienti

]]> 224 1 https://cdn.slidesharecdn.com/ss_thumbnails/poisdeadlonglivethepo-181111061707-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Design a UI for your Microservices @ Do IT Better /slideshow/design-a-ui-for-your-microservices-do-it-better/121268104 designingauiformicroservices-181031053923
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.]]>
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.]]> Wed, 31 Oct 2018 05:39:23 GMT /slideshow/design-a-ui-for-your-microservices-do-it-better/121268104 mauroservienti@slideshare.net(mauroservienti) Design a UI for your Microservices @ Do IT Better mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/designingauiformicroservices-181031053923-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Design a UI for your Microservices @ Do IT Better from Mauro Servienti

]]> 433 1 https://cdn.slidesharecdn.com/ss_thumbnails/designingauiformicroservices-181031053923-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Microservices and pineapple on pizza what do they have in common - dos and don'ts /slideshow/microservices-and-pineapple-on-pizza-what-do-they-have-in-common-dos-and-donts/119967513 microservicesandpineappleonpizza-whatdotheyhaveincommon-dosanddonts-181019044509
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.)]]>
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.)]]> Fri, 19 Oct 2018 04:45:09 GMT /slideshow/microservices-and-pineapple-on-pizza-what-do-they-have-in-common-dos-and-donts/119967513 mauroservienti@slideshare.net(mauroservienti) Microservices and pineapple on pizza what do they have in common - dos and don'ts mauroservienti 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.) <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/microservicesandpineappleonpizza-whatdotheyhaveincommon-dosanddonts-181019044509-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.)

Microservices and pineapple on pizza what do they have in common - dos and don'ts from Mauro Servienti

]]> 137 2 https://cdn.slidesharecdn.com/ss_thumbnails/microservicesandpineappleonpizza-whatdotheyhaveincommon-dosanddonts-181019044509-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 All our aggregates are wrong (ExploreDDD 2018) /slideshow/all-our-aggregates-are-wrong-exploreddd-2018/114504800 allouraggregatesarewrong-180914164151
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.]]>
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.]]> Fri, 14 Sep 2018 16:41:51 GMT /slideshow/all-our-aggregates-are-wrong-exploreddd-2018/114504800 mauroservienti@slideshare.net(mauroservienti) All our aggregates are wrong (ExploreDDD 2018) mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/allouraggregatesarewrong-180914164151-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

All our aggregates are wrong (ExploreDDD 2018) from Mauro Servienti

]]> 976 2 https://cdn.slidesharecdn.com/ss_thumbnails/allouraggregatesarewrong-180914164151-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Designing a ui for microservices /slideshow/designing-a-ui-for-microservices-102807853/102807853 designingauiformicroservices-180622083957
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.]]>
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.]]> Fri, 22 Jun 2018 08:39:56 GMT /slideshow/designing-a-ui-for-microservices-102807853/102807853 mauroservienti@slideshare.net(mauroservienti) Designing a ui for microservices mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/designingauiformicroservices-180622083957-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Designing a ui for microservices from Mauro Servienti

]]> 196 2 https://cdn.slidesharecdn.com/ss_thumbnails/designingauiformicroservices-180622083957-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Po is dead, long live the po /slideshow/po-is-dead-long-live-the-po/97682068 poisdeadlonglivethepo-180519211241
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.]]>
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.]]> Sat, 19 May 2018 21:12:41 GMT /slideshow/po-is-dead-long-live-the-po/97682068 mauroservienti@slideshare.net(mauroservienti) Po is dead, long live the po mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/poisdeadlonglivethepo-180519211241-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Po is dead, long live the po from Mauro Servienti

]]> 209 3 https://cdn.slidesharecdn.com/ss_thumbnails/poisdeadlonglivethepo-180519211241-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Shipping code is not the problem, deciding what to ship it is! /slideshow/shipping-code-is-not-the-problem-deciding-what-to-ship-it-is/93790754 shippingcodeisnottheproblemdecidingwhattoshipitis-180413121209
What if the PO doesn't exist and everyone in the company is in charge of product ownership?]]>
What if the PO doesn't exist and everyone in the company is in charge of product ownership?]]> Fri, 13 Apr 2018 12:12:09 GMT /slideshow/shipping-code-is-not-the-problem-deciding-what-to-ship-it-is/93790754 mauroservienti@slideshare.net(mauroservienti) Shipping code is not the problem, deciding what to ship it is! mauroservienti What if the PO doesn't exist and everyone in the company is in charge of product ownership? <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/shippingcodeisnottheproblemdecidingwhattoshipitis-180413121209-thumbnail.jpg?width=120&height=120&fit=bounds" /> What if the PO doesn't exist and everyone in the company is in charge of product ownership?

Shipping code is not the problem, deciding what to ship it is! from Mauro Servienti

]]> 138 2 https://cdn.slidesharecdn.com/ss_thumbnails/shippingcodeisnottheproblemdecidingwhattoshipitis-180413121209-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 GraphQL - Where are you from? Where are you going? /slideshow/graphql-where-are-you-from-where-are-you-going/82210912 graphql-171117124019
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.]]>
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.]]> Fri, 17 Nov 2017 12:40:19 GMT /slideshow/graphql-where-are-you-from-where-are-you-going/82210912 mauroservienti@slideshare.net(mauroservienti) GraphQL - Where are you from? Where are you going? mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/graphql-171117124019-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

GraphQL - Where are you from? Where are you going? from Mauro Servienti

]]> 454 1 https://cdn.slidesharecdn.com/ss_thumbnails/graphql-171117124019-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Dall'idea al deploy un lungo viaggio che passa per git flow e semver /slideshow/dallidea-al-deploy-un-lungo-viaggio-che-passa-per-git-flow-e-semver/81130045 dallideaaldeploy-unlungoviaggiochepassapergitflowesemver-171024043300
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.]]>
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.]]> Tue, 24 Oct 2017 04:33:00 GMT /slideshow/dallidea-al-deploy-un-lungo-viaggio-che-passa-per-git-flow-e-semver/81130045 mauroservienti@slideshare.net(mauroservienti) Dall'idea al deploy un lungo viaggio che passa per git flow e semver mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/dallideaaldeploy-unlungoviaggiochepassapergitflowesemver-171024043300-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Dall'idea al deploy un lungo viaggio che passa per git flow e semver from Mauro Servienti

]]> 254 1 https://cdn.slidesharecdn.com/ss_thumbnails/dallideaaldeploy-unlungoviaggiochepassapergitflowesemver-171024043300-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Progettare una UI per i Microservices /slideshow/progettare-una-ui-per-i-microservices/79757026 designingauiformicroservices-170914065145
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.]]>
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.]]> Thu, 14 Sep 2017 06:51:45 GMT /slideshow/progettare-una-ui-per-i-microservices/79757026 mauroservienti@slideshare.net(mauroservienti) Progettare una UI per i Microservices mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/designingauiformicroservices-170914065145-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Progettare una UI per i Microservices from Mauro Servienti

]]> 171 2 https://cdn.slidesharecdn.com/ss_thumbnails/designingauiformicroservices-170914065145-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 The road to a Service Oriented Architecture is paved with messages /slideshow/the-road-to-a-service-oriented-architecture-is-paved-with-messages/76874058 theroadtoaserviceorientedarchitectureispavedwithmessages-170612170440
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.]]>
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.]]> Mon, 12 Jun 2017 17:04:40 GMT /slideshow/the-road-to-a-service-oriented-architecture-is-paved-with-messages/76874058 mauroservienti@slideshare.net(mauroservienti) The road to a Service Oriented Architecture is paved with messages mauroservienti 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/theroadtoaserviceorientedarchitectureispavedwithmessages-170612170440-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

The road to a Service Oriented Architecture is paved with messages from Mauro Servienti

]]> 99 2 https://cdn.slidesharecdn.com/ss_thumbnails/theroadtoaserviceorientedarchitectureispavedwithmessages-170612170440-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://cdn.slidesharecdn.com/profile-photo-mauroservienti-48x48.jpg?cb=1571057888 https://cdn.slidesharecdn.com/ss_thumbnails/welcometothestatemachine-190921123527-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/welcome-to-the-state-machine-exploreddd-2019/174549134 Welcome to the (state)... https://cdn.slidesharecdn.com/ss_thumbnails/designingauiformicroservices-190530041953-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/designing-a-ui-for-microservices-net-day-switzerland-2019/148222620 Designing a ui for mic... https://cdn.slidesharecdn.com/ss_thumbnails/welcometothestatemachine-190525135812-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/welcome-to-the-state-machine-xe-one-day-enterprise-applications/147557426 Welcome to the (state)...