Ruby on Rails okiem developera Javy

Grudzień 20th, 2010 · 6 Comments ·

Jakiś czas temu w mojej głowie narodził się pomysł uruchomienia nowego biznesu – hostingu narzędzi developerskich firmy Atlassian. Ja znam się na administracji tymi narzędziami oraz ich programistycznym rozszerzaniem, zaś kolega kwiat jest administratorem i sieciowcem. W taki sposób powstał AtlasHost, gdzie oferujemy na razie hosting issue trackera JIRA.

Jak to do każdego biznesu, potrzebowaliśmy jakiejś stronki z ofertą. Można było oczywiście postawić pierwszy lepszy PHP-owy CMS, ale my jesteśmy ambitni. Zdecydowaliśmy się wykonać prostą stronę, spełniającą kilka prostych założeń:

ładne URL-e dla SEO
internacjonalizacja (polski i angielski)
cennik trzymany w bazie danych
składanie zamówień, zapis w bazie
powiadomienie mailowe o nowym zamówieniu

Jak widać, jest to niewiele ponad prostą wizytówkę. Nie ma nic ciekawego w tworzeniu takiej stronki… chyba że napisze się ją w czymś nowym i nieznanym. Tylko w czym? Na kanale #graveyard na ircnecie mamy bota, który zawsze pomaga w podejmowaniu trudnych, życiowych decyzji.

<@Nowaker> ,(random-choose '(play lift grails web2py rails catalyst))
<@straganiarz> rails  ..(symbol)

Wypadło – stronka będzie napisana w Ruby on Rails. :-)

Ruby on Rails to kompletny framework

Nie można tego powiedzieć o frameworkach PHP. Nawet do najprostszych rzeczy trzeba było coś sobie dopisywać. Nigdy nie dostałem OOTB dokładnie wszystkiego, co było potrzebne – a były to dość typowe wymagania. W przypadku Ruby on Rails nie napisałem żadnego dodatkowego kodu. Zmieściłem się dokładnie w tym, co framework udostępnia.

Ekosystem Javy to całkowicie inna historia. Tutaj typowym podejściem jest budowanie całej aplikacji z klocków. Tak więc za warstwę webową odpowiada np. Apache Wicket, za bazę danych kontener EJB, a za cokolwiek innego – biblioteki zdefiniowane jako zależności. Jedyne znane mi kompletne rozwiązanie to Play Framework, które upodabnia webdevelopment w Javie do znanego z języków dynamicznych.

Ruby on Rails jest prosty

Ruby on Rails jest bardzo intuicyjny. Wszystko wykonuje się w taki sposób, w jaki sobie pomyślałem. Do dokumentacji oczywiście musiałem trochę zaglądać, ale w kilka chwil dostawałem odpowiedź na moje pytanie. Bez porównania z dokumentacją KohanaPHP – zawsze należało zaglądać do kodu źródłowego, aby dostać odpowiedź. Nie byłbym szczęśliwy, gdybym musiał zaglądać do kodu źródłowego Rails.

Rails jest prosty. Stworzenie jednej prostej strony wystarczyło mi, aby odpowiedzieć na kilka pytań na Stack Overflow. To mówi samo za siebie.

Oszczędzajmy kod

Wykonanie strony zgodnej z podanymi przeze mnie założeniami wymagało napisania ok. 250 linii kodu w języku Ruby. Gdyby odliczyć puste linie, wyszłoby pewnie z 200. Naprawdę mało, jak na podane przeze mnie wymagania. Cała reszta to widoki, pliki i18n, itp.

Podsumowanie

Rails jest idealny do robienia prostych stronek z niewielką logiką. Można powiedzieć, że nie trzeba pisać praktycznie żadnego kodu, by osiągnąć potrzebne rzeczy. Polecam zwłaszcza developerom Javy, ponieważ nasze ciężkie, korporacyjne technologie to najczęściej za dużo do prostych stronek. :-)

Każdy developer PHP powinien zaznajomić się z Ruby on Rails, a najlepiej od razu porzucić ten zły świat. Sam koszt wejścia w Rails jest minimalny. Zarówno język Ruby, jak framework Rails są proste. NetBeans zaś pomoże w poznaniu API. Ale wystarczyło mi napisanie jednego projektu, by kolejne pisać już w zwykłym edytorze tekstu.

Jeśli zaś chodzi o aplikacje internetowe (czyli nie “stronki”), to pozostaję oczywiście w Javie. Zbyt bardzo cenię sobie wykrywanie błędów jeszcze w czasie kompilacji i wielkie możliwości refaktoryzacji.

Tags: Java · PHP · Programowanie

Jest już 6 komentarzy ↓

Tomek Dziurko // gru 20, 2010 at 08:51

Twój post potwierdza moje obserwacje, że Ruby On Rails to taki naturalny następca PHP do projektów, które nie są zbyt rozbudowane i nie ma co do nich zaprzęgać nie wiadomo jakich technologii :) PHP to generalnie straszny kibel, przynajmniej w takim wykonaniu, jakie widziałem, więc RoR wydaje sie dużo przyjemniejszy :) No i widzę, że rozkręcacie własny biznes, gratuluję pomysłu i życzę powodzenia! :)
Tomasz Kowalczyk // gru 20, 2010 at 13:33

Aj, znowu będziecie psioczyć na PHP. ;] Nie wiem, jak Wy, ale ja po zobaczeniu nawet nie samego Railsów, ale zwyczajnej składni Ruby’ego, stwierdziłem, że wolę jednak coś może gorszego funkcjonalnie, ale przynajmniej “ludzkiego”. Jeszcze nie jestem aż tak zdesperowany, żeby się przesiadać na BrainFucka.
Konrad Starzyk // gru 20, 2010 at 22:59

A ja z kolei polecam Grails dokładnie z tych powodów, o których piszesz. Dla developera Javy jest to chyba jeszcze przyjemniejsza przesiadka, bo może wykorzystywać wiedzę, którą już ma (Spring i Hibernate). Do tego przyjemny dostęp do bazy (podobny do Active Record, choć uczciwie przyznaję, że z RoR nie korzystałem). Jednocześnie Groovy pozwala oszczędzić sporo pisania. Chyba nigdy nie zauważyłem tak szybkiego wzrostu produktywności jak po przesiadce na Grails.
Zyx // sty 22, 2011 at 09:45
Grrr, Ruby On Rails. Miałem z tym raz do czynienia jakiś rok temu i powiedziałem: nigdy więcej.

“Ruby on Rails to kompletny framework… a frameworki PHP nie.” – nie wiem, kiedy ostatnio programowałeś w PHP, ale ja zasiadając do Rubiego odniosłem dokładnie odwrotne wrażenie. Scaffolding był tak biedny, że musiałem mnóstwo czasu poświęcić na dostosowanie każdego (!) wygenerowanego kawałka kodu, by w ogóle mógł być używalny nawet przez programistę. Próba zmodularyzowania szablonów zajęła mi dobre pół dnia, zanim doszedłem, co i jak.

Do tego dochodziły problemy z obsługą Unikodu (no rany… jak można wypuścić rzekomo stabilną wersję, w której sypie się to totalnie i z rozbrajającą szczerością przyznać “no tak, jest błąd w Active Record, sorry, polskich liter sobie nie użyjesz”) i z kompatybilnością z wersjami Rubiego. Wprawdzie później dowiedziałem się, że ponoć trafiłem na najgorszy możliwy okres, ale jednak niesmak pozostał.

Jednak najbardziej nie polubiłem założeń projektowych:
- Active Record próbuje sam odtwarzać połowę funkcjonalności systemów zarządzania bazą danych, co uważam za totalną głupotę,
- wszechobecna magia,
- całkowite wypaczenie wzorca MVC. Wystarczy spojrzeć na dokumentację RoR oraz na oryginalne (tzn. nienapisane przez ludzi tworzących strony WWW) definicje tego wzorca, by zauważyć, że jedno ma się do drugiego, jak pięść do nosa. To, że coś sobie nazwiemy “Modelem”, “Widokiem” i “Kontrolerem” nie znaczy, że powstaje nam od razu z tego MVC. Wzorzec używany w RoR ma swoją własną nazwę: “Model-View-Presenter with Passive Views” i nie wolno go mylić z oryginalnym MVC, z którego wprawdzie się wywodzi, ale jednak działa inaczej.
Szymon Jeż // lut 14, 2011 at 20:24
Ciekawe podejście do podejmowania technicznych decyzji. Do tego w oryginalny sposób – botem IRC. Skoro padło na rozwiązania w Ruby to polecam na przyszłość: ruby -e ‘frameworks = %w{Play Lift Grails Web2py Rails Catalyst}; puts frameworks[rand(frameworks.size)]‘ ;-)

Wracając do meritum – ogólnie się zgadzam. Czepię się tylko dwóch rzeczy:
- Skoro coś wymaga pisania małej ilości kodu, to dlaczego sprowadzać to odrazy do czegoś do pisania “stronek”? Mało jest poważnych projektów opartych o Ruby i Railsy, które temu pierwszemu/pobieżnemu wrażeniu zaprzeczają?
- To, że coś jest proste to zaleta nie implikująca tego czegoś prostactwa czy niedojrzałości. Jasne cool jest robić coś skomplikowanego, bo wygląda groźnie i łatwo zaimponować ;-)
Jak zawsze wszystko można sprowadzić do: “używaj tego narzędzia, które się do danej rzeczy tobie najlepiej nadaje” (truizm) Nie pisał bym w Ruby softu do elektrowni atomowej, ale do 80% rzeczy (server side) tego świata się dla mnie nadaje.

“Zbyt bardzo cenię sobie wykrywanie błędów jeszcze w czasie kompilacji” powinno być NIEKTÓRYCH rodzajów błędów ;-) IMHO testy jednostkowe dają dużo więcej albo co najmniej to (analizę statyczną) równoważą.
Seban // kwi 25, 2011 at 12:42

Od wykrywania błędów masz testy automatyczne :)

#!/bin/nwkr devblog