devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
2 minut

DevTalk#39 – O sagach z Robertem Pankoweckim


05.09.2016

Robert PankoweckiŻegnamy lato, witamy jesień! A z nią: DevTalk wraca na antenę po wakacyjnej przerwie! Z utęsknieniem na ten moment czekałem, przyznać muszę. I bardzo fajnie mi się dzisiejszy odcinek nagrywało.

Waszym i moim gościem jest Robert Pankowecki: programista Ruby… i nie tylko. Występuje na konferencjach, pisze książki (sic!), bloguje itede. Zresztą, sam się porządnie przedstawi po naciśnięciu PLAY. Na Twitterze: @pankowecki. Na Snapchacie: pankowecki.

Mamy dziś tech-mięsko: na tapetę bierzemy SAGI. Co to jest i po co to jest, w jakich scenariuszach je implementować i jak je przetestować? Poruszamy bardzo wiele tematów związanych z tym zagadnieniem, ślizgając się również po powiązanych kwestiach. Niejednokrotnie kwestie te doczekały się własnych dedykowanych odcinków podcasta, linki do nich znajdziecie niżej.

Daj znać w komentarzu jak się podobało. Podziel się w socialach. Rośnijmy w siłę.

Dodatkowo gorąco proszę o wejście na iTunes (http://devtalk.pl/itunes) i zostawienie tam oceny/recenzji. Pomoże to w walce o lepszą pozycję DevTalk na ajtunsowej liście. A zajmowaliśmy tam już miejsce w pierwszej trójce podcastów technologicznych najchętniej słuchanych przez Polaków!

Oprócz tego podczas minionych wakacji liczba odsłuchań podcasta przekroczyła 100 tys! I to tak całkiem znacząco.

Najs i spox z podzięxem!


Montaż odcinka: Krzysztof Śmigiel.
Ważne adresy:

Linki


Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). Powered by ConvertKit
Notify of
Pawel Klimczyk

Super odcinek! Da się odczuć, że model aktorowy jest przydatny.

Marcin Pietraszek

“Saga (…) skedżuluje taki komand (…) – zkapczuruj tę transakcję”
LOL :)

PiotrB

Orkiestruj defaultowe settingsy … i wszystko będzie jasne.

Marcin Pietraszek

Z jednej strony to dziwnie brzmi ale z drugiej jak np przetłumaczyć “cherry-pickować commita na heada brancha” ;)

Czereśniować zobowiązanie na głowę gałęzi?

Pawel
Pawel

Może pytanie z innej beczki, ale jak autor, doświadczony programista w RoR zapatruje się na Elixir ? Czy środowisko Elixir/Erlang OTP ma szanse przebić się w RoR, zwłaszcza, iż Actor model w Erlangu występuje jako out-of-box.

Mirosław Pragłowski
Mirosław Pragłowski

Zdecydowanie inna beczka ;)
Saga / process manager to koncept (wzorzec). Może być zaimplementowany w dowolnym języku. IMHO nie ma aż tak dużego znaczenia w czym będzie zaimplementowany. Wiadomo (o czym Robert też mówił) że gdzieś będzie łatwiej (bo np. do implementacji możesz wykorzystać wbudowany w platformę actor model (np. Erlang)), gdzieniegdzie trudniej bo musisz sam pewne rzeczy ogarnąć.

Co ma Elixir do RoR? Hmm, … nie wiem :) Inny rodzaj młotka ;) Zależy jakie “gwoździe” masz do wbicia – aby wbić gwoździk w ścianę pod obrazek nie ma sensu używać młotka do wbijania mostowych pali ;)

Robert Pankowecki

Hej Pawle, Nie bawiłem się jeszcze z Elixir/Erlang więc trudno mi się wypowiedzieć na jego temat. Myślę, że do części community się przebije, na to wygląda. Przy czym mówiąc to mamy na myśli oczywiście taki skrót myślowy, który oznacza, że tak naprawdę RoR community przyjdzie do E/E community po wiedzę i młotki :) Sam natomiast nie będę raczej obstawiał tego konia. Mam w planach pójść bardziej w JRuby / JVM i jego języki (Clojure/Scala/Java8) oraz biblioteki (Akka) bo widzę tam większy wybór oraz dobry tooling. Czas pokaże czy to dobra droga. Od siebie mogę polecić tylko używanie narzędzi, które lubisz.… Read more »

Pawel
Pawel

Hej Robert, Dzięki za odpowiedź na moje pytanie odnoście przyszłości Ruby oraz Elixir. Wracając do tematu samego podcast-u, to świetnie, iż przekazałeś kiedy powinno stosować się wzorce typu Sagas oraz tendencję do pisanie aplikacji w stylu Event-Driven Development i jakie ma to korzyści na tworzeniem wszelkich rozwiązań opartych o scheduler i cron. Sam jestem zwolennikiem tworzenia aplikacji w duchu pull i reactive niż push, zwłaszcza w czasie, kiedy modne jest pojęcie real-time. Co do Elixir-a, sam też nie jestem przekonany jak przyjmie się w rozwiązaniach komercyjnych Tutaj raczej też skłaniam się do Java/Scala, chociaż same języki w porównaniu z C#,… Read more »

Karol
Karol

Ja mam następujące pytanie. Powiedziane zostało, że saga to przeniesienie transakcji z warstwy bazy danych na warstwę aplikacji. To jest jasne. Jednak rodzi się inne pytanie. W pewnym momencie pan Robert przytoczył przykład z systemem sprzedaży biletów i powiedział, że w pewnych sytuacjach trzeba “odblokować” pieniądze na koncie usera. A co jeśli z jakiegoś powodu nie możemy tego zrobić? np api do płatności jest niedostępne z powodu awarii. Jak w takiej sytuacji powinna zachować się saga?

Robert Pankowecki

Hej, tutaj Pan Robert ;) > A co jeśli z jakiegoś powodu nie możemy tego zrobić? np api do płatności jest niedostępne z powodu awarii. Jak w takiej sytuacji powinna zachować się saga? Wtedy możesz np zapisać event, że się nie udało i zaplanować powtórkę tej akcji na przyszłość (zakładając, że masz infrastrukturę, która na to pozwala) etc. Inny przykład, który my mamy, to że obsługujemy faktycznie bramki płatności, które nie mają API do zwrotu pieniędzy :-) Serio. Mają tylko do kupowania. Na szczęści to jakaś mniejszość, bo to są bramki, w których np. się płaci biorąc kredyt (bo bilet… Read more »

Karol
Karol

Dzięki za odpowiedź :)

Faktycznie można robić tak jak piszesz. Ja się za bardzo przywiązałem do transakcji i myślenia, że w razie niepowodzenia natychmiast trzeba wycofać zmiany. Jak widać w sagach wycofywanie wprowadzonych zmian również może być rozłożone w czasie.

Robert Pankowecki

> myślenia, że w razie niepowodzenia natychmiast trzeba wycofać zmiany.

to jest spoko do pewnego momentu :) Do momentu aż cały proces jest tak skomplikowany albo ma taki contention na jakimś zasobie, że lockowanie i transakcyjność stają się nieadekwatne do wymagań wyajnościowych.

Albo do momentu, gdzie ten proces staje się już rozproszony (distributed) po różnych systemach i nie ma sensu udawać, że możemy to wrapnąć w transakcję :)

Jak długo można warto jednak robić transakcje, bo rollback bardzo prosty, oczywiście.

Moja książka

Facebook

Zobacz również