Ruby on Rails

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Rafałem Piekara o frameworku Ruby on Rails.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć, mój dzisiejszy gość to programista z 9-letnim doświadczeniem, który zwiedził wszystkie możliwe miejsca dla programistów: korporacje, start-upy, software house’y i firmy produktowe. Przez trzy lata prowadził również własny software house. Wyznaje zasadę, że najlepsza technologia to taka, która rozwiąże problem w projekcie i przyniesie zysk. Dlatego też przez wszystkie lata w branży korzystał z wielu różnych frameworków, języków, tworząc aplikacje webowe, mobilne i cloud. Bloguje na grubykodzi.pl. Można go spotkać na meet-upach, konferencjach. Zakochany w Ruby i Railsach, twórca pierwszego polskiego Ruby Newslettera grubymailing.pl. Moim i Waszym gościem jest Rafał Piekara.

Cześć, Rafał, bardzo miło mi gościć Cię w podcaście.

Cześć, Krzysiek, dzięki za zaproszenie. Witajcie Wszyscy.

Słuchacze tego nie widzą, ale Rafał jest w pięknej czerwonej bluzie z logo Railsów. I właśnie o Ruby on Rails będziemy dzisiaj z Rafałem rozmawiać. Ale takie standardowe pytanie, które zawsze u mnie widnieje na początku, to: Czy słuchasz, Rafał jakichś podcastów? Jeśli tak, to może masz jakieś godne polecenia?

Słucham wielu podcastów. Oczywiście Porozmawiajmy o IT to jest jeden z moich ulubionych podcastów, jestem regularnym słuchaczem od kilku lat. Słucham też podcastu Mariusza Gila, Better Software Design. Z polskich podcastów słucham jeszcze Zen Jaskiniowca i Małą wielką firmę. A z zagranicznych Modern CTO i podcasty o Ruby: Ruby Rogues i The Ruby on Rails Podcast, to też polecam dla fanów Ruby’ego i Ruby on Rails, ciekawe rzeczy. I chyba tyle. Podcasty jakoś ostatnio u mnie dobrze wchodzą. Aha, i jeszcze z polskich lubię Start-up My Way Bogusza Pękalskiego.

Tak, całkiem fajna lista. Bogusz co prawda ostatnio jakoś rzadziej publikuje, ale faktycznie, to są takie merytoryczne, treściwe odcinki, też jak najbardziej mogę polecić. Okej, to powiedz, Rafał, jak ta Twoja miłość do Ruby on Rails i Ruby’ego w ogóle się zaczęła. W przedstawieniu Twojej osoby wspominałem, że z różnymi technologiami miałeś do czynienia. Co Cię wobec tego w Rubym i w Ruby on Rails urzekło?

Ja w ogóle zaczynałem programować od .Neta i pisałem na początku skrypty w Visual Basic. Jak ktoś kojarzy Visual Basic, to jest to język średnio przyjemny do pisania ze względu na różne mechanizmy charakterystyczne dla niego, m.in. ze względu na prace z kolekcjami, z pętlami. I to był taki moment, że sprawiało mi to duże problemy często, kiedy musiałem pracować z pętlami.

I jest taka historia związana z tym, że jadłem zupę z moją żoną i moja żona znalazła na Facebooku reklamę Railsów parę lat temu i powiedziała: „Słuchaj, ty znasz Railsy, Ruby’ego?”. Mówię, że coś tam się bawiłem, ale nie znam. „A bo tutaj szkolą z Railsów właśnie”. Mówię, a tam Railsy, co tam. Ale wieczorem wszedłem, zobaczyłem sobie to szkolenie. I poszedłem na nie.

I akurat tak się złożyło, że szybko się udało nauczyć ze względu na to, że znałem inne technologie i, co mi się spodobało w Rubym, to to, że składnia Ruby’ego jest mega przyjemna dla programisty do pisania i praca z kolekcjami jest bardzo prosta, fajna i elastyczna. I stąd się wzięła miłość do Ruby’ego, a potem jak już się jest na Rubym to już się kocha Railsy naturalnie. To mnie urzekło, że można w nich szybko tworzyć rzeczy i realizować swoje pomysły i w ciągu kilku godzin można stworzyć jakąś prototypową działającą aplikację, w fajny sposób.

Sam język programowania. Też kilka odcinków temu rozmawiałem m.in. o Ruby i u podstaw samego tego języka leży takie założenie, żeby dawać przyjemność programistom, oczywiście z pisania kodu, i to też się udziela w Railsach, więc fajnie to działa.

Okej, to może taki krótki rys historyczny, jeśli coś tam pamiętasz. Jak te Railsy się urodziły, kto je w ogóle stworzył, jak ta historia się rozpoczęła?

Railsy rodziły się gdzieś na początku gdy zaczynałem programować i było dużo szumu wokół tego. Twórcą Railsów jest Duńczyk David Heinemeier Hansson, Myślę, że dobrze przeczytałem, ale popularnie jest znany jako DHH i jest CTO Basecampa i teraz jest znany z kolejnego produktu Hey.com, takiego klienta mailowego. I on właśnie budując Basecamp, takie narzędzie do zarządzania zadaniami, używał właśnie Ryby’ego, języka, który bardzo lubił i w trakcie tych prac wyklarował się jakiś framework tworzenia aplikacji webowej i postanowił to później opublikować jako właśnie Ruby on Rails w jakichś pierwszych wersjach i to był chyba 2004 rok z tego, co gdzieś kojarzę z dat.

I generalnie DHH jest ciekawą osobowością w całej społeczności i był dobrym punktem zapalnym do tego, żeby Railsy zyskały na popularności, kiedy weszły, bo oprócz tego, że są elastyczne, że pozwalają szybko tworzyć aplikacje, dzieje się dużo magii, generatorów itd., korzystają bardzo mocno z zalet języka Ruby, to jeszcze DHH był takim gościem, który łamał trochę stereotyp klasycznego programisty w koszuli, grubych okularach. On jest uważany za przystojnego, występował w czapeczce, jest bardzo elokwentny, jest ciekawą osobą, bardzo dobrze się go słucha, jest mocno charyzmatyczny, więc jako założyciel samego frameworka i społeczności był mocnym motywatorem do tego, że Railsy poszły szeroko na świat i miały bardzo dobry odbiór, głównie w świecie start-upów. Bo pozwalają szybko budować rozwiązania. Gdzieś takie początki właśnie frameworka sięgają, prawie 20 lat już ma.

Dokładnie. I też mam wrażenie, że to jest takie koło napędzające się w powiązaniu z językiem, ponieważ Ruby mocno się wybił dzięki popularności Railsów, nawet w różnych indeksach popularności języków był językiem roku, z tego co pamiętam wg TIOBE, i to oczywiście było napędzane rozwojem Railsów, zyskiwaniem przez nie popularności. Ruby już istniał paręnaście lat, o ile mnie pamięć nie myli, jak nie więcej, od kiedy się Railsy narodziły, więc to nie był jakiś zupełnie świeżak na rynku, mocno się na Railsach gdzieś tam też wybił.

No właśnie, ale to, co powiedziałeś, jest, myślę, znaczące, że dzięki tej postawie kontrowersyjnego lidera Railsy miały w ogóle szansę, żeby zaistnieć i żeby się przebić do świadomości.

Okej, to teraz może spójrzmy na nieco bardziej techniczny aspekt Railsów, bo z frameworkami zazwyczaj kojarzy nam się coś takiego, że to jest taki monolit, że to jest jedna duża biblioteka używana do rozszerzania czy budowania na nich aplikacji. Ale Railsy składają się z różnych gamów, czyli takich właśnie małych bibliotek. Gdybyś mógł powiedzieć kilka słów na temat architektury Railsów. Jakie najbardziej istotne komponenty możemy w nich znaleźć?

Sama architektura Railsów bazuje na wzorcu MVC i podstawowa rzecz w tym wzorcu to jest Model-View-Controller, więc w tym klasycznym monolitowym schemacie Railsów znajdziemy widoki, czyli HTML-e renderowane przez framework, kontrolery do procesowania requestów i modele, czyli odwzorowania obiektowe bazy danych na bazie ORM-a i za obsługę modeli, obsługę zapytań do bazy danych w Railsach odpowiada biblioteka Active Record, która jest interpretacją tego wzorca Active Record, czyli każdy model, który mamy w aplikacji, mapuje się na fizyczną tabelę w bazie danych, i mając dostęp do modelu, mamy też dostęp do wszystkich metod związanych z transakcjami na bazie, czyli możemy zapisywać, usuwać, update’ować obiekt, zasoby w bazie danych.

To są trzy główne warstwy w aplikacji i same Railsy składają się po prostu z bibliotek, takich jak np. Active Record, jak Active Support, Controller Action View. To są biblioteki, które wchodzą w skład całego frameworka, mogą też żyć osobno, ale tutaj nabierają mocy zestawione razem.

I dzięki temu wzorcowi możliwe jest bardzo szybkie startowanie nowej aplikacji. Wygenerowany nowy projekt jest właściwie gotową aplikacją do użytkowania. Nieważne, czy chcemy stworzyć monolit z renderowanymi po stronie serwera widokami, czy chcemy stworzyć API restowe. To jest dosłownie jedna, dwie komendy, które pozwalają sprawić, że coś już działa, a co więcej, w wersji Rails 7 twórcy dodali obsługę frameworków front-endowych, tak że możemy sobie bardzo szybko postawić aplikację z wbudowanym Bootstrapem, Tailwindem, Bulmą na przykład. Dodatkowo możemy dopiąć jeszcze Reacta czy Angulara View. Właściwie wspiera cały stack webowy bardzo dobrze. Sam framework już na starcie ma taką paczkę narzędzi, która pozwala od razu ruszyć do pracy bez jakiejś zbędnej konfiguracji.

To jest, powiem Ci szczerze, coś, co mnie też urzekło na samym początku, kiedy ja zaczynałem z Railsami. Co prawda coraz rzadziej się do tego przyznaję z racji odległości w czasie, ale to był 2006 rok, kiedy zacząłem faktycznie tworzyć już w Railsach…

Zaraz na początku.

Tak, to była wersja jeden kropka coś. Natomiast urzekło mnie właśnie to, o czym teraz mówiłeś, że wcześniej programowałem w PHP i to był ten czas, kiedy każda firma tworzyła swój framework. To było normalne, każdy miał jakiś swój framework, jakiś zrąb aplikacji, taki Boilerplate, który był wykorzystywany do każdej kolejnej aplikacji. I każda firma, każdy Software House to był po prostu taki osobny Boilerplaite.

Natomiast w Railsach wówczas uderzyło mnie to, że tam wszystko było już gotowe i było wiadomo, jak rzeczy robić. Nie pozostawiało to raczej pola do interpretacji, o tym sobie jeszcze później porozmawiamy, czy to dobrze, czy to źle, natomiast mnie na początku zdecydowanie właśnie to urzekło.

Posiadałem do dyspozycji wszystkie komponenty i sposób działania z nimi. Nie musiałem kombinować, jak tu zestawić w ogóle aplikację, to wszystko już tam działało, więc to była fajna rzecz. I myślę sobie, że to jest też jeden z czynników wpływających na popularność Railsów, zwłaszcza na początku. Ale co by też dużo nie mówić, wiele języków też później kopiowało ten framework, oczywiście w znaczeniu architektury, możliwości, developer experience, chociażby PHP z Laravelem, Phyton, Elixir z Phoenixem. One w dużej mierze zwłaszcza na początku wzorowały się na Railsach.

No właśnie, jak wg Ciebie ta popularność Railsów i ich wpływ na inne technologie się kształtuje? Czy to jest jakaś zmienna popularność? Jak to widzisz?

Jak zaczynałem z Railsami, to one były jeszcze w Piku, były dość popularnym frameworkiem, popularnym rozwiązaniem, było dużo ofert pracy, można było sobie wybierać firmy, gdzie się chciało pracować, mimo że polski rynek był dużo węższy niż obecnie, jeśli chodzi o ruby’owe i railsowe firmy, to jednak było spoko. Zapotrzebowanie było duże. Później przyszły frameworki JavaScriptowe, Front-endowe, zaczęły się rozwijać bardzo mocno Reacty, Angulary i gdzieś te Railsy zeszły w cień. Zaczęły być uznawane jako takie dinozaury minionej epoki, które gdzieś tam sobie żyły i były te wszystkie argumenty na temat Ruby’ego i Railsów, że Ruby jest wolny, że Railsy są wolne, a z drugiej strony były to niesłuszne argumenty, bo da się je łatwo zbić, więc chciałbym życzyć każdemu, kto stawia projekt i buduje aplikację, żeby doszedł do takiej skali, gdzie faktycznie narzut szybkości języka mu zaczyna przeszkadzać. Bo nawet Shopify, w tym momencie największa railsowa aplikacja na świecie, z milionami linii kodu i milionami komponentów nie narzeka performance, więc to jest generalnie ciekawa dyskusja.

I później właśnie Railsy zeszły sobie w cień. Były takim frameworkiem gdzieś w cieniu, więc były oferty pracy, ale ten rynek nie był tak dynamiczny. I teraz od pewnego czasu obserwuję taki renesans, jeśli chodzi o oferty pracy i jeśli chodzi o sam framework, który odżył dzięki nowym technologicznym rzeczom, które zostały wprowadzone w nowej wersji. Jest wielki szał. W Polsce się tego może tak nie do końca widzi w przestrzeni w sieci, natomiast w Stanach jest szał na nowe Railsy i ludzie się mega jarają. Społeczność jakby odżyła i na nowo się fascynuje frameworkami. Jak śledzę jakieś wątki na Twitterze, to widzę wielu ludzi z innych technologii, którzy zaczynają naukę Railsów teraz w wersji 7 i robią wielkie WOW. I są historie PHP-owców, JavaScriptowców, którzy mówią: „WOW, jakie to jest super teraz”.

Tak że jesteśmy świadkami takiego renesansu i to idzie w coraz lepszą stronę, bo rozmawiałem ze znajomymi ze Stanów, nie sprawdziłem do końca tej informacji, więc dobrze, że ją opowiem teraz, to mam nadzieję, że społeczność ją sprawdzi skuteczniej: Jest taki fundusz Y Combinator i w ramach tego funduszu powstają start-upy i właśnie Railsy są częstym wyborem, ok. 3/4 projektów obecnie budowanych w ramach tego funduszu wybiera Railsy, jeśli chodzi o start-upy. Próbowałem dotrzeć do jakichś informacji, znalazłem jakieś tam posty, artykuły, ale konkretnych liczb nie mam, więc rzucam tak, po prostu do zweryfikowania. Ale na pewno coś jest na rzeczy.

Jasne. Ja też obserwuję to po ilości ofert pracy, które dostaję. Bo ciągle na LinkedInie widnieje u mnie Ryby Developer, chociaż od kilku lat już nie piszę aktywnie w tym języku, i widzę faktycznie to, co powiedziałeś, że tych ofert zaczyna być coraz więcej, co też bezpośrednio świadczy o tym, że faktycznie coraz więcej firm i projektów wybiera tę technologię.

Jak jesteśmy przy tym temacie, to chciałbym Cię zapytać właśnie o to, kto wybiera ten framework. W jakich projektach możemy go uświadczyć? Czy nadal jest tak, że to start-upy lubują się w Railsach z uwagi na prostotę startu i szybkość dowożenia ficzerów, czy też może inne rynki też sobie zaadoptowały Railsy z sukcesem?

Ciągle start-upy mają pierwszeństwo jeśli chodzi o liczbę wyborów frameworka Ruby on Rails ze względu na to, co mówiłem już wcześniej, o czym Ty też wspomniałeś: że jest pewna konwencja, są gotowe komponenty, które pozwalają szybko tworzyć aplikację, więc w momencie prototypowania jest to bezcenne, ten współczynnik Time to Market jest dużo szybszy. Więc to są głównie start-upy, natomiast obserwuję też większe firmy, które rozpoczynają nowe projekty w Ruby on Rails lub np. transformują stare projekty do projektów w Railsach.

Sam pracowałem też w projektach, które były przenoszone np. z PHP na Railsy, ze względu na to, że Railsy już teraz są dojrzałym frameworkiem. I tak jak we frameworkach node’owych to wszystko jeszcze żyje, pojawiają się nowe biblioteki, rozpoczyna się nowy projekt, to jest tysiąc bibliotek do wyboru do jednego rozwiązania, ciężko się zdecydować, to wszystko cały czas się rozwija, to Railsy są już dojrzałe i mają cały narzut community, open source, gotowych gemów, bibliotek gotowych do tworzenia wzorców w Railsach. On już jest dojrzały i często są zarzuty, że biblioteki railsowe są mało rozwijane, a one są mało rozwijane, bo już doszły do takiej dojrzałości, ze tam nie ma co znaleźć, one są dojrzałe i bezbłędne w dużej mierze.

Więc start-upy bardzo często sięgają po Railsy i sięgają po nie firmy produktowe generalnie, SaaS-y, bo jest dużo gotowych zestawów do tworzenia aplikacji, np. ze Stanów jest taki projekt Jumpstart, który pozwala wygenerować gotową aplikację, która ma od razu panel administratora, Multi-tenant, organizacje, płatności, wszystko już jest gotowe do wdrożenia i do dalszego rozwoju, więc to jest dalej pierwszy wybór.

Rozmawiałem z CTO mojej firmy, w której pracowałem, Dutchie. To jest taka firma, która jest obecnie wyceniana na 4,5 mld dolarów, ona w ciągu 5 lat się rozwinęła i to jest e-commerce dla kannabinoidów. Ma bardzo duży ruch i właśnie była taka dyskusja u nas na czacie na temat Rails, aplikacji, technologii, rozmawialiśmy o Node, o Elixirze i padło takie pytanie, gdyby dziś przy tej skali startował jeszcze raz ten projekt, to jaką technologię by wybrał, i on właśnie powiedział, że tylko Railsy, bo nic innego tak szybko nie daje wartości.

Więc jeśli ktoś najczęściej wybiera, to głównie start-upy, ale duże firmy też sięgają po Railsy, można je znaleźć też w korporacjach, gdzie są stosowane do jakichś zewnętrznych projektów, czy tych do zarządzania wewnątrz. I to też będziemy widzieć na rynku pracy, Bo rynek pracy w Railsach już się rozwinął w tę stronę, że sam framework ma 18 lat, na początku startowały z Railsami start-upy. Start-upy mają to do siebie, że większość upada, ale te, które nie upadły, rozwinęły się już teraz do rangi dużych firm i dalej są z Railsami. I jak patrzymy na oferty pracy, to dużo jest ofert w firmach produktowych, takich, które już wyszły z Software House’ów i budują swoje zespołowe wewnątrz.

No właśnie, to okrzepnięcie, taka profesjonalizacja całego tego ekosystemu myślę, że jest widoczna i to nawet wiąże się, myślę, z samymi programistami, że już trochę odkleja się taka łatka hipsterów, ludzi, którzy odstają od tego mainstreamu i wybierają Ruby jako alternatywę do innych, częściej spotykanych języków czy technologii. A teraz już nie jest to tak oczywiste, i faktycznie to, co powiedziałeś: te firmy, które przetrwały, które startowały na początku jako małe start-upy, jako takie EVC próby, teraz jest to już duży codebase, który trzeba utrzymywać, rozszerzać, rozbudowywać itd.

A z drugiej strony to bogactwo bibliotek i rozwiązań w ekosystemie, myślę, że to jest ważne dla każdej technologii, bo już nie tylko sam język jako taki świadczy o tym, czy technologia się przebije do mainstreamu, czy nie, ale cała ta otoczka. Bo nic nie istnieje w próżni, nawet jak sobie zaczniesz tworzyć jakiś mały projekt, to potrzebujesz tam czegoś do autentykacji czegoś, do podstawowych operacji, no i nie będziesz tego pisał oczywiście od zera. W Railsach czy w Rubym można znaleźć bibliotekę praktycznie do wszystkiego.

Wspomniałem wcześniej o tym, że mnie np. urzekło to, że w Railsach wszystko jest w miarę ustalone, wiadomo, jaka jest struktura katalogów, w jaki sposób tworzyć chociażby generatorami jakieś skafoldy, modele itd., w jaki sposób postępować, gdzie pakować logikę itd. Wszystko to w takim szerszym kręgu nazywa się Rails Way, czyli też taki sposób budowania aplikacji, który mocno DHH reklamuje, żeby nie powiedzieć, że wymusza wręcz czasami.

No właśnie, i to jest może fajne na początku, kiedy nie musisz się zastanawiać, jak to wszystko połączyć. Ale pytanie, co z większymi aplikacjami, które już często wymykają się z takiego planu początkowego, które rozszerzają się w różnych dziwnych kierunkach, Czy tutaj to podejście nadal się sprawdza?

Jest dokładnie tak, jak powiedziałeś, że jest Rails Way, który od razu daje nam gotowy zestaw zasad do tworzenia aplikacji i ten początek faktycznie jest spoko, bo wiemy, gdzie wszystko upakować i korzystamy też z tej zasady railsowej, konwencja nad konfiguracją, że Railsy bazują na tym, że odpowiednie nazewnictwo klas i plików robi taką magię, że Railsy wiedzą, jeśli mamy model post i kontroler post kontroler, to on wie, że ma szukać sobie widoków w katalogu Views i Post i on sobie wszystko znajdzie, tak jak trzeba.

I na początku to wygląda dobrze, natomiast wszystko rozbija się o dojrzałość deweloperów i świadomość biznesu na temat długu technologicznego, który może rosnąć, bo Rails Way jest sam w sobie elastyczny i wygodny, natomiast może prowadzić do wielu antywzorców, zresztą jak w każdej technologii można znaleźć furtki do antywzorców i takim głównym antywzorcem jest właśnie duży coupling w aplikacjach ze względu na to, że mamy ten domyślny podział architektury railsowej: nie jest domenowy, ale jest funkcjonalny i warstwowy.

Więc będziemy mieć rzeczy dotyczące jednej warstwy, jednej domeny, jednego kontekstu w aplikacji będziemy szukać w kilku lub w kilkunastu różnych katalogach, nie będziemy mogli znaleźć w jednym miejscu. I to może być problem. Więc początek spoko wygląda jeśli chodzi o tworzenie w Reals Way, chociaż inne firmy też mówią o tym głośno, np. Basecamp. Więc pewnie to się rozbija wszystko o dojrzałość deweloperów, świadomość, skill, znajomość architektury i samego frameworka, ale też przy rozwoju większych aplikacji rodzą się problemy w związku z couplingiem, w związku z przywiązaniem do Active Recorda, który też jakby sam wzorzec ma pewne zalety, ale ma też wady takie, że wszędzie w aplikacji możemy zmieniać bazę danych w każdym miejscu.

To też może być problematyczne. I odpowiedzią na to wydaje się być np. Domain-Driven Design, który jest też promowany przez polską firmę Arkency, przez Andrzeja Krzywdę i to jest taki drugi głos chyba w społeczności railsowej. Tak mi się wydaje, że o ile pierwszym głosem jest Rails Way DHH i tutaj ten Core Team, to Arkency ma bardzo mocny głos już teraz na świecie, jest rozpoznawalną marką i fajnie, że polska firma ma duży wkład w społeczność, więc przy większych aplikacjach wydaje się, że Domain-Driven Design jest dobrą odpowiedzią, i z tego co wiem, np. Shopify ma bardzo mocno wdrożony podział domenowy u siebie i to im się sprawdza przy naprawdę ogromnej skali.

Więc myślę, że to jest naturalne przejście z Rails Waya na bardziej zaawansowaną architekturę; jest naturalnym procesem w developmencie aplikacji. To samo obserwujemy też w innych frameworkach. Tutaj nie ma niczego nadzwyczajnego. Kwestia dojrzałości, planowania i architektury w zespole wpływa na to, czy są problemy przy skalowaniu, czy nie ma.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-157-ruby-on-rails/

--

--

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Krzysztof Kempiński

Krzysztof Kempiński

655 Followers

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.