To jest 157. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o Ruby on Rails. Przypominam, że w poprzednim odcinku rozmawiałem języku Rust. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/157. 

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Od niedawna można wystawiać oceny podcastom w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla Ciebie tworzę. Dziękuję. 

Sponsorem dzisiejszego odcinka jest Orange, dostawca usługi Orange Flex – sieć komórkowa w aplikacji z elastyczną ofertą. Dzięki Flex wszystko znajdziesz w jednej aplikacji bez konieczności chodzenia do salonów. Bez kolejek, bez papierologii. Jedną z jej opcji jest Flex dla Firm – oferta przeznaczona dla jednoosobowych działalności gospodarczych. W ramach Flex dla Firm znajdziesz pięć planów do wyboru, w tym 5G już od 35 zł, social media i popularne komunikatory bez limitu gigabitów, rozmowy, SMS-y, MMS-y bez limitu i aż 150 GB w najwyższym planie.

Dodatkowo tylko dla słuchaczy podcastu Porozmawiajmy o IT mam specjalny rabat: dowolny plan Flex dla Firm – nawet ten najwyższy – w promocji 50% taniej przez trzy miesiące. Wystarczy wpisać kod flexit podczas aktywacji numeru Flex dla Firm.

Sponsorem dzisiejszego odcinka jest platforma rekrutacyjna SOLID.Jobs. Jeśli szukasz pracy w IT, koniecznie odwiedź adres solid.jobs. Znajdziesz tam tylko oferty pracy z widełkami wynagrodzeń. Jeśli aktualnie nie myślisz o znalezieniu nowej pracy to koniecznie zapisz się na Job Alert. Nie częściej niż raz w tygodniu otrzymasz wiadomość e-mail z zestawieniem ofert, które mogą Cię zainteresować. Jeśli w swojej pracy dalej korzystasz z SVN-a, to koniecznie odwiedź SOLID.Jobs. 

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły. Jednocześnie bardzo dziękuję moim obecnym patronom. A teraz życzę Ci już miłego słuchania!

Odpalamy!

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.

Chciałbym Cię zapytać o początki branży. Bo jakoś tak się utarło, że Phyton czy JavaScript są sugerowane jako pierwsze języki, w sensie jeśli ktoś chce wejść do IT, zostać programistą, to zazwyczaj znajdzie w sieci kursy z tych języków. Jak to jest z Ruby, jak to jest z Ruby on Rails? Czy tutaj ten próg wejścia również jest na tyle nisko, że można to zarekomendować jako pierwszą technologię w ogóle do rozpoczęcia programowania? Jak Ty to widzisz?

Próg wejścia Ruby’ego i Phytona jest podobny. Ja bym nawet zaryzykował stwierdzeniem, że Ruby jest dużo łatwiejszy niż Phyton ze względu na składnię. To, co mnie urzekło na początku w Ruby, to jest to, że Ruby ma tzw. bang methods, czyli taką metodę z wykrzyknikiem na końcu, albo takie… nie pamiętam nazwy, ale takie metody, które zwracają boolean i one mają pytajnik na końcu. I możemy tworzyć sobie kod, który czyta się jak język angielski tak naprawdę, jak specyfikację. I dla osoby, która wchodzi do świata IT i zderza się np. z PHP, z JavaScriptem, z Javą, i tam ma te nawiasy, średniki, jakieś bardziej złożone pętle, tak wchodzi do Ruby’ego i czyta sobie po prostu zdania po angielsku. 

Mamy task update, task create, name coś tam, if coś tam pytajnik, if task exist i jest pytajnik na końcu i czytam to jak zdanie, to dużo łatwiej jest mi rozumieć pewne koncepty. Więc Ruby jest świetnym językiem na start i pozwala szybko wejść i poznać pierwsze koncepty, natomiast ja zawsze polecam, żeby równolegle z Rubym zapoznać się przynajmniej powierzchownie z jakimś językiem średnio typowanym typu Java, żeby zrozumieć, jak to działa pod spodem. 

Bo Ruby jest odciążony, jest dynamicznie typowanym językiem, jest interpretowany, jest bardzo obiektowy, natomiast brakuje kilku elementów takich, które są np. w Javie, a które pomagają też zrozumieć to, co się dzieje w Rubym. Np. mnie było łatwo wejść do Ruby’ego, bo wszedłem z .Neta, który jest silnie typowany, jest mocno obiektowy, są interfejsy, abstrakcyjne klasy i te wszystkie takie struktury i wchodząc do Ruby’ego wiedziałem, że o kurcze, nie muszę już robić tych rzeczy, więc Ruby mi się jawił jako taka fajna lekka, przyjemna opcja, która ma te rzeczy poukrywane i odciąża mnie od tej całej odpowiedzialności ogarniania innych spraw, właśnie związanych z interfejsami i typowaniem. 

Natomiast sam język dla kogoś, kto wchodzi bezpośrednio, jest prosty do przyswojenia. Więc próg wejścia jest naprawdę przyjemny i myślę, że jest nawet lepszy niż w JavaScripcie. Mimo że w JavaScript tak naprawdę wystarczy tylko przeglądarka – tutaj trzeba trochę skonfigurować środowisko. Aczkolwiek teraz chyba nawet na Linuxie Ruby jest zainstalowany w by default, bo na Macu na pewno.

To jeszcze może o samej nauce słów kilka. Co Ty byś doradzał? Najpierw w miarę opanować język Ruby, później dopiero z jego pomocą zacząć tworzyć cokolwiek w Railsach? Czy może połączyć te dwie drogi i próbować jednocześnie opanowywać Ruby’ego i tworzyć sobie jakieś tam strony, serwisy API w Railsach?

Doradzałbym zaczęcie od Ruby’ego. Zapoznanie się z samym językiem, przerobienie jakiegoś prostego kursu z internetu, np. na Codeacademy to jest tydzień, żeby poznać koncepty i wtedy można wejść do Railsów. Bo jeśli wejdziemy do samego frameworka od razu, to dużo rzeczy będzie dla nas niejasnych, będą niezrozumiałe pewne zabiegi, a Railsy jako sam framework narzucają trochę specyficzny dialekt Ruby’ego. I ten Ruby w Railsach to jest trochę tak, jak jest dyskusja, że Java w androidzie to nie jest ta Java, która jest w Springu. 

Więc tu jest trochę tak, że ten Ruby w Railsach jest specyficznie używany w odróżneiniu od tego, jak się pisze same skrypty w Rubym. Ale warto przynajmniej zrozumieć, jak działa język, warto zrozumieć te specyficzne dla języka elementy, jak np. bloki – to jest rzecz na co dzień używana w samym Rubym. I trzeba się też zapoznać, przynajmniej na jakimś podstawowym poziomie, o co chodzi z Metaprogrammingiem w Rubym, bo Railsy bardzo bazują na Metaprogrammingu. Ich cała ta magia, o której się mówi w Railsach, że pisze jeden obiekt i tam się dzieje wszystko pod spodem, to właśnie bazuje na tym, że Railsy potrafią się domyślić, o co mi chodzi. Więc najpierw Ruby, potem Railsy. I później Just in time learning W trakcie nauki frameworka, w trakcie tworzenia jakiegoś swojego projektu douczać się, doczytywać nowe rzeczy, które są niezrozumiałe.

Metaprogramming, czyli można powiedzieć kod, który pisze inny kod. To z jednej strony jest spora zaleta Ruby’ego, Railsów, które też mocno z tego mechanizmu korzystają, ale oczywiście wszystko, co w przeszycie, to szkodzi. I pewnie zgodzisz się ze mną, że jeżeli jest tam za dużo tej magii, to zwłaszcza debugowanie może być problematyczne.

Dokładnie.

Wspomnieliśmy trochę o rynku pracy. Myślę, że warto też powiedzieć parę słów, jak ten rynek obecnie wygląda w Polsce, na świecie. Może dysponujesz jakąś informacją, jak np. wynagrodzenie się ma do innych języków? Do czego tutaj można aspirować?

Jeśli chodzi o rynek pracy w Polsce, to obecnie mamy masę firm Ruby’owych, które rekrutują i są to software house’y czy firmy produktowe. Są fajne polskie firmy produktowe, np. Się pomaga u pacjenta.pl – to są takie rzeczy, gdzie też domena jest ciekawa, nie tylko sama technologia; można popracować też w dziedzinie medycyny czy działalności charytatywnych, to jest też super sprawa. Jest dużo software house’ów, które mają już bardzo mocno rozwinięte i doświadczone zespoły, np. Ragnarson czy Arkency może nie jest software housem, ale jest taką silną firmą, jeśli chodzi o doświadczenie. No masa jest takich naprawdę fajnych firm, w których można pracować i które aktywnie rekrutują. 

I ten rynek pracy w Railsach w Polsce jest naprawdę teraz szeroki i ja bym nawet powiedział, że firmy chętniej spoglądają na ludzi, którzy wchodzą do technologii, zwłaszcza z innych technologii, z innych języków programowania. Czyli ktoś zna już Javę i przesiada się na Railsy i wchodzi z tym doświadczeniem z innej technologii, i to jest też mile widziane.

Jeśli chodzi o stawki, to te stawki w porównaniu z innymi technologiami są naprawdę atrakcyjne teraz. Głównie ze względu na to, o czym mówiłem wcześniej, że te start-upy się rozwinęły. Czyli start-upy z Zachodu rozwinęły się i operują na trochę innych stawkach niż polskie firmy, i one budują teraz swoje zespoły. A pandemia i sam covid przyspieszyły nam ofline, więc jest łatwość teraz dostania pracy w firmie bezpośrednio z innego kraju, która oferuje dużo wyższe stawki niż w Polsce. 

I te stawki są naprawdę atrakcyjne. Można sobie wejść na Just Join IT, poprzeglądać. Patrzyłem nawet wczoraj, tak z ciekawości, jak to wygląda i jest naprawdę duże WOW i są to stawki konkurencyjne względem PHP – tak sobie porównywałem – czy nawet względem części ofert z .Neta. Front-endowych ofert jest dużo na niższym poziomie niż te stawki w Railsach i doświadczony programista Ruby on Rails może liczyć na naprawdę wysokie wynagrodzenie.

To jest też jedna z przyczyn, dla których warto w tę technologię, w ten język, w ten framework iść, bo faktycznie i liczba ofert pracy jest spora i atrakcyjność finansowa, ale też takiego środowiska, w którym się będzie pracowało. Bo oczywiście pieniądze są ważne, ale moje doświadczenia są takie, że firmy, które korzystają z tego frameworka, zazwyczaj mają fajną kulturę pracy – ja mam takie doświadczenia, że fajnie w takich zespołach się pracuje.

Mówiliśmy na początku, że język to jest jak gdyby jedna rzecz, ale potrzeba całego ekosystemu, żeby język, technologia mogły się wybić. Jednym z takich elementów składowych tego wszystkiego jest community, które odgrywa znaczącą rolę jeśli chodzi o upowszechnienie i rozwój technologii, języka, frameworków. Jak to community wygląda w Polsce, na Zachodzie, czy są jakieś spotkania, konferencje, meet-upy, na które można się udać, żeby coś posłuchać na temat Railsów?

Jeśli chodzi o cały świat, to najpopularniejszą konferencją jest RailsConf w Stanach – teraz w maju będzie kolejna edycja. I to jest taka konferencja organizowana bardzo regularnie. W czasie covidowym była organizowana na YouTubie, teraz będzie wracać na scenę, więc to jest jedna rzecz, można sobie też śledzić nagrania z tej konferencji, odsłuchać z poprzednich lat. Więc samo community, takie globalne jest bardzo mocne i ten głos jest mocno słyszalny głównie dzięki temu, że Railsy napędzają marki, które są znane. Ciężko jest poszukać, co jest napisane w note’cie, natomiast jeśli mówię, że w Railsach są napisane Shopify i Github i np. Dribbble czy Kickstarter, to każdy kojarzy te marki i wie, o co chodzi. Głównie Github i Shopify to są dwaj najwięksi gracze teraz na rynku. Dużo kontrybutorów i ludzi aktywnych w community takim światowym jest właśnie z tych dwóch firm.

A jeśli chodzi o polski rynek, to tutaj jest bardzo fajna sytuacja obecnie, bo kiedy Railsy wchodziły do Polski, to tak jak rozmawiałem kiedyś z Andrzejem Krzywdą, było dosłownie kilku railsowców czy ruby’owców w Polsce i się wszyscy znali. I oni dzisiaj poszli wysoko, prowadzą teraz własne firmy, znają cały framework, mają doświadczenie w latach wdrażania, rozwijania frameworków i budowania projektów.

Więc jest kilka naprawdę mocnych osób w Polsce, od których można się uczyć i które napędzają community. Bo samo community przez to, że wybuchła pandemia, trochę upadło, tak jak pozostałe meet-upy w Polsce. A teraz to wszystko odżywa, odżywają konferencje i teraz w tym roku ma być Wroc_love.rb, taka konferencja railsowa, więc można robić reklamę teraz.

Są też ciekawe inicjatywy oddolne, jeśli chodzi o popularyzację Ruby’ego i Railsów w Polsce. Jedną z takich rzeczy jest mój mailing – grubymailing – gdzie chciałem stworzyć pierwszy taki polski newsletter o Rubym w języku polskim, bo dużo było takich głosów, jak gdzieś tam działałem w społeczności, że fajnie, ale nie ma materiałów w języku polskim i może ten framework byłby bardziej popularny w Polsce, gdyby można było poczytać o nim po polsku. I stąd właśnie te inicjatywy. Więc samo community jest też bardzo pomocne. Jeśli się wejdzie na pytania na Stack Overflow, to jest masa odpowiedzi. Tweeter też, można sobie śledzić dobrych gości, jak Tomek Starewicz, jak Piotrek Solnica, Andrzej Krzywda, Robert Pankowecki. No dużo jest solidnych ludzi z Ruby’ego i z Railsów w Polsce, do których można zawsze napisać, zawsze pomogą. Więc community było zawsze mega zaletą tego frameworka, że było takie pomocne, otwarte, radosne, i to cały czas widać.

Tak jak mówisz. Myślę, że to jest po prostu w DNA i języka i frameworka. Pomoc innym, przyjemność z tworzenia rozwiązań, dobre środowisko do rozwijania całego ekosystemu.

Jak sobie tak spojrzymy na rozwój Railsów, a może też na rozwój w ogóle tworzenia aplikacji internetowych, to oczywiście na początku był to standardowy, klasyczny układ, gdzie była aplikacja działająca na serwerze, która generowała nam HTML, CSS, JavaScript wyświetlany później w przeglądarce. Później zachłysnęliśmy się aplikacjami typu SPA, gdzie ten front-end był taki bogaty i przez kilka lat było tak, że Railsy głównie służyły do budowania API. Do wystawiania API jest wręcz dostępny taki tryb. Teraz zaczynamy wchodzić jeszcze w coś innego, czyli w generowanie dynamicznego front-endu na back-endzie. I tutaj wiele technologii wokół tego krąży, nie tylko Railsy, ale chociażby Next.js, też elixirowy Phoenix ma podobne zastosowania.

No właśnie gdybyś mógł opowiedzieć trochę o tym wynalazku i jak Railsy się w to wpasowują.

Właśnie ten wynalazek nazywa się Hotwire w dialekcie railsowym, czy w ogóle cokolwiek, co jest wire w innych technologiach, bo Laravel ma chyba life wire. To jest taka technologia, która polega tak, jak samo hasło na stronie mówi, że to jest asti.mel over the wire HTML przesyłany przez sieci, przez jakieś tam kable i opiera się na WebSocketach. Teoretycznie jest więc to coś odkrywczego i nowego, a z drugiej strony to nie jest wale jakiś nowy wzorzec i rozwiązanie, bo takie coś już było np. w Meteorze, że Meteor komunikował się z back-endem po WebSocketach.

Polega to na tym, że możemy tworzyć teraz reaktywny front-end bez konieczności wpinania żadnego frameworku JavaScriptowego. Nawet wczoraj miałem taką prezentację na konferencji dev.js Summit, gdzie mówiłem o JavaScript less front-end i naprawdę to, co wcześniej trzeba było zrobić z pomocą JavaScriptu, jakieś dynamiczne scrolle, paginacje, reaktywne dodawanie elementów na stronie, to teraz dzieje się za pomocą kodu back-endowego tak naprawdę. I Railsy w nowej odsłonie, w wersji 7 są teraz spaf’s first dzięki mechanizmowi Hotwire i Turbo, który pozwala za pomocą dosłownie kilku jakichś tam konfiguracji przesyłać dynamiczny HTML z back-endu i front-end. Właśnie ten mechanizm Hotwire wie już, gdzie sobie podmienić te wszystkie elementy.

Więc wcześniej mieliśmy ten monolit i teraz wracamy do monolitów railsowych i na ten moment ja teraz rozwijam jeden projekt taki start-upowy, jest już w takiej już dość zaawansowanej fazie i praktycznie nie ma tam JavaScriptu. I nie mieliśmy ani przez moment potrzeby wpięcia kodu Reacta i tak jeszcze dodam, że przenieśliśmy widoki, które były w React’cie do Railsów i wykasowaliśmy masę kodu, który był dodatkowo narzucony. I właśnie Railsy są takie spaf’s first dzięki temu mechanizmowi. Ten SPA experience, takie doświadczenie, ze to jest cgroup page application, bo bez przeładowania strony możemy edytować jakieś elementy na stronie.

I są już oferty pracy na full state deweloperów, bo Railsy generalnie jako framework zawsze były takim frameworkiem Full-Stacków, potem się to trochę zmieniło, a teraz z powrotem tak się dzieje, bo cechą back-end deweloperów jest to, że nie chcą dotykać frontu i JavaScriptu, a tutaj jest okazja tworzyć front-endy za pomocą tak naprawdę Ruby’ego tylko. Reaktywny front-end, jest jeszcze taka biblioteka, stworzona przez GitHuba, nazywa się ViewComponent, który pozwala tworzyć komponenty w Rybym, które są tym samym, czym są komponenty np. w Reactcie. I to wszystko się dzieje na poziomie jednego języka. I one są unit testowane w Rubym i renderowane do widoków. Ja jestem zakochany w tym rozwiązaniu, mimo że jestem też reactowcem i dużo pisałem w Reactcie i naprawdę jest taki renesans, jest experience SPA w nowych Railsach i warto się temu przyjrzeć, w którą stronę to będzie szło, bo będzie szło naprawdę w ciekawym kierunku.

Mam wrażenie, że jest wiele właśnie takich elementów powrotu do wcześniejszego podejścia do tworzenia aplikacji. Chociażby ten Full-Stack, który na początku nawet się nie nazywał Full-Stackiem, po prostu były osoby, które tworzyły rozwiązania od A do Z, i to było dosyć normalne. Ale też Web Developer po prostu. Ale to też może dlatego, że tych narzędzi nie było aż tyle. Nie trzeba było się doktoryzować w tylu różnych rzeczach. Po prostu miałeś framework, który ogarniał wszystko i tam się cała ta magia działa.

Potem poszliśmy trochę w bardzo ciężkie front-endy, z nawet logiką, a to jest już chyba jakiś AntyPattern, mam wrażenie. Teraz wracamy do tych podstaw, ale to też trzeba sobie powiedzieć, dzięki rozwojowi technologii, to nie chodzi tylko o sam taki mindshift, ale też rozwój technologii, wydajności, żeby przesyłać po WebSocketach sobie te rzeczy dynamicznie, to oczywiście serwer też musi być odpowiednio mocniejszy.

To nie pozostaje mi chyba nic innego, Rafał, jak zapytać Cię, w którym kierunku Railsy będą się rozwijać. Czy ta popularność będzie rosła? Jak Ty widzisz przyszłość dla Railsów?

Na pewno popularność będzie rosła w stosunku do tego, co mieliśmy przez ostatnie kilka lat. Właśnie dzięki tym nowym rozwiązaniom. Bo też widać ten oddech w społeczności. Frameworki front-endowe były i nadal są spoko, wiadomo, każda technologia jest dobra do konkretnego problemu biznesowego. Ale to, co frameworki front-endowe przyniosły, to tak naprawdę trzecią warstwę. Chcieliśmy mieć odseparowany front-end od back-endu, a tak naprawdę front-endowe frameworki dorzuciły nam jeszcze stan, czyli back-end na froncie. Dostaliśmy trzecią warstwę do zarządzania i do spójności i zaczęły się robić problemy. 

Mówię o tym, że to jest nowa era front-endów, gdzie ten stan wraca do bazy danych i mamy jedno źródło prawdy. I Railsy w tym kierunku będą szły. Czy będą jakimś wiodącym frameworkiem webowym? – nie sądzę. Tak jak żaden inny framework webowy nie będzie jakimś wielkim graczem. Pewnie pojawi się coś nowego niedługo, co przejmie pałeczkę na rok, dwa i potem wróci do szeregu. Natomiast Railsy będą dalej ważnym graczem, jeżeli chodzi o Web Development i to widać, bo tworzą się nowe projekty, dopalane naprawdę milionami dolarów. 

I to też widać po ofertach pracy, po stawkach. Bo stawki są kolosalne, tak jak mówiłem. I community się rozwija. Cały czas dochodzą nowi ludzie, cały czas się jarają, przechodzą z innych technologii do Railsów. Więc przed 2021 rokiem mówiło się, że Railsy już dojrzały i nic więcej już nie wymyślą, a okazały się, że jednak wymyśliły Hotwire i pokazują, że można tworzyć coś nowego, w nowy sposób i szybko, i to robi wielkie WOW. Bo tak naprawdę w kilka godzin można stworzyć naprawdę reaktywną aplikację full wypas, z frameworkiem front-endowym, trade windem wpiętym, reaktywną, wodotryski i wszystko się dzieje, więc to robi wielkie WOW. 

A z drugiej strony w dalszym ciągu będą wymagać doświadczonych programistów do rozwijania tych projektów i do budowania odpowiedniej architektury, jak każdy framework. I myślę, że dalej będą ważnym graczem. Dla start-upu, dla dużych firm. Jest też masa projektów, które się rozwinęły, zarabiają teraz kupę kasy i trzeba je utrzymywać. Tak że rynek pracy ciągle żyje i będzie żył. Już na pewno nie w takiej skali, jak to było na początku Railsów, ale dalej to będzie rosło i będzie można znaleźć fajną pracę.

I tu jeszcze taką fajną zaletą Railsów jest to, że Railsy dają możliwość pracy w fajnych projektach. Jakoś tak się składa, że akurat aplikacje w Railsach dotyczą ciekawych domen biznesowych, czy to jest medycyna, czy sprzedaż biletów. Różne ciekawe rzeczy. Ja np. pracowałem przy e-commerce dla kannabinoidów, jakieś self-care help, takie helpingowe aplikacje à la OLX. Tych domen jest dużo i są bardzo ciekawe.

To jest zawsze ciekawy kierunek i wierzę w Railsy i wierzę, że prawdziwa era Ruby’ego i Railsów dopiero nadchodzi i ja się też chcę do tego przyczynić dzięki swoim projektom. Mam nadzieję, że się spotkamy jeszcze za rok czy dwa i zobaczymy, jak prężnie działa community w Polsce.

Oczywiście wszystkie projekty będą podlinkowane w notatce do odcinka. Rafał Piekara był moim gościem. Rozmawialiśmy o frameworku Ruby on Rails. Rafał, bardzo Ci dziękuję za poświęcony czas i za rozmowę.

Dziękuję bardzo, Krzysiek. Bardzo miło się rozmawiało.

Cieszę się bardzo. To powiedz jeszcze, gdzie Cię można znaleźć w sieci. Gdzie odesłać słuchaczy, żeby mogli się więcej dowiedzieć na temat języka i frameworka?

Można mnie znaleźć właściwie na wszystkich możliwych socialach, czy to jest LinkedIn, czy Tweeter, czy Facebook. Na Instagramie jestem bardziej dostępny, więc mój profil Rafał Piekara na Instagramie można znaleźć. Tam też dużo jest o Railsach i o Rubym. Ale też mam własne projekty, dzięki którym kontrybuję w społeczności. Głównym projektem jest grubymailing. Gruby dlatego, że Ruby i dlatego, że jestem gruby, i to jest taka gra słów. I to jest mailing polski o Rubym, więc zachęcam, bo teraz akurat maj jest takim miesiącem, gdzie dużo się będzie działo w ramach tego mailingu. Będą też darmowe rzeczy, darmowe materiały, darmowe szkolenia, więc tu można wejść. jeśli ktoś chce się jeszcze bliżej zapoznać z Railsami i z frameworkiem, to jest dobry moment. 

Prowadzę także bloga grubykodzi, więc wszystko, co z hasłem gruby, to można sobie googlać i bardzo możliwe, że się mnie tam znajdzie. I mam jeszcze jeden newsletter techniczny PM dla Project Menedżerów, ale on już jest mniej o Rubym, a więcej o technikaliach i komunikacji między biznesem a programistami. Tak że tych miejsc jest dość sporo. Występuję też na konferencjach, meet-upach, tak że jest spora szansa, że jak będziecie szukać po haśle Ruby i Gruby, i Railsy w Polsce, to gdzieś na mnie wpadniecie, nawet niechcący.

Dokładnie tak. Zapraszam do linków, postaram się podlinkować wszystkie te rzeczy, o których Rafał wspomniał. Jeszcze raz, Rafał, bardzo Ci dziękuję za poświęcony czas i do usłyszenia. Cześć!

Dzięki wielkie, cześć!

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Osobiście z projektami opartymi o Ruby on Rails pracowałem ponad 10 lat. Sam framework, jak i community wspominam bardzo dobrze. Coś, co mnie zawsze urzekało w tej technologii, to stosunkowa łatwość i szybkość tworzenia rzeczy, co jest nie tylko ważne dla biznesu, ale i dla satysfakcji programisty z rychłego oglądania efektów swojej pracy.

Jeśli ten odcinek był dla Ciebie interesujący i przydatny, odwdzięcz się, proszę recenzją, oceną lub komentarzem w social mediach. Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o Ruby on Rails. Zapraszam do kolejnego odcinka już wkrótce, cześć!