�ݺ�ߣshows by User: danielpokusa

�ݺ�ߣshows by User: danielpokusa / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: danielpokusa / Mon, 07 May 2018 14:49:04 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: danielpokusa Errors errors, everywhere! - JSession /slideshow/errors-errors-everywhere-jsession/96274526 errorserrors-180507144904
Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji.]]>
Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji.]]> Mon, 07 May 2018 14:49:04 GMT /slideshow/errors-errors-everywhere-jsession/96274526 danielpokusa@slideshare.net(danielpokusa) Errors errors, everywhere! - JSession danielpokusa Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/errorserrors-180507144904-thumbnail.jpg?width=120&height=120&fit=bounds" /> Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji.

Errors errors, everywhere! - JSession from Daniel Pokusa

]]> 143 2 https://cdn.slidesharecdn.com/ss_thumbnails/errorserrors-180507144904-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 Errors errors, everywhere! - 4Developers 2018 /slideshow/errors-errors-everywhere/93308786 errorserrors-180409090146
Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji.]]>
Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji.]]> Mon, 09 Apr 2018 09:01:46 GMT /slideshow/errors-errors-everywhere/93308786 danielpokusa@slideshare.net(danielpokusa) Errors errors, everywhere! - 4Developers 2018 danielpokusa Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/errorserrors-180409090146-thumbnail.jpg?width=120&height=120&fit=bounds" /> Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji.

Errors errors, everywhere! - 4Developers 2018 from Daniel Pokusa

]]> 465 2 https://cdn.slidesharecdn.com/ss_thumbnails/errorserrors-180409090146-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 Errors errors everywhere! - BoilingFrogs 2018 /slideshow/errors-errors-everywhere-boilingfrogs-2018/91990972 errorserrors-180326204134
Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji.]]>
Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji.]]> Mon, 26 Mar 2018 20:41:34 GMT /slideshow/errors-errors-everywhere-boilingfrogs-2018/91990972 danielpokusa@slideshare.net(danielpokusa) Errors errors everywhere! - BoilingFrogs 2018 danielpokusa Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/errorserrors-180326204134-thumbnail.jpg?width=120&height=120&fit=bounds" /> Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać “monolitów”. Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów. Byłeś tam może? Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji.

Errors errors everywhere! - BoilingFrogs 2018 from Daniel Pokusa

]]> 310 1 https://cdn.slidesharecdn.com/ss_thumbnails/errorserrors-180326204134-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 Orchestrate Your Choreography /slideshow/orchestrate-your-choreography/80397395 orchestrateyourchoreography-jdd-171003094631
When we speak about orchestration we should think of conductor in philharmonic orchestra. Basically His role is to show rhythm to all musicians. In the other hand “Swan Lake” don’t need conductor for dancers. They know when its their part, and which steps they need to do. Its all because of choreography. You can find a lot of examples which use this two fundamental ways of keeping processes in correct order. You can find them in Event Driven Architecture, Microservices, CQRS, Hexagonal Architecture and so on. In my opinion we should talk about them more- to understand them and use them in correct and proper way. Sometimes you need to do one step back to be able to do two steps forward. I would like to show you advantages and disadvantages of orchestration and choreography. I would like to show you when to use them and finally – how to do it effectively.]]>
When we speak about orchestration we should think of conductor in philharmonic orchestra. Basically His role is to show rhythm to all musicians. In the other hand “Swan Lake” don’t need conductor for dancers. They know when its their part, and which steps they need to do. Its all because of choreography. You can find a lot of examples which use this two fundamental ways of keeping processes in correct order. You can find them in Event Driven Architecture, Microservices, CQRS, Hexagonal Architecture and so on. In my opinion we should talk about them more- to understand them and use them in correct and proper way. Sometimes you need to do one step back to be able to do two steps forward. I would like to show you advantages and disadvantages of orchestration and choreography. I would like to show you when to use them and finally – how to do it effectively.]]> Tue, 03 Oct 2017 09:46:31 GMT /slideshow/orchestrate-your-choreography/80397395 danielpokusa@slideshare.net(danielpokusa) Orchestrate Your Choreography danielpokusa When we speak about orchestration we should think of conductor in philharmonic orchestra. Basically His role is to show rhythm to all musicians. In the other hand “Swan Lake” don’t need conductor for dancers. They know when its their part, and which steps they need to do. Its all because of choreography. You can find a lot of examples which use this two fundamental ways of keeping processes in correct order. You can find them in Event Driven Architecture, Microservices, CQRS, Hexagonal Architecture and so on. In my opinion we should talk about them more- to understand them and use them in correct and proper way. Sometimes you need to do one step back to be able to do two steps forward. I would like to show you advantages and disadvantages of orchestration and choreography. I would like to show you when to use them and finally – how to do it effectively. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/orchestrateyourchoreography-jdd-171003094631-thumbnail.jpg?width=120&height=120&fit=bounds" /> When we speak about orchestration we should think of conductor in philharmonic orchestra. Basically His role is to show rhythm to all musicians. In the other hand “Swan Lake” don’t need conductor for dancers. They know when its their part, and which steps they need to do. Its all because of choreography. You can find a lot of examples which use this two fundamental ways of keeping processes in correct order. You can find them in Event Driven Architecture, Microservices, CQRS, Hexagonal Architecture and so on. In my opinion we should talk about them more- to understand them and use them in correct and proper way. Sometimes you need to do one step back to be able to do two steps forward. I would like to show you advantages and disadvantages of orchestration and choreography. I would like to show you when to use them and finally – how to do it effectively.

Orchestrate Your Choreography from Daniel Pokusa

]]> 466 5 https://cdn.slidesharecdn.com/ss_thumbnails/orchestrateyourchoreography-jdd-171003094631-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 Evolving architecture 4 Confitura 2017 /slideshow/evolving-architecture-4-confitura-2017/77421873 evolvingarchitecture4confitura2017-170701123558
During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very sucessfull. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares.]]>
During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very sucessfull. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares.]]> Sat, 01 Jul 2017 12:35:58 GMT /slideshow/evolving-architecture-4-confitura-2017/77421873 danielpokusa@slideshare.net(danielpokusa) Evolving architecture 4 Confitura 2017 danielpokusa During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very sucessfull. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/evolvingarchitecture4confitura2017-170701123558-thumbnail.jpg?width=120&height=120&fit=bounds" /> During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very sucessfull. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares.

Evolving architecture 4 Confitura 2017 from Daniel Pokusa

]]> 949 2 https://cdn.slidesharecdn.com/ss_thumbnails/evolvingarchitecture4confitura2017-170701123558-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 Evolving architecture 4 QualityExcites 2017 /slideshow/evolving-architecture-4-qualityexcites-2017/77216953 evolvingarchitectureqe-170623204843
When developing a system, it is very easy to cross a certain boundary – on the one hand we want to predict all possibilities and changes that can happen in our project. On the other hand, when we are under the time pressure, we take shortcuts which could in the end increase cost of the smallest changes. How to deal with “overdesign”? How, at the same time, not to close for improvement and changes? When should we make crucial technical decisions and when to accept technical debt? This talk is about true stories, mostly about huge mistakes, but also about decisions that in the end were very sucessfull. The talk is dedicated to all of those who don’t want to end up with a project that needs to be rewritten whenever we want to add a new button. The session is for all of those who care.]]>
When developing a system, it is very easy to cross a certain boundary – on the one hand we want to predict all possibilities and changes that can happen in our project. On the other hand, when we are under the time pressure, we take shortcuts which could in the end increase cost of the smallest changes. How to deal with “overdesign”? How, at the same time, not to close for improvement and changes? When should we make crucial technical decisions and when to accept technical debt? This talk is about true stories, mostly about huge mistakes, but also about decisions that in the end were very sucessfull. The talk is dedicated to all of those who don’t want to end up with a project that needs to be rewritten whenever we want to add a new button. The session is for all of those who care.]]> Fri, 23 Jun 2017 20:48:43 GMT /slideshow/evolving-architecture-4-qualityexcites-2017/77216953 danielpokusa@slideshare.net(danielpokusa) Evolving architecture 4 QualityExcites 2017 danielpokusa When developing a system, it is very easy to cross a certain boundary – on the one hand we want to predict all possibilities and changes that can happen in our project. On the other hand, when we are under the time pressure, we take shortcuts which could in the end increase cost of the smallest changes. How to deal with “overdesign”? How, at the same time, not to close for improvement and changes? When should we make crucial technical decisions and when to accept technical debt? This talk is about true stories, mostly about huge mistakes, but also about decisions that in the end were very sucessfull. The talk is dedicated to all of those who don’t want to end up with a project that needs to be rewritten whenever we want to add a new button. The session is for all of those who care. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/evolvingarchitectureqe-170623204843-thumbnail.jpg?width=120&height=120&fit=bounds" /> When developing a system, it is very easy to cross a certain boundary – on the one hand we want to predict all possibilities and changes that can happen in our project. On the other hand, when we are under the time pressure, we take shortcuts which could in the end increase cost of the smallest changes. How to deal with “overdesign”? How, at the same time, not to close for improvement and changes? When should we make crucial technical decisions and when to accept technical debt? This talk is about true stories, mostly about huge mistakes, but also about decisions that in the end were very sucessfull. The talk is dedicated to all of those who don’t want to end up with a project that needs to be rewritten whenever we want to add a new button. The session is for all of those who care.

Evolving architecture 4 QualityExcites 2017 from Daniel Pokusa

]]> 312 3 https://cdn.slidesharecdn.com/ss_thumbnails/evolvingarchitectureqe-170623204843-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 Java: Nie popełniaj tych błędów! /slideshow/java-nie-popeniaj-tych-bdw/76366673 javadonotmakethesemistakes-170526062940
Jako opiekun praktyk, stażów, mentor młodszych kolegów i koleżanek z zespołu, osoba odpowiedzialna za rekrutację techniczną, a także programista, który każdego dnia pracuje z oprogramowaniem dane mi było widzieć wiele błędów, złych zachowań i pomyłek w podejściu do tworzenia czystego kodu. Chciałbym się z Wami podzielić tymi najczęstszymi wpadkami w pracy z językiem Java. To nie będzie zwyczajna pogawędka! Zobaczycie kod źródłowy i ostry refaktoring. Zobaczycie, jak proste zmiany i lepsze zrozumienie samego języka mogą poprawić wydajność i czytelność Waszych aplikacji. Na podstawie całkiem prostych fragmentów kodu pokażę, na co zwrócić uwagę, żeby - to zabrzmi banalnie - być lepszym. Prezentacja dla wszystkich, którzy są na początku (i nie tylko) wspaniałej przygody z programowaniem (i zawrotnej kariery!).]]>
Jako opiekun praktyk, stażów, mentor młodszych kolegów i koleżanek z zespołu, osoba odpowiedzialna za rekrutację techniczną, a także programista, który każdego dnia pracuje z oprogramowaniem dane mi było widzieć wiele błędów, złych zachowań i pomyłek w podejściu do tworzenia czystego kodu. Chciałbym się z Wami podzielić tymi najczęstszymi wpadkami w pracy z językiem Java. To nie będzie zwyczajna pogawędka! Zobaczycie kod źródłowy i ostry refaktoring. Zobaczycie, jak proste zmiany i lepsze zrozumienie samego języka mogą poprawić wydajność i czytelność Waszych aplikacji. Na podstawie całkiem prostych fragmentów kodu pokażę, na co zwrócić uwagę, żeby - to zabrzmi banalnie - być lepszym. Prezentacja dla wszystkich, którzy są na początku (i nie tylko) wspaniałej przygody z programowaniem (i zawrotnej kariery!).]]> Fri, 26 May 2017 06:29:40 GMT /slideshow/java-nie-popeniaj-tych-bdw/76366673 danielpokusa@slideshare.net(danielpokusa) Java: Nie popełniaj tych błędów! danielpokusa Jako opiekun praktyk, stażów, mentor młodszych kolegów i koleżanek z zespołu, osoba odpowiedzialna za rekrutację techniczną, a także programista, który każdego dnia pracuje z oprogramowaniem dane mi było widzieć wiele błędów, złych zachowań i pomyłek w podejściu do tworzenia czystego kodu. Chciałbym się z Wami podzielić tymi najczęstszymi wpadkami w pracy z językiem Java. To nie będzie zwyczajna pogawędka! Zobaczycie kod źródłowy i ostry refaktoring. Zobaczycie, jak proste zmiany i lepsze zrozumienie samego języka mogą poprawić wydajność i czytelność Waszych aplikacji. Na podstawie całkiem prostych fragmentów kodu pokażę, na co zwrócić uwagę, żeby - to zabrzmi banalnie - być lepszym. Prezentacja dla wszystkich, którzy są na początku (i nie tylko) wspaniałej przygody z programowaniem (i zawrotnej kariery!). <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/javadonotmakethesemistakes-170526062940-thumbnail.jpg?width=120&height=120&fit=bounds" /> Jako opiekun praktyk, stażów, mentor młodszych kolegów i koleżanek z zespołu, osoba odpowiedzialna za rekrutację techniczną, a także programista, który każdego dnia pracuje z oprogramowaniem dane mi było widzieć wiele błędów, złych zachowań i pomyłek w podejściu do tworzenia czystego kodu. Chciałbym się z Wami podzielić tymi najczęstszymi wpadkami w pracy z językiem Java. To nie będzie zwyczajna pogawędka! Zobaczycie kod źródłowy i ostry refaktoring. Zobaczycie, jak proste zmiany i lepsze zrozumienie samego języka mogą poprawić wydajność i czytelność Waszych aplikacji. Na podstawie całkiem prostych fragmentów kodu pokażę, na co zwrócić uwagę, żeby - to zabrzmi banalnie - być lepszym. Prezentacja dla wszystkich, którzy są na początku (i nie tylko) wspaniałej przygody z programowaniem (i zawrotnej kariery!).

Java: Nie popeナＯiaj tych bナて囘テウw! from Daniel Pokusa

]]> 301 3 https://cdn.slidesharecdn.com/ss_thumbnails/javadonotmakethesemistakes-170526062940-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 How to become a DevOps /slideshow/how-to-become-a-devops/74926525 howtobecomeadevops-170412085749
What this term means exactly? Is it a movement? A new process or technology? A job title? Or just a way of thinking? Let's find out!]]>
What this term means exactly? Is it a movement? A new process or technology? A job title? Or just a way of thinking? Let's find out!]]> Wed, 12 Apr 2017 08:57:49 GMT /slideshow/how-to-become-a-devops/74926525 danielpokusa@slideshare.net(danielpokusa) How to become a DevOps danielpokusa What this term means exactly? Is it a movement? A new process or technology? A job title? Or just a way of thinking? Let's find out! <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/howtobecomeadevops-170412085749-thumbnail.jpg?width=120&height=120&fit=bounds" /> What this term means exactly? Is it a movement? A new process or technology? A job title? Or just a way of thinking? Let's find out!

How to become a DevOps from Daniel Pokusa

]]> 946 5 https://cdn.slidesharecdn.com/ss_thumbnails/howtobecomeadevops-170412085749-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 Evolving architecture @ 4Developers 2017 /slideshow/evolving-architecture-4developers-2017/74249668 evolvingarchitecture4dev-170403152358
During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very successful. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares.]]>
During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very successful. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares.]]> Mon, 03 Apr 2017 15:23:58 GMT /slideshow/evolving-architecture-4developers-2017/74249668 danielpokusa@slideshare.net(danielpokusa) Evolving architecture @ 4Developers 2017 danielpokusa During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very successful. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/evolvingarchitecture4dev-170403152358-thumbnail.jpg?width=120&height=120&fit=bounds" /> During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very successful. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares.

Evolving architecture @ 4Developers 2017 from Daniel Pokusa

]]> 359 3 https://cdn.slidesharecdn.com/ss_thumbnails/evolvingarchitecture4dev-170403152358-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 Work in agile distributed teams. Cookbook /danielpokusa/work-in-agile-distributed-teams-cookbook-63130329 work-in-agile-distributed-teams-agilesilesia-160616095249
Work in agile distributed teams. Cookbook. Short presentation supporting my talk on Agile Silesia meeting. ]]>
Work in agile distributed teams. Cookbook. Short presentation supporting my talk on Agile Silesia meeting. ]]> Thu, 16 Jun 2016 09:52:49 GMT /danielpokusa/work-in-agile-distributed-teams-cookbook-63130329 danielpokusa@slideshare.net(danielpokusa) Work in agile distributed teams. Cookbook danielpokusa Work in agile distributed teams. Cookbook. Short presentation supporting my talk on Agile Silesia meeting. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/work-in-agile-distributed-teams-agilesilesia-160616095249-thumbnail.jpg?width=120&height=120&fit=bounds" /> Work in agile distributed teams. Cookbook. Short presentation supporting my talk on Agile Silesia meeting.

Work in agile distributed teams. Cookbook from Daniel Pokusa

]]> 539 5 https://cdn.slidesharecdn.com/ss_thumbnails/work-in-agile-distributed-teams-agilesilesia-160616095249-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 Jak wdrożyć Continuous Delivery do Twojego (starego) projektu? /danielpokusa/continuous-delivery-careercon continuousdelivery-careercon-150207114246-conversion-gate02
Stworzenie nowego produktu na bazie starego kodu źródłowego nie jest sprawą prostą. Nie jest też rzeczą niemożliwą! Na bazie własnych doświadczeń przedstawię możliwości i sposoby zorganizowania środowiska pracy tak, aby ciągłe dostarczanie nowych wersji i aktualizacji aplikacji stało się faktem. Zaproponuję narzędzia, które sprawdzają się w praktyce, wskażę rozwiązania jakich należy unikać, a także przedstawię kilka podejść do budżetu, który niekoniecznie pozwoli na kilka miesięcy „sprzątania” przed rozpoczęciem właściwych prac.]]>
Stworzenie nowego produktu na bazie starego kodu źródłowego nie jest sprawą prostą. Nie jest też rzeczą niemożliwą! Na bazie własnych doświadczeń przedstawię możliwości i sposoby zorganizowania środowiska pracy tak, aby ciągłe dostarczanie nowych wersji i aktualizacji aplikacji stało się faktem. Zaproponuję narzędzia, które sprawdzają się w praktyce, wskażę rozwiązania jakich należy unikać, a także przedstawię kilka podejść do budżetu, który niekoniecznie pozwoli na kilka miesięcy „sprzątania” przed rozpoczęciem właściwych prac.]]> Sat, 07 Feb 2015 11:42:46 GMT /danielpokusa/continuous-delivery-careercon danielpokusa@slideshare.net(danielpokusa) Jak wdrożyć Continuous Delivery do Twojego (starego) projektu? danielpokusa Stworzenie nowego produktu na bazie starego kodu źródłowego nie jest sprawą prostą. Nie jest też rzeczą niemożliwą! Na bazie własnych doświadczeń przedstawię możliwości i sposoby zorganizowania środowiska pracy tak, aby ciągłe dostarczanie nowych wersji i aktualizacji aplikacji stało się faktem. Zaproponuję narzędzia, które sprawdzają się w praktyce, wskażę rozwiązania jakich należy unikać, a także przedstawię kilka podejść do budżetu, który niekoniecznie pozwoli na kilka miesięcy „sprzątania” przed rozpoczęciem właściwych prac. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/continuousdelivery-careercon-150207114246-conversion-gate02-thumbnail.jpg?width=120&height=120&fit=bounds" /> Stworzenie nowego produktu na bazie starego kodu źródłowego nie jest sprawą prostą. Nie jest też rzeczą niemożliwą! Na bazie własnych doświadczeń przedstawię możliwości i sposoby zorganizowania środowiska pracy tak, aby ciągłe dostarczanie nowych wersji i aktualizacji aplikacji stało się faktem. Zaproponuję narzędzia, które sprawdzają się w praktyce, wskażę rozwiązania jakich należy unikać, a także przedstawię kilka podejść do budżetu, który niekoniecznie pozwoli na kilka miesięcy „sprzątania” przed rozpoczęciem właściwych prac.

Jak wdrożyć Continuous Delivery do Twojego (starego) projektu? from Daniel Pokusa

]]> 557 1 https://cdn.slidesharecdn.com/ss_thumbnails/continuousdelivery-careercon-150207114246-conversion-gate02-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 IDE to za mało! Jak stworzyć efektywne środowisko pracy? /slideshow/ide-srodowisko-pracy-36296791/36296791 ide-srodowiskopracy-140625104914-phpapp01
Dawno minęły już czasy gdy specjalistów zamykało się w pokoiku o czterech ścianach, wręczało klawiaturę i prosiło o "produkcję kodu źródłowego". Sam proces wytwarzania oprogramowania stał się bardzo skomplikowanym mechanizmem w którym, każdy pracownik niezależnie od stanowiska poza swoimi podstawowymi zadaniami musi także zadbać o inne aspekty pracy. Zarówno podczas pisania kodu jak i w wypadku owych "innych" obowiązków nie istnieje jedno wspólne narzędzie załatwiające wszystkie problemy, każdego pracownika zespołu. W zależności od obszaru w jakim się poruszamy - potrzebujemy innego zestawu narzędzi. Często początkujący programiści są zdania, że jedynym młotkiem jaki potrzebują jest środowisko. Niestety nawet podczas wykonywania podstawowych zadań, często okazuje się, że samo IDE nie wystarcza... Wiele osób z braku znajomości alternatywnych narzędzi stara się wszystko zrobić ręcznie, bądź zaczyna marginalizować kwestie, których nie da się w łatwy sposób rozwiązać. W efekcie marnuje swój czas (i często swoich kolegów), budżet projektu, pieniądze klienta co wpływa na jego zadowolenie, a finalnie na opinię o pracowniku w oczach pracodawcy. ]]>
Dawno minęły już czasy gdy specjalistów zamykało się w pokoiku o czterech ścianach, wręczało klawiaturę i prosiło o "produkcję kodu źródłowego". Sam proces wytwarzania oprogramowania stał się bardzo skomplikowanym mechanizmem w którym, każdy pracownik niezależnie od stanowiska poza swoimi podstawowymi zadaniami musi także zadbać o inne aspekty pracy. Zarówno podczas pisania kodu jak i w wypadku owych "innych" obowiązków nie istnieje jedno wspólne narzędzie załatwiające wszystkie problemy, każdego pracownika zespołu. W zależności od obszaru w jakim się poruszamy - potrzebujemy innego zestawu narzędzi. Często początkujący programiści są zdania, że jedynym młotkiem jaki potrzebują jest środowisko. Niestety nawet podczas wykonywania podstawowych zadań, często okazuje się, że samo IDE nie wystarcza... Wiele osób z braku znajomości alternatywnych narzędzi stara się wszystko zrobić ręcznie, bądź zaczyna marginalizować kwestie, których nie da się w łatwy sposób rozwiązać. W efekcie marnuje swój czas (i często swoich kolegów), budżet projektu, pieniądze klienta co wpływa na jego zadowolenie, a finalnie na opinię o pracowniku w oczach pracodawcy. ]]> Wed, 25 Jun 2014 10:49:14 GMT /slideshow/ide-srodowisko-pracy-36296791/36296791 danielpokusa@slideshare.net(danielpokusa) IDE to za mało! Jak stworzyć efektywne środowisko pracy? danielpokusa Dawno minęły już czasy gdy specjalistów zamykało się w pokoiku o czterech ścianach, wręczało klawiaturę i prosiło o "produkcję kodu źródłowego". Sam proces wytwarzania oprogramowania stał się bardzo skomplikowanym mechanizmem w którym, każdy pracownik niezależnie od stanowiska poza swoimi podstawowymi zadaniami musi także zadbać o inne aspekty pracy. Zarówno podczas pisania kodu jak i w wypadku owych "innych" obowiązków nie istnieje jedno wspólne narzędzie załatwiające wszystkie problemy, każdego pracownika zespołu. W zależności od obszaru w jakim się poruszamy - potrzebujemy innego zestawu narzędzi. Często początkujący programiści są zdania, że jedynym młotkiem jaki potrzebują jest środowisko. Niestety nawet podczas wykonywania podstawowych zadań, często okazuje się, że samo IDE nie wystarcza... Wiele osób z braku znajomości alternatywnych narzędzi stara się wszystko zrobić ręcznie, bądź zaczyna marginalizować kwestie, których nie da się w łatwy sposób rozwiązać. W efekcie marnuje swój czas (i często swoich kolegów), budżet projektu, pieniądze klienta co wpływa na jego zadowolenie, a finalnie na opinię o pracowniku w oczach pracodawcy. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/ide-srodowiskopracy-140625104914-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> Dawno minęły już czasy gdy specjalistów zamykało się w pokoiku o czterech ścianach, wręczało klawiaturę i prosiło o "produkcję kodu źródłowego". Sam proces wytwarzania oprogramowania stał się bardzo skomplikowanym mechanizmem w którym, każdy pracownik niezależnie od stanowiska poza swoimi podstawowymi zadaniami musi także zadbać o inne aspekty pracy. Zarówno podczas pisania kodu jak i w wypadku owych "innych" obowiązków nie istnieje jedno wspólne narzędzie załatwiające wszystkie problemy, każdego pracownika zespołu. W zależności od obszaru w jakim się poruszamy - potrzebujemy innego zestawu narzędzi. Często początkujący programiści są zdania, że jedynym młotkiem jaki potrzebują jest środowisko. Niestety nawet podczas wykonywania podstawowych zadań, często okazuje się, że samo IDE nie wystarcza... Wiele osób z braku znajomości alternatywnych narzędzi stara się wszystko zrobić ręcznie, bądź zaczyna marginalizować kwestie, których nie da się w łatwy sposób rozwiązać. W efekcie marnuje swój czas (i często swoich kolegów), budżet projektu, pieniądze klienta co wpływa na jego zadowolenie, a finalnie na opinię o pracowniku w oczach pracodawcy.

IDE to za mało! Jak stworzyć efektywne środowisko pracy? from Daniel Pokusa

]]> 782 3 https://cdn.slidesharecdn.com/ss_thumbnails/ide-srodowiskopracy-140625104914-phpapp01-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-danielpokusa-48x48.jpg?cb=1524057811 Just love good software & agile development ;) http://www.danielpokusa.pl https://cdn.slidesharecdn.com/ss_thumbnails/errorserrors-180507144904-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/errors-errors-everywhere-jsession/96274526 Errors errors, everywh... https://cdn.slidesharecdn.com/ss_thumbnails/errorserrors-180409090146-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/errors-errors-everywhere/93308786 Errors errors, everywh... https://cdn.slidesharecdn.com/ss_thumbnails/errorserrors-180326204134-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/errors-errors-everywhere-boilingfrogs-2018/91990972 Errors errors everywhe...