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.
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.
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.
[QE 2017] Daniel Pokusa - Architektura, która ewoluujeFuture Processing
Jak uniknąć „overdesignu”, równocześnie nie zamykając się na potencjalny rozwój? Na jakim etapie podejmować kluczowe decyzje oraz kiedy opłaca się świadomie zaciągać dług technologiczny? Wykład Daniela skierowany do wszystkich tych, którym zależy, aby ich aplikacje były utrzymane w dobrym stanie (uwzględniając często spore ciśnienie biznesowe). Prawdziwa historia o pomyłkach, porażkach, ale i decyzjach, które okazały się zbawienne dla projektu.
Scrum Studio - Lukasz Filut@Scrum Experience Day 2020Łukasz Filut
Scrum Studio i wyzwania, które napotyka w czerwonych i pomarańczowych organizacjach. Dzielę się swoimi doświadczeniami i receptami, które w tym przypadku uruchomiły Scruma w niełatwym środowisku.
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.
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.
[QE 2017] Daniel Pokusa - Architektura, która ewoluujeFuture Processing
Jak uniknąć „overdesignu”, równocześnie nie zamykając się na potencjalny rozwój? Na jakim etapie podejmować kluczowe decyzje oraz kiedy opłaca się świadomie zaciągać dług technologiczny? Wykład Daniela skierowany do wszystkich tych, którym zależy, aby ich aplikacje były utrzymane w dobrym stanie (uwzględniając często spore ciśnienie biznesowe). Prawdziwa historia o pomyłkach, porażkach, ale i decyzjach, które okazały się zbawienne dla projektu.
Scrum Studio - Lukasz Filut@Scrum Experience Day 2020Łukasz Filut
Scrum Studio i wyzwania, które napotyka w czerwonych i pomarańczowych organizacjach. Dzielę się swoimi doświadczeniami i receptami, które w tym przypadku uruchomiły Scruma w niełatwym środowisku.
The document discusses various distributed system patterns and concepts including microservices, CQRS, event sourcing, queues, circuit breakers, and retries. It also mentions fallacies of distributed computing and the CAP theorem. There are code examples for implementing retries and circuit breakers in Java as well as health checks. Distributed system issues like errors, timeouts, and failure recovery are also addressed.
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.
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.
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!).
Jak wdrożyć Continuous Delivery do Twojego (starego) projektu?Daniel Pokusa
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.
IDE to za mało! Jak stworzyć efektywne środowisko pracy?Daniel Pokusa
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.
The document discusses various distributed system patterns and concepts including microservices, CQRS, event sourcing, queues, circuit breakers, and retries. It also mentions fallacies of distributed computing and the CAP theorem. There are code examples for implementing retries and circuit breakers in Java as well as health checks. Distributed system issues like errors, timeouts, and failure recovery are also addressed.
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.
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.
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!).
Jak wdrożyć Continuous Delivery do Twojego (starego) projektu?Daniel Pokusa
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.
IDE to za mało! Jak stworzyć efektywne środowisko pracy?Daniel Pokusa
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.
48. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
49. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
50. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
51. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
52. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
53. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
54. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
55. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
9. Spróbuj zrozumieć biznes,
56. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
9. Spróbuj zrozumieć biznes,
10. Jeśli tylko możesz -> DDD i TDD,
57. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
9. Spróbuj zrozumieć domenę biznesową,
10. Jeśli tylko możesz -> DDD i TDD,
11. Nie zamykaj się na nowe technologie, ale równocześnie ograniczaj ich ilość.