Jacek Milewski

trener Java

Pomagam zespołom dostarczać wartość dla użytkowników szybciej i precyzyjniej dzięki zrozumieniu potrzeb biznesowych i budowaniu skalowalnych produktów zabezpieczonych pragmatycznymi testami.

Wszystko to z entuzjazmem i zaufaniem.

Mam wiedzę, pasję, otwartość i ciekawość ludzi - zestaw cech które gwarantują budowanie wartościowych produktów:

  • osiągających przewagę nad konkurencją i wykorzystać szanse
  • skalowalnych i bezpiecznych, stabilnie wykorzystujące wypracowaną przewagę w dłuższej perspektywie
  • Doświadczenie potwierdzone dostarczonymi produktami

  • bezpośrednio używanymi przez użytkowników oraz krytycznymi systemami będącymi podstawą działania organizacji
  • znacząco redukującymi koszt testów manualnych przez implementację strategii testowania Shift-left
  • iteracyjne rozwijanie architektury odpowiadającej na potrzeby organizacji
  • Social Media:

    Czym jest dla mnie Bottega IT Minds?

    Są w IT ludzie których się podziwia, absolutni liderzy w branży, miejsca gdzie chce się być. Bottega od lat dla mnie jest takim miejscem. Obecność w tym gronie to wielka rzecz.

    Na czym polega moja praca?

    Rozwijam produkty z którymi organizacje czują się bezpiecznie w realizacji najważniejszych celów. Bezpieczeństwo daje dbałość o jakość ale też rzetelne realizowanie wymagań biznesowych.

    Specjalizacja trenera

    • Spring Framework

      Wprowadzenie jak i zagadnienia zaawansowane. Moduły Springa, Boot, microservices.
      Zobacz szkolenia...

    • Testowanie i QA

      Nowoczesne techniki testowania automatycznego i manualnego. TDD, BDD, Spec by Example.
      Zobacz szkolenia...

    • Testowanie automatyczne

      Nowczesne praktyki testowania automatycznego. BDD, TDD, Spec by Example.
      Zobacz szkolenia...

    • Zaawansowana Java


      Zobacz szkolenia...

    • Microservices

      Kompleksowy zestaw szkoleń. Podejście od strony DevOps, architektury aplikacji i integracji oraz kodu i testowania.
      Zobacz szkolenia...

    Materiały Trenera

    Idea renesansowej pracowni - Bottegi zakłada nieustanną pracę jej członków i dzielenie się jej wynikami.

    • Outbox Pattern: kiedy ten strzał do API to jednak za mało
      KATEGORIE: Wzorce architektoniczne

      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? :)

    • Testy Kontraktowe
      KATEGORIE: Testowanie automatyczne

      Testowanie nie kończy się na pojedynczym mikroserwisie. Testy Kontraktowe rozwiązują problem bezpieczeństwa interakcji, integracji, bezpieczeństwa wdrożeń w dużych systemach. Rozmowa zgłębia szanse jakie dają testy kontraktowe.

    • Testowanie automatyczne: czego kursy Cię nie nauczą
      KATEGORIE: Testowanie automatyczne

      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?

    • Testing Code is simple. Just write units and integration
      KATEGORIE: Testowanie automatyczne

      "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? It's worth to pick 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

    • Zaimplementuj monolit. Ale taki modularny z granicami
      KATEGORIE: Wzorce architektoniczne

      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ć.

    • Hasła - Czy to Ty je łamiesz moim użytkownikom?
      KATEGORIE: Bezpieczeństwo

      Historie dla programistów z życia wzięte o zabawie w kotka i myszkę z hackerami. 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ń.

    • Testowanie automatyczne: czego kursy Cię nie nauczą
      KATEGORIE: Testowanie automatyczne

      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?

    • Outbox Pattern: kiedy ten strzał do API to jednak za mało
      KATEGORIE: Wzorce architektoniczne

      I znowu ten moment: w swoim procesie wywołujesz API zewnętrznego systemu. Co robisz? Jeśli jest piątek po poł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 róż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ę.

    • Zaimplementuj monolit. Ale taki modularny z granicami
      KATEGORIE: Wzorce architektoniczne

      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ć.

    Szkolenia autorskie trenera