Świetny wykład, bardzo mądry i inteligentny prowadzący
@alicjasopek36186 күн бұрын
Bardzo ciekawy wykład
@Rzkacper6 күн бұрын
Kiedy kolejne spotkania?
@mleczakm6 күн бұрын
No dobrze, ale to jest po prostu SRP i zaprzestanie pisania kodu domenowego jako "to co mi PM opisał", zaaplikowanie tego za szybko łatwo prowadzi do wyciągania przedwczesnych abstrakcji nawet bez DDD.
@LuminousWatcherАй бұрын
Can we get english subtitles please?
@DanielŚmigiela2 ай бұрын
fajny, treściwy, konkretny sposób przekazywania wiedzy :) do mnie trafia :) pozdrawiam :)
@anotherguyonyt96352 ай бұрын
Awesome presentation and imagery
@ForgottenKnight13 ай бұрын
Title in English, video in Polish. Good job, kurwa :)
@abartosz3 ай бұрын
Smuci mnie jak wiele z tych antypaternów, o których wspominałeś występowało w mojej poprzedniej pracy... Ale cieszy mnie, że zmieniłem pracę na BEC. Liczę, że skoro zaprosili takiego prelegenta, to dbają o dobrą architekturę.
@marcinb75785 ай бұрын
Jakiego tabletu używa tutaj Pan Jakub, że tak fajnie może rysować LIVE?
@ArekTheBoss2 ай бұрын
ja tam widzę makbuka
@marcinb75782 ай бұрын
@@ArekTheBoss Musisz mieć bardzo dobry wzrok 😄W której minucie?
@MateuszSiemieniuk972 ай бұрын
@@ArekTheBoss Bardzo prawdopodobne. W 1:10:44 wspomina o AirPlay. :)
@rafald5097Ай бұрын
ipad, ale nie wiem, który pewnie pro
@maciej123456785 ай бұрын
2:31 os/360 IBM do 1979 roku większość projektów upadała więc matematycy (KNUTH) (kryzys programowania) zajęli się sprawą żeby uporządkować sprawy a inny wymyślili programowanie obiektowe w c++ (sorry C) 6:32 tak jak pisałem (ale cicho sza o kryzysie programowania) a teraz rozwiąniem ma być ML i w ogóle wszyscy na bruk... coś co nie potrafi między 2 a 4 zdaniem dostrzec sprzeczności z drugiej strony taki system jest chyba nie możliwy według niezupełności arytmetyki tw. Godla .. czyli niemożność zautomatyzowania matematyki .. ale lepiej nie mówić o tym co nie działa albo jest sprzeczne i trudne do odkręcenia grunt że nowe rzeczy powstają nowe typy procesorów PCM zamiast HBM może kiedyś memrystory ... nowy hype AGI za 3 lata.. a ja myślę że Winter is Comming Again AI Winter.. 14:14 to nic innego jak modele w logice i podejście no właśnie formalizacji do matematyki bazując na kryzysie po 1930 czyli tworzenie modeli.. meta meta meta ... model może zautomatyzować te meta.. no tak ML ... end
@krzysztoft58976 ай бұрын
2:22:55 - mega szacunek Jakub za ten tekst, to właśnie pokazuje patologię pod tytułem "outsourcing". Inaczej zwany al...ierą :)
@maciejszewczyk24306 ай бұрын
Super
@kacperpitas91737 ай бұрын
Anthony Fantano?
@danieldaniel46638 ай бұрын
Bardzo dużo konkretnej wiedzy, przekazane krótko zwięźle. Brawo!
@ambrozykleks6269 ай бұрын
Bo nie umieją. Cieniasy. Nie obejrzałem minuty i już wiem dlaczego..
@takiezycie116 ай бұрын
Dzban detected
@ambrozykleks6265 ай бұрын
@@takiezycie11 Pan Jakub nie zasłużył na takie słowa. Popitolił, ale jest fajny.
@ArekTheBoss2 ай бұрын
@@ambrozykleks626 xD
@user-ng1qo6cp8k9 ай бұрын
Nice to see, that this event took place at the WFC office building, where I had pleasure to be a Chief Engineer for 15 years... ;)
@mariuszsiera9 ай бұрын
Osobiście mam spory żal do tej prezentacji. Mimo iż merytorycznie bardzo mocna w większości przypadków, to przedstawia bardzo czarno-biało wyższość mikroserwisów nad innego rodzaju architekturą (tu: monolitem). Wiadomo że rzeczywistość nie jest czarno-biała. Chyba że klucz kryje się w stwierdzeniu "dużego monolitu", który dość niekonkretnie definiuje grupę docelową. Wg Randy'ego Shoupa (kzbin.info/www/bejne/b4KaeHSEjdNjaM0) 1% systemów wpada w tę kategorię. Oczywiście każdy chce mieć poczucie, że jest w tych 1%. Dlaczego z mikroserwisami należy ostrożnie? M. in. z powodu Fallacies of distributed programming, o których wspomina Kuba, ale bardzo wybiórczo i pobieżnie. Tworzenie systemów rozproszonych nie jest łatwe i w niemal każdym przypadku, kiedy Kuba odnosi się do omawianych problemów i stwierdza "to proste", w praktyce, jeśli schodzimy poniżej ivory tower view, nie jest proste. Jest sporo rzeczy, które wprowadzają komplikacje i to znaczące, które wprowadzają złożoność np. data locality i idąca za tym eventual consistency, eventual consistency w ogóle, proprawna implementacja komunikacji messagingowej (reordering, duplication, domain events vs state transfer events), congnitive load infrastruktury i zrozumienia tego co się dzieje w systemie. No free lunch. Co jest nie do zrobienia w monolicie to głównie: niezależnych stacków technologicznych, niezależność wdrożeń, wysoka efektywność skalowania (mimo że całkiem nieźle można skalować nawet duże systemy). Reszta jest do ogarnięcia, nie wchodząc w Fallacies of distributed programming. Rzeczywistość jest dużo bardziej zniuansowana.
@Mathes8819 ай бұрын
Skad najlepiej czerpac wiedze dotyczaca tych pul wątków (na request, bazy danych itp), zuzycia cpu itp? Od teorii po praktyke? Zeby moc sie tym pobawic w lokalnych warunkach.
@ArekTheBoss2 ай бұрын
Co masz konkretnei ma nysli? Teorię dotyczącą pól wątków? W zależności od technologii w któej pracujesz to w dokumentacji (trudna ściezka dla nowicjusza) lub różnego rodzaju kursach online (któe co prawda często są ogólne i prawie zawsze nei wyczerpują tematu ale dla nowicjusza to imho ok). Jeżeli chodzi o praktykę to, zakładając, że masz jakąś aplikację która działa i jest od nie jakich ruch, możesz ywykorzystać metryki (grafana, prometheus itp) gdzie możesz sobie wizualizować właśnie takie rzeczy jak utylizacja wątków itp.
@mariuszsiera9 ай бұрын
Smutne/zabawne jest to, że z tego powodu, że programiści nie potrafią się dogadać, tworzą skomplikowane (rozproszone) architektury, żeby uniknąć bólu związanego z komunikacją z ludźmi...
9 ай бұрын
Conway's law
@seNick77 ай бұрын
Dogadać? Jak masz 50,100,200 osób w projekcie to nie nazwałbym tego "dogadaniem". A co dopiero w ogromnych projektach? To jest niewykonalne. Do 20 osób może można się "dogadać".
@user-yf1to3lf1d10 ай бұрын
Bad English. Impossible to listen.
@JuniorJavaReady10 ай бұрын
❤
@j-krolik11 ай бұрын
1:26:09 czy ktoś wie o jakim konkretnie nagraniu mowa?
@JakubNabrdalik9 ай бұрын
Chodziło mi o stronę en.wikipedia.org/wiki/Fallacies_of_distributed_computing
@j-krolik9 ай бұрын
@@JakubNabrdalik dziękuje!
@krzysztofwroblewski941711 ай бұрын
1:08:48 wspominany jest pattern którego nazwy że słuchu nie udało mi się rozkodować. Można prosić o zapisanie?
@hawi7411 ай бұрын
Strangler pattern
@londonkaitlin4822 Жыл бұрын
'PromoSM'
@korniszon68 Жыл бұрын
Git człowiek!
@fringefringe7282 Жыл бұрын
Od 5 lat pajtam sie po roznych firmach i zespolach i nigdy nie widzialem jeszcze dobrze skonstruowanego srodowiska stworzonego metodykami zwinnymi. Wszystko po lebkach, dlug technologiczny jak z Warszawy do Nowego Yorku, zespoly wypalone, management najwazniejszy, zespol nie ma nic do powiedzenia w zadnej kwestii, nie ma bezposredniego kontaktu z klientem, kazdy "robi swoje" i nosa poza "swoje" nie wysciubia, etc. Metodyki zwinne powinno sie zlikwidowac. To jest nieudany projekt i tylko co jakis czas ktos sie objawia, zeby zaprezentowac jak zrobic z tego cos uzytecznego. Jedyne czemu tak naprawde sluza to wieksza kontrola nad technicznymi i ucieczka od odpowiedzialnosci przez ludzi biznesu "bo przeciez zawsze mozemy zmienic kierunek". Wszystko jest w tych Agile'ach najwazniejsze, tylko nie dobra, inzynieryjna robota. Stad zreszta wzial sie ruch "software craftsmanship". Lub inaczej, Google zadnych Agile'ow nie robi i nadal dobrze sobie radzi.
@qbakuba2057 Жыл бұрын
Gościu zna się na rzeczy
@krystianlaskowski Жыл бұрын
Skąd wiesz? Bo brzmi mądrze? 😅
@qbakuba2057 Жыл бұрын
@@krystianlaskowski bo mówi o moim doświadczeniu. Przerabiałem to co on i się z tym zgadzam. To co proponuje jest lepszym rozwiązaniem niż popełnianie błędów które są w necie i wielu firmach IT.
@BookBacklog8511 Жыл бұрын
jak zrobić spójny backup danych w sytuacji 10^X mikroservisów z własnymi bazami ?
@JakubNabrdalik Жыл бұрын
Co to jest spójny backup mikroserwisów? I do czego ma służyć?
@mrngwozdz9 ай бұрын
Możliwe, że bazy danych są oparte o sequencery i w takim przypadku spójny backup danych jest niezbędny ponieważ istnieje ryzyko że dane pomiędzy serwisami się rozsynchronizuja i będą wskazywać na id, zupełnie innego rekordu niż pierwotnie. W takim scenariuszu to nie backup jest problemem tylko niepoprawnie zaprojektowane mikro serwisy/tabele bazodanowe. W sumie nie za często spotykam się z omawianiem tego problemu na prezentacjach, a źle zaprojektowana baza danych z mojego doświadczenia to największa kula u nogi projektu.
@JakubNabrdalik9 ай бұрын
@@mrngwozdz Ciekawa uwaga. Ale się z nią nie zgadzam. Nie widziałem przypadku by ktoś wykonywał backup baz wszystkich mikroserwisów na raz i oczekiwał w tym backupie spójności. No bo niby czemu miałoby to służyć, skoro cały system i tak musi być zbudowany w oparciu o effectively-once delivery, oraz przywracanie danych każdego mikroserwisu jest kompletnie niezależne od pozostałych? Chyba nie mówimy o tym samym. Wspominasz o źle zaprojektowanej bazie jako problemie projektu, podczas każdy z mikroserwisów ma swoje własne bazy, enkapsuluje dane, ma swoje własne read-modele (zawsze nieaktualne), i idealnie powinien mieć w dupie co się dzieje w pozostałych mikroserwisach (resiliency). Pewnie łatwiej byłoby się dogadać jakbyśmy przyjeli jakieś założenia (np: event-driven na k8s z PostgreSQL, Redis lub MongoDB per serwis i Kafką z topic'ami z nieskończoną retencją gdzie pasuje + read modele w oparciu o compacted topics i Kafka Streams). Na przykład takie coś gitlab.com/jakubn/usage-analyzer/-/blob/main/README.md?ref_type=heads Możesz na tym przykładzie wytłumaczyć do czego miałby służyć "spójny backup danych"?
@mrngwozdz9 ай бұрын
@@JakubNabrdalik Dzięki za odpowiedź. Zacznijmy od tego że rozmawiamy o problemie który faktycznie występuje w projektach, ale nie powinien istnieć w przypadku prawidłowo wykonanej architektury mikrousługowej. Spróbuję wyjaśnić prawdopodobny problem kolegi @mariuszgodziszewski8511 na przykładzie z życia, gdzie sam ostatnio miałem "przyjemność" pracować przy projekcie gdzie taki "spójny backup danych" występował. Projekt całkiem spory, wszystko na rhelu z openshiftem na pokładzie (Self-managed) i oczywiście mikrousługami. Problem pojawił się taki, że osoby które prowadziły ten projekt wcześniej pracowali na monolitach i wszystkie tabele w bazach danych były na sequencerach. Dane pomiędzy serwisami często były powiązane właśnie po nich co doprowadziło do sytuacji gdzie w jednym module, odpowiedzialnym za raporty coś się mocno podziało nie tak, na tyle że trzeba było przywracać bazę danych. Gdyby została przywrócona tylko baza danych w module raportującym, okazałoby się że serwis, który wiązał po id z raportami zacząłby dostawać nie swoje raporty (do czasu wyrównania sequencerów do stanu poprzedniego). I tak o to powstała potrzeba przywracania baz danych dla wszystkich mikrousług, bo jeden z serwisów miał problem. Pewnie dla Ciebie opisana sytuacja jest niedorzeczna bo jest to zwyczajnie kardynalny, podstawowy błąd. No ale cóż, tak to wygląda w wielu projektach szczególnie gdy ktoś przechodzi z pisania monolitów do mikrousług. Podsumowując "spójny backup danych" jest odpowiedzią na problem, który nie powinien istnieć przy dobrze zaprojektowanej architekturze, co zresztą udowadniasz dziwiąc się na tak zadane pytanie. Także @mariuszgodziszewski8511 - jeżeli doszło do sytuacji, że potrzebujecie takiej funkcjonalności to znaczy że coś mocno poszło nie tak.
@JakubNabrdalik9 ай бұрын
@@mrngwozdz Wow, dzięki za odpowiedź. To faktycznie sytuacja chora w samych założeniach.
@krzysztofbardzinski Жыл бұрын
Świetna odpowiedź o bezsensie szacowania przy braku wiedzy z przeszłości
@vev Жыл бұрын
#My nootes The actual problems you're trying to solve The costs and risks of adopting a new architecture The benefits in terms maintainability, flexibility and long-term costs Entities define the business rules Use cases implement application logic and orchestrate entities Interface adapters translate user requests into use cases Frameworks implement the platform-specific code The 'main' component combines everything by depending on abstractions
@paweskarzynski8068 Жыл бұрын
1:1:50 - niech rzuci kamieniem ten, kto we własnym jednoosobowym projekcie nie musiał rozwiązywać merge conflictów ;-)
@katvonalex4694 Жыл бұрын
Jaki cel ma nawiązanie w tytule do zdrowia psychicznego?
@nanoGPT Жыл бұрын
clickbait microservice dobre dzielenie roboty (1h)
@Rafa-wf3ui Жыл бұрын
Na confiturze prowadzil prezentacje bardziej na temat zdrowia psychicznego ;)
@JakubNabrdalik Жыл бұрын
W książce podanej w 5:45 masz odpowiedź
@EASYPWNAGE8 ай бұрын
@@JakubNabrdalikczy prezentacja jest może dostępna pod jakimś URL?
@ArekTheBoss2 ай бұрын
Na confiturze 2023 jest talk jakuba o zdrowiu psychicznemu i wymienia tam kilka rzeczy któe pozwalają lepiej o nie zadbać dzięki mikroserwisom (continuous deployment, observability, autonomy, tdd itp). Pracowałem w zespole rozwijającym mikroserwis który miała utonomię i przykładał uwagę do testów -> teraz pracuję w zespole dopisującym ify w monolicie bez testów z releasem raz na kwartał i manualnymi testerami którzy są klikaczami i jednak poziom wygody a przez to stresu pogorszył się o kilka rzędów wielkości przez co myślę o zmianie.
@Alessandro_Russo Жыл бұрын
If there is only one version of the library shared, is this a coupling to a dependencies? This can became a disadvantages because of the need to develop a module based on a specific library version?
@forsh2966 Жыл бұрын
Thank you so much ❤
@mohamedsalama95 Жыл бұрын
Good work 💡👍
@rhinavlad Жыл бұрын
If we use monorepos and change version to shell and microfrontends, does it mean we need to deploy all artefacts from shell to microfrontends? Do we lose one of the main advantage of loading micro frontends in runtime and avoiding building shell app every time something's changed in MFE?