Szymon Warda: Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie klasycznie na Patoarchitekci.io lub gdzieś, głównie chyba na dole. Nie ma sensu mówić góra, bok, bo zawsze są na dole, patrząc na playery.

Szymon Warda: To dzisiaj mamy nie lada gratkę, bo rozmowę z człowiekiem, z którym gdzieś tam się kiedyś przecinaliśmy, ale z którym już od dawna chciałem porozmawiać. Andrzej Krzywda, założyciel Arkency, programista, szachista. Ci, którzy wiedzą, Ci wiedzą doskonale z czym Andrzeja łączyć. A temat dzisiaj będzie ciekawy, bo porozmawiamy sobie o technologiach, co się z nimi dzieje, jak hype minął i czym właśnie są legacy? Czy możemy mówić o Legacy? Ale zanim zaczniemy, to ponieważ na samym przedstawieniu Andrzeja połączyliśmy od razu z Arkency. Andrzej, powiedz w ogóle czym się zajmuje Arkency?

Andrzej Krzywda Cześć wszystkim! Specjalizujemy się w projektach Ruby on Rails zastanych, legacy najczęściej i próbujemy je uładniać i doprowadzać do jakiejś żywotności. Jest nas kilkanaście osób. Sami starzy wyjadacze, którzy już w tych railsach siedzą, wielu z nich powyżej 10 lat. Ja sam jestem w branży od 20 lat mniej więcej i nawet więcej, dwadzieścia kilka lat już będzie, bo samego Ruby zacząłem używać w 2004 roku i w miarę się tego trzymam, ale wcześniej trochę różnych innych technologii używałem. Byłem dosyć mocnym java’owcem, ale też miałem okazję trochę porobić .Neta, miałem okazję porobić Pythona, miałem okazję porobić .Neta z Pythonem czyli Iron Pythona, PHP oczywiście, więc sporo poznałem, a potem ustatkowałem się z Ruby.

Łukasz Kałużny: Dobra, to słuchaj, bo może zróbmy to, co Szymon powiedział, dzisiaj chcemy sobie porozmawiać o tym, jak wygląda technologia, która się rzekomo ustabilizowała i jak wygląda prowadzenie w niej projektów? Takie pierwsze jeszcze, w ogóle powiedzieć sobie jak z Ruby wygląda układanka, jaki jest obecny stan Ruby’ego? Bo też nie do końca można powiedzieć, że to jest technologia, która stoi w miejscu.

Andrzej Krzywda Tak, przepraszam, że Cię skoryguję, ale ruby’owcy są na to bardzo wyczuleni. Mówimy Ruby.

Łukasz Kałużny: Ruby, tak, wiedziałem.

Andrzej Krzywda Mi to osobiście aż tak bardzo nie przeszkadza, ale gdyby to inni ruby’owcy słyszeli, to będą mieli za złe, że nie zaznaczyłem. Wiesz co, z Ruby jest ciekawa sytuacja, bo to już trochę żyje, można powiedzieć, że już jest takie faktycznie gdzieś odległe, zastana technologia mocno. Ale ona ma taki pierwiastek buntowniczości cały czas w sobie. To znaczy wszyscy co robią w Ruby można uogólnić robią Ruby on Rails, robimy wszyscy webówkę, robimy wszyscy najczęściej startupy i też startupy, którym się udało i przeżyły dalej. Liderem Ruby on Rails jest David Heinemeier Hansson, DHH, podejrzewam, że również Wam znany. I on jest takim liderem technologicznym, który nadaje bardzo dużo buntowniczości całej społeczności i on się bardzo często nie godzi na zastane rzeczy, na takie status quo i on podważa bardzo wiele elementów. Z jednej strony mamy technologię Ruby, która jest bardzo dojrzała, bardzo fajnie się rozwinęła, bardzo powolutku, ewolucyjnie tam wybrała swoich dziecięcych problemów i doszła do fajnego etapu. A z drugiej storny mamy DHH-a i jego grono ludzi, bardzo poważane i bardzo wpływowe w naszym środowisku, który cały czas przeciera nowe szlaki i robi to bardzo skutecznie. I my na pewno, jako Ruby, nie możemy się porównać z popularnością np. z Pythonem, który jako język podstaw jest bardzo, bardzo podobnie zbudowany. W jakimś momencie Python odskoczył dzięki też Data Science i tym rzeczom. My zostaliśmy bardzo mocno przy webówce na pewno. Ale w tej swojej niszy webowej, nie wiem czy, chętnie bym podebatował czy jest lepszy framework webowy niż Ruby on Rails. Jestem nawet gotowy. Wydaje mi się, że właśnie Ruby on Rails się fantastycznie cały czas rozwija. A jeśli chodzi o aktualny stan rzeczy, to nawet mamy do czynienia z czymś, co my wewnątrz świata ruby’ego powoli zaczynamy nazywać Ruby renesans, że mamy jakieś odrodzenie fajne. Ma to na pewno związek z tym, co też widzimy dookoła. Jest jakaś forma kryzysów na rynku IT, są zwolnienia i bardziej się uważnie patrzy na koszta. Ruby on Rails jest frameworkiem, który jest często nazywany One Person Framework, który niesie za sobą pewną wizję produktywności, czyli że jedna osoba jest w stanie zrobić całkiem sporo. I to na pewno jest filozofia, która cały czas jest silna, aby jedna osoba była w stanie robić całość, cały full stack, można powiedzieć. A ostatnio myślę, że takim unikalnym selling pointem świata Ruby on Rails jest Hotwire, czyli sposób na rozwiązanie interfejsów użytkownika, powrót do server side renderingu i wydaje mi się, że na tym też polega odrodzenie Ruby on Rails teraz.

Łukasz Kałużny: Ja bym zażartował, że wróciło nam MVC i inne template’owanie z powrotem, zatoczyliśmy koło w tym elemencie takie duże.

Andrzej Krzywda Oczywiście zrobiliśmy koło, ale z fajnym dodatkiem, bo to koło by nie zadziałało bez WebSocketów i to jest ten ważny czynnik.

Łukasz Kałużny: Czyli tak, ten reloading dla słuchaczy, dość ciekawa koncepcja reloadingu, czyli pisz HTML’a w backendzie mając całe doświadczenie SPA dla siebie. A wiesz co, jak jest z gonieniem króliczka? Bo jeżeli popatrzymy sobie na całość układanki, to jest dużo takich rzeczy. Pojawiły się cloudy, kontenery, gdzieś tam wątki open telemetry i wszystkich tych narzędzi, DevOpsów. Tego jest bardzo sporo, czy podejścia do całego testowania aplikacji. Jak wygląda w takich rzeczach, które są hype’owane na rynku? Czy ta technologia z takiej perspektywy ona to goni, czy nie goni, czy żyje sobie w swoim światku?

Andrzej Krzywda Ja zawsze porównuję te światy technologiczne do krajów i my sobie tam niby graniczymy. Teoretycznie Polska wie, co się dzieje w Niemczech, ale tak naprawdę to nie mamy pojęcia, Niemcy nie bardzo się muszę interesować Polską. Więc to podobnie wygląda np. w świecie technologicznym, kiedy jest państwo Ruby, jest państwo .Netu, państwo Javy i pewne rzeczy dzieją się świecie .Netu czy w Javie bardzo intensywnie, a my w świecie Ruby niespecjalnie jesteśmy tym zainteresowani. I w drugą stronę, np. u nas się dzieje intensywnie, np. ten Hotwire, nie mam wrażenia, że to gdzieś tam mocno przeniknęło w inne światy, może trochę tylko. Pewne rzeczy, tak jak wspomniałem, Ruby on Rails jest używany najczęściej w startupach, to jest nasza taka nisza. Niektóre z tych startupów przeobraziły się w duże firmy. Tam, w tych dużych firmach oczywiście, że takie rzeczy jak kontenery, jak open telemetry i tego typu rzeczy wchodzą, bo ciężko sobie wyobrazić sensowne DevOpsowanie bez tych rzeczy. Ale nie nazwałbym tego trendem wiodącym. To jest po prostu ta grupa projektów, którym się udało, które się rozrosły, przy których pracuje, jak na Ruby np. kilkadziesiąt programistów, to strasznie dużo. W większości projekty programistyczne Ruby są stosunkowo małe. Też te projekty, które używają kontenerów w Ruby załóżmy, to myślę, że nie mają też lekkiego życia, bo to nie jest aż tak masowo używane. Natomiast chmura oczywiście jest chyba do tej pory najbardziej popularną chmurą mimo wszystko, jest Heroku i wszyscy się hostują na Heroku. Ale np. hostowanie się bezpośrednio na AWS-ie, żeby to samoczynnie sobie skonfigurować nie wydaje mi się popularną opcją. A już na przykład, bo Wy chyba jesteście bliżej .Neta, to nie wiem, te np. Azure’y czy takie rzeczy, to jest kompletnie u nas nieistniejącym konceptem.

Łukasz Kałużny: Odpalaliśmy dla klientów, to jest ciekawostka, da się to odpalić. Tak jak powiedziałeś, w większych mękach odpala się Elixira, tak bym powiedział, ale nie jest to taki… Mieliśmy z Szymonem dywagację, jak się przygotowaliśmy z rozmową, jak się czuje Heroku i czy nadal jest tą platformą numer 1 przy tym, jak deploy’ujesz coś w Twoim stosie technologicznym? A że zerknęliśmy jak to tam wygląda dla porównania, bo dla mnie od tej strony deploymentowey, tak jak miałem okazję pracować z Ruby, to zawsze trochę było tak jakby przesiąknięte PHP-em od tej strony OPS-owej.

Szymon Warda: Żebyście teraz widzieli minę Andrzeja, taka bym powiedział.

Andrzej Krzywda Ale mnie subtelnie obraziłeś.

Łukasz Kałużny: Słuchaj, Mariusz Gil by się obraził za porównanie i obrażanie PHP-a.

Andrzej Krzywda Tak, ja z Mariuszem się technologicznie przyjaźnię, jesteśmy z tego samego wydziału, więc wiele nas łączy, ale na pewno nie PHP.

Szymon Warda: Sprowadzając dyskusję na tory, które były, mówimy cały czas o dwóch tematach, że technologia, która już nie jest na hype’ie, to jest jeden element i legacy. Jaka jest różnica między tym, że technologia już nie jest na tym świeczniku, że już to nie jest ten główny element, gdzie mieliśmy na Hacker News, czy gdziekolwiek pisać codziennie o tym? A gdzie zaczyna się legacy? Jak nie ma hype’u, to już jest Legacy? Czy gdzie jest to Legacy?

Andrzej Krzywda Zgodzę się, że największy hype na Ruby był w okolicach 2004, 2005, 2007 powiedzmy gdzieś tam zaczął już gasnąć, bo wtedy największą zmianę proponowało Ruby on Rails. Jako framework faktycznie produktywnościowo, np. ja, jako java’owiec, mocny taki fan, bo jak zobaczyłem Ruby on Rails i po prostu ok, to na razie Java’o, jakby nie ma w ogóle porównania jeśli chodzi o produktywność i tam zostałem. Natomiast oczywiście to się zgadza, że ten hype już minął. Nawet były takie lata, że pamiętam, że już nawet w samym naszym światku było w 2018 “is Ruby dead” i w ogóle się przebijały. Jeśli pojawialiśmy się na Hacker Newsach, to w tym kontekście. Ale wydaje mi się, że naprawdę fajne odrodzenie nastąpiło i wewnątrz światka Ruby’ego naprawdę jest dużo poruszenia. Np. kwestia nawet widoczności, bo sam organizuję konferencję Ruby’ową we Wrocławiu i ciężko się wbić w ogóle z terminem gdzieś, żeby w Europie nie było w tym czasie innej konferencji Ruby’owej. To jest naprawdę intensywne i w tym momencie się dzieje. Mam wrażenie, że po covidzie też coś się mocno odrodziło w tym temacie. Ale tak, w jakimś sensie ok, można przyjąć, że to… Ja nie nazywam tego legacy, ja bardziej nazywam, że projekty są legacy niż technologia może. Ale rozumiem co masz na myśli i wydaje mi się, że to jest fajne, bo Ruby on Rails w tym momencie jest po prostu naprawdę dojrzałym stosem technologicznym i można było się w 2004, 2005, 2006 o wiele rzeczy słusznie przyczepić, to po prostu tam było w niektórych miejscach klejone kompletnie na ślinę, tak teraz nie. W ogóle był bardzo duży, bardzo duża inwestycja. Sam twórca Ruby’ego, Matz, całe to japońskie grono programistów, oni byli bardzo skoncentrowani też na przyspieszaniu Ruby’ego i wersji, bo tam były zarzuty do Ruby’ego o kwestię wydajności. To Ruby teraz, wersja 3.2, 3.3, to są naprawdę już przepotężne wydajnościowe maszyny z najnowszymi optymalizacjami. I to jest nieporównywalna szybkość z tym, co było powiedzmy w Ruby 1.8 tam 20 lat temu, czy tam jeszcze wcześniejsze wersje. Więc mega dużo się po prostu działo w tle. To jest takie spokojne ewolucyjne poprawianie aż rozwinęło do tego, że Ruby jako język jest po prostu, jakby nadal ma to fajne piękno programowania obiektowego, a jednocześnie pod spodem jest mega szybki, nic mu już nie można zarzucić z takich rzeczy. Chyba, że oczywiście będziemy filozoficznie się przebijać o statycznych typach czy dynamicznych typach, bo tutaj oczywiście jesteśmy frontem dynamicznych typów.

Szymon Warda: Nawet załóżmy jak się sam przedstawiałeś, to mówiłeś, że zajmujecie się w Arkency głównie właśnie projektami legacy. Bo np. my z Łukaszem, jak próbowaliśmy znaleźć definicję, to w sumie stwierdziliśmy, że cokolwiek co już jest na produkcji staje się automatycznie legacy, bo trzeba to utrzymywać. I trochę nie mamy innej definicji czym jest legacy, bo to jest takie słowo, które jest używane nagminnie w systemach i z reguły ma nacechowanie bardzo negatywne.

Andrzej Krzywda Tak, natomiast ja używam to w scope’ie projekt. Znaczy projekt jest legacy kiedy jest już tam napisany, na produkcji i to faktycznie, ja się zgadzam, że nie ma dobrej definicji. Tam Michael Feathers mówi, że brak testów to jest powiedzmy definicja legacy albo mało testów, obawa przed zmianą powiedzmy. Ale zgadzam się, że w większości sytuacji to weszło na produkcję i trzeba utrzymywać, to już jest jakiś tam status legacy i ok, przyjmijmy tą definicję. My się w tym specjalizujemy, bo w świecie Ruby on Rails ciekawą specyfiką projektów legacy, że one są legacy wszystkie na ten sam sposób. Znaczy Ruby on Rails jest bardzo zunifikowanym frameworkiem, bardzo ustandaryzowanym, bardzo opartym na konwencjach, bardzo opartym na opiniach chociażby DHH-a lub jakiegoś grona influencerów ruby’owych. I w związku z tym one wszystkie kończą w podobny sposób. Grzechem Ruby on Rails jest bardzo wiele zalet. Ja jestem tutaj w roli ewangelizatora Ruby na pewno i ewangelizatora Ruby on Rails. Ale nie ukrywam, że jest jeden grzech pierworodny Ruby on Rails, a mianowicie miłość do patternu Active Record. Wszystko się opiera na wzorcu Active Record i tego się nie da ukryć.

Łukasz Kałużny: Przepraszam Andrzeju, ale każda technologia, każdy język ma swoje grzechy pierwotne.

Andrzej Krzywda Ja wiem, ja wiem, bo ja też w pewnym momencie się zacząłem rozglądać. Zresztą nie zapomniałem o swoich korzeniach wywodzących się z innych technologi, ja też mam takiej troszeczkę w sobie akademickości. Miałem też swoje jakieś tam paper’y publikowane kiedyś w temacie z inżynierii oprogramowania, więc ja staram się zerkać co w innych tematach się dzieje, co w innych technologiach się dzieje. Ja akurat Active Record mam wrażenie, że jest inaczej nazywany, ale bardzo powszechny wszędzie. Więc jakaś ta crudowość tych różnych frameworków jest powszechna. Ale trzeba przyznać, że po prostu w Railsach, z racji tego, że wszyscy używają tej samej biblioteki do RM-a tego samego Active Recorda, tej samej biblioteki do widoków, tej samej biblioteki do JSON-ów, to sposoby, na jakie są te aplikacje psute i na jaki sposób docierają do fazy legacy, są po prostu identyczne. I my jako ekipa railsowa od wielu lat jesteśmy w stanie takim projektom legacy bardzo szybko pomagać, bo my po prostu widzieliśmy to wszystko w działaniu wielokrotnie i wiemy, z czego jak wychodzić. Więc w tym rozumieniu używam tego pojęcia legacy w railsach, że to legacy railsowe jest jednorodne. Nie wiem jak u Was, ale u nas jest bardzo jednorodne, bardzo są zbliżone te błędy.

Szymon Warda: U nas jest ogólny pierdolnik, nie ma raczej wzorców, można powiedzieć.

Łukasz Kałużny: To może być kontrowersyjne, ale największy pierdolnik jest w Pythonie chyba, patrząc się tak rynkowo na przestrzał, bo tam jest największa możliwość. Bo Java z .Netem, drzewko decyzyjne się ustabilizowało troszeczkę, tak jak powiedziałeś, bibliotek i innych rzeczy.

Andrzej Krzywda To jest dobra nazwa, drzewko decyzyjne.

Łukasz Kałużny: Bo wiesz, jak sobie pójdziesz to idziesz czysty, tak jak w Javie. Teraz Spring Boot króluje z NHibernatem, w .Necie masz albo mikro RM-a, albo Linq, albo Entity Framework albo NHibernate’a i też drzewko się kończy. Więc te drzewka trochę w tym. A jak popatrzymy na Pythona, to zaczynamy iść już w definicje religijne mam wrażenie już w ich środowisku.

Andrzej Krzywda Bo tam jest co? Fast API jako lider w tym momencie i Django gdzieś tam drugie chyba?

Łukasz Kałużny: Django, jeszcze masz Flaska. Jest tego trochę.

Szymon Warda: Nazbierało się. Ale jedna rzecz mnie zastanowiła, bo mówiłeś, że zajmujecie się głównie projektami legacy i że pomagacie je ogarnąć. Co w nich zmieniacie? Bo skoro to są popularne błędy, to jak wygląda status startu, a jak wygląda to, do którego dążycie? Bo tu trochę zahaczamy o drugi temat, który jest interesujący, jak mówimy legacy, to od razu pojawia się słówko kluczowe - refaktoring. Jak to u Was wygląda?

Andrzej Krzywda Projekty, do których wkraczamy, biorą nas… Na szczęście wkraczamy z taką siłą brandu. Arkency jest rozpoznawalną marką w świecie Ruby on Rails, całym świecie powiedzmy. Bardzo często, kiedy jesteśmy wzywani, mamy taką już dosyć komfortową sytuację, kiedy pozwala się nam… Nam daje się często dużo większe zaufanie niż programistom, to jest takie niefortunne trochę, bo to jest trochę nie fair, niż programistom pracującym przy danym projekcie już tam od lat. I jesteśmy wezwani, żeby coś pomóc tam w tych projektach, które utknęły, jest wolny development, są bugi. Bardzo często np. w Ruby, w świecie railsowym są problemy z upgrade’ami, bo to akurat jest trudnym procesem u nas, tu akurat trzeba przyznać, że między innymi z powodu dynamiczności, itd. Meta programowania, też nie możemy sobie pozwolić na bardzo bezpieczne refaktoring, więc u nas refaktoryzacja, w porównaniu np. z CSharpem, jest dużo trudniejsza, na pewno, nie będę walczył z tym z racji tego, że u nas nie wszystko się wykryje na etapie kompilacji, musimy mieć pokrycie testami. Na szczęście to jest jedną też z zalet świata Ruby’ego, wszyscy testują. To jest bardzo powszechna praktyka. Jest to bardzo miłe, że nikogo do testów nie trzeba przekonywać. Można czasami podebatować o jakości tych testów, ale raczej testy są. Więc u nas czasami na wejście… Są różne punkty wejściowe. Bo co boli w organizacji najbardziej? Np. ostatnio wchodziliśmy do organizacji, gdzie najbardziej bolało to, że była bardzo stara wersja railsów, a rynek regulowany, więc nie można już było używać tej wersji, bo już tam kwestie bezpieczeństwa. Więc to był fokus. Ale bardzo często mówiłeś Łukasz o tym drzewku decyzyjnym. To w railsach właściwie nie ma drzewka decyzyjnego. Bierzesz railsy, a railsy są zbiorem bibliotek i tu już masz całe drzewko decyzyjne, dziękujemy, to jest cały Twój wybór. Oczywiście tam jest, my to nazywamy gemy, nasze biblioteki to są gemy, więc my sobie wybieramy jakieś potem gemy. I upgrade railsów w skrócie się sprowadza do tego, że trzeba upgrade’ować gemy i te gemy są bardzo często trudno upgrade’owalne, w zależności od tego jak są używane w danym projekcie. Więc jest to takie typowe rozsupłowywanie, trzeba zrobić upgrade tej biblioteki, tamtej biblioteki, w końcu można zrobić upgrade Ruby’ego, w końcu upgrade railsów. Więc jest to taka bardzo detektywistyczna, analityczna praca. Więc to jest jeden z możliwych punktów wejścia. Inny punkt wejścia to jest zepsuty performance, bo typowe crudowe podejście, wszystko gada z wszystkim, a żeby wyświetlić potem raport finansowy, to trzeba zrobić milion joinów i to się wszystko zamula i to nie działa. Więc czasami, jeśli od tej strony wchodzimy, to tutaj my też mamy swój pewien pakiet, którego nie ukrywamy już na starcie. To znaczy my wchodzimy z jakimiś narzędziami wokoło Domain Driven Design, CQRS i Event Driven ogólnie i np. robimy read modele zamiast joinów. I read modele wymagają tego, żeby jakaś część komunikacji… Znaczy najlepiej działa jakaś część komunikacji idzie eventowo, więc stopniowo te eventy zaczynają pojawiać i tak jakby krok po kroku, bardzo ewolucyjnie tą refaktoryzację robimy. To są faktyczne refaktoryzacje, to nie są rewrite, to są małe kroki cały czas, wszystko na zielonym i upewniamy się, że wszystko działa. Więc w dużym skrócie tak to można uogólnić, że zastajemy taki jeden wielki model danych, a docelowo lądujemy z modelem obiektowym i z jakimiś eventami i z jakimiś kontekstami.

Szymon Warda: Właśnie nasze pytanie, bo właśnie zaznaczyłeś, że to nie są rewrite’y. Ja tam odnośnie rewrite’ów i fraktorów mam swoje dość mocne zdanie. A czemu właśnie nie są rewrite’y? Czemu właśnie to jest ważne, żeby… Tak rozumiem, po prostu pracujecie na zielonym i robicie małymi kroczkami, słowo harcerza, że będzie lepiej z tego jak zmienię coś i po kolei. Jest to ewolucja, nie rewolucja u Was, tak jak Cię rozumiem, tak?

Andrzej Krzywda Tak, u nas jest to na pewno ewolucja. Dlaczego nie rewrite’y? To jest bardziej ludzki problem niż technologiczny. Rewrite z definicji ma być rewritem, czyli przypisaniem tego, co było na nowy stos technologiczney załóżmy na nowo. Nie da się okiełznać tutaj kreatywności ludzi, którzy w tym uczestniczą i to prawie zawsze jest robienie innej wersji aplikacji, co jest mega trudną sytuacją biznesową, bo kończysz w biznesie z dwoma produktami spełniającymi tą samą rolę.

Szymon Warda: I w którym ten drugi ma gonić funkcjonalności pierwszego.

Andrzej Krzywda Tak i teraz którego klienta dajemy na to, którego klienta dajemy na to. Ja też w tym brałem udział, więc ja wiem. Nie mówię, że nigdy rewrite nie byłby opcją. Są sytuacje, gdzie bym powiedział: tak, rewrite jest lepszy, ale trzeba okiełznać wtedy pewnego rodzaju kreatywność i zastanowić się, co będzie w tej nowej wersji, albo np. zaakceptować, że będzie mniej na początek, a potem będziemy ewolucyjnie to rozwijać. W świecie railsowym mega łatwo się startuje nowe aplikacje, to jest właśnie ten cały Rails. Railsy są takie mega startupowe, takie wszystko na MVP oparte, więc można powiedzieć, że ten światek aż zachęca do tego, żeby na nowo coś zacząć. Ale tam gdzie my wchodzimy to raczej rzadko byśmy w tą stronę szli.

Łukasz Kałużny: A słuchaj, to patrząc się na Twoje doświadczenie i w projektach, czy miałeś podejścia, bo to są może dwa pytania o doświadczenie. Pierwsze czy miałeś gdzieś ewidentnie wchodząc w projekt, że niestety trzeba to przepisać, albo z drugiej strony przekonać klienta, że lepiej to zrefaktorować niż przepisywać?

Andrzej Krzywda Miałem sytuację, gdzie akurat sam w tym projekcie brałem udział programistycznie i klient nas postawił przed faktem dokonanym, że my musimy zrobić aplikację od nowa. On ma działający biznes w świecie wydawniczym, fantastyczny biznes, natomiast jego produkt technologicznie jest oparty o coś z jakichś bardzo odległych światów microsoftowych. Możliwe, że bardziej byście rozpoznali jakieś tam rzeczy, do których się skończyło wsparcie i do których już po prostu nie można było nic zrobić. To był jakiś stary typ bazy danych. W ogóle nie wiem, czy to był dBASE, czy jeszcze coś innego. Nie dało się za bardzo z nim nawet podyskutować, bo ja wciąż tam drążyłem wtedy na starcie, bo on nas bardzo chciał wziąć właśnie już od początku. On w ogóle wziął Vernona do konsultacji na start, aby zrobić tak jakby architekturę systemu, a potem bardzo chciał, żeby to był robione w railsach, więc znalazł nas i myśmy to mieli realizować. I realizowaliśmy. Ale mimo że robiliśmy rewrite tak naprawdę, to ja cały czas drążyłem, jak się możemy wpiąć w stary system. Cały czas szukałem opcji i dyskutowałem. Tą debatę niestety z tym klientem przegrałem i klient ostatecznie nie skończył w jakimś złym miejscu, bo ostatecznie powstał drugi produkt, który wystarczająco spełniał rolę, żeby klientów tam można było przepinać, ale miał trudną po prostu biznesową wtedy sytuację, bo starego produktu nie mógł jeszcze wygasić, nowy już żył, więc były to dla niego jakieś tam komplikacje. Ale w jakimś sensie ten rewrite ostatecznie, w wielkich trudach oczywiście, ale się udał.

Szymon Warda: Czyli podsumowując, rewrite w tym momencie, kiedy faktycznie chcemy zmienić coś technologicznie, co nas blokuje bardzo mocno przed tym, że tego w refaktorze nie ogarniemy.

Andrzej Krzywda Tak, myślę, że są powody takie, że rewrite jest jedyną opcją. Chociaż ja uważam, że w tamtej sytuacji wystarczyłoby, żeby nam jakieś API ten stary system wystawiał i to by było takie bardziej ewolucyjne. Wydaje mi się, że niepotrzebnie poszliśmy taką naprawdę w alternatywną wersję. Natomiast można było zrobić w ten sposób. I też drugi rewrite, w którym brałem udział, jak jeszcze z tym rewritem możemy sobie porozmawiać, to zupełne początki Arkency, czyli gdzieś tak okolice roku 2006-2007, gdzie dostaliśmy serwis, który nazywał się Restaurant Critica i to było takie typowe, tak jak teraz w Google’u są te oceny restauracji. To było bardzo silne na rynku niemieckim wtedy i było napisane w PHP. I myśmy mieli kontakt z inwestorem, który dawał nam po prostu jako inwestor produkty, które on skupował do portfolio i właśnie które były w PHP i on je nam dawał do przypisywania na railsy lub też firmom w Polsce, które miał pod opieką. I myśmy przepisywali to na railsy, ale właśnie tam już się przynajmniej wpięliśmy w bazach danych poprzednią, więc to było takie ewolucyjne, rewrite, docelowo. I fajnie się zrobiło pewnej nocy podmiankę i wszystko działało.

Szymon Warda: Dopytam się jeszcze odnośnie refaktorów, bo są dwa podejścia do refaktorów. Jest taki zwany ewolucyjny. Jest taki refaktor na hurra, teraz wszyscy robimy refaktor całego systemu tak naprawdę, co jest często promowane przez developerów mam wrażenie. Ja tak patrząc z perspektywy tego, co ja widziałem, to to się nigdy nie udaje, takie opcje, że zrefaktorujmy teraz wielki kawałek. A jakie jest Twoje zdanie w tym temacie? Czy po kawałku, ewolucyjnie, mało? Czy jednak po prostu stawiamy wszystkich i mówimy: teraz zmieniamy system?

Andrzej Krzywda Zdecydowanie małymi krokami to wszystko musi iść. Jest parę wymogów aby zacząć taki refaktoring i w ogóle. Ja zawsze uważam, że trzeba wiedzieć dokąd zmierzamy. Wszyscy musimy mieć wizję końca. Musimy co do tej wizji być zgodni. Jeśli tej wizji końca nie ma, to każdy będzie refaktoryzował w inną stronę. Uważam, że każdy powinien refaktoryzować, więc w tym rozumieniu to jest takie ok na hurra, ale to wszystko powinno być bardzo bezpieczne, bardzo małymi krokami, bardzo małe commity, bardzo wszystko jest dobrze otestowane, mamy pewność, że to działa. Też wiemy jakie są te techniki, czyli np. jak najlepiej z active recordowej klasy przejść do czegoś co zaczyna publikować eventy, gdzie te eventy dokładnie publikować, jakie będziemy mieć te strumienie na początku. To są już bardzo szczegółowe rzeczy. One są konieczne, aby zachować spójność systemu i spójność danych. Przy refaktoryzacji uważam, że muszą być najlepsze osoby zaangażowane i muszą dobrze się orientować, co robimy, dokąd zmierzamy, jakie konteksty widzimy na końcu, jakie read modele będą na końcu, jakie process managery będą na końcu, jakie eventy są kluczowe w tym systemie, to wszystko musi być.

Szymon Warda: Jasne. Skoro mówisz, że musi być, w takim razie jak przygotowujesz się? Bo ja uważam, że przygotowanie się przed jakimiś refaktorami, co powiedziałeś, stwierdzenie gdzie chcemy być, itd., jest kluczowe. Jak takie przygotowanie np. u Was wygląda? Jak taki proces, co się dzieje przed, co się dzieje po refaktorze? Jak byś mógł mniej więcej opisać?

Andrzej Krzywda Też nie chciałbym stworzyć wrażenia, że my wchodzimy i robimy w 99% refaktoring. Jesteśmy wezwani po prostu do kontynuowania pracy nad systemem i to bardzo często nie jest utrzymanie, aby on żył, tylko to jest rozwijanie tego systemu nadal. I bardzo często dlatego jesteśmy wezwani, że już wcześniejsza ekipa nie za bardzo jest w stanie to rozwijać i my mamy odblokować. W jakimś sensie nawet pracujemy nad takim developer experience, czyli mamy innych programistów odblokować, aby mogli nowe feature’ki dodawać. Więc z przygotowaniem jest akurat u nas naprawdę jest wymagana głęboka wiedza samego świata Ruby on Rails technicznie, tych różnych szczegółów, włącznie z tym, co tam się między wersją Rails 6 a Rails 5 zmieniło, bo to jest ważne, bo te kwiatki zajmują dużo czasu, żeby jeśli ktoś tego nie znał, to to zajmie dużo czasu. I też nam jest dużo łatwiej np. komuś zupgrade’ować Railsy mimo, że jesteśmy z zewnątrz, bo my to robiliśmy już wielokrotnie, niż ekipie, która jest w tym produkcie już wiele lat, bo oni właśnie najwyraźniej z tej piątki na szóstkę nigdy nie przeszli, więc nie mają pojęcia z czym to się wiąże w ogóle. I mimo, że oni znają domenowo ten produkt lepiej, to my będziemy znali techniczne problemy wokół upgrade’u dużo lepiej i to jest akurat w tym aspekcie ważniejsze. Więc wrzucam upgrade’y jako pewną formę refaktoringu tutaj też. Jak się przygotowujemy? To już akurat jest nasze znowu rozeznanie świata Ruby, świata Railsów i widzimy te typowe problemy. Widzimy, że ktoś użył gema acts_as_state_machine, czyli takiej maszyny stanów, takiej biblioteczki. Wiemy jakie ona ma konsekwencje, wiemy, że ona za chwilę przeszkadzała, więc np. jednym z kroków jest pozbycie się acts_as_state_machine i wiemy na co to zamienić. I dopiero jak to zamienimy, pozbędziemy się tego gema, odblokowują się kolejne ścieżki. Więc to jest akurat znowu to drzewko decyzyjne, tylko już takiego refaktoringu, czyli żeby coś nam się czasami otworzyło, trzeba zrobić pewną żmudną pracę wcześniej.

Szymon Warda: Jasne. Właśnie poruszyłeś taki temat, mianowicie, że przychodził do Was inwestor generalnie i przepisywaliście aplikację z PHP na Ruby. Kiedy ma sens, a kiedy nie ma sensu taki switch technologiczny? Kiedy powiedzieć ok, teraz musimy zmienić? Czy może mieliście taką sytuację, że powiedzieliście, że ok, tego przepisanie na Railsy, na Ruby nie ma sensu np.

Andrzej Krzywda Wydaje mi się, że akurat sytuacja z inwestorem była dosyć jasna, że chodziło o zeskalowanie też tego systemu. Zwykle jak jest inwestor dochodzi pewnego rodzaju proces skalowania biznesowego i technologicznego również i PHP-owa wersja była zrobiona przez wcześniejszego foundera tego projektu i to nie był jakiś tam standardowy PHP-owy framework, tylko jakieś tam wymysły jednej osoby. I Railsy akurat, to co faktycznie ze sobą niosą, czasami to jest dobre, czasami to jest złe, ale Railsy są prawie że synonimem standaryzacji, to znaczy że wszystkie projekty railsowe są takie same. Bierzesz railsowca i on się odnajdzie w innym projekcie railsowym bardzo szybko. Więc czasami zaletą pójścia na Railsy jest to, że nawet jeśli railsowców na rynku jest ogólnie mniej, bo nie oszukujmy się, jest dużo mniej niż Pythonowców, niż JavaScriptowców, itd., to bierzesz dowolnego railsowca i on wie gdzie się tam w tym kodzie poruszać. Więc to jest akurat jakąś zaletą. Jeśli to miałby być powód przepisania na Railsy, chociażby rekrutacyjnie czy pewnego rodzaju zabezpieczenie się od tej strony, kto może nad tym pracować, to powiedzmy dzisiaj trochę rynek pracy się zmienił, ale kiedyś było mega ciężko kogokolwiek znaleźć, kto by tam coś ogarnął, to to mógł być argument. Ale głównie chyba chodziło o to, że ten PHP po prostu też dotarł do ściany z rozwojem w tamtym projekcie konkretnym.

Szymon Warda: Jasne, a w takim razie idziemy do kolejnego elementu, który często jest blokujący, trochę poruszyłeś go. Bo wchodząc do projektu, chcąc go upgrade’ować, chcąc go zmieniać jakkolwiek, często napotykamy się na to, że po prostu developerzy, którzy tam istnieją, albo generalnie w ogóle skill set developerów nie odpowiada tym umiejętnościom. Więc jak zarządzacie tym właśnie reskillingiem, jak właśnie uczenie nowych technologii, przygotowanie organizacji do tego miejsca, gdzie chcemy być w ogóle, może organizacji nawet nie, projektu tego całego tak naprawdę?

Andrzej Krzywda To jest chyba najtrudniejszy obszar naszej pracy, bo my poza taką typową programistyczną częścią, programistyczną wiedzą, musimy się wykazywać bardzo dużą sztuką dyplomacji.

Szymon Warda: To jest śliskie, tak.

Andrzej Krzywda Bo wchodzimy do istniejących zespołów i to bardzo często nie te zespoły nas zaprosiły tam. Czasem to się zdarza, ale bardzo często jest to CTO albo ktoś tam wyżej. Ja też zaznaczę, że w świecie railsów akurat stosunkowo mało jest takich firm, które nazwalibyśmy korporacją, to jest rzadsza sytuacja. Jesteśmy w jednym projekcie korporacyjnym, ale to jest właściwie jedyny, jaki mieliśmy, taki prawdziwie korporacyjny projekt. Więc tu nie mówimy o skali tam tysięcy osób. Tu mówimy o skali maksymalnie kilkudziesięciu osób zaangażowanych w ten projekt. I mimo że powiedziałem o tej standaryzacji w świecie Ruby on Rails, ja to nazywam The Rails Way, wszyscy robią takim railsowym podejściem, to zawsze na 20 osób znajdzie się jedna, która np. ma kompletnego bzika na punkcie funkcyjnego podejścia. Jest jedna osoba, która bardzo optymalizuje i to jest dla niej wszystko najważniejsze. Albo jedna osoba, która np. Domain Driven Design próbuje wprowadzać tylko np. źle jej to wychodzi, więc robi tam chaosu więcej niż pożytku. Więc naszą rolą jest stosunkowo szybkie wykrycie, z kim mamy do czynienia, powiedzmy nawet politycznie. Bardzo często robimy szybką rozpiskę osób zaangażowanych w projekt i zastanawiamy się, kto tu gra z nami do jednej bramki, a kto będzie grał przeciwko nam i co możemy z tym zrobić. Jest naszym takim wewnętrznym żartem, że prędzej czy później kogoś zwalniamy niestety, bo jest przeszkodą w projekcie i sygnalizuje. Oczywiście próbujemy, dajemy szansę jedną, drugą, trzecią, a jak to się nie udaje, to bardzo często jesteśmy w tej pozycji, że możemy powiedzieć naszym mocodawcom, że ten ktoś w tym projekcie w tym momencie może nie powinien być.

Szymon Warda: Tak, to się zdarza zawsze.

Andrzej Krzywda W ten sposób sobie z tym radzimy. Natomiast reszta to, my jako Arkency, poza taką naszą typową działalnością projektową, programistyczną, my mamy bardzo dużą taką gałąź edukacyjną, propagandową i bardzo dużo materiałów. Zrobiliśmy blok postów, książek, kursów, więc mamy bardzo dużo rzeczy, które możemy tym ludziom podsunąć natychmiast. I mówimy: słuchajcie, będziemy tu robić eventów troszkę, zaznajomcie się z tym na tym projekcie np. opensource’owym, który zrobiliśmy, żebyście zrozumieli z grubsza o co chodzi. Albo robimy jakieś tam commity przykładowe. Stosujemy Perl Programming, Mob Programming, jak jest taka opcja, więc wszystko co się da, aby wszyscy byli w ramach jednego zespołu, jednej misji. I to jest najtrudniejsza część na pewno, bo cała reszta później może pójść gładko i wszyscy strzelają do jednej bramki. To jest spoko.

Szymon Warda: Ok, ale teraz takie pytanie, już powoli zamykające, czy można mieć system, który już nazwaliśmy, użyjmy tego słowa, legacy, czyli który żyje na produkcji, żyje jakiś czas, w którym nie przychodzi developer i np. nawet developer nie powie: o Jezu, weź, przepiszmy to, zmieńmy to? Czy może istnieć system, który żyje, w którym developerzy nie marudzą, że Jezu, trzeba go zmienić? Ta chwila ciszy.

Łukasz Kałużny: Mina Andrzeja jest ciekawa.

Andrzej Krzywda Wydaje mi się, że warto tego króliczka gonić wszyscy razem, ale wątpię, żebyśmy go złapali, żebyśmy byli np. wszyscy w jakiejś ocenie jednego projektu identyczni, że jest już dobrze albo jeszcze nie. Wydaje mi się, że to, co według mnie jest ważne dla programistów, przynajmniej takich, z którymi ja się spotykałem, to jest pewna sprawczość. To znaczy jest większe zadowolenie w projekcie jeśli masz przyzwolenie na zmianę, ktoś ci ufa i jesteś w sytuacji, kiedy zmiany możesz wprowadzać. I to jest dla nas, właściwie fundamentem istnienia Arkency jest ta sprawczość. To znaczy my wchodzimy do projektu, bo my możemy być tym sprawczym, bo jesteśmy wzięci na takiej pozycji, że możemy być sprawczy. Natomiast często rozmawiam z innymi firmami, gdzie pracują nawet na produktach swoich niby, więc ta sprawczość powinna być wysoka, ale jakoś tak to wszystko poplątane w hierarchii, że nie pozwala się na takie zaufanie do programistów, otacza się ich milionem procedur, pull requestów, reviewsów, itd. Więc każdy każdego musi tam kontrolować na wszystkie sposoby. I wydaje mi się, że jeśli pytanie gdzieś zahaczało o to pewnego rodzaju zadowolenie tych programistów, programistek danego projektu, to wydaje mi się, że sprawczość może być czasami ważniejsza niż to, czy w danym momencie czasu osiągnęliśmy jakąś utopię, czy nie osiągnęliśmy.

Szymon Warda: Mieliśmy badanie, które pokazywało właśnie to - sprawczość i zadowolenie z pracy tak naprawdę, że to były te główne elementy, gdzie ludzie nie narzekali na projekty.

Łukasz Kałużny: Dobra, ja jeszcze chciałbym wrócić do jednego wątku, jak sobie tak popatrzymy, bo wspominałeś, że dość mocno przy refaktorze wchodzicie właśnie w DDD, CQRS i inne tego typu elementy, te układanki, które powiedzmy, że na rynku technologicznym gdzieś są szeroko w świecie .Netowym, javowym też popularne. O tak, te układanki jak popatrzymy, bo Hacker News już padło. Jak się poprzegląda to jest mocno zopiniowane towarzystwo. To bardzo często tam synonimy DDD, CQRS, event story to jest traktowane jako bullshit, że to jest zaprzeczenie produktywności, tak można powiedzieć, w niektórych miejscach. Jak macie odbiór właśnie, jak pokazujecie te wzorce, odbiór w takich środowiskach, powiedzmy quasi startechowych, produktowych, które nie są duże i nie są takim korpo softem?

Andrzej Krzywda Bardzo dobrze to ująłeś z Hacker Newsami. Ja się zgadzam, że powszechna percepcja jest negatywna. Wydaje mi się, że to, że też rozmawiamy sobie w polskim gronie to jest pewnego rodzaju nasz kontekst, dosyć interesujący, bo na moje rozeznanie jesteśmy krajem bardzo mocno Domain Driven Design, bardzo mocno. Ja tutaj osobiście uważam, to jest rola Sławka Sobótki w dużej mierze, ale całe grono osób potem dołączyło i jakby ewangelizowało i polscy programiści i programistki są niesamowicie silni w Domain Driven Design i ta wiedza jest bardzo mocna. To oczywiście też Maciek i robić jego kurs, Wy też jesteście zaangażowani w szkolenia, więc wiele ludzi propaguje to i ta wiedza jest już bardzo, bardzo powszechna, dużo bardziej niż w innych krajach, więc to bym chciał zaznaczyć. Natomiast drugi taki przekrój czy druga perspektywa to jest per technologia. I teraz pytanie czy to Domain Driven Design w świecie railsowym jest jakoś utożsamiane dobrze czy źle? Więc jeśli ktoś wprowadził Domain Driven Design w świecie railsów na jakieś tam salony, to nieskromnie powiem, że to byliśmy my na pewno, bo zrobiliśmy najwięcej pracy, aby to popularyzować i dużo o tym blogowaliśmy, dużo zamieszania tworzyliśmy wokoło tego. Też nasz projekt opensource’owy, teraz nazywa się to Arkency eCommerce, jest chyba największym projektem DDD przykładowym w Ruby, być może nawet w innych technologiach również, bo jest taki już dosyć nietrywialny. Natomiast pytałeś o konkretny kontekst, jak my wchodzimy do konkretnego projektu, to jak jest to odbierane? To zawsze jest kwestia jak bardzo ich boli coś, a jak jesteśmy brani to ich bardzo boli, bo Panie, nie jesteśmy tani ani nie jesteśmy komfortowi i do wzięcia, bo będziemy robić jakieś tam jednak docelowo nawet trochę rewolucyjne zmiany, więc ich musi bardzo boleć to, że przychodzi lekarz i mówi dam Ci zastrzyk o nazwie DDD i będzie mniej bolało, to w pewnym momencie taki pacjent z bólem mówi whatever, po prostu niech mnie nie boli. I myślę też, że mamy pewną wiarygodność. Jesteśmy tą ekipą, która stoi za Rails Event Storem. Rails Event Store to jest narzędzie, które wprowadzamy do projektów railsowych, aby można było publikować eventy. To jest bardzo proste narzędzie, które pozwala na postgresach czy relacyjnych bazach danych eventy trzymać i publikować. Więc za nami idzie wiarygodność, jesteśmy w tym temacie tam już od 10 lat przynajmniej z produktami na rynku. I my też akurat wchodząc wręcz wymagamy tej wolności na wprowadzanie tej sprawczości w temacie wprowadzania tam eventów czy czegoś takiego. Ja też dla jasności mam taką definicję Domain Driven Design. Mówię tak, mam jednocześnie w głowie CQRS-y i event sourcing. Też event sourcing jako najbardziej jeszcze opcjonalny fragment tej układanki, bo wiem, że w innych światach np. czasami faktycznie ludzie robią Domain Driven Design i np. nie łączą tego z eventami. Dla mnie średnio to brzmi, ale ok, są różne dialekty Domain Driven Design. Ale skłamałbym jakbym powiedział, że to jest niesamowicie ciepło przyjęte zawsze, że Domain Driven Design to super. To tak nie jest. Dlatego nawet czasami warto wprowadzać Domain Driven Design nie używając tej nazwy, czy też po prostu mówimy, że zamiast call backa active recordowego wrzucimy sobie event. I to jest tak naprawdę to samo i zmienimy tylko warstewkę.

Łukasz Kałużny: OK, a słuchaj jak, bo jeżeli dobrze kojarzę historię, to Rails Event Store jest waszym dzieckiem, które aktywnie rozwijacie. Jak Wam to się, bo to jest też rzecz, którą zawsze gdzieś tam poruszamy, przewija się u nas w odcinkach, jak ma się utrzymywanie opensource’u do modelu biznesowego?

Andrzej Krzywda W naszym przypadku to zadziałało fantastycznie, bo Rails Event Store jest dla nas darmowym, opensource’owym produktem, nie mamy wokoło tego jakiejś tam premium wersji czy czegokolwiek takiego, w to nie poszliśmy. Rails Event Store robi nam marketing i przyciąga nam klientów. Firmy, które wprowadzają Rails Event Store do swojego projektu, to są firmy, które zdecydowanie skorzystałyby na współpracy z nami. A naszym core naszej działalności jest po prostu konsulting, jest obsługa projektów. Przy czym jak my wchodzimy na projekt, jest nas kilkanaście osób, wchodzimy najczęściej w trzy osoby i wchodzimy na bardzo długo. Nasz model biznesowy nie wymaga tego, że my znajdujemy klienta co 3 miesiące. Nam wystarczy nowy klient raz na dwa lata powiedzmy. Więc my powiedzmy pielęgnując społeczność wokół Rails Event Store’a i rozwijając kolejne wersje, naprawiając bugi, itd., bardzo się mocno przyglądamy, bo tam są nasi klienci i ci klienci prędzej czy później do nas dotrą. Dla nas ten opensource jest po prostu nieodłącznym elementem modelu biznesowego i na ten moment nawet chyba już nie bierzemy projektów, które nie miałyby Rails Event Store’a w sobie, albo jest to jakaś anomalia troszeczkę, czyli nawet się zniszowaliśmy jeszcze bardziej na projekty Rails Event Store’owe i ich jest prawdopodobnie na rynku kilka tysięcy może. Ale powiedzmy, że na naszą skalę firmy to jest wystarczające. My też nie mamy ambicji rosnąć jako firma, tam nie wiemy, do 100 osób, to nasze kilkanaście osób to jest w sam raz i z grubsza się tego trzymamy. Rails Event Store jest dla nas brandem też, tak samo jak Arkecny jest brandem i myślę, że mamy bardzo dobre skojarzenia w świecie Ruby on Rails wśród tych programistów, którzy już zostali powiedzmy zranieni tą infekcją active recordową. Oni zawsze szukają, ktoś już ma trochę dość active recordy i tak sobie myśli: tu musi być coś lepszego. To prędzej czy później trafi do nas i zawsze pisze do nas maila taka osoba: o Jezu, odkryłem w końcu coś i dziękuję Wam.

Łukasz Kałużny: Gdzieś tam miałem styczność z tym na produkcji w ogóle i zawsze miałem taki… W niektórych momentach czułem się, jakbym się do Visual Basica cofnął, w niektórych takich tych filozofii myślenia, tym czystym. Ale też byłem skrzywdzony przez hinduski kod, więc to było ciekawe połączenie.

Andrzej Krzywda Ale to mówisz ogólnie o Ruby on Rails, tak?

Łukasz Kałużny: Wiesz co, tam były active recordy i inne rzeczy, które bardzo crudowo, napisana aplikacja była mega crudowo.

Andrzej Krzywda Więc my jesteśmy tą ekipą w świecie railsowym, która jest niestety, ale w opozycji do tego mainstreamu. To znaczy ja się tam z DHH-em ogólnie zgadzam w wielu kwestiach i uważam, że jest dobrym liderem naszej społeczności, to całe jego lansowanie active recordy jako głównego rozwiązania na wszystko, to jest kompletny bullshit według mnie. I ja ratuję ludzi zranionych tym poglądem. Więc my jesteśmy ekipą jednak tą buntowniczą w świecie Railsu.

Szymon Warda: Co ciekawe, active record tak naprawdę nie przetrwał w innych technologiach, bo był taki bum, że nagle wszystkie technologie miały swój active record, a tak naprawdę dość szybko wymarł.

Andrzej Krzywda Wiesz co, z jednej strony na ile śledziłem, to tak, z drugiej strony, jak się spojrzy, jak są używane ORM-y, Hibernate, itd., to jest po prostu reimplementowany active record, mam wrażenie.

Szymon Warda: Obudowa na sesję.

Andrzej Krzywda Tak, więc nie widzę wielkiej różnicy. Active record w railsach to jest niesamowita rzecz na sterydach, bo np. chwalony przeze mnie Hotwire i naprawdę jak ktoś tegogo słucha i chciałby spróbować przez godzinkę, dwie godzinki się pobawić czymś nowym, to polecam railsy i zrobić coś z Hotwire, bo można naprawdę zachwycić się tym. To też można zobaczyć jak w akcji w rekordzie nawet jest odwołanie do tego, że tutaj właśnie będziemy odświeżać jakiś widok hotwire’owy, czy to się nazwa pod spodem już turbo. Więc mamy klasę active recordową, która jest reprezentacją rekordów w bazie danych, która jednocześnie ma w sobie wbudowany mechanizm, bo wie jak się ma odświeżać, bo to przez konwencję, przez nazwę działa, wie jaki kawałek HTM-a, gdzie się ma odświeżyć, więc totalna magia. Zreszt a jak cały świat railsów jest bardzo magiczny. Jak ktoś tego nie znał, to bardzo często nie wie dlaczego tam się coś nagle wydarzyło. A to się dzieje pewnego rodzaju metaoprogramowaniem zbliżonym do aspektowego oprogramowania czasami, czasami do czegoś innego, przez jakąś nazwę, przez jakąś refleksję coś nagle się gdzieś wywołuje. Więc osobom, tak jak Łukasz mówi, że wpadłeś coś takiego, jeszcze napisane przez kogoś słabego, to naprawdę współczuję, to jest duży problem.

Łukasz Kałużny: Za to Hotwire’a jak dotknąłem, to jak mówisz magia, bo kiedyś gdzieś mi wyskoczyło i sobie poświęciłem tam jedno popołudnie. Brak tej ilości JavaScriptu, Reacta czy innego frameworka był przepiękną rzeczą i doświadczeniem.

Andrzej Krzywda To jest według mnie game changer naprawdę. To znaczy wszyscy tu jesteśmy na tyle długo w tym światku technologicznym, że wiemy, że kiedyś nie było osobnych Java Scriptowych aplikacji, tylko robiło się wszystko w ramach jednej aplikacji. Dopiero od 2010 roku zaczęła się jakaś rewolucja, że zaczęły się te wyciągać Angularami czy jakimiś reaktami.

Łukasz Kałużny: Trochę wcześniej jeszcze jQuery, chyba to pierwsze…

Andrzej Krzywda Było jQuery, raczej jQuery było powiedzmy takim, jak to w railsach mówimy, springroll, takie dodatki…

Łukasz Kałużny: Raczej robiło się te hot reloading, żeby z tych web API i innych rzeczy, żeby to co było gdzieś na MVC napisane w różnych technologiach, żeby nie było hot reloadu strony robionego.

Andrzej Krzywda Natomiast Hotwire to jest niesamowita prostota. Nie robisz API, to jest performance’owo też w ogóle fantastyczne, bo nie masz tej serializacji, deserializacji do JSON-a, z JSON-a. W ogóle prawie nic nie piszesz Java Scriptu to jest taki selling point. Myślę, że dla wielu backendowców jest to mocny selling point. Rubiowcy mimo wszystko to jest jakaś tam mocno backendowa frakcja i wielu rubiowców nagle odkrywa też ten świat frontendowy poprzez Hotwire’a, bo już nie trzeba czekać aż frontendowiec coś tam wyklepie, bo my po prostu możemy zrobić cały feature od backendu, od tabelki do widoku. To jest czysty HTML. My też, nie wiem czy mogę się tym podzielić, ale od jakiegoś czasu u nas jest Maciek Korsan, jeden z takich naczelnych frontendowców polskich. Niesamowity człowiek, niesamowite umiejętności frontendowe. I Maciek od niedawna powiedział: ok, to jest oficjalne, wolę Hotwire niż React.

Szymon Warda: Poważne słowa.

Szymon Warda: To mogła być też forma jakiegoś żartu, ale naprawdę Maciek się szybko wkręcił w Hotwire’a i świetnie się w tym porusza.

Łukasz Kałużny: Może zająć się CSS-em tak jak lubi. Mi ten Hotwire akurat przypomina, bo byłem na meetupie, gdzie występowałeś i w Warszawie był jakiś meetup właśnie z Ruby. I było stwierdzenie, że ktoś wymienił cały team reactowy, po prostu rozszerzył fullstacków w railsach na Hotwire, bo się dało.

Andrzej Krzywda Tak, bo wtedy kiedy się widzieliśmy, to akurat Jaroslav taki programista, z którym teraz też współpracujemy już, miał właśnie prezentację o Hotwire’rze. I to była jedna z takich… On jest jednym z takich fajnych ewangelizatorów Hotweire’a. I to też nie jest tak, że ten Hotwire w railsach jakoś niesamowicie od razu się przyjął. Każda taka nowa rzecz trochę trwa. Ja przyznam, że my mieliśmy w świecie railsów pewnego rodzaju ważny epizod, nie wiem, takie ciemniejsze czasy. Znaczy to były takie czasy, kiedy już świat poszedł w single page application. Railsy jakoś nie za bardzo miały taki w swoim tym standardowym stacku, nie za bardzo ma jakąś ofertę. Pamiętam, że sam proponowałem to, nie wiem, idźmy w parze z Angularem, nie wiem, zwiążmy się z kimś, bo te railsy same nie wystarczają, bo się sprowadzimy do API. Natomiast muszę przyznać, że DHH miał bardziej długofalową wizję niż ja to zauważałem wtedy. On miał taką technologię, która nazywa się Turbolinksy. To był taki początek Hotwire’a. Turbolinksy pozwalały na podmianę całej strony, ale w taki sposób, że to nie był faktycznie reload. I to był krok w kierunku Hotwire’a i on bardzo to lansował. Ja tego nie czułem. Ja mimo wszystko poszedłem w single page aplikacje, robiłem bardzo dużo Reacta, ja lansowałem Reacta, lansowałem JavaScriptowe rozwiązania, bo uważałem, że nie ma alternatywy. Natomiast w momencie, kiedy dojrzały alternatywy, czyli właśnie Hotwire się pojawił, to to wszystko już nie ma potrzeby. I wydaje mi się, że jako rynek powinniśmy wszyscy to sobie uświadomić, że całe te JavaScriptowe frontendy jako osobne aplikacje w wielu miejscach jest nadużyciem. To w wielu miejscach jest po prostu przerośniętym kosztem również. I jeśli jest jakaś dobra strona tego kryzysu, który teraz się odbywa według mnie, to jest to, że pewne marnotrawstwa będą zauważane. I jednym z takich marnotrawstw jest przesadne pójście w rozbicia tych aplikacji na frontendowe i backendowe, gdzie szczególnie w jakiś aplikacjach B2B to w ogóle nie jest potrzebne.

Łukasz Kałużny: Oj tak, oj tak.

Andrzej Krzywda Tutaj się odpaliłem trochę.

Szymon Warda: Nie oszukujmy się, w wielu sytuacjach wciskanie tego JavaScriptu to jest po prostu pobawienie się nowymi zabawkami tak naprawdę i nie dobieranie technologii do problemu, który realnie mamy.

Andrzej Krzywda Tam była w ogóle druga fala problemu, bo akurat jeśli railsy z czymś konkurowały na takim rynku technologicznym, szczególnie o nowe dusze powiedzmy, to to był raczej ten stack node’owy, tak mi się wydaje. Stack Node’owy, według mnie, on zaczął zyskiwać na popularności na tym argumencie - po co inny język, skoro na frontendzie i tak będzie JavaScript. Więc ok, to na backendzie mamy JavaScript. Jest to słaby argument, ale ok, można powiedzieć, że jednak zdobyło sobie popularność. Więc mamy ten JavaScript na frontendzie i na backendzie. I teraz na Node’zie, nie wiem czy śledzicie te różne frameworki jakie tam są, to tam dojrzałość tych frameworków jest bardzo niska. Nawet nie będę się śmiał, że co tydzień powstaje nowy, tylko że po prostu te istniejące od wielu lat one robią rzeczy, które w railsach zrobiliśmy w 2011.

Łukasz Kałużny: Raczej wiesz co, bo właśnie miałem zaszydzić, że do Reacta wjechał oficjalnie w zeszłym roku Server Side Rendering. Oprócz renderingu funkcje po stronie server side wjechały.

Andrzej Krzywda Tam jest ogromny kryzys tożsamościowy na świecie Reacta w tym momencie. Ja nie wiem w którą stronę to pójdzie, to wciąż jest ogromny rynek, ja nie chcę nikogo tam z tego rynku urazić. Natomiast jak się tam zaobserwuje, jak ten świat powstawał, jak się teraz popatrzy, jakie są alternatywy, to wydaje mi się, że to brnięcie w takiego czystego Reacta jest kłopotliwe dosyć dla wielu projektów.

Szymon Warda: My mieliśmy takie spostrzeżenie ogólne jakiś czas temu właśnie, że to jednak rozdrobnienie developerów, które mieliśmy, to teraz jednak z powrotem jest to połączenie i wracamy do takich ludzi, którzy jednak generalnie ogarniają jak największą część developmentu aplikacji. Więc może dlatego właśnie Ruby ma taki właśnie powrót? Bo powiedziałeś, to jest taki one man developer show, że to poszło dokladnie całość.

Andrzej Krzywda Przez jakiś czas się szczyciliśmy, że jesteśmy fullstackowi w pełni, że my potrafimy robić tam UI-e również, bo robiliśmy w Reaktach również bardzo wiele rzeczy, nie mieliśmy osobnych frontendowców. Muszę przyznać, że od kiedy do nas Maciek Korsan dołączył, to zauważyliśmy, że jednak warto mieć takiego 100% eksperta geniusza frontendu u siebie, bo mega nam to pomaga. Ale sam fakt, że jeden programista nawet backendowy z natury jest w stanie zrobić sobie feature do tego momentu CSS-ów, a tymi CSS-aami się już zajmie ktoś taki jak Maciek, to jest po prostu rewelacja. I ten One Person Framework według mnie jest jak najbardziej prawdziwym marketingowym sloganem Ruby on Rails w tej chwili.

Łukasz Kałużny: Byłaby dyskusja teraz już o filozofii, w którą idzie cały rynek technologicznie, bo Microsoft próbował zrobić, teraz próbuje nawet ciągle Blazora, czyli to akurat jest na oparciu o Web Assembly, ale tak samo, że piszesz fullstackowo aplikację, pozbywasz się API i innych rzeczy. To się raczej w tym światku w ogóle nie przyjęło, tak, bo to jest, gdzieś próbuje cisnąć. Java, nie ma żadnej alternatywy. Python, powiedzmy, że ma swoje Django, które też tam MVC w jakiś sposób wykorzystuje, żeby budować też aplikacje. Ale te technologie są utożsamiane ze starociami, mam wrażenie, ciągle w ten sposób, że nie możemy zaakceptować, że to co kiedyś było, jest ok. To trochę jak z chmurą a share’owanie sesji kiedyś na komputerach, że takie coś istniało.

Andrzej Krzywda I bardzo ciekawa jest ta sytuacja na tym całym naszym świecie technologicznym. Też ciekawią mnie zawsze przepływy, bo stosunkowo według mnie, nie wiem jaka jest Wasza opinia, ale wydaje mi się, że nie aż tak wielu programistów przeskakuje z jednego stacku na drugi. To jest jakiś tam segment tylko programistów, ale nie aż tak duży. Ktoś był .Netowcem, potem stanie się Pythonowcem. Albo był Pythonowcem, stanie się .Netowcem. Raczej walczymy o ten, jeśli już jest jakaś walka i konkurencja między technologiami, to walczymy o te nowe dusze, o tych ludzi, którzy nadciągają na rynek. Ja sam przez 5 lat wykładałem Ruby on Rails na Uniwersytecie Wrocławskim, więc ja byłem zaangażowany w to, jak był naciąg młodych ludzi na rynek i railsy np. na różnego rodzaju bootcampach są bardzo popularne. W ogóle w Ameryce, bardzo popularne w Ameryce, w Europie troszkę mniej to widzimy, tą railsowość.

Łukasz Kałużny: U nas Python i JavaScript.

Andrzej Krzywda Tak, my tutaj przegraliśmy jakąś tam rywalizację. Natomiast ja też zawsze mówię ludziom, jak ktoś mnie pyta o to wejście i wybór technologii na start, to tu jest też kwestia popytu i podaży. Możesz iść w Pythona, gdzie jest bardzo wiele ofert pracy, ale podaż jest też bardzo ogromna. Podaż w sensie dostępność ludzi na rynku. Możesz iść w JavaScripta, gdzie jest bardzo dużo ofert pracy, jeśli jest popyt, ale jest bardzo duża podaż. Albo możesz iść w coś takiego, co jest według mnie tak pomiędzy, bo railsy, one nie są niszą. To jest naprawdę duży rynek. To nie jest malutki rynek. Nie wiem, ile oceniałbym programistów ruby’ego na rynku, ale myślę, że około miliona na świecie może być. Więc popyt jest mniejszy niż Python czy JavaScript, ale podaż też nie jest zbyt duża, więc naprawdę można konkurować, można dostać pracę jako junior. Jeśli jeszcze spojrzymy na ten cały taki argument produktywności, że jedna osoba wstanie zrobić dużo, to już taki junior teoretycznie też jest w stanie zrobić dużo. Czyli jeśli ktoś nas słucha, kto jest juniorem, pewnie mało takich osób, to warto spróbować dać szansę, weekend railsom i zobaczyć, że można zrobić całą aplikację w ten weekend i wszystko będzie działało i wszystko będzie production ready, kompletnie deployowalne na Heroku i tutaj będzie pod tym względem wszystko ok. Więc mnie ciekawią najbliższe lata. Wiem, że odcinek miał być o tym jak Ruby jest bardziej już zachodzącą technologią, ale mi się wydaje, że tu renesans jest w trakcie i w świecie Ruby’ego dosyć podekscytowani na to wszystko patrzymy.

Szymon Warda: Jest tak, .Net, czy inne technologie, np. Java, że to już nie jest na Hacker Newsach, to już nie jest ta technologia, gdzie generalnie wchodzą i to jest ten taki nowy i co dzień jest nowy news tak naprawdę. się rozwija, która będzie miała swoje górki, dołki, itd. Ale pokazanie tego, że ok, co z tego, że nie mówimy o tym codziennie, tam dalej jest masa do zrobienia, to się dalej rozwija.

Łukasz Kałużny: Ale wiesz co, ja bym powiedział, że Java i .Net mają takie renesans parę lat temu za sobą, bo zobacz, że .Net odżył na nowo z tym .Net Core 3.1 i .Netem 5, kiedy pojawił się Linux, multiplatformowość tak na poważnie i produkcyjnie. Java, jak wyszła 17, 18, jak wtedy było dość sporo odświeżenie, które było w JDK, rzeczy, które są dostępne, że one miały takie swoje, to co teraz Ty mówisz, że u Was w tym stacku technologicznym jest jakiś renesans odświeżenie, tam też były takie strzały odświeżające.

Szymon Warda: To są platformy, które są na tyle dojrzałe, że mogą pozwolić sobie na takie zupełnie nowe pomysły i próby. Więc technologie póki żyją, póki są systemy, one do końca nigdy nie będą martwe, bo tam zawsze ktoś przyjdzie młody, pomyśli: a może byśmy zrobili to w ten sposób?

Andrzej Krzywda Tak, wydaje mi się, że tu ciekawym tematem jest w ogóle marketing technologiczny, jak mamy do czynienia z tym, bo np. świat Ruby’ego i świat Railsów on jest bardzo marketingowy, nie da się tego ukryć. Np. sam DHH jest świetnym produktem marketingowym i świetnie różne rzeczy lansuje. Jest świetnym influencerem, celebrytą, jeśli chodzi o lansowanie Ruby on Rails. I oczywiście my nigdy nie będziemy mieć ambicji, nie będziemy konkurować popularnością z Javą czy z .Netem. To jest bardziej tylko pytanie o to, czy możemy zwiększyć kawałek swojego tortu troszeczkę, czy nie możemy tego zwiększyć. Wydaje mi się, że tu jest dobre momentum, ja pamiętam w 2004 roku, dlaczego w 2004 roku akurat był moment, znaczy zaczął się moment i ja byłem tego przykładem, że ludzie z innych technologii przesiadali się na Ruby on Rails? Bo zysk produktywności był na tyle znaczący, że opłacało się w to zainwestować. Wtedy to był duży przeskok. Więc te odświeżenie, o których mówimy, czy jakieś małe renesansy, one wtedy będą miały duży impakt, kiedy one niosą za sobą coś takiego, że ludzie stwierdzają wow, to naprawdę niesie ze sobą pewną obietnicę, pewien marketing, coś mi to obiecuje, co mogę tu naprawdę znacząco skorzystać. Według mnie Ruby on Rails w aktualnej sytuacji z Hotwirem niesie za sobą obietnicę pewnej dużej produktywności, pewną obietnicę, że dasz radę zrobić UI samodzielnie pisząc Ruby, a nie JavaScripta, niesie ze sobą obietnicę nie pisania JavaScriptów generalnie. I to jest bardzo duża obietnica. To jest mniejsza obietnica niż rok 2004, więc nie spodziewam się tłumów przychodzących z Javy, z .Neta, z PHP. Natomiast jest to obietnica, która jest troszkę większą obietnicą niż po prostu kolejna wersja Ruby’ego czy tam Railsów. U nas w świecie to poruszenie widać, pewnie to jeszcze nie jest aż takie przeciekające na inne technologie, bo jako .Netowiec nie ma żadnego powodu, żeby się interesować tym, co się dzieje w railsach, więc coś musi wypłynąć na agregatorach typu Hacker Newsy, żeby zaczęło się to pojawiać. Wątek, którego nie poruszyliśmy w ogóle, to jest też ten temat i wydaje mi się, że on ma troszeczkę znaczenie w przypadku tego typu renesansu,. Tzn. cały wątek tego AI-a, czyli ludzie teraz mają szansę z jakimś tam prostym GPT dużo szybciej coś tworzyć, bo ten GPT im bardzo sensownie podpowiada. I z railsami muszę przyznać, że to działa fantastycznie. To znaczy GPT może Ci naprawdę dużo rzeczy podpowiedzieć i ta jedna osoba, która nawet w świecie railsów jest bardzo wielu programistów, których w .Naecie wątpię, żebyśmy spotkali, czyli programistyów, którzy tak naprawdę są biznesmenami, solopreneurami, itd., enterpreneurami, którzy tak naprawdę nie umieją programować, ale coś tam w railsach sklepali na start, żeby zrealizować jakąś ideę biznesową i potrafili z tym wyjść na rynek nie mając żadnego programisty. A teraz jeszcze z takimi narzędziami jak GPT to tym bardziej są wspomagani. I my nie raz takim ludziom pomagaliśmy. My braliśmy od nich takie totalne koszmarki programistyczne, ale jednak działające I oni mówili: dobra, ja się skupiam na sprzedaży, a Wy mi to tam poukładajcie, naprawcie i doróbcie parę nowych feature’ków. I to zawsze był ważny segment świata Ruby i Rails, bo Ruby jest językiem, który jest bardziej [niesłyszalne 00:46:09] ruby’ego niż samych railsów, Ruby jest językiem niesamowicie czytającym się jak angielski. To jest naprawdę takie quantize, takie elegant. I bardzo mało jest takich interpunkcji, tzw. klamerek, przecinków i tego typu rzeczy, średników. W Ruby jest to do minimum zawężone. W związku z tym dla normalnej osoby to powiedzmy wygląda bardziej przystępnie i rzadziej wpada się w sytuacje, tak jak nie wiem, w JavaScriptach, że zabrakło średnika gdzieś tam i na tym się skończyło, straciło się dużo debugowania. Więc ten zlepek paru cech świata Ruby i Ruby on Rails wydaje mi się, że powoduje, że to jest jakaś atrakcyjność dla ludzi, którzy nie mieli styku z programowaniem, nawet niekoniecznie chcą programować. Oni chcą mieć szybko produkt i chcą go sami zrobić.

Szymon Warda: Bo to jest dobry powód, żeby mieć system, który działa i potem trzeba go tylko ulepszyć, żeby działał wewnętrznie lepiej. Działa i zarabia, może nawet tak. Dobrze, to co, kończymy panowie.

Łukasz Kałużny: Dobra, dzięki Andrzeju za świetną rozmowę. Na razie.

Andrzej Krzywda Dziękuję Wam bardzo, fajnie się rozmawiało. Cześć.

Szymon Warda: Dzięki, trzymaj się.