- 280
- 827 855
Warsaw JUG
Приєднався 13 лют 2013
319. WJUG - Marcin Baranowski "Padłeś? Powstań! Temporal.io"
Nagranie 319. spotkania Warsaw Java User Group z 29.10.2024.
Partnerem spotkania była firma Snowflake www.snowflake.com
www.meetup.com/warszawa-jug/events/304149171
Abstrakt:
Kupujesz mieszkanie (robisz przelew ekspresowy na setki tysięcy złotych). Przy dużej inwestycji towarzyszy nam stres, nawet gdy wszystko idzie zgodnie z planem. A co jeśli pieniądze już zniknęły z twojego konta, ale nie pojawiły się na koncie odbiorcy... Mija 5 minut, 15 minut, pół godziny... Ręce spocone, serce bije szybciej... gdzie są moje pieniądze?! Po przedarciu się przez infolinię i po 3 przekierowaniach udaje Ci dowiedzieć, że wystąpił błąd systemu informatycznego, ale wszystko jest pod kontrolą i pieniądze właśnie dotarły do odbiorcy. Uff... Co jako programista możesz zrobić, by zniwelować takie stresujące sytuacje? Być może więcej, niż na pierwszy rzut oka się wydaje. Na prezentacji zamiast stresu będzie o Temporal.io, który pozwala opanować ścieżki non happy path w aplikacjach.
Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount
Nagranie dzięki uprzejmości Paramount paramount.tech/
Partnerem spotkania była firma Snowflake www.snowflake.com
www.meetup.com/warszawa-jug/events/304149171
Abstrakt:
Kupujesz mieszkanie (robisz przelew ekspresowy na setki tysięcy złotych). Przy dużej inwestycji towarzyszy nam stres, nawet gdy wszystko idzie zgodnie z planem. A co jeśli pieniądze już zniknęły z twojego konta, ale nie pojawiły się na koncie odbiorcy... Mija 5 minut, 15 minut, pół godziny... Ręce spocone, serce bije szybciej... gdzie są moje pieniądze?! Po przedarciu się przez infolinię i po 3 przekierowaniach udaje Ci dowiedzieć, że wystąpił błąd systemu informatycznego, ale wszystko jest pod kontrolą i pieniądze właśnie dotarły do odbiorcy. Uff... Co jako programista możesz zrobić, by zniwelować takie stresujące sytuacje? Być może więcej, niż na pierwszy rzut oka się wydaje. Na prezentacji zamiast stresu będzie o Temporal.io, który pozwala opanować ścieżki non happy path w aplikacjach.
Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount
Nagranie dzięki uprzejmości Paramount paramount.tech/
Переглядів: 567
Відео
311. WJUG - Mateusz Gajewski "Modern Java for decade-old problems"
Переглядів 751Місяць тому
Nagranie 311. spotkania Warsaw Java User Group z 23.01.2024. www.meetup.com/warszawa-jug/events/298586763 Abstrakt: Mateusz opowiada o upgradzie Javy w dużym projekcie Open Source (Trino) i wyzwaniami, jakie taka zmiana stawia przed zespołem. Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount Nagranie dzięki uprzejmości Paramount paramount.tech/
317. WJUG - Andrus Adamchik - "DataFrame - a Swiss Army Knife of Java Data Processing" [English]
Переглядів 141Місяць тому
317. WJUG meetup - 01.10.2024. www.meetup.com/warszawa-jug/events/303636317 Abstract: Can we use big data techniques without big data infrastructure? As Java developers, we deal with data processing all the time: analyzing app logs, extracting data from Excel, copying tables between databases, etc. Yet, the “standard” Java falls short in processing capabilities compared to more complex and heav...
316. WJUG - Grzegorz Piwowarek - "Embracing microservices"
Переглядів 748Місяць тому
316. WJUG meetup - 03.09.2024 www.meetup.com/warszawa-jug/events/303059680 Abstrakt: Mikrousługi już od dłuższego czasu nie są rzadkością na rynku - przez ten czas branża odkryła tysiące sposobów jak wdrażać je źle. Przykładowo: poprzez przywiązanie do starych nawyków przyjaznych monolitom, złych praktyk wdrożeniowych, groteskowej polityki bezpieczeństwa firmy itp. Podczas tej prelekcji będziem...
316. WJUG - Mateusz Chrzonstowski i Damian Kaczmarczyk - "Trochę więcej o testach w Springu"
Переглядів 969Місяць тому
316. WJUG meetup - 03.09.2024 www.meetup.com/warszawa-jug/events/303059680 Abstrakt: Niby nie jest to inżynieria rakietowa, jednak przeskakując z firmy do firmy i z projektu na projekt, widuje się podobne błędy i problemy, zwłaszcza z testami integracyjnymi. Podczas wykładu zwrócimy uwagę na najpopularniejsze kompromisy, pomyłki i sztuczki, m.in. duże i cache’owalne konteksty Springa vs. małe i...
315. WJUG - Michał Niczyporuk "Beginner's guide to observability" [English]
Переглядів 366Місяць тому
Nagranie 315. spotkania Warsaw Java User Group z 04.06.2024 Recording of 315. WJUG meetup from June 4th 2024 www.meetup.com/warszawa-jug/events/301345351 Abstract: In this talk, I will go over different types of observability tools - logs, metrics, traces and events - and show how they can be applied in day-to-day work. Throughout the talk, I will provide practical do’s and don’ts for applicati...
315. WJUG - Juliusz Marciniak - "k8s on-premises - dlaczego nie chcesz tego robić?"
Переглядів 6213 місяці тому
Nagranie 315. spotkania Warsaw Java User Group z 04.06.2024. www.meetup.com/warszawa-jug/events/301345351 Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount Nagranie dzięki uprzejmości Paramount paramount.tech/
311. WJUG - Krzysztof Przygudzki - "Dlaczego heksagon nie zawsze ma osiem boków?"
Переглядів 6443 місяці тому
Nagranie 311. spotkania Warsaw Java User Group z 23.01.2024 www.meetup.com/warszawa-jug/events/298586763 Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount Nagranie dzięki uprzejmości Paramount paramount.tech/
306. WJUG - Marcin Jakuszko - "Pierwsza randka z ‘krypto'..."
Переглядів 2753 місяці тому
Nagranie 306. spotkania Warsaw Java User Group z 19.09.2023. www.meetup.com/warszawa-jug/events/296074859 Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount Nagranie dzięki uprzejmości Paramount paramount.tech/
309. WJUG- Tomasz Ducin - Dlaczego FE wraca na serwer: ewolucja architektury webowej
Переглядів 9183 місяці тому
Nagranie 309. spotkania Warsaw Java User Group z 21.11.2023. www.meetup.com/warszawa-jug/events/297416293 Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount Nagranie dzięki uprzejmości Paramount paramount.tech/
308. WJUG - Maciej Przepióra - "Java Memory Model for Mere Mortals" [EN]
Переглядів 3233 місяці тому
Nagranie 308. spotkania Warsaw Java User Group z 07.11.2023. www.meetup.com/warszawa-jug/events/297023830 Partnerem tego spotkania była firma Vodeno - vodeno.com/ Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount Nagranie dzięki uprzejmości Paramount paramount.tech/
308. WJUG - Damian Kamyszek - "Projektowanie Architektury Aplikacji"
Переглядів 1,1 тис.3 місяці тому
Nagranie 308. spotkania Warsaw Java User Group z 07.11.2023. www.meetup.com/warszawa-jug/events/297023830 Partnerem tego spotkania była firma Vodeno - vodeno.com/ Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount Nagranie dzięki uprzejmości Paramount paramount.tech/
303. WJUG - Jan Siekierski "Mikroserwisy w chmurze - jak to wygląda z lotu ptaka"
Переглядів 3393 місяці тому
Nagranie 303. spotkania Warsaw Java User Group z 06.06.2023. www.meetup.com/warszawa-jug/events/293894277 Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount Nagranie dzięki uprzejmości Paramount paramount.tech/
305. WJUG - Piotr Przybył - Java 21: What's new and noteworthy?
Переглядів 1,2 тис.7 місяців тому
Nagranie 304. spotkania Warsaw Java User Group z 05.09.2023. www.meetup.com/warszawa-jug/events/295783311/ Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount Nagranie dzięki uprzejmości Paramount paramount.tech/
304. WJUG Krzysztof Ślusarski - Architektura "Thread-per-core" jako droga do najlepszej wydajności
Переглядів 1,1 тис.7 місяців тому
Nagranie 304. spotkania Warsaw Java User Group z 20.06.2023. www.meetup.com/warszawa-jug/events/294222275/ Spotkanie odbyło się w siedzibie Partnera WJUG - firmy Paramount Nagranie dzięki uprzejmości Paramount paramount.tech/
301. WJUG Chris Suszyński - "You need event mesh, not a service mesh"
Переглядів 2467 місяців тому
301. WJUG Chris Suszyński - "You need event mesh, not a service mesh"
301. WJUG Robert Szarejko - "JVM Garbage Collector - świadomy wybór"
Переглядів 7067 місяців тому
301. WJUG Robert Szarejko - "JVM Garbage Collector - świadomy wybór"
299. WJUG - Sławek Sobótka - "Modularyzacja - miało być pięknie, a wyszło jak zawsze"
Переглядів 2,1 тис.7 місяців тому
299. WJUG - Sławek Sobótka - "Modularyzacja - miało być pięknie, a wyszło jak zawsze"
292. WJUG - Krzysztof Ślusarski "Porty, adaptery, CQRS, Event Sourcing, DDD… w Springu?
Переглядів 20 тис.2 роки тому
292. WJUG - Krzysztof Ślusarski "Porty, adaptery, CQRS, Event Sourcing, DDD… w Springu?
WJUG Extra - Jakub Pilimon - "Testing - Love, Hate, Love" [ENG]
Переглядів 3,3 тис.4 роки тому
WJUG Extra - Jakub Pilimon - "Testing - Love, Hate, Love" [ENG]
WJUG #269 ONLINE - Piotr Przybył - Java 14. Nowości godne uwagi
Переглядів 2,4 тис.4 роки тому
WJUG #269 ONLINE - Piotr Przybył - Java 14. Nowości godne uwagi
WJUG #267 ONLINE - Krzysztof Ślusarski Profiling cz. 1 - kręgi piekła profilingu (JProfiler G1GC)
Переглядів 7 тис.4 роки тому
WJUG #267 ONLINE - Krzysztof Ślusarski Profiling cz. 1 - kręgi piekła profilingu (JProfiler G1GC)
WJUG #266 - Matt Jarvis - Introduction to KUDO - Kubernetes operators the easy way
Переглядів 4604 роки тому
WJUG #266 - Matt Jarvis - Introduction to KUDO - Kubernetes operators the easy way
WJUG #265 - Andrzej Goławski - CI/CD on OKD (Origin Community Distribution of Kubernetes)
Переглядів 9844 роки тому
WJUG #265 - Andrzej Goławski - CI/CD on OKD (Origin Community Distribution of Kubernetes)
WJUG #264 - Sandra Rogalska - Znajdowanie „wąskich gardeł” przy użyciu Jamesa i Elasticsearcha
Переглядів 1 тис.4 роки тому
WJUG #264 - Sandra Rogalska - Znajdowanie „wąskich gardeł” przy użyciu Jamesa i Elasticsearcha
WJUG #263 - Michał Szynkiewicz - Quarkus - Javowy framework nowej generacji
Переглядів 2,3 тис.4 роки тому
WJUG #263 - Michał Szynkiewicz - Quarkus - Javowy framework nowej generacji
WJUG #262 - Arkadiusz Gasiński - Fruits of the Loom - Lightweight Concurrency for Java
Переглядів 1,5 тис.4 роки тому
WJUG #262 - Arkadiusz Gasiński - Fruits of the Loom - Lightweight Concurrency for Java
WJUG #261 - Kevlin Henney - Structure and Interpretation of Test Cases
Переглядів 1,3 тис.4 роки тому
WJUG #261 - Kevlin Henney - Structure and Interpretation of Test Cases
WJUG #260 - Paul Czarkowski - Spring into Kubernetes
Переглядів 1,6 тис.4 роки тому
WJUG #260 - Paul Czarkowski - Spring into Kubernetes
WJUG #259 - Błędy w Agile & Corda Blockchain - lesson learned
Переглядів 4065 років тому
WJUG #259 - Błędy w Agile & Corda Blockchain - lesson learned
Bardzo dobry content. Ten talk trzeba też zrobić na jakimś Boiling Frogs, a nie tylko Java Group. Tylko next time proszę szybciej mówić.
Ogólnie plus, ale... "Do not start with microservices" - to jest mit powtarzany w kółko, odkąd modular monolith został re-odkryty przez celebrytów software engineering'u. Prawidłowa odpowiedź: zaczynasz z tym, z czym musisz. Jak masz 10 teamów i ogromny system, to rozbicie tego na serwisy powinno być pierwszym krokiem. Można ewentualnie później poprawić granice, ale 60 osób commitujące do tego samego serwisu to proszenie się o problemy.
Swietna prezentacja!
Fajnie ze Djoković po tych wszystkich turniejach tenisa ma czas wpaść na JUGa do Warszawy i opowiedzieć o GC
Jestem w sytuacji zawodowej, w której od około 7 lat pracuję jako programista Java w różnych firmach. W każdej z tych firm pracowałem w metodyce Scrum z wykorzystaniem sprintów. Zauważyłem powtarzający się schemat i w mojej obecnej pracy jest podobnie: menedżerowie używają sprintów jako narzędzia nadmiernej kontroli i wywierania presji na dostarczenie wszystkiego w ramach sprintu. Często mówią o terminach i deadline’ach. Atmosfera jest taka, że zawsze czuję, że jestem w tyle i że nie robię wystarczająco dużo. Mam trudności z pracą pod presją w sprintach i z tego powodu rozważam zmianę stanowiska na takie, na którym nie musiałbym pracować w sprintach. Jaką radę moglibyście mi dać?
Czy pracowałeś w dużych korpo, czy może w startupach? Z doświadczenia wiem, że duże korpo to większy work-life balance i sprawniej ułożone procesy(oczywiście każdy może mieć inne zdanie). Managerowie z którymi ja pracowałem można podzielić na a) bawiący się w micromanagement - wszędzie wtyka nos, optymalizuje i 'usprawnia' wszystko, żeby pokazać wzrost produktywnosci o 3%(kosztem odejść pracowników w dłuższej perspektywie). b) dobrze znający domene, procesy i biznes - dzięki temu sprawnie może przelewać wymagania na historyjki, a dobrze przegadane historyjki to dużo większy uzysk w produktywnośći. c) PM został Scrum Masterem i "korzystając" ze swojej bogatej wiedzy managerskiej (nie agilowej) i dostając się bezpośrednio do feature teamów pushował teamy żeby pokazać, że można pracować lepiej, szybciej i często z pominięciem prawidlowego podejscia scrumowego (wyciaganie asap storiesow, wciskanie do sprintu za duzo zeby potem "wrocic do tego nastepnym razem na retro"). D) servant leader - podejście w którym manager jest dla Ciebie ostoja spokoju, pomaga Ci w Twoich problemach, oraz w problemach klientow, wyzszego szczebla itd. Rozumie, że jego rolą jest rozwiązywanie problemów dla klientów za pośrednictwem feature teamu (takich spotkałem tylko dwóch przez 10 lat expa) Ja jestem wyznawcą podejścia, żeby znaleźć sobie miejsce w takiej firmie i w takim teamie w jakim w koncu bedziesz szczesliwy ze mozesz się spełniać zawodowo, ale też mieć dużo czasu dla siebie :)
Dzięki za komentarz :) Zaczynamy jednak bardzo szeroki temat, który mocno odbiega od wykładu, więc proponowałbym przejść z nim na Slacka JVM-Poland: warszawa.jug.pl/contact/ 👀 1. Z jednej strony, sprinty miały być trochę takim gwarantem - zespół deklaruje, że dowiezie konkretne rzeczy i może się na nich skupić. 2. Z drugiej, Scrum miał być "implementacją" Agile, a w Agile chodzi o zwinność, rozmowy z klientami, adaptację, samoorganizujące się zespoły itp... 3. Podoba mi się spojrzenie Allena Holuba, przedstawione w wykładzie "The death of Agile" ( ua-cam.com/video/vSnCeJEka_s/v-deo.html ), które opisywałem w swoim marcowym newsletterze ( mailchi.mp/08e92c7af3e2/materialy-marzec ) - jeśli w zdaniu możemy zastąpić "Agile" przez "flexibility", to jest OK. 4. Z tego, co piszesz, to u Ciebie jest bardzo daleko od "flexibility". 5. Wydaje mi się, że miałeś jednak sporego pecha, żeby przez 7 lat wciąż spotykać się z podobną sytuacją. Być może przechodziłeś zawsze przez podobne firmy, jak sugeruje @Mayar555? Sam próbowałem różnych rzeczy i podejścia do sprintów też były różne, ale raczej lepsze niż gorsze 🤷♂ 6. Dobrze wspominam np. czasy, kiedy pracowałem z Kanbanem. IMO Scrum pozwala na więcej nadużyć. 7. Na szybko, nie szukałbym innego stanowiska (chyba że programowanie Cię jednak nie bawi), tylko podczas rozmów rekrutacyjnych na programistę Java, pytałbym więcej o organizację pracy. Na podstawie doświadczeń powinieneś być w stanie sformułować pytania, które pozwolą Ci wychwycić czerwone flagi. Zadawałbym je zarówno programistom podczas technicznej rozmowy, jak i managerom, podczas tzw. "culture fit" i w zależności od odpowiedzi akceptował lub odrzucał oferty. 8. Alternatywnie, jeśli masz możliwości wpłynięcia na procesy w firmie czy to bezpośrednio, czy to przez kogoś "wyżej", czy to podczas jakichś ankiet, "all-handsów" itp., możesz próbować podsyłać materiały jak wykład Holuba albo artykuły o "mierzeniu produktywności", które tłumaczą jak bardzo mija się to z celem i co robić zamiast tego. Mam ciekawe przykłady np. w tym wydaniu newslettera, w punkcie 4: mailchi.mp/c3122bee7746/materialy-wrzesien :)
@remek712 Pracujesz przy projekcie (ograniczony umowami z Klientem) czy przy produkcie (Twoja firma jest także Klientem)? Projekty często mają deadline'y wynikające z umów i to ciężko przeskoczyć. Jeśli problem dowożenia jest realny a nie sztucznie napędzany przez menadżerów, to myślę, że w takiej sytuacji można: 1. Porozmawiać z PO, żeby skupić się tylko na rzeczach koniecznych w projekcie a zadania nice-to-have wrzucić gdzieś na koniec - po prostu okroić Sprint do rzeczy koniecznych. 2. Pomyśleć czy estymacja w projekcie jest ok - jak problem stale występuje, możliwe, że zadania są niedoszacowane a kierownictwo traktuje Story Pointy jako umowę z programistą :) BTW polecam prezkę Jarosława Ratajskiego na ten temat: ua-cam.com/video/I-0e4d__oXk/v-deo.html 3. Rozważyć rozmowę z Klientem (jeśli jest realny problem z dowożeniem, a nie tylko taka sztuczna atmosfera) i przedyskutować czy jest możliwe zmniejszenie zakresu projektu - to raczej jako broń ostateczna, ale jak Firma jest też Klientem to jak najbardziej wykonalne. 4. Odświeżyć CV :)
Filmik ma 9 lat, a ciężko znaleźć lepszy materiał na YT
Jako backendowiec przykro mi się patrzy na te wszystkie osoby tak bardzo stojące przy tym, jak skomplikowane to to nie jest i niepotrzebne. Nextjs daje ogromne możliwości dzięki SSR i od wersji 13-stej wszystko stało się jaśniejsze i prostsze ale widzę, że dla niektórych pisanie witryn w HTMLu i JSie nadal jest najlepszą opcją 😅
Fajny wykład.
Jak działa nowoczesny komputer ? Co to za brednie ? Komputer działa tak samo, to jest o optymalizacji w czasie rzeczywistym na przykładzie JIT, JIT to software a nie hardware. Kiedyś były komputery wieloprocesorowe które działały jak obecne wielokorowe. Co to jest ?
Gratuluje prowadzącemu cierpliwości w odpowiadaniu na pytania Pana Backendowca.
Ale... ale heksagon nigdy nie ma osiem boków, bo zawsze ma sześć 😅
2:55 ciekawy ten trzeci case 😏
W odniesieniu do pytania prowadzącęgo: jakby ktoś używał Springa i się zastanawiał dlaczego Java 20 może nie być najlepszym wyborem, wklejam ich aktualną politykę: "We fully test and support Spring on Long-Term Support (LTS) releases of the JDK: currently JDK 8, JDK 11, JDK 17, and JDK 21. Additionally, there is support for intermediate releases such as JDK 18/19/20 on a best-effort basis, meaning that we accept bug reports and will try to address them as far as technically possible but won't provide any service level guarantees. We recommend JDK 17 and 21 for production use with Spring Framework 6.x as well as 5.3.x."
Odkopuje stare wideo> Na początku mówisz, że dwóch odeszło i to źle. Ale podobno reszta pracowników przestała się martwić o raty za dom i zaczęli cenić swoje miejsce pracy i podobno ogólna lojalność i wydajność wzrosła. Czy to prawda? Nie wiem. Wiele lat później mamy (za wikipedią, która cytuje jakiś wywiad): "In March 2020, Price said that the pay raise has worked well for his company in particular. He extended the same minimum wage to all employees of ChargeItPro, a company Gravity Payments acquired in 2019"
Trzeba zrobi erratę - ani słowa o Kotlinie, choć rozumiem że 7 lat temu jeszcze nie wiedziano że będzie popularny.
Można obejrzeć dla zajawki. Aby cokolwiek *wiedzieć* trzeba przeczytać Java Concurrency In Practice.
Fajna prezentacja. Fajna dyskusja na początku (pierwsze pytanie) :D
Świetny materiał! Tak pięknie wytłumaczone, że dziś odpalam ten wykład żonie zamiast netflixa.
Ale Jakub ma wiedzę. Podziw
Świetna prezentacja, same konkrety, przykłady, o to chodzi !
Świetna prezentacja!
Bardzo fajna prezentacja, aż chciałoby się więcej takich materiałów o Kotlinie od totalnych podstaw po jakieś zaawansowane zagadnienia. Dzięki za filmik :)
Dobry wykład, pozdrawiam
Ciekawie mówi
Dzięki temu filmowi dziś dałam radę rozwiązać problem, który nie sądziłam, że dam radę rozwiązać samodzielnie (myślam, że jest wyciek, a okazało się, że to pamięci było za mało). Dziękuję serdecznie, Krzysztofie!
Wspaniały wykład!!
Bardzo dobra prezentacja, jako laik w kwestiach współbieżności sporo się dowiedziałem. Dzięki, Mateusz.
Fajny wykład, dzięki wielki.
Dobre to bylo!
no i to jest kurwa prezentacja, zawsze tu wracam i mysle TO JEST prezentacja na poziomie, a nie kolejny raz walkowanie o podstawach FP ktore kazdy zna (PURE IMMUTABILITY) i 0 real world caseow.
nie przeklinaj
W końcu prezentacja, której nie trzeba przyspieszać, a do tego merytoryka na wysokim poziomie. Sztos totalny.
Zajebisty wykład
Oj, radzę przed prezentacją potwierdzić coś czego nie jesteśmy pewni - mnie to zakuło w uszy :-o : English def. 'argument': "a reason or set of reasons given with the aim of persuading others that an action or idea is right or wrong." Use example: "there is a strong argument for submitting a formal appeal".
Rewelacyjny wykład! Dzięki wielkie.
Super wykład pod względem merytorycznym! Dodatkowo głos i sposób mówienia prowadzącego idealny do prezentowania.
chciałem sie przekonać do DDD ale nie potrafie. to jest armata na muche. postawiony fikcyjny problem typu "ktos bedzie chcial nam zmienic stan obiektu przez repozytorium" ktos czyli kto? i kiedy? o jakiej katastrofie mowisz na poczatku projektu? od czego jest code review? kto by taka zmiane przepuscil? te ddd to taki dam bullsht jak soa na poczatku lat 2000. wymarlo to smiercia naturalna bo overhead jaki to narzucalo generowal raczej bol glowy. to samo jest obecnie z mikroserwisami, ze ludzie stosuja to na potege bez myslenia po co to zostalo stworzone i potem maja tone integracyjnych problemow i redundancje danych miedzy bazami. wracajac do ddd: ile razy zmieniales repo w projekcie? 2 lata robimy na postgresie a potem nagle "ej wrzucmy mongo jednak"? dostarczylem ponad 250 ludzi przestrzeni 5ciu lat na setki projektow i nikt w polowie projektow nie zmienial repo. a co jak chcemy zmienic jezyk programowania? a co jak pojawia sie komputery kwantowe? nie widze sensu tego ddd. szmat kodu na fikcyjne problemy. ale sam prowadzacy sztos. merytoryka i wiedza na najwyzszym poziomie. szacunek tutaj :)
W ogóle mam wrażenie, że to wszystko jest przekomplikowane. W pracy próbuję przekonać szefa do docker;a, dzielenia monolitów na kilka serwisów ale on woli klepnąć skrypcik w bazie. W pewnym sensie ma racje, przy stopniu skomplikowania mechanizmów u nas. i tego, że to firma produkcyjna, a nie software house, to rozkminy jak na filmie byłyby u nas nadmiarowe. A repo - nigdy nie zmieniałem repo, taniej jest kupić przedrożoną licencję niz przerabiać setki procedur.
te wszystkie rzeczy są potrzebne do odpowiedniego skalowania projektu, nie tylko pod względem performance, ale też pod względem wdrażania nowych developerów. Gdy stosujesz takie podejście, masz całą logikę zamkniętą w agregacie, bardzo prostą do testowania jednostkowego, więc nie boisz się wprowadzać zmian i masz mniejszą rotację pracowników :)
Mnóstwo kodu, a prosty CRUD z początku prezentacji robi to samo XD
i tak i nie :) idąc od strony biznesu i zarabiania hajsów kod ma działać, a jak to robi to inna sprawa a z drugiej strony uporządkowanie świadczy o kunszcie a z trzeciej strony skłaniam się ku prostym rozwiązaniom, aktualnie pozbywamy się Setterów/Builderów lombokowych z kodu, encje mają swoje odpowiedzialności tak w skrócie i uważam to za w miarę czyste
Po 6 miesiącach ale i tak odpowiem. ES daje ci możliwość odtworzenia dowolnego stanu obkietu i daje ci dokładna historię zmian co jest np bardzo wazne w systemach bankowych.
@@JuMi896 Przecież se śmieszkuję XD
Bardzo dobra prezentacja! Pięknie zobaczyć wszystkie te koncepcje w praktyce.
prezentacja zaczyna się: 8:23
I'm from India , Can you make this video in English as well.
Hi. I'm not planing to record that in English, sorry. That was probably last time when I presented that particular presentation.
59:24 Nawiązując jeszcze do pytania o mockowanie criteria API w HashMapowym test-repo. Kilka myśli na chłodno. Jak dla mnie: - Criteria API powinno być używane do widoków/raportów, więc przekładając to na moją architekturę, będzie ono albo w query repository, albo w CRUDzie - tu powstaje pytanie, czy trzeba to testować? Według mnie nie. Jedyne co tym testujemy to czy Criteria API działa jak należy, czyli nie swój kod. Dla mnie to nie pasuje do testu jednostkowego modułu. - Wewnątrz jednego modułu ja tworzę JEDEN agregat w rozumieniu DDD, który może mieć wiele encji. W dobrym modelu agregaty są małe i całość da się wyciągnąć z FetchType == EAGER. Nie widzę przy wysyłaniu komendy do agregatu potrzeby używania Criteria API, wszystko mogę przeliczyć w RAMie, bo wyciągam cały agregat. - Jeżeli logika biznesowa jednego modułu zależy od wyniku Criteria API read modelu drugiego modułu, to na pierwszy rzut zweryfikowałbym, czy można to przerobić, np. przez odwrócenie zależności/redundancję danych w dodatkowych read-modelu. Nie umiem obecnie wymyśleć przykładu, że się tego nie da zrobić, ale chętnie go usłyszę. W moim podejściu CommandHandler zorkiestrowałby pracę tych 2 modułów, czyli to warstwa aplikacji uderza do Criteria API jednego modułu i przekazuje wynik do drugiego modułu. Dzięki temu drugi moduł nie zależy od repo pierwszego modułu, tylko od wyniku który jest przekazywany, czyli możesz przetestować oba moduły jednostkowo bez mocka Criteria API. Problemem będzie test jednostkowy pojedynczego CommandHandlera. Na teraz nie mam innych pomysłów niż: nie testować/przerobić bez Criteria API. - metody JPA Repo typu findByFirstName(...) są banalnie proste do mockowania, database.stream().filter(...).toList(), więc tu raczej nie ma co myśleć, tylko to zamockować jak jest potrzeba.
Jesli chodzi o prezentacje Michala R.: W prezentacji zostało wspomniane tylko o dwóch wzorcach: chain of responsibility oraz strategia. Wydaje mi się, że fajnie by było zrobić lekkie wprowadzenie do tych wzorców przed ich użyciem. Przykłady ciekawe, myślę, że dobrze oddają ideę. Z chęcią posłuchał bym o innych przykładach zastosowania wzorców w Spirngu.
Szef totalny
Bardzo dobra prezentacja i bardzo dobry kod :) od siebie dorzucę kilka sugestii: - Można zrezygnować z adnotacji w domenie i dodać mapowanie dopiero w adapterach przy pomocy pliku orm.xml. Wiem, trochę barbarzyńskie, ale zarówno Spring jak i IntelliJ mają do tego dobre wsparcie - W części "query" z CQRS-a można rozważyć projekcje Springa. W wielu przypadkach wystarczy samo repo i interfejsy z getterami, których nazwy są "kompatybilne" z nazwami pól (pole "name" w encji domenowej = getter "getName" w interfejsie-projekcji) - Polecam dodatek do IntelliJ "Presentation Assistant". Publika widzi wtedy jaki skrót klawiszowy został użyty przez prezentującego
Ach, jeszcze AssertJ polecam :)
Wspomniane referencje: ua-cam.com/video/ILBX9fa9aJo/v-deo.html ua-cam.com/video/do-xqIbKZ_8/v-deo.html ua-cam.com/video/JJXmgCx_wh0/v-deo.html ua-cam.com/video/cJDDsSj2vJA/v-deo.html ua-cam.com/video/aq3Jwti9K14/v-deo.html
Gdzie moglibyśmy znaleźć kod źródłowy?
@@MaRsOnIxPL Link jest w opisie filmu.
@krzysztofslusarski7081 Jak podejść do problemu zwracania informacji o rezultacie operacji przez handlery (gdy mają być voidami) do klienta API (UI)? Klient api może po wysłaniu rozkazu wysłać zapytanie o stan operacji ale tu może dojść do wyścigu. Pytam w kontekście gdy klient komunikuje się w ramach request - response i nie ma możliwości nasłuchiwania na eventy wysyłane przez serwer.
Gość jest totalnym szefem, mam nadzieję, że nie był ostatni raz oraz że jego wykłady pojawią się na YT w przyszłości również
Fajna prezentacja, rzeczowa - doceniam mało lania wody, jednak wprowadziłeś atmosferę stresu, co dla słuchacza niespecjalnie jest komfortowe. Mogłeś to poprowadzić w tym samym czasie, po prostu ton i sposób mówienia. Popracuj nad tym przed Confiturą, proszę. Inna sprawa że IMO nie powinno się przenosić logiki do obiektu. Dla mnie najlepsze są DTO i logika w serwisie - wiem, to jest abiektowe, ale dlaczego? Rozszerzalność, DI, możliwość wywalenia /zmiany frameworków, SRP. Co jakbyś chciał weryfikować dodanie płatności w takim pracowniku? Gdzie logika? Gdzie nasłuch - aspekty dodasz czy proxy? Dla mnie argument że "logika rozsiana po 70 serwisach jest zła" jest zły - dzisiaj IDE wszystko Ci znajdzie, jeden klik. Tym bardziej, jak mamy mikroserwisy - to wtedy jest zaleta, bo możesz ograniczyć powielenie w niektórych momentach i lepiej podzielić kod.
z tą logiką w serwisach to jesteś w błędzie :) też tak kiedyś myślałem ale przychodzi z czasem :)
@@ML-hf6ii a co zrobisz jak jeden klient ma wymaganie takie a inny takie? Strategie jakieś? Gdzie warunki oddelegujesz? Poza tym jesteś w błędzie to niezbyt zachęcające do dyskusji stwierdzenie.
@@kretynek1 generalnie przeczysz temu co mówią zarówno "wielcy" tej branży jak i temu co pokazuje historia że projekty z rozsiana logika gdzie wszystko zależy od wszystkiego nie należą do łatwych i przyjemnych w utrzymaniu. Poczynaj o rich/anemic domain, DDD i clean code.
@@ArekTheBoss a gdzie ja mówię że wszystko zależy od wszystkiego? Poza tym w clean architecture jest chociażby powiedziane żeby zmiany były atomowe i od razu widoczne co i gdzie się zmienilo, w kontekście pakietów. Jak chcesz to zrobić mając cała logikę w DTO? Jeszcze raz, jak chcesz to potem rozszerzać? Krytykujecie bez argumentów, rozmowa typu "ja wiem lepiej, jesteś głupi". Nawiasem mówiąc, czytałem te tematy/książki, poza OOP jest też FP, dla przykładu. Jak sobie zamodelujesz makaron, to makaron będziesz miał.
@@kretynek1 jaką logikę w dto? kto tu mówi o dto? tam nie powinno być logiki. mowa o obiektach stricte domenowych vs logika rozsiana po n serwisach. Mylisz pojęcia. Mam w aktualnym projekcie (który nie jest crudem, zawiera mnóstwo logiki jako takiej) właśnie takie podejście (bogata domenta, clean architecture) i sprawdza się to bardzo dobrze.
Wielkie dzięki za nagranie. Mam parę podpowiedzi. W testach miło jest używać @DisplayName - liczy się czytelność AttributeOverride nie jest potrzebny - użyj AttributeConverter - z autoApply = true Co do likwidacji adnotacji JPA Entity z domeny to można użyć interfejsów w domenie a implementacji z @Entity w infrastrukturze, bo JPA umie śledzić zmiany bazując na polach jak również na getterach
Też bardzo fajne pomysły. Dziękuję.
I teraz można spokojnie obejrzeć z prędkością 0.75
Ja zazwyczaj oglądam na x2 ale muszę powtarzać x1 żeby wszystko zrozumieć
1:29:21 za dużo kodu nawalone, polecam SOLID