To jest 149. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o języku Ruby.

Przypominam, że w poprzednim odcinku rozmawiałem o Service Design w IT.

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/149.

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut.

Sponsorem podcastu jest Apptension, wiodący polski twórca produktów cyfrowych i wydajnych, skalowalnych aplikacji. Zerknij na ich portfolio na apptension.com/portfolio.

Sponsorem dzisiejszego odcinka jest również 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ści e-mail z zestawieniem ofert, które mogą Cię zainteresować. SOLID.Jobs to więcej niż job board. Na stronie znajdziesz nie tylko oferty pracy, ale również poszerzysz swoje kompetencje. Odwiedź zakładkę Prasówka, czyli agregator polskich blogów i podcastów, gdzie z jednego miejsca dotrzesz do solidnej dawki informacji i newsów ze świata IT i nie tylko. Jeśli w swojej pracy dalej korzystasz z SVN-a, to koniecznie odwiedź SOLID.Jobs.

Nazywam się 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 Ruby od 7 lat, wcześniej tworzył aplikacje mobilne z wykorzystaniem Javy. Obecnie Principal Engineer w Monterail, gdzie zajmuje się programowaniem, rekrutacją, analityką biznesową oraz doradztwem w zakresie architektury. Fascynat serverlessowego podejścia, baz grafowych, GraphQL-a i niestandardowych rozwiązań w Rubym. Moim i Waszym gościem jest Wojciech Maciejak.

Cześć, Wojtku! Bardzo miło mi gościć Cię w podcaście.

Cześć! Bardzo dziękuję za zaproszenie.

Przyjemność po mojej stronie. A temat dzisiaj to język programowania Ruby. Temat, nie ukrywam, dla mnie też wyjątkowy i taki bliski, ponieważ ponad 10 lat swojej kariery właśnie w tym ekosystemie Ruby, Ruby on Rails spędziłem, więc bardzo się cieszę, Wojtku, że będziemy mieli okazję o tym porozmawiać. Dopiero teraz nagrywamy o tym właśnie języku. Patrząc na ilość odcinków w moim podcaście, to mogę powiedzieć, że dopiero teraz, bo faktycznie miałem plany już dawno, dawno, żeby o tym języku porozmawiać. Tym niemniej cieszę się, że mam tutaj okazję z Tobą na ten temat porozmawiać.

Ale żeby wszystkim formalnościom stało się zadość, to muszę Cię na początku zapytać, tak jak każdego mojego gościa, czy słuchasz podcastów? Jeśli tak, to może masz jakieś swoje ulubione audycje, o których chciałbyś powiedzieć.

Oczywiście. Kiedyś słuchałem tych podcastów zdecydowanie więcej, ponieważ jeździłem autem do pracy i to był taki czas, takie co najmniej dwie godziny dziennie, żeby przesłuchać to, co mnie najbardziej interesuje. Obecnie pracuję w większości z domu i słucham tych podcastów zdecydowanie mniej. Natomiast z takich serii, których słucham nadal i słuchałem, to jest oczywiście Twój podcast.

Dziękuję.

To jest też Tech Leaders Garetha Davisa, Better Software Design Mariusza Gila – i to jest chyba jeden z najlepszych podcastów polskich, jakie są dostępne w Internecie. Ale poza takimi technicznymi seriami, słucham również podcastów o psychologii, między innymi Strefa Psyche Uniwersytetu SWPS.

Dzięki za te rekomendacje. Dobrze, Wojtek, na początku chciałbym Cię zapytać trochę z historii języka Ruby, jak on powstał, kto go stworzył. Mówi się, zresztą dużo jest w tym prawdy, że jedną z takich motywacji do powstania, do stworzenia języka Ruby, było to, żeby dawać taką przyjemność stworzenia kodu z jego wykorzystaniem, więc powiedz, proszę, jak to się wszystko zaczęło.

Ruby tak naprawdę powstał w roku 1993 lub 1995. Różne źródła różne informacje podają, natomiast jakby przyjmować tę datę, kiedy powstała pierwsza taka stabilna wersja 0.9.5, to był właśnie rok 1995. Język ten został stworzony przez Yukihiro Matsumoto o pseudonimie „Matz”. I Matzowi, tak jak powiedziałeś, od początku zależało, żeby to programowanie w Rubym dawało radość, żeby ten język był zrozumiały dla człowieka i żeby dawał radość z programowania. Osobiście myślę, że to były takie czasy, że dostępne wtedy języki stawiały na funkcjonalność, na możliwości, a nikt nie myślał o tym, żeby język sam w sobie był przejrzysty, czytelny, czy też właśnie przyjemny w samej pracy. Ruby i kilka innych języków z lat 90. miało to zmienić, przynajmniej tak z mojej perspektywy, na tyle ja kojarzę tę historię.

Co ciekawe, rok 1995 był bardzo wyjątkowy w historii języków programowania, ponieważ wtedy powstał Python, Java, PHP, JavaScript. Można powiedzieć, że Ruby miał od samego początku potwornie silną konkurencję i mógł to być też jeden z takich powodów, dlaczego Ruby sam w sobie nie odniósł wielkiego sukcesu od samego początku istnienia. Ponieważ tak na dobrą sprawę, parę lat po tym roku 1995 o Rubym nadal nie było głośno. To była gdzieś mimo wszystko nisza.

Ale można też na to popatrzeć z nieco innej perspektywy. Na przykład Java i JavaScript miało dosyć silne wsparcie ze strony tak zwanych enterprise’ów. W przypadku Javy była to firma Sun, w przypadku JavaScriptu była to firma Netscape. Natomiast reszta języków, jak i Ruby, to był wysiłek najczęściej 1 programisty czy 2-3. Wracając, Ruby nie był wybitnie popularny od początku istnienia, tak jak powiedziałem, natomiast motorem napędowym popularności Rubiego stał się w roku 2003 framework Ruby on Rails, stworzony przez Davida Heinemeiera Hanssona. Wprowadził on całkiem nową jakość w świecie developmentu i już po 3 latach, zdaje się, Ruby został ogłoszony językiem roku 2006.

Od tego czasu minęło wiele lat, oba narzędzia nieco straciły na popularności, ale mimo to uważam, że wielu programistów na świecie czerpie taką właśnie przyjemność z programowania w tych narzędziach i też jest sporo światowej sławy produktów opartych na Rubim czy właśnie na Railsach. Railsy obecnie wskoczyły na wersję 7, a ostatnie wydanie Rubiego to wersja 3.1.0 i myślę, że mimo, iż powiedziałeś, że długi czas minął od początku nagrywania Twojego podcastu, kiedy mówimy w końcu o Rubim, to jest dobry czas, żeby o tym powiedzieć, bo to też jest taki moment, kiedy zostają wprowadzone nowe fajne mechanizmy i można dużo fajnych rzeczy opowiedzieć o Rubim.

Dokładnie. O to jeszcze na pewno dzisiaj Cię zapytam nie raz. Ja trafiłem, pamiętam, na język Ruby, właściwie to na framework Ruby on Rails, bo tak jak powiedziałeś, od tego się bardziej zaczynało, gdzieś w roku 2006. To były bardzo wczesne jeszcze etapy istnienia frameworka. Język już był ponad dziesięcioletni, więc można powiedzieć, że tam już trochę tych mechanizmów było, ale faktycznie, był raczej mało znany, można powiedzieć, zwłaszcza w Europie. W Japonii częściej się go wybierało, natomiast w Europie był praktycznie nieznany.

I wtedy, pamiętam, to był taki trochę język dla hipsterów, można powiedzieć, dla osób, które stawały trochę w takiej sprzeczności z tym, co oferował rynek. Głównie tutaj myślę o Javie, bo to był wtedy taki mainstream. I to jest dosyć ciekawe, że historia takim trochę kołem się toczy i Java, która wcześniej była właśnie tego typu językiem, który stawał w szranki z tymi mainstreamowymi językami, teraz był tego typu językiem dla Rubiego. Ale osoby czy też takie grono, środowisko, które zajmowało się tym językiem, to było właśnie grono mniej lub bardziej hipsterów, którzy, można powiedzieć, w kawiarniach, na Macach pracowali nad tym językiem. Mnie to wówczas bardzo imponowało, to było faktycznie coś.

Natomiast chcę Cię zapytać, czy nadal albo czy, w Twojej opinii, w ogóle kiedykolwiek Ruby był językiem preferowanym przez hipsterów? Czy nadal tak jest?

Pamiętam, że jak byłem na studiach i zacząłem myśleć o Rubim, to faktycznie moi znajomi tak na mnie patrzyli ze zdziwieniem, ponieważ na polskich uczelniach bardzo często uczy się głównie Javy. To jest taki główny standard, można tak to określić. Moi znajomi patrzyli na mnie z takim zdziwieniem, że czemu Ruby. Właściwie co to jest ten Ruby, bo mało osób o tym wiedziało. I faktycznie gdyby tak na to popatrzeć, to mogłoby się okazać, że to jest trochę nadal język dla hipsterów. Natomiast po tych paru ładnych latach programowania w Rubim, ale też poznawania różnych innych języków, rozpatruję to, można powiedzieć, w dwóch kategoriach.

Pamiętam, że jak byłem na studiach i zacząłem myśleć o Rubim, to faktycznie moi znajomi tak na mnie patrzyli z takim zdziwieniem, ponieważ na polskich uczelniach bardzo często uczy się głównie Javy. To jest taki główny standard, można tak to określić. Moi znajomi patrzyli na mnie z takim zdziwieniem, że czemu Ruby. Właściwie co to jest ten Ruby, bo mało osób o tym wiedziało. I faktycznie gdyby tak na to popatrzeć, to mogłoby się okazać, że to jest to trochę nadal język dla hipsterów. 

Pierwsze to, czy język jest nowy i czy jest niszowy sam w sobie. Czy Ruby jest nowy? Ma już swoje lata i nie można go nazwać ani językiem nowym, ani młodym. Ma za sobą okres dynamicznego wzrostu i teraz ten język tak naprawdę dojrzewa. Natomiast na pytanie o niszowość można odpowiedzieć: to zależy (jak zwykle). To zależy, czy patrzymy na niszowość względem ilości programistów, czy używanie tego języka w produktach i dojrzałych aplikacjach. Ja osobiście lubię patrzeć na tę drugą stronę medalu, czyli czy na rynku istnieje dużo rozwiązań, które opierają się lub wykorzystują Ruby.

I przychodząc tutaj z odpowiedzią, z takich większych graczy, chyba największych, to na pewno GitHub jest tutaj najciekawszym przykładem, że zbudowano oraz nadal buduje się aplikacje z użyciem Ruby i Ruby on Rails. Kolejnym ciekawym przykładem jest między innymi Twitter, który od początku był rozwijany w Rubim, chociaż obecnie, z tego, co mi wiadomo, tam zdecydowana większość codebase’u to już jest inny język. Ale są też takie aplikacje jak Discourse, jak Airbnb, jak Kickstarter, ale przede wszystkim chyba największy e-commerce w Rubim, czyli Shopify jako taki flagowy przykład użycia najpopularniejszego frameworka w dużej skali działania.

I prawdopodobnie jest jest jeszcze wiele innych przykładów, gdzie Ruby czy Ruby on Rails są wykorzystywane, ale tak podsumowując, wydaje mi się, że języki hipsterskie to takie, które nie mają jeszcze lub już nie mają zbyt wielu praktycznych przykładów użycia, lub wprowadzają takie totalnie nowe podejście do programowania. Raczej nie powiedziałbym, że jest to język hipsterski, aczkolwiek żeby być tutaj obiektywnym, na pewno nie ma tutaj tak dużo programistów jak w Javie, jak w C Sharpie, jak w Pythonie. Natomiast mimo wszystko nie sądzę, że już jest to język hipsterski.

Ciekawe. Kontynuując ten wątek, powiedziałeś, że w 2006 roku zgodnie z indeksem TIOBE Ruby był ogłoszony językiem roku. Faktycznie wtedy był na takiej szczytowej pozycji. Obecnie jest gdzieś w okolicach miejsca 15, więc jest jakiś spadek, ale to też nie jest tak, że zupełnie wypadł z tej puli języków najczęściej wybieranych. W związku z tym, bazując na tym miejscu w rankingu oraz na tym, że już zebrał trochę doświadczeń i rozwoju z biegiem lat, czy można powiedzieć, że ten język już okrzepł, że już jest jednym z tych mainstreamowych języków?

Okrzepł na pewno. Tak jak powiedziałeś, okres wybuchu popularności ma za sobą, to nie ulega wątpliwości. Po cichu mimo wszystko liczę na to, że Ruby przeżyje w najbliższym czasie drugą młodość, aczkolwiek myślę, że o tym jeszcze porozmawiamy. Natomiast to, że okrzepł, ma swoje plusy moim zdaniem. Nowe wersje są raczej stabilną ewolucją niż rewolucją wprowadzającą masę nowości. To samo dotyczy najpopularniejszych bibliotek i frameworków. Raczej nie zdarza się, żeby kolejne wydania były niedopracowane, kontrowersyjne albo wprowadzały jakieś breaking changes, które naprawdę wymagałyby bardzo dużych zmian w kodzie.

Osobiście myślę, że Ruby już od paru ładnych lat zagościł obok innych znanych i lubianych języków programowania na piedestale. Jest często wybieranym językiem do tworzenia aplikacji webowych, choć faktem jest, że nie jest to narzędzie pokroju Javy, która stała się ulubieńcem szerokiego grona enterprise’ów, o których wcześniej mówiłem. Natomiast inna sprawa, to myślę, że Ruby nie do końca powinien bić się o takie miejsce. To jest taka moja osobista opinia, ponieważ każdy język ma swoje charakterystyczne zastosowania i jedne są nieco bardziej nastawione na szybkość pisania kodu, na dostarczanie tej wartości biznesowej, drugie na niezawodność, kolejne na stabilność i long-termowe wsparcie. Zawsze warto wziąć pod uwagę te aspekty podczas tworzenia konkretnych rozwiązań i szukać narzędzia do konkretnego rozwiązania, a nie dostosować rozwiązanie do narzędzi.

Tak, to jest taka naczelna zasada, którą się powinno wybierać, zdecydowanie. Właśnie o tej zmianie, o tym wyborze technologii pasującej do naszego problemu może świadczyć też taki shift w Twojej karierze, prawda? Przedstawiając Ciebie, mówiłem że rozpoczynałeś jako programista aplikacji moblinych w Javie. Chciałbym Cię zapytać, co cię skłoniło przede wszystkim do przejścia na Backend, co Cię skłoniło też do wyboru Rubiego, jak te początki z tym językiem wyglądały u Ciebie?

Ta historia może być nieco dłuższa i nieco bardziej zawiła, ale postaram się to tak w kilku punktach streścić. Można powiedzieć, że praktycznie od samego początku sensownego – czyli pomijam tutaj pisanie gier w Turbo Pascalu – od początku sensownego programowania miałem styczność z Javą, mniejszą lub większą, mniej lub bardziej profesjonalną, ale jednak gdzieś koło tej Javy byłem. I początkowo oczywiście pisałem proste struktury danych czy jakieś proste aplikacje, które nie robiły nic specjalnego, ale z biegiem czasu człowiek zaczął uczyć się, jak rozwiązywać pewne problemy i jak modelować biznes. To jest jedna historia.

Natomiast druga historia jest taka, że zawsze fascynowały mnie aplikacje mobilne i gdy na studiach wykładowcy uczyli nas, jak tworzyć proste struktury danych w Javie, ja już byłem ten jeden krok dalej i ja już pisałem pierwsze aplikacje na Androida, chyba wtedy jeszcze w wersji 2.2.1. I był to dla mnie taki naturalny kierunek rozwoju. Natomiast przewrotnie powód, dla którego odszedłem od aplikacji mobilnych, był nie do końca związany z programowaniem.

Tak jak każdemu programiście na początku kariery i mnie potrzebny był mentoring. I czasami dobre code review potrafi zrobić świetną robotę. Czasami wskazanie kierunku rozwoju, a czasami podrzucenie ciekawego, rozwijającego artykułu, kieruje, można powiedzieć, naszym rozwojem w karierze. Niestety na początku mi tego trochę zabrakło i czułem, że aplikacje mobilne i Java nie mają mi zbyt wiele do zaoferowania. I to oczywiście nie było prawdą, ale zrozumiałem to dopiero po paru latach. Wtedy uważałem, że po prostu trochę stanąłem w miejscu i muszę trochę zmienić kierunek rozwoju.

Tak jak każdemu programiście na początku kariery i mnie potrzebny był mentoring. I czasami dobre code review potrafi zrobić świetną robotę. Czasami wskazanie kierunku rozwoju, a czasami podrzucenie ciekawego, rozwijającego artykułu, kieruje, można powiedzieć, naszym rozwojem w karierze. Niestety na początku mi tego trochę zabrakło i czułem, że aplikacje mobilne i Java nie mają mi zbyt wiele do zaoferowania. I to oczywiście nie było prawdą, ale zrozumiałem to dopiero po paru latach. 

Zacząłem szukać innych możliwości rozwoju i trafiłem na dodatkowe wykłady na Politechnice Wrocławskiej z Koła Naukowego Tworzenia Aplikacji Webowych, które organizowało Monterail. Usłyszałem wtedy pierwszy raz o Rubim, o tej firmie, i uznałem, że to jest coś dla mnie. Pamiętam, że to były wykłady. To nie było tak, że dołączyłem do tego koła od samego początku jego istnienia, tylko chyba trafiłem na 5. czy 6. wykład i to był wykład o tworzeniu testów w RSpecu – i to było coś zupełnie nowego, jak ten język wygląda. Mimo że to są tylko testy, które są często nielubiane przez programistów, to byłem pod dużym wrażeniem, jak ten kod wygląda i jak fajnie się pisze w Rubim.

To, co jest zabawne, to na początku zatrudniłem się w Monterail jako Quality Assurance, czyli tak naprawdę jako tester, ponieważ ja kompletnie nie potrafiłem programować Rubim, a dopiero po 3-4 miesiącach zostałem Junior Developerem właśnie w Rubim w firmie Monterail. Jakie były początki? Były dosyć trudne, bo byłem gościem, który pisał aplikacje mobilne i ciężko mi było zmienić sposób myślenia z telefonu na przeglądarkę. Ale chyba największym problemem było odrzucenie pewnych naleciałości po Javie. Gdy to już udało mi się zrobić, to cała przygoda zaczęła się na nowo.

I myślę, że ogólnie to, co mnie najbardziej zafascynowało w Rubim, to fakt, jak wiele mogłem stworzyć  w krótkim czasie i jak jest to przyjemne. Czyli właśnie to pierwsze wrażenie z tych wykładów, o których wcześniej mówiłem, potwierdziło się już kilka tygodni, kilka miesięcy później. I tak naprawdę jako osoba nieznająca języka albo znająca go w bardzo małym stopniu, byłem w stanie stworzyć w kilka godzin banalną aplikację i wrzucić ją na platform as a service takie jak Heroku. Oczywiście miałem nieco ułatwione zadanie, bo na przykład SQL-a znałem zdecydowanie wcześniej. Już kilka lat wcześniej bawiłem się w tworzenie serwerów gier online, więc to był taki jeden krok, który przybliżał mnie do Backendu. Ale mimo to uważam, że tworzenie kodu z użyciem Rubiego czy Ruby on Rails to od samego początku była taka frajda i czysta przyjemność.

Po kilku tygodniach nauki skończył się czas banalnych aplikacji i zaczęło się takie modelowanie prawdziwego biznesu, rozwiązywanie problemów – i tu już tak kolorowo nie było. Natomiast myślę, że dzięki liderom, których spotkałem na swojej drodze, czyli właśnie tego, czego mi brakło przy Javie, dzięki wielu godzinom spędzonym na nauce kolejnych aspektów tego języka, udało mi się wejść na ścieżkę, na której jestem do dzisiaj. Aczkolwiek tutaj właśnie, żeby być szczerym, nie oznacza to, że Javę porzuciłem całkowicie i wracam do niej, gdy jest taka potrzeba. I nawet w ciągu ostatnich tygodni musiałem napisać pewną funkcjonalność do biblioteki, z której korzystam przy bazach grafowych, ale to jest chyba taka charakterystyka pracy programisty.

I tu się powtórzę, i możliwe, że jeszcze raz się powtórzę w trakcie całego podcastu, że powinniśmy wybierać język, który pasuje do konkretnego rozwiązania, a nie taki, który zawsze znamy najlepiej. I myślę, że to też miało bardzo dobry wpływ na mój rozwój, że gdzieś pomiędzy tymi technologiami  lawirowałem w całej tej historii. I ogólnie uważam, że dużym błędem, który popełniają młodzi programiści – może to zabrzmi tak, jakbym chciał komuś przekazać jakąś dobrą radę, ale myślę, że to jest taka dosyć istotna informacja, że młodzi programiści popełniają taki błąd, że wybierają język, który był na studiach albo który był w ich historii. Natomiast to jest takie pozorne poczucie, że już znamy ten język i że będzie zdecydowanie łatwiej. A prawda jest jednak taka, że język, który poznajemy na studiach czy w szkole, to coś zupełnie innego niż komercyjne zastosowanie tej technologii i powinniśmy raczej wybierać technologię, która nas cieszy, daje poczucie spełnienia i po prostu będzie nam się z nią dobrze pracowało przez lata, a nie taką, w której się już dobrze czujemy w tym momencie i jest okej na tym etapie.

Tak, zabawne, że wspomniałeś o testach, o RSpecu, czyli takim rozwiązaniu właśnie do pisania testów w Rubim, bo mnie z kolei to urzekło też od samego początku kontaktu z frameworkiem, z językiem również, jak duże jest nastawienie, jak duże jest, powiedziałbym nawet, wymaganie na pisanie testów, a jednocześnie jak łatwo jest to robić w tym ekosystemie. To wręcz motywuje do tego, żeby te testy pisać. Ja przy tym pierwszym kontakcie już konkretnie z Railsami byłem zdziwiony, jak bardzo pełny jest ten ekosystem, jak bardzo stawia od samego początku już na wszystkie istotne elementy, które wcześniej były mocno opcjonalne, przynajmniej z mojego doświadczenia.

Ty dokonałeś tego shiftu z aplikacji mobilnych na webowe. Ja od samego początku programowałem aplikacje webowe i miałem kilkuletnią przygodę również z aplikacjami mobilnymi na iOS-a. I to jest, myślę, bardzo ważna rzecz, którą powiedziałeś, że ta produktywność, jaka jest w samym Rubim, i to, że szybko widzisz rezultaty, jak bardzo to jest porównywalne do tego pisania aplikacji na rozwiązania mobilne, gdzie też bardzo szybko widzisz efekt swojej pracy. I jak to jest istotne, żeby ta pętla w ogóle istniała, bo to motywuje Cię do dalszej pracy.

Jest tu pewne rozróżnienie od takich dużych, enterprise’owych rozwiązań, gdzie albo odtworzysz bardzo mały fragmencik i tego w ogóle nie widzisz, albo musisz faktycznie tego boilerplate’owego kodu dużo napisać, żeby zobaczyć rezultaty. Jak bardzo to zmniejsza naszą radość z pisania kodu. Ruby mocno stawia na developer experience. Jest to język interpretowalny, który ten paradygmat obiektowy ma jednak na pierwszym miejscu, i dzięki temu, myślę, też ten developer experience może być na dosyć wysokim poziomie. Developer experience, czyli zadbanie o to, żeby programista miał ten przysłowiowy uśmiech na twarzy pisząc kod.

Chcę Cię teraz zapytać, w czym to zadbanie o dewelopera się w Rubim najbardziej przejawia.

Autor Rubiego czy twórca Rubiego, Matz, kiedyś powiedział, że chciałby zobaczyć, że Ruby pomaga programistom na świecie być produktywnym, cieszyć się z programowania i być szczęśliwym. I to jest główny powód istnienia Rubiego. I powiem szczerze, myślę, że to zdanie bardzo dużo mówi o charakterystyce tego języka oraz o kierunku wytyczanym przez core team i dokładnie potwierdza to, co powiedziałeś. Natomiast w czym to się objawia? Przede wszystkim ten język jest czytelny i tworzenie kodu często wygląda jak pisanie zdań językiem naturalnym po angielsku. I to naprawdę czuć podczas pierwszego spotkania z językiem, i to też sprawia, że my wchodzimy na taki trochę wyższy poziom – nie chcę, żeby to tak zabrzmiało – ale taki wyższy poziom programowania, że my piszemy bardzo naturalnie.

Ten kod, który tworzymy, tak po prostu wychodzi z naszych palców, wychodzi z naszej głowy, a nie musimy myśleć: „Okej, to czego tutaj użyć?”. Musimy to znaleźć w dokumentacji, ponieważ nie wiemy, jak to się dokładnie nazywa. Tutaj jest to bardzo naturalne i myślę, że bardzo, bardzo szybko można napisać pewne fragmenty kodu. Myślę też, że bardzo przełomowe w takim myśleniu o developer experience jest podejście i łatwość podejścia do metaprogramowania w Rubym. Wykorzystanie siły drzemiącej w tej technice jest też bardzo ważne i podczas rozwoju w Rubym to otwiera zupełnie nowe drzwi i można myśleć o tym programowaniu w zupełnie inny sposób, można pisać kod w zupełnie inny sposób. I to znowu jest przyjemne. To nie jest tak, że my się musimy męczyć, żeby to zrobić, tylko to jest przyjemne samo w sobie.

Natomiast to, co ja bardzo cenię w Rubim, w świecie Rubiego, to jest ekosystem i takie ogólne podejście, żeby ułatwiać życie deweloperowi, bo to nie jest tylko tak, że sam język działa w ten sposób, sam język tak wygląda. Ale też widać, że wszyscy programiści Rubiego trochę mają takie podejście, żeby jak najbardziej ułatwić to życie innym programistom, ale też żeby używanie ich narzędzi było proste, fajne, nieskomplikowane. I właśnie widać, że Matz zapoczątkował takie podejście. Ono zostało zaadoptowane przez core team, potem przez community, a teraz tak naprawdę przez większość open-source’owego świata w Rubim. I myślę, że pomijając wszelkie aspekty techniczne czy biznesowe, to jest jedna z najistotniejszych cech Rubiego.

Tak, zdecydowanie, tak jak powiedziałeś, przy pierwszym kontakcie to jest coś, co zdecydowanie się wyróżnia i bardzo trudno jest później przeskoczyć do tych języków, które tego nie mają. Wydaje się, że to jest tak naturalne i powinno być w każdym języku. Człowiek bardzo szybko się do tego przyzwyczaja.

Dokładnie.

Okej, jest to świetny kawałek technologii, ale wiadomo, że żadna technologia bez konkretnych zastosowań, bez konkretnych aplikacji w biznesie po prostu nie przetrwa zwyczajnie. Więc teraz pytanie, gdzie są te obszary zastosowań? Kto używa najczęściej albo w jakich obszarach najczęściej się wykorzystuje właśnie język Ruby?

Oczywiście najpopularniejszym użyciem Rubiego są aplikacje webowe razem z użyciem Railsów czy innych bibliotek, ponieważ tych bibliotek, tych frameworków oprócz Railsów trochę jest. Z takich mniej znanych, aczkolwiek możliwych innych zastosowań, są biblioteki do tworzenia gier 2D, ale również do tworzenia cross-platformowych aplikacji mobilnych i to jest coś, co znowu mnie w pewnym momencie urzekło w Rubym, ponieważ miałem taki mały powrót do aplikacji mobilnych i dało się bardzo fajne rzeczy stworzyć w narzędziu, które się nazywa RubyMotion akurat w tym wypadku. Także zastosowań jest naprawdę wiele, jednak, tak jak powiedziałem, zdecydowanie najpopularniejszymi są aplikacje webowe, gdzie Railsy to faktycznie najczęściej wspominana biblioteka w kontekście Rubiego. I tak jak wspomniałem wcześniej, nie bez powodu tacy gracze jak GitHub, Shopify, Airbnb czy Twitter zaufali tej technologii.

Oczywiście najpopularniejszym użyciem Rubiego są aplikacje webowe razem z użyciem Railsów czy innych bibliotek, ponieważ tych bibliotek, tych frameworków oprócz Railsów trochę jest. Z takich mniej znanych, aczkolwiek możliwych innych zastosowań, są biblioteki do tworzenia gier 2D, ale również do tworzenia cross-platformowych aplikacji mobilnych i to jest coś, co znowu mnie w pewnym momencie urzekło w Rubym, ponieważ miałem taki mały powrót do aplikacji mobilnych i dało się bardzo fajne rzeczy stworzyć w narzędziu, które się nazywa RubyMotion akurat w tym wypadku. 

Drugie miejsce to zdecydowanie aplikacje mobilne, gdzie właśnie RubyMotion ma na swojej stronie listing klientów, którzy korzystają z ich narzędzia, którzy tworzą aplikacje z użyciem ich narzędzia. Także widać, że to też nie jest takie martwe narzędzie, martwa technologia, tylko widać, że to się ciągle rozwija i gdzieś jest to używane w Internecie. Z takich bardziej alternatywnych zastosowań, to jakiś czas temu słyszałem, że choćby takie narzędzia jak Capistrano, które jest napisane w Rubym, ma lub miało zastosowanie w innych językach, takich jak C Sharp, jak PHP do deploymentu aplikacji. Więc widać, że nawet w innych językach ten skryptowy język jest wykorzystywany czy narzędzia napisane z wykorzystaniem tego języka.

Najczęściej z Rubiego i Railsów korzystają startupy i młode firmy, i to nie ulega wątpliwości. Po prostu są to firmy, które muszą szybko uzyskać efekty swojej pracy. Natomiast nie tylko, znam wiele firm, oprócz tych, które wspomniałem wcześniej, które korzystają z tego stacku technologicznego i tworzą naprawdę skomplikowane i long-termowe projekty, i nie myślą (przynajmniej jeszcze) o zmianie technologii na zupełnie inną. Jak zawsze, nie ma konkretnej odpowiedzi na to pytanie. Natomiast faktycznie kluczowym aspektem jest szybkość dostarczania efektów pracy i gdy takie hasło pojawia się podczas rozważań technologicznych, to na pewno zaraz potem pada hasło: Ruby czy Ruby on Rails.

Język to jest oczywiście ważna rzecz, żeby był praktyczny, wydajny, żeby dawał radość z programowania. Zastosowania biznesowe to jest kolejna rzecz, ale do tego dochodzi cały narzędziownik, cały ten toolbox z różnymi rzeczami, bez których ciężko byłoby w dzisiejszych czasach tworzyć jakiekolwiek oprogramowanie. Co możesz powiedzieć o ogólnie rozumianych narzędziach, bibliotekach, frameworkach i IDE – wszystkiego tego wokoło Rubiego, co na co dzień wykorzystują programiści, by tworzyć realne rozwiązania?

Community jest naprawdę duże i produktywne, dlatego nie możemy narzekać na brak jakiegoś narzędzia. Zaczynając od największych, czyli od frameworków, to mamy przede wszystkim Railsy, o których już wspominałem, ale jest również Hanami czy Trailblazer, które stawiają na nieco inne podejście do tworzenia aplikacji webowych w Rubym. Mamy też kilka mikroframeworków, takich jak Sinatra czy Roda, jednak powiedziałbym, że ich zastosowanie jest nieco mniej uniwersalne i na pewno nie polecałbym początkującym programistom rzucać się na te narzędzia. To ma dosyć specyficzne zastosowania i czasami jesteśmy w stanie uzyskać zdecydowanie lepszą wydajność na przykład, używając takich narzędzi, ponieważ nie mamy całej tej otoczki, tej dużej ilości narzędzi, które są w środku zaadoptowane. Natomiast myślę, że to mimo wszystko są nieco bardziej skomplikowane narzędzia na samym początku drogi.

Oprócz wielu przydatnych bibliotek, które praktycznie zawsze się znajdą, gdy musimy rozwiązać jakiś problem, mamy też sporo rodzimego toolsetu, że tak to nazwę, albo przynajmniej takiego, który został zapoczątkowany przez naszych rodaków i jest to między innymi Ruby Object Mapper, który został stworzony przez Piotrka Solnicę oraz cała rodzina gemów dry-rb, między innymi dry container, dry monads. Co ciekawe, Piotrek Solnica, czyli osoba, która stworzyła Ruby Object Mapper, jest zasłużonym programistom w świecie Rubiego i dostał Ruby Prize w 2017 roku jako osoba, która zrobiła najwięcej w tym roku dla języka, także to też jest bardzo fajna informacja. Widać jakie to community, też w Polsce, jest prężne.

Oprócz tych wszystkich narzędzi muszę też wspomnieć o świetnym toolingu do testowania, między innymi gem Mutant, który pozwala na testowanie mutacyjne, świetna implementacja GraphQL-a oraz Ruby Event Store, który pozwala na wdrożenie Event Sourcingu w naszych aplikacjach. Jak teraz o tym myślę, to mamy naprawdę świetny zbiór narzędzi na każdą potrzebę i to nie jest tak, że musimy bardzo dużo robić, by te narzędzia wdrożyć do naszych aplikacji. Bardzo często jest tak, że dodajemy gema, konfigurujemy go w odpowiedni sposób, a następnie on sam z siebie zaczyna działać i to jest naprawdę świetne w naszym ekosystemie.

Jeśli chodzi o IDE, to przyznaję, że sam korzystam tylko z Visual Studio Code, wcześniej korzystałem a Sublime’a, z Atoma, różne były tam historie. Natomiast praktycznie do każdego najprostszego edytora tekstu mamy wtyczki usprawniające pracę z Rubym. Mamy też RubyMine od JetBrains. Jak ktoś programuje w Javie, to będzie kojarzył IntelliJ i to jest to samo, tylko że, można powiedzieć, taka nakładka na Ruby. Jest to taki kombajn, który ma w sobie wszystko, czego możemy potrzebować, a nawet zdecydowanie więcej i są tam też narzędzia, z których nigdy nie skorzystamy prawdopodobnie. Więc myślę, że można powiedzieć, że każdy znajdzie coś dla siebie, tak żeby biblioteki czy IDE najbardziej pasowały do naszego stylu programowania.

Tak, ten ekosystem jest bardzo dojrzały. Gemy, czyli biblioteki, rozszerzenia do tego ekosystemu, są na tyle szerokie, że praktycznie do każdego problemu, który mamy, jesteśmy w stanie znaleźć gem, którzy przynajmniej będzie przydatny. Przez tyle lat rozwoju faktycznie ten ekosystem pokrył większość zastosowań i problemów, z którymi się w takim codziennym programowaniu spotykamy. Ja używałem przez wiele lat Vima również do programowania tak na co dzień w Rubim i tam też jest naprawdę wiele różnych rozszerzeń, które idealnie się do tego nadają, więc ten ekosystem jest naprawdę bogaty i pełny.

Powiedziałeś, że Ruby on Rails, najbardziej popularny framework webowy, który bardzo często jest wymieniany jednym tchem, gdy mówimy o Rubym, niektórzy wręcz mylą te dwie rzeczy, nic dziwnego, w nazwie faktycznie można się łatwo pomylić. Zgadzam się i absolutnie potwierdzam to, że wiele startupów, które mają jakiś pomysł na to, żeby wystartować z biznesem, chcą zwalidować ten pomysł, wybierają właśnie tę technologię, żeby stworzyć tak zwane MVP (Minimal Viable Product), czyli coś, co jest już jakąś namiastką finalnego produktu i co umożliwia wypuszczenie tego na rynek i zwalidowanie tego pomysłu. Więc wybierany jest framework właśnie przez tego typu firmy.

To nie jest do końca całość możliwych zastosowań, ponieważ istnieją też całkiem duże aplikacje, które tutaj wymieniłeś. Dodałbym do tego jeszcze, że Pepsi na przykład również wykorzystuje Ruby on Rails w wielu zastosowaniach. To nie pokrywa nam całości rynku. Natomiast jest jeszcze, można powiedzieć, taka niechlubna łatka, która przylgnęła trochę do języka, związana z wydajnością. Oczywiście można argumentować, że to jest coś kosztem czegoś. Ta przyjemność w pisaniu kodu musi iść z jakimś kosztem związanym z wydajnością. Czy musi, czy nie musi, o tym za chwilę sobie porozmawiamy, ale chciałby Cię zapytać, czy to nadal jest issue, problem związany z językiem, ta wydajność, i czy ten nowy Ruby 3, Ruby 3.1, jest game changerem w tym aspekcie?

I tutaj dochodzimy do momentu, kiedy opowiemy sobie o fajnych nowościach w Rubim, które do nas przyszły. Natomiast zacznę od jeszcze jednej rzeczy, o której wspomniałeś. Ja mam taką jedną zasadę podczas analizowania różnych języków i wybierania też języka czy narzędzia do konkretnego produktu czy pomysłu biznesowego, że to raczej nie język jest powolny lecz nasz kod. I oczywiście nie można tego traktować dosłownie, wiadomo, że są jedne języki, które zdecydowanie lepiej radzą sobie z procesowaniem danych. Są inne, które lepiej radzą sobie z wielowątkowością.

Ja mam taką jedną zasadę podczas analizowania różnych języków i wybierania też języka czy narzędzia do konkretnego produktu czy pomysłu biznesowego, że to raczej nie język jest powolny lecz nasz kod. I oczywiście nie można tego traktować dosłownie, wiadomo, że są jedne języki, które zdecydowanie lepiej radzą sobie z procesowaniem danych. Są inne, które lepiej radzą sobie z wielowątkowością. 

Natomiast kluczem jest to, że rzadko zdarza się – nie mówię, że nigdy, ale rzadko zdarza się, że język jest wąskim gardłem naszej aplikacji. Częściej jest to nasz kod, nasz pomysł na implementację albo nasza nieznajomość lepszych mechanizmów do rozwiązywania pewnych problemów. Nawet znajomy kiedyś powiedział mi taką fajną rzecz, że wiele biznesów nie odczułoby problemów z wydajnością, gdyby nie Ruby i Railsy, bo te firmy upadłyby, zanim ich produkty zdążyłyby zdobyć dość rynku, ponieważ tak szybko dostarczyli swój produkt, że dopiero odczuli faktycznie te problemy.

Natomiast żeby być obiektywnym albo przynajmniej podejmę próbę bycia obiektywnym, Ruby i Ruby on Rails faktycznie miały przez długi czas pewne problemy związane z wydajnością. Od paru lat trwają prace nad usprawnianiem działania pewnych elementów. Między innymi Matz założył sobie, że Ruby 3 będzie trzykrotnie szybszy niż Ruby w wersji 2.0. Czy mu się to udało? Odpowiem, że moim zdaniem tak, chociaż różne są opinie w Internecie, natomiast na pewno Ruby przyspieszył w wersji 3, porównując do wersji 2.0. Ale tak naprawdę to tylko jeden element całej układanki.

Drugim elementem, który został wprowadzony, jest uchylenie sobie drzwi na asynchroniczną pracę Rubiego. Jest taka biblioteka, która nazywa się Async i która wraz z dodaniem tak zwanego fiber schedulera do Ruby w wersji 3 otwiera sobie drogę do tworzenia nadal prostego i czytelnego kodu, ale tym razem uzyskując całkiem niezłą współbieżność bez żadnego wysiłku. I świetnym rzeczywistym przykładem tego podejścia i benefitów z tym związanych jest historia z Airbnb. Znalazłem ją kilka tygodni temu, zdaje się na Reddicie, gdzie jakiś programista pisał o tym, że po wdrożeniu wyżej wymienionych mechanizmów udało się zredukować zasoby dla jednej z usług o 85% przy braku efektów ubocznych.

I jak zawsze może być on nieco przekłamany, może to nie być reguła, widać pewien kierunek rozwoju i ścieżkę obraną przez cały core team, ale także przez twórców Railsów, że wszyscy idą w kierunku poprawienia tego performance’u. Nie mówię, że nagle z dnia na dzień ten język będzie bardzo szybki i nagle wyprzedzi wszystkie inne pod kątem performance’u, ale tak jak powiedziałeś, mając tę radość z programowania, możliwość tworzenia szybko produktów, dostajemy całkiem niezły performance, który się ciągle poprawia, to na pewno jest to taka droga, którą warto iść i która z biegiem lat będzie coraz lepiej wyglądała.

Kontynuując ten wątek, jakie w Twojej opinii są największe problemy, braki, z którymi się obecnie mierzy Ruby? Co Ty w nim lubisz, a czego nie?

Największym brakiem jest wciąż współbieżność. I to też jest kwestia, która sprawiła, że Jose Valim stworzył Elixira. Nawiasem, zachęcam każdego do przesłuchania odcinka podcastu o Elixirze, świetny materiał.

Dziękuję.

Mimo że ciągle trwają prace nad tym aspektem, to jednak daleko Rubiemu do wspomnianego Elixira. To są dwa różne światy, dwa różne podejścia. I właśnie w tym podcaście też było powiedziane, że dużo ludzi mówi, że tak łatwo jest przejść z Rubiego na Elixir, ale to też tak do końca nie wygląda. To są dwa zupełnie różne style programowania i też dwa zupełnie różne problemy, które można rozwiązać za pomocą tych języków, takie odnoszę wrażenie.

To jest taki największy brak, natomiast to, czego ja najbardziej nie lubię w Rubim, to chyba są Railsy. [śmiech] Uważam, że brakuje naprawdę dobrych i kompleksowych alternatyw dla Railsów. Choć mamy Hanami, mamy rodzinę gemów dry-rb, mamy Ruby Object Mappera, to wciąż między nimi widać różnicę, jeśli nawet nie przepaść, i ona wynika prawdopodobnie z tego, że Railsy są rozwijane przez dużą grupę deweloperów przy współpracy nad produktem firmy Basecamp. Natomiast wyżej wymienione narzędzia to praca dodatkowa wielu programistów na całym świecie i jednak to zawsze będzie drobna różnica.

Nie lubię ich dlatego, że Railsy wprowadzają swoistą magię w programowaniu. To jest trochę tak, że ja wolę, gdy widzimy, że kod, który napisaliśmy, coś robi, niż tego kodu nie widać i to się dzieje gdzieś pod spodem. Jest taka magia, pewne automatyzmy, które dzieją się pod spodem w kodzie, nie jesteśmy tego świadomi. Natomiast mimo wszystko trzeba pamiętać, że tworząc oprogramowanie, tworzymy je by spełnić czyjeś założenia dotyczące biznesu i Railsy nadają się tutaj bardzo dobrze i spełniają swoje zadanie, dlatego nie odsuwam tego narzędzia, a co najwyżej trochę mniej je lubię niż sam język.

Natomiast rzeczy, które na pewno lubię – i tutaj znowu się będę powtarzał – jest to community, wyżej wymienione narzędzia i sam język. Teraz po kilku latach, gdy muszę napisać coś w innym języku albo gdy po prostu jest taka potrzeba, to czuję taką nutkę podekscytowania. Takie małe wyzwanie, że wchodzę znowu w jakiś inny świat. Natomiast wracając potem do Rubiego, czuję, że to język, w którym czuję się naprawdę dobrze i dobrze się z nim pracuje i chcę tutaj zostać na dłużej.

Jasne, community to jest też istotny element sukcesu Rubiego, to, że ludzie wzajemnie sobie pomagają, że chcą się dzielić tą wiedzą. To jest też coś, co robicie w Monterail, prawda? Tam też się zajmujecie między innymi edukowaniem w tematach związanych z Rubim. Jak Ty oceniasz to community języka Ruby u nas w kraju, za granicą?

Niestety, można powiedzieć, że Covid troszeczkę namieszał, jeśli chodzi o community. Wcześniej wyglądało to nieco lepiej. Każde większe miasto w Polsce, zaczniemy od Polski, miało swój meetup. I te meetupy nadal są powoli odpalane z powrotem, natomiast jeszcze jest potrzebna taka długa droga, żeby to wszystko zaczęło działać tak, jak kiedyś. Wcześniej był również GrillRB, wroc_love.rb, Nerds on lakes – pewnie jeszcze parę innych inicjatyw by się znalazło. I to były naprawdę duże inicjatywy, które w Polsce cieszyły się dosyć fajną popularnością.

Natomiast na świecie jest masa konferencji, nawet zdalnych, gdzie najpopularniejszą w Europie zdaje się jest EuRuKo, natomiast na świecie jest to RubyConf i RailsConf. Ale jest też masa konferencji o różnym targecie w niemal każdym kraju na świecie od Ameryki Północnej, Południowej, przez Ukrainę, Rosję i oczywiście po kolebkę Rubiego, czyli Azję. Jest tego naprawdę dużo i gdy tylko wpiszemy sobie nawet na YouTubie: „konferencja Ruby”, to od razu wyskoczy nam naprawdę duża lista z ostatnich lat bardzo fajnych konferencji, które dzieją się na całym świecie.

Edukacja to temat, który musiałbym opowiedzieć nieco historycznie, ponieważ osobiście uczyłem się kilka ładnych lat temu Rubiego za pomocą Rails for Zombies – możliwe, że ktoś jeszcze pamięta te zamierzchłe czasy. Wtedy ciężko było dostać dobre kursy, książki do języka czy frameworka i tak naprawdę można było złapać podstawy za pomocą takich wideokursów, ale potem należało dużo czytać i pisać na własną rękę z pomocą dokumentacji, a bardzo często dokumentacji w narzędziach brakowało i trzeba było zaglądać do testów i analizować, co się w tych testach dzieje, żeby zrozumieć, jak działa dane narzędzie. Możliwe, że to też jest dobra droga do nauki języka.

Teraz mamy naprawdę dużo materiałów, z których można wyciągnąć esencję, jak i coraz więcej inicjatyw pozwalających na dzielenie się wiedzą. Na przykład w Polsce jest organizowany Rails Girls, które też organizowaliśmy w Monterail parę lat temu. Jest to taka inicjatywa, gdzie w jeden weekend można się nauczyć, jak zbudować proste aplikacje w Rubim, w Railsach za pomocą mentorów z całej Polski. Także jest to znowu bardzo fajna inicjatywa, gdzie w jeden weekend, nie mówię że można się nauczyć super profesjonalnie programować, ale można poczuć siłę drzemiącą w tym języku, to też jest mega istotne.

W zeszłym roku w Monterail zorganizowaliśmy również dwa Bootcampy w Rubim, natomiast myślę, że nie powinny one być kojarzone dosłownie z Bootcampami, gdzie uczymy się z syntaxa języka. Były to inicjatywy nakierowane na naukę praktycznego podejścia do programowania poprzez poznawanie narzędzi, różnych podejść, styli architektonicznych, ale również albo może przede wszystkim, rozwiązywania realnych biznesowych problemów. Przez te dwie edycje wyedukowaliśmy 15 osób, które są na naprawdę fajnym poziomie i pracują w komercyjnych projektach. I wydaje mi się, że jest to jedna z lepszych możliwości rozpoczęcia swojej przygody z programowaniem, a dla nas jako dla firmy była to efektywna możliwość zapełnienia braków na rynku pracy.

Obecnie organizujemy również Bootcampy dotyczące Vue.js. Myślę że ogólnie community jest dosyć pomoce i niehermetyczne. To jest bardzo ważne, bo widać, że dzielenie się wiedzą jest w programistach Rubiego zakorzenione i gdy ktoś naprawdę chce zacząć swoją przygodę z programowaniem, to może dostać bardzo, bardzo dużo pomocy od swoich kolegów czy koleżanek.

Powiedziałeś tutaj o rynku pracy, który w szeroko rozumianym IT jest trudne na dziś, tego nie da się ukryć. Natomiast jak to wygląda w przypadku Ruby Developerów, jak jest z ofertami pracy, z ich ilością, z wynagrodzeniem. Jak mógłbyś ten rynek pracy podsumować?

Znowu nieco historycznie, stawki w Rubim zawsze wyglądały dosyć dobrze. Może nie można się było nigdy porównywać z ofertami na przykład dla Golang Developerów, ale Ruby był zawsze w okolicy średniej z innych technologii. Sytuacja z koronawirusem podniosła stawki i znowu nieco namieszała. Obecnie widełki są na bardzo konkurencyjnym poziomie względem najpopularniejszych technologii i widać tutaj zmiany od już od prawie 3 lat, czyli to jeszcze nawet przed koronawirusem widać było taki trend wzrostowy.

To, co nieco martwi, chociaż nie wiem, czy to jest charakterystyczna cecha Rubiego, czy po prostu w całym świecie programowania jest taki trend, to fakt, że coraz rzadziej spotykane są oferty pracy dla Juniorów. Nie jestem pewny, z czego to wynika. Sam rekrutowałem często naprawdę dobrych, utalentowanych Juniorów w przeszłości, ale może być to charakterystyka aktualnych czasów, że firmy zawsze szukają doświadczonych programistów, a tych początkujących nieco rzadziej. Nawet był taki żart parę lat temu, zdaje się o Elmie, że gdy język istniał 2 czy 3 lata to były oferty pracy szukające programistów z 5-letnim doświadczeniem. Komiczne, ale niestety zdarzają się takie sytuacje.

Coraz rzadziej spotykane są oferty pracy dla Juniorów. Nie jestem pewny, z czego to wynika. Sam rekrutowałem często naprawdę dobrych, utalentowanych Juniorów w przeszłości, ale może być to charakterystyka aktualnych czasów, że firmy zawsze szukają doświadczonych programistów, a tych początkujących nieco rzadziej. Nawet był taki żart parę lat temu, zdaje się o Elmie, że gdy język istniał 2 czy 3 lata to były oferty pracy szukające programistów z 5-letnim doświadczeniem. Komiczne, ale niestety zdarzają się takie sytuacje.

Natomiast charakterystyczną cechą w Rubim, a jednocześnie problemem dla kogoś, kto jest odpowiedzialny również za rekrutację, jest fakt, że ciężko pozyskać kogoś doświadczonego. Deweloperzy, którzy nie są super aktywni w sieci, mają tylko profil na LinkedInie, dostają po kilka ofert tygodniowo, a osoby, które są naprawdę aktywne w community, mogą dosłownie przebierać w fajnych ofertach. To tylko pokazuje, jakie jest zapotrzebowanie na programistów Rubiego, jednocześnie trochę pokazuje, jakie jest tutaj błędne koło.

Rodzi się pytanie, czy to jest dobry język na start, czy warto zaczynać swoją przygodę z programowaniem od języka Ruby?

Nie wiem, czy mogę odpowiedzieć na to pytanie obiektywnie, bo ja bardzo lubię ten język i gdybym miał powiedzieć, co mam w sercu, to powiedziałbym, że oczywiście, na start jest to świetny język, i myślę, że nie tylko na start. Natomiast myślę, że ogólnie tak podsumowując, to mając tak dużo inicjatyw i możliwości, gdzie można nauczyć się programowania w Rubim przede wszystkim, jest to mimo wszystko fajny i dosyć atrakcyjny wybór. Jednak podejmując próbę bycia obiektywnym i patrząc na swoje doświadczenie, uważam, że każdy powinien spróbować kilku języków programowania i dopiero po jakimś czasie wybrać swoją drogę.

Innymi słowy, można zacząć z Rubim jak najbardziej, bo można wtedy naprawdę polubić programowanie, jest to język przyjemny do nauki, ale uważam, że nie powinniśmy zamykać się na ten jeden wybrany język, tylko powinniśmy eksperymentować i szukać swojej drogi. To też będzie rozwijało na pewno nasze umiejętności i będzie poszerzało horyzonty.

Tak, bez dwóch zdań. Czy jesteś w stanie wobec tego polecić jakieś materiały, sposoby uczenia się, które by się sprawdziły na początku przygody z Rubim?

Myślę, że warto zacząć poznawać ten język z kursów internetowych, wideokursów i inicjatyw właśnie takich jak wspomniany wcześniej Rails Girls. To chyba takie pierwsze strzały, które dadzą najlepsze efekty na samym początku. Ja ze swojej strony mogę też polecić kilka kanałów na YouTubie, między innymi kanał mojego kolegi „Ruby po polsku”, gdzie prezentuje on nie tylko jak wygląda syntax języka, jakie są metody, ale przede wszystkim daje cenne wskazówki, jak programować i co robić krok po kroku tworząc proste aplikacje.

I dlatego też ze względu na te cenne praktyczne uwagi, polecam wszelkie inicjatywy takie jak Bootcampy, gdzie można dostać dużą dawkę wiedzy, ale przede wszystkim kontakt z innymi programistami. Myślę, że jest to jedna z bardziej efektywnych metod nauki i gdy mamy możliwość zrobienia nawet 10-minutowego programmingu, żeby rozwiązać problem, dostać naprawdę rzeczowe code review od bardziej doświadczonego programisty, to będzie zdecydowanie bardziej efektywne niż przeczytanie kilku artykułów czy też obejrzenie kilku odcinków jakiegoś wideokursu. Myślę, że warto na to zwracać szczególną uwagę.

Pewnie, nauka w praktyce jednak jest zdecydowanie zawsze bardziej efektywna, niż oglądanie mnóstwa materiałów. Jak najszybciej zanurzyć się w pisanie kodu. A to, co powiedzieliśmy na początku, czyli ten developer experience na wysokim poziomie i to, że pisze się w języku, który niekiedy przypomina wręcz język angielski, myślę, że ułatwia ten start i nie trzeba poznawać mnóstwa detali syntaxu, żeby zacząć już coś, co działa tworzyć.

Wojtek, rodzi się pytanie, co dalej, w którym kierunku ten język będzie się rozwijał. Czy osiądzie, okrzepnie w mainstreamie, czy też może będzie wypierany przez inne technologie? Jaką tutaj widzisz przyszłość dla języka, dla całego ekosystemu Rubiego?

Przede wszystkim powiedziałbym, że czas Rubiego na pewno nie przeminął. I uważam, że to niemożliwe, gdy ciągle tworzą się nowe produkty oparte o tę technologię. A prawda też jest taka, że często w Internecie słyszymy pytanie, czy Ruby jeszcze żyje w danym roku. Uważam, że jest to dobry clickbait przy wielu artykułach i ludzie często wykorzystują to do marketingu. Można znaleźć masę artykułów pytających, czy w danym roku Ruby jeszcze żyje i zapewne w ciągu kilku najbliższych tygodni pojawią kolejne artykuły mówiące o tym samym w roku 2022.

Natomiast jakie są kierunki rozwoju? Są tutaj dwie kwestie właśnie, jedna to Railsy, druga to Ruby. Jeśli chodzi o Railsy, one nadają ton w całym ekosystemie i tutaj David Heinemeier Hansson ostatnio bardzo dużo mówi o Hotwire, czyli HTML Over The Wire. Nowe podejście do tworzenia Front-Endu, do aplikacji opartych o Railsy i Hotwire wraz z Turbo i Stimulusem, czyli takimi dwoma innymi technologiami, może faktycznie zrewolucjonizować podejście do tworzenia aplikacji internetowych, szczególnie że widać tutaj duży nacisk ze strony Davida na to podejście. A co tym idzie? Na pewno będzie tutaj widoczny ciągły, stały rozwój.

Railsy już od dłuższego czasu nie szły w zgodzie z podejściem single-page applications, ale czy to będzie dobry kierunek? Jeszcze nie umiem tego ocenić. Po cichu myślę, że dzięki temu Railsy mogą przeżyć drugą młodość na rynku, ale myślę, że czas pokaże. Ciężko to w tym momencie ocenić. Widać też pewne dążenia do usprawnień współbieżności w Railsach, szczególnie zmiany w wersji 7. Ale nadal to bardzo, bardzo mały krok na drodze, którą muszą jeszcze pokonać.

Drugi aspekt to Ruby i tutaj pojawiają się wszystkie rzeczy, o których wcześniej mówiłem. Będziemy mieli na pewno ewolucyjne zmiany wynikające z potrzeb. Na pewno będzie dużo fokusu na optymalizację i wydajność. Nawet Matz mówił o tym rok czy półtora roku temu na konferencji, że chciałby, żeby Ruby 4 był znowu trzykrotnie szybszy niż Ruby 3. I on sam wie, że to są ambitne, może nierealne plany, ale widać też, że stawiają na to mocny nacisk.

Kolejna rzecz to Stripe od dłuższego czasu próbuje wypromować Sorbet, czyli narzędzie do tworzenia adnotacji i sprawdzania typowania w naszych aplikacjach. Jest RBS, który jest bardzo aktywnie rozwijany przez oficjalny zespół Rubiego i ma bardzo podobne zadania. Dodatkowo myślę, że Ruby nie przestanie działać nad właśnie współbieżnością, bo jest to atrakcyjny temat dla wielu programistów i tego samego developer experience.

Także jak widać jest wiele kierunków rozwoju, ciężko przewidzieć, co core team nam zaproponuje, ale jednego możemy być pewni, na pewno nie zrezygnują z tego, co w Rubim jest najważniejsze, czyli przyjemność z programowania. A co więcej obecny core team jest gwarantem, że przyszłość przyniesie nam bardzo, bardzo dużo dobrego.

I rozwój tych narzędzi w ekosystemie i fakt, że naprawdę wiele dużych aplikacji już zostało w tym ekosystemie napisanych, trzeba je rozwijać, trzeba je utrzymywać. To są chyba dwa najlepsze dowody na to, że Ruby w 2022 jeszcze nie umarł. Myślę, że nie raz jeszcze o nim usłyszymy. Wojciech Maciejak z firmy Monterail był moim gościem. Rozmawialiśmy właśnie o języku Ruby. Wojtku, bardzo Ci dziękuję za tę rozmowę.

Również bardzo dziękuję za zaproszenie.

Powiedz, proszę, gdzie Cię można znaleźć w Internecie? Jak się z Tobą skontaktować?

Przede wszystkim jest to LinkedIn, jestem tam najbardziej aktywny. Czasami też Twitter. Natomiast gdyby ktoś chciał poczytać artykuły, które napisałem, to zapraszam na blog firmy Monterail. Można tam czasami przeczytać coś ciekawego z mojej strony.

Super, oczywiście wszystkie linki jak zawsze będą w notatce do tego odcinka. Wojtku, jeszcze raz bardzo Ci dziękuję. Miłego dnia. Do usłyszenia. Cześć!

Miłego dnia. Bardzo dziękuję.

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Język Ruby powstał, by dawać przyjemność z pisania w nim kodu. Ta cecha oraz kompletność jego ekosystemu urzekła mnie lata temu i nadal uważam, że jest to świetny język, idealny na start i perfekcyjnie sprawdzający się tam, gdzie chcemy szybko zobaczyć efekty swojej pracy. Polecam.

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

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o języku Ruby.

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!