Ruby

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Wojciechem Maciejakiem o języku programowania Ruby.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

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.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-149-ruby/

--

--

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

Get the Medium app

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