Jacek Milewski
IT Trainer | DDD Architect | Developer | Consultant | Speaker | Mentor
Trener IT | Architekt DDD | Programista | Konsultant | Prelegent | Mentor
Warsaw, Poland
Actions
🎯I help teams delivering value faster, understanding business needs and building scalable Architecture and Shift-left Testing Strategy. With a passion and trust.
🥇 I have the experience, knowledge, passion and open mindset - perfect skills to deliver value to the customers and the businesses with:
✔Speed - required to catch the market opportunity
✔Quality - to retain and scale
Proven by:
✔Building and maintaining systems at the core for the entire business stability
✔Significantly reducing the cost of manual tests by implementing Shift-left testing strategy
✔Iteratively designing and building Architecture open for business expansion yet not over-engineered
🙋🏻 I'm curious about you and the challenges you're facing. I'm happy to get to know each other. It is inspiring to work together and discuss solutions that help you in making responsible, educated decisions.
🎯 Pomagam zespołom szybciej dostarczać wartość, lepiej rozumieć potrzeby biznesowe oraz budować skalowalną architekturę i strategię testowania typu shift-left. Z pasją i zaufaniem.
🥇 Posiadam doświadczenie, wiedzę, pasję i otwarty umysł — idealny zestaw kompetencji, by dostarczać wartość klientom i biznesowi poprzez:
✔ Szybkość — niezbędną, by wykorzystać okazje rynkowe
✔ Jakość — potrzebną do utrzymania i skalowania
Potwierdzone przez:
✔ Tworzenie i utrzymanie systemów będących fundamentem stabilności całego biznesu
✔ Znaczną redukcję kosztów testów manualnych dzięki wdrożeniu strategii testowania shift-left
✔ Iteracyjne projektowanie i budowanie architektury otwartej na rozwój biznesu, ale nieprzesadnie skomplikowanej
🙋🏻 Ciekawi mnie, kim jesteś i z jakimi wyzwaniami się mierzysz. Z przyjemnością Cię poznam. Wspólna praca i rozmowy o rozwiązaniach, które pomagają podejmować odpowiedzialne i świadome decyzje, są bardzo inspirujące.
Area of Expertise
Topics
Shift-left: Testing microservices' code is simple. Strategy is to write units and integration. en pl
"Oh... Now I see... I mean Integration tests between `modules`, while you mean between `components`" - Discovered after an hour-long discussion during Code Review. They need one more our to find out that integrating a `module` is very different from `component`. But first things first, let them discover first that they define a `module` and `component` in a different way. Then the tester says: Integration is when we connect `microservices` together...
Is that true that we can only develop unit, integration and E2E tests? Then what is the `unit`? And `Integration` - means we integrate what? Why not call it a `unit` too, since it is written in jUnit? Surely, the `Integration` is the one that is slow, `unit` is the fast one. Why actually they say we should separate Application Logic from Domain Logic, while we still cover it with the same type of Integration test?
In E2E System tests what are the `Ends`: classes, components, modules, microservices, contracts or the whole system? Do we even have components and modules inside? What can a tester do in such a case? To be safe and to keep chaos under control he resorts to duplicate test cases 'on his own'. He will use SIT with a fully running system to reach the seventh step in the form where he enters a first name that is... one char too long. Nothing better than an expensive test suite that is steadily red.
Ouch! Enough! Stop it, it hurts!
This is how it goes with testing. jUnit is simple, AssertJ as well, Mockito, even Spock. Just one tutorial to go. There we are with several tools. We miss guidelines on how to use them together to build confidence. It's worth picking one of the testing strategies. Wow... so we can have a strategy? And there's more than one to choose? Show us!
I will! But please leave behind your boundaries and prepare to embrace something new.
audience: For Developers and testers (Intermediate)
time: 30-60 min
Shift-left: Testowanie kodu mikroserwisów jest proste. Piszesz unity i integration. en pl
"Aha... Bo widzisz... ja mówię o testach integracyjnych między modułami, a Ty - między komponentami" - Powiedzieli sobie po godzinnej dyskusji nad Code Review. Po kolejnej godzinie okaże się że integracja modułu i komponentu to zupełnie dwie różne bajki. Ale po kolei - najpierw niech dojdą do tego że nie rozumieją nawzajem czym jest 'moduł' a czym 'komponent'.
Czy naprawdę jest tak że możemy pisać jedynie testy jednostkowe, integracyjne i UI? No, to czym jest ten unit? A integracyjny - to co z czym zintegrowane? A dlaczego to nie unit, skoro też pisze się w jUnit? Pewnie Integracyjny to ten wolny, a unit to ten szybki? Dlaczego w zasadzie mówią aby rozdzielać Logikę Aplikacyjną od Logiki Domenowej skoro i tak obkładam to testem integracyjnym?
Aj... przestań już! Boli! Chaos!
Z tym testowaniem to już tak jest. jUnit jest prosty, AssertJ również, Mockito, nawet Spock. Do ogarnięcia tutorialem. I tak zostajemy sami z rozrzuconymi narzędziami. Ale jak to poskładać... sensownie... trzeba by przyjąć jedną ze strategii testowania. Czekaj... to można mieć strategię?! Nawet kilka?... To nie ma jednej słusznej piramidy?! Pokaż!
Pokażę! Ale wyjdźcie z ustalonych ram i przygotujcie się na coś nowego.
audience: For Developers and testers (Intermediate)
time: 30-60 min
Contract tests: Spare us the shame. Shift-left and detect the problem before deployment. en pl
What do you mean it doesn't work?! My code doesn't work in the environment? The tests are passing, just look at CI! I coded this at the beginning of the sprint, and now you come to me at the end when I have to push other things through with my knee.
The code has been changed, and of course, the tests too. Just to make sure they pass.
But the contract is broken.
Every backend exposes a contract. And sometimes half the company relies on it. How is it that, up until now, the only way to ensure compatibility is through manual tests or GUI clickers? What goes into testing sometimes comes back a week later as a bug. Shameful :) This is not what we fought for with CI! And the only way to find out who uses the API is... you know - turn it off and see who comes and how quickly.
We have tools at our disposal. They are unknown, so instead of poking at them with a stick and avoiding them, I will show how to implement them. Practically, not academically.
audience: Developers, Intermediate
Testy kontraktowe: Wstydu oszczędź. Shift-left i wykryj problem przed deployem. en pl
Jak nie działa?! Mój kod nie działa na środowisku? Testy zielone, zobacz tylko na CI! Zakodowałem / Zakodowałam to na początku sprintu, a Ty w końcówce do mnie przychodzisz jak ja muszę inne rzeczy kolanem dopychać.
Kod zmieniony, testy oczywiście też. Żeby przechodziły.
Ale kontrakt złamany.
Każdy backend wystawia kontrakt. I czasem pół firmy na nim polega.
Jak to jest że jeszcze do tej pory jedyny sposób aby zapewnić kompatybilność to testy manualne lub GUI klikacze. Co trafia do testów wraca czasem po tygodniu jako bug. Wstyd :) Nie o takie CI walczyliśmy!
A jedyny sposób żeby dowiedzieć się kto korzysta z API to… wiadomo - wyłączyć i zobaczyć kto przyjdzie i jak szybko.
Przecież mamy narzędzia. Nieznane są, więc zamiast dotykać patykiem i omijać, pokażę jak to wdrożyć. Praktycznie, nie akademicko.
audience: Developers, Intermediate
Outbox Pattern: when API call magically disappeared en pl
Three main challenges in distributed systems:
2. message order
1. duplicates
2. message order
3.
"I've told them once that splitting my modularized monolith to microservices will be easy. Well, it should be easy then..."
Nothing changes, just the network.
And here they are: messages are lost or duplicated, delayed or out of order, testing is more complex and less reliable, infrastructure implementation details leaks into the apps.
Talk gives hint on all those and even more aspects of reliable communication, focusing on Outbox Pattern. Giving the heuristics on deciding which issue affects you, and how, plus solutions: how strong solution you need to deal with it.
audience: Developers, Architects (Intermediate)
Outbox Pattern: kiedy ten strzał do API to jednak za mało en pl
I znowu ten moment: w swoim procesie wywołujesz API zewnętrznego systemu. Co robisz? Jeśli jest piątek popołudniu - wołasz synchronicznego POSTa i super :) Implementacja prosta, szybka, testy implementujesz błyskawicznie.
Ale w weekend nie odpoczniesz. Bo przecież co jak POST nie dojdzie bo sieć zawodna. A Ty już po swojej stronie zrobiłeś commit nowego rekordu w bazie. A jak POST dojdzie, ale będzie długo? User będzie czekał na UI a przecież co go interesuje że pod spodem jakiś zewnętrzny system jest powolny. No chyba w poniedziałek trzeba będzie doczytać o tych rozproszonych transakcjach i Two-phase commit. I już wiesz że kawa się będzie lała strumieniami.
Opowiem o komunikacji asynchronicznej z zachowaniem spójności końcowej z użyciem wzorca integracji Outbox. Sprawdza się gdy zmiana musi się zakomitować w kilku systemach które pojedynczo może i są transakcyjne, ale jako całość nie są. Zmiana zapisuje się do bazy ale musi trafić też na kolejkę? A co jak zapiszesz na kolejkę ale transakcja na bazie się nie powiedzie? Trzeba rollbackować z kolejki? Oby tylko ta wiadomość jeszcze tam była, prawda? :)
Historia oparta na case-study integracji systemów rożniących się od siebie. Wymienię jakie problemy dzięki Outbox macie rozwiązane za darmo, a jakie problemy wygenerowane. Też za darmo :) Po to abyś wiedział i świadomie podjął decyzję.
audience: Developers, Architects (Intermediate)
Implement the monolith - the one well modularized en pl
How many times did you hear: `Modularize the monolith, instead of doing microservices`? And maybe you see the point, but the next day you sit in front of your IDE wondering... How to actually implement it?
The title sounds like it was presented in the previous era, isn't it? Now everyone is doing Serverless. Possibly microservices in older systems. Or maybe it is a very urgent topic to talk about, as all three architectures find their fit into a particular case. Particularly the modularized monoliths are important when facing a decision of distributing your system.
The presentation is full of content - the Case Study based on a product that started as a Monolith, to become a Modularized Monolith. Shows the process of codebase modularization, starting with basic repackaging, defining modules in code up until the presentation of the tool that guards the modules' border for us automatically - the ArchUnit. Because we surely want to avoid manual rules checking.
In a presentation I assume that module boundaries are already defined on a business level. The focus is on implementing and enforcing them in the code.
audience: Developers, Architects (Intermediate)
Zaimplementuj monolit. Ale taki modularny z granicami en pl
Ile razy słyszeliście że 'nie mikroserwisy tylko modularny monolit'? I nawet się z tym zgadzasz. Ale po konferencji siadasz do kodu i... Jak to właściwie zrobić?
Tytuł jak wzięty z konferencji z poprzedniej epoki, prawda? Teraz implementuje się Serverless. a w starszych systemach - Mikroserwisy. A może jest inaczej - może to tytuł z następnej epoki gdy historia zatoczy koło? A może jednak temat jest bardzo aktualny, bo wszystkie te trzy architektury mają swoje zastosowanie. Szczególnie dużo o modularnym monolicie i pilnowaniu granic mówi się w kontekście mikroserwisów.
Prezentacja to Case Study na bazie produktu który zaczął się jako monolit i skończył jako modularny monolit. Pokazuje proces modularyzacji kodu. Zaczynając od zwykłego przesuwania klas między paczkami, przez definiowanie modułów w kodzie, oraz pokazanie jak korzystam z narzędzia do wymuszania tych reguł - ArchUnit. Bo przecież tak nie chcemy tego pilnować ręcznie na Code Review.
Prezentacja zakłada że granice modułów są już wymyślone. Skupimy się na tym jak te wyznaczone granice zaimplementować i dopilnować.
audience: Developers, Architects (Intermediate)
Login API Security - is that you who attacks my system? en pl
A real life story for backend developers about the game of cat and mouse with hackers. They know the passwords of my users and they make use of that knowledge. But I know that they know. And where do they know it? Do I know who they are? Yes - I'll show you how.
They also know the passwords of your users. And they will come to you. For sure we care a lot about the complex business logic we build. Login endpoints, well, are just a tiny piece of it, however, critical. Do you monitor them? Let me show you how my login endpoints are attacked, so that you are prepared.
I'll show you those attacks - the traffic patterns, data they had, how they did it, why they did it and what they achieved. Also what we did with this knowledge and how the culture is important in such moments. I will show you a lot - maybe even too much. In an open manner - exactly how security should be treated in serious systems. We speak too little about security.
audience: Dev, Sec, Ops, Architects (Intermediate)
Hasła - Czy to Ty je łamiesz moim użytkownikom? en pl
Historie dla programistów z życia wzięte o zabawie w kotka i myszkę z hakerami. Oni znają hasła moich użytkowników i robią z tego użytek. Ale ja wiem że oni wiedzą. I wiem skąd wiedzą. Czy wiem kim oni są? Tak. Pokażę Wam skąd.
Oni znają także hasła Twoich użytkowników. I przyjdą też atakować Twój system. Na pewno bardzo dbamy o elegancką implementację reguł biznesowych. Proces logowania, no cóż - wygląda przy tym jak niewielka część całości, jednak niezwykle ważna. Monitorujesz kto się do Ciebie loguje? Pokażę Ci jak moje endpointy do logowania są atakowane abyście mogli się przygotować.
Pokażę Ci te ataki - zmiany w ruchu sieciowym, jakie dane mają atakujący, jak to robią, po co to robią i z jakim rezultatem. Pokażę też co my zrobiliśmy w tej sytuacji i zauważysz jak kultura zespołu jest ważna w takich chwilach. Pokażę Ci dużo, być może za dużo. Otwarcie - dokładnie tak jak powinno się mówić o bezpieczeństwie w poważnych systemach. Tak aby inni mogli skorzystać z naszych doświadczeń.
audience: Dev, Sec, Ops, Architects (Intermediate)
Unit tests - am I doing it right? en pl
How many tests are failing while you're changing the production code? Of course they do - that's why we have them. But take a look... do they fail because the essential business logic has changed or... are those accidental failures? You know the drill: avoid accidental failures.
There are many approaches to design and develop automated unit and integration tests. Each system might require a different approach. As a result - there is a whole bunch of materials on it, but still is it enough? Probably not, as still we all see the tests that we think are not good enough, don't we?
You'll find something for you here. You'll get a recipe on how to implement it in your project, as this is not yet another presentation showing only the concept, but also the code. I'll be coding it live, step by step. Going from the very basic setup, showing real life cases. You'll see my approach on building and testing modularized systems. You'll get familiar with the whole idea and get heuristics when to use it and... when not to. Also I'll show you some nice practices I use every day that make the tests better.
audience: Developers (Intermediate)
Testy unitowe - czy ja to robię dobrze? en pl
Praktyk stosowanych w testach automatycznych jest wiele. Materiałów które o tym mówią też jest wiele, ale nadal niewystarczająco. Warto inspirować się na nowo.
Powiem o podejściu do testów jednostkowych i integracyjnych. Zaczynając od koncepcji testowalnych modułów, przez kodowanie na żywo przykładu, w końcu przechodząc do kilku wygodnych praktyk usprawniających pisanie testów.
Chcę tym samym zasiać ziarnko inspiracji i naruszyć strefę komfortu w której wielu z nas biegle porusza się od lat mockując i fejkując zależności w testowanej klasie. Dołożymy po prostu jeszcze jedno narzędzie do Twojej kompletowanej przez lata skrzynki.
Jestem przekonany że odnajdziesz w mojej prezentacji coś dla siebie. Dostaniesz przepis jak od jutra wdrożyć to u siebie oraz dowiesz się jaka jest odpowiedź na wiecznie aktualne pytanie rekrutacyjne: Jak testujesz swój kod?
audience: Developers (Intermediate)
Reliable Messaging: Outbox and a Spectrum of At-Least-Once Delivery Patterns en pl
"We don’t just slap everything in the same way because it worked once or failed." This often-repeated mistake highlights a critical challenge in reliable messaging: choosing the right delivery pattern for your specific needs. While the Outbox Pattern is a well-known solution for at-least-once delivery, it's far from the only option – and even it has many flavors.
This session will equip you with a comprehensive understanding of diverse at-least-once delivery patterns, ranging from simplified approaches to more complex implementations. We'll explore how each pattern optimizes different architectural drivers, helping you move beyond common pitfalls and make truly informed design decisions.
You'll gain practical insights and clear criteria to:
* Assess the effectiveness of existing or proposed delivery mechanisms.
* Choose the most suitable pattern for your project's unique requirements.
* Lead your team with confidence, providing strong arguments for your architectural choices and demonstrating a broad perspective on complex communication challenges.
Become the leader who understands the needs and consequences of reliable network communication. Leave this session ready to elevate your team's approach to message delivery and build more robust, resilient systems.
audience: Developers, Architects (Intermediate)
Niezawodne przesyłanie wiadomości: Outbox i spektrum wzorców "at least once" en pl
„Nie robimy wszystkiego w ten sam sposób tylko dlatego, że raz się udało lub nie.” Ten często powtarzany błąd podkreśla kluczowe wyzwanie w niezawodnym przesyłaniu wiadomości: wybór odpowiedniego wzorca dostarczania dla Twoich konkretnych potrzeb. Chociaż wzorzec Outbox jest dobrze znanym rozwiązaniem do dostarczania wiadomości „at least once”, jest on daleki od jedynej opcji – a nawet on ma wiele wariantów.
Ta sesja wyposaży Cię w kompleksowe zrozumienie różnorodnych wzorców dostarczania wiadomości „at least once”, od uproszczonych podejść po bardziej złożone implementacje. Zbadamy, jak każdy wzorzec optymalizuje różne czynniki architektoniczne, pomagając Ci uniknąć typowych pułapek i podejmować prawdziwie świadome decyzje projektowe.
Zdobędziesz praktyczne spostrzeżenia i jasne kryteria, aby:
* Oceniać efektywność istniejących lub proponowanych mechanizmów dostarczania.
* Wybierać najbardziej odpowiedni wzorzec dla unikalnych wymagań Twojego projektu.
* Prowadzić swój zespół z pewnością, przedstawiając mocne argumenty za swoimi wyborami architektonicznymi i demonstrując szeroką perspektywę w złożonych wyzwaniach komunikacyjnych.
Zostań liderem, który rozumie potrzeby i konsekwencje niezawodnej komunikacji sieciowej. Opuść tę sesję gotów do podniesienia poziomu podejścia Twojego zespołu do dostarczania wiadomości i budowania bardziej niezawodnych, odpornych systemów.
audience: Developers, Architects (Intermediate)
Jacek Milewski
IT Trainer | DDD Architect | Developer | Consultant | Speaker | Mentor
Warsaw, Poland
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top