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.
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:
Doświadczenie potwierdzone dostarczonymi produktami
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.
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.
Wprowadzenie jak i zagadnienia zaawansowane. Moduły Springa, Boot, microservices.
Zobacz szkolenia...
Nowoczesne techniki testowania automatycznego i manualnego. TDD, BDD, Spec by Example.
Zobacz szkolenia...
Nowczesne praktyki testowania automatycznego. BDD, TDD, Spec by Example.
Zobacz szkolenia...
Kompleksowy zestaw szkoleń. Podejście od strony DevOps, architektury aplikacji i integracji oraz kodu i testowania.
Zobacz szkolenia...
Idea renesansowej pracowni - Bottegi zakłada nieustanną pracę jej członków i dzielenie się jej wynikami.
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? :)
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.
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?
"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
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ć.
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ń.
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?
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ę.
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ć.