Dlaczego Ruby on Rails jest wyjątkowy?

Opublikowane przez Jarosław Zabiełło Sun, 14 May 2006 04:22:00 GMT

Niektórym osobom stykającym się z po raz pierwszy z Railsami wydaje się, że jest to tylko jakieś kolejne, tradycyjne środowisko developerskie pracujące wg wzorca projektowego MVC (model-widok-kontroler). Przywiązani do swoich języków i frameworków czasami się dziwią, dlaczego temat Railsów wywołuje od jakiegoś czasu tyle emocji i komentarzy. Na pewno po częsci jest tak pewnie dlatego, że RoR jest bardzo dobrze wypromowany. Dobra strona główna, dobra dokumentacja, książki, filmy, bardzo aktywna społeczność – nic tylko naśladować. Z drugiej strony, trzeba też przyznać, że jest to środowisko świetnie zaprojektowane – w Railsach sie pracuje po prostu komfortowo.

Nie dziwią więc ciągłe próby naśladowania Railsów w innych językach (PHP, Python, Java, C# itp) Jednakże między nimi a Railsami będzie ciągle pewna, trudna do osiągnięcia, jeśli nie w ogóle niemożliwa – bariera. Railsy posiadają nie tylko wszystko, co potrzeba do bardzo produktywnego tworzenia aplikacji internetowych, ale są przy tym równocześnie bardzo eleganckie i czytelne. Eleganckie i czytelne czyli łatwe do nauki. Tak, nauka Rubiego nie jest przeszkodą. Przekona się o tym każdy, kto trochę bliżej przyjrzy się jak działa RoR.

Miałem okazję porównywać ze sobą kilka różnych frameworków. Gdy chciałem przekonać się do któregoś z nich, zawsze ostatecznie wracałem z powrotem do RoR. Po prostu żaden z nich nie jest jak elegancki i prosty w użyciu1. Co jest główną przyczyną takiego wrażenia? Twórca Railsów, David Heinemeier Hansson powiedział kiedyś, że gdyby nie Ruby to nie powstałby Ruby on Rails. Powiedział także, że uważa iż w żadnym innym języku nie da się napisać tak eleganckiego i pięknego kodu. Zatem można powiedzieć, że prawdziwą siłą Railsów jest Ruby. Razem tworzą nierozłączną parę i ta łączność nie dotyczy bynajmniej tylko nazwy. ;) Ruby posiada bowiem pewne unikalne cechy, które pozwoliły stworzyć RoR w postaci, która jest raczej mało nieosiągalna dla innych języków. Już to wyjaśniam.

Panuje powszechnie mniemanie, że Ruby to połączenie cech Pythona i Perla. Ruby (podobnie jak Perl) posiada np. wbudowaną w składnię obsługe wyrażeń regularnych. Posiada także (podobnie jak Python) pełną obiektowość i bardzo elegancką, czytelną (choć nie taką samą) składnię. Pewnym odkryciem było dla mnie to, że językie, do którego Ruby ma najwięcej podobieństw to innego języka – Smalltalk. Lektura cech, filozofii (i nawet do pewnego stopnia składni) Smalltalka pokazuje zdumiewające podobieństwo do Rubiego. Można wręcz odnieść wrażenie, że Ruby to swego rodzaju przeróbka Smalltalka2. Podobieństw jest bardzo wiele. Od słów kluczowych po symbole, sposób tworzenia instancji klas, bloki kodu (ang. closures), kontynuacje3 itp. Jak ktoś jeszcze nie rozumie filozofii Rubiego, jego modelu obiektowego i powodu istnienia otwartych klas, powinien poczytać sobie trochę o Smalltalku.

Ruby jak i Smalltalk posiadają bardzo podobny model obiektowy. Wszystkie obiekty (na drodze dziedziczenia) wywodzą się z jednej, ostateczniej klasy Object. Oba języki mają zaimplementowaną pełną obiektowość. Nie ma (tak ja w Javie) podziału na prymitywy i typy referencyjne. Wszystko jest obiektem i wszystko posiada metody. Dotyczy to nie tylko liczb i napisów ale także obiektu nil, true czy false. Każdy obiekt można przeciążyć i/lub zmodyfikować wewnetrznie (dynamicznie dodając lub usuwając jego metody w trakcie pracy programu)

Z tego wynika, że właściwie to można modyfikować sam język. Daje to możliwości zupełnie nieosiągalne nawet dla tak dobrego i obiektowego języka jakim jest Python. Ruby pozwala na łatwe dodawanie nowych metod do liczb czy napisów. Pozwala na taką modyfikację samego siebie, aby optymalnie nadawał się do realizacji pewnych, specyficznych zadań. Ruby umożliwia zatem tworzenie tego, co się określa mianem języków domenowych (Domain-specific Programming Languages). Są to języki, które w przeciwieństwie do języków ogólnego zastostosowania, zostały zaprojektowane do wykonywania specyficznego zadania/zadań. Zarówno Smalltalk jak i Ruby pozwalają na tworzenie języków domenowych.

Ruby on Rails to nic innego jak framework napisany za pomocą Rubiego zmodyfikowanego w celu uzyskania wysoce produktywnego środowiska do tworzenia nowoczesnych aplikacji internetowych.

Przykładowe helpery dostępne w Rails, które korzystają z nowych metod nie będących standardową częścią Rubiego. Poniższe przykłady pochodzą z 1-g wydania książki Agile Web Development in Rails.

puts 20.bytes #=> 20
puts 20.kilobytes #=> 20480
puts 20.megabytes #=> 20971520
puts 20.gigabytes #=> 21474836480
puts 20.terabytes #=> 21990232555520
puts 20.minutes.ago #=> Tue May 10 16:43:43 CDT 2005
puts 20.hours.from_now #=> Wed May 11 13:03:43 CDT 2005
puts 20.weeks.from_now #=> Tue Sep 27 17:03:43 CDT 2005
puts 20.months.ago #=> Thu Sep 18 17:03:43 CDT 2003
now = Time.now
puts now #=> Tue May 10 17:15:59 CDT 2005
puts now.ago(3600) #=> Tue May 10 16:15:59 CDT 2005
puts now.at_beginning_of_day #=> Tue May 10 00:00:00 CDT 2005
puts now.at_beginning_of_month #=> Sun May 01 00:00:00 CDT 2005
puts now.at_beginning_of_week #=> Mon May 09 00:00:00 CDT 2005
puts now.at_beginning_of_year #=> Sat Jan 01 00:00:00 CST 2005
puts now.at_midnight #=> Tue May 10 00:00:00 CDT 2005
puts now.change(:hour => 13) #=> Tue May 10 13:00:00 CDT 2005
puts now.last_month #=> Sun Apr 10 17:15:59 CDT 2005
puts now.last_year #=> Mon May 10 17:15:59 CDT 2004
puts now.midnight #=> Tue May 10 00:00:00 CDT 2005
puts now.monday #=> Mon May 09 00:00:00 CDT 2005
puts now.months_ago(2) #=> Thu Mar 10 17:15:59 CST 2005
puts now.months_since(2) #=> Sun Jul 10 17:15:59 CDT 2005
puts now.next_week #=> Mon May 16 00:00:00 CDT 2005
puts now.next_year #=> Wed May 10 17:15:59 CDT 2006
puts now.seconds_since_midnight #=> 62159.215938
puts now.since(7200) #=> Tue May 10 19:15:59 CDT 2005
puts now.tomorrow #=> Wed May 11 17:15:59 CDT 2005
puts now.years_ago(2) #=> Sat May 10 17:15:59 CDT 2003
puts now.years_since(2) #=> Thu May 10 17:15:59 CDT 2007
puts now.yesterday #=> Mon May 09 17:15:59 CDT 2005
puts "cat".pluralize #=> cats
puts "cats".pluralize #=> cats
puts "erratum".pluralize #=> errata
puts "cats".singularize #=> cat
puts "errata".singularize #=> erratum

Z racji tego, że Railsy zmodyfikowały Rubiego do realizacji swoich zadań, uważam, że próba sklonowania tego środowiska w jakimś innym języku (poza Smalltalkiem), jest z góry skazana na niepowodzenie. Po prostu nigdy to nie będzie tak piękny kod jak Ruby dla Railsów. Na otarcie łez dla pythonistas, mogę powiedzieć, że przy wszystkich zaletach Rubiego, nadal uważam że Python (jako język) jest nie tylko łatwiejszy do opanowania ale także bardziej produktywny. Ale jeśli chodzi o frameworki, to Rails jest nie do pobicia jeśli chodzi o komfort, możliwości i DRY[4].

1 Zupełnie identyczne wrażenia prostoty jak z Railsami miałem w przypadku szukania dobrego systemu CMS’a. Taki np. pythonowy Plone w porównaniu do ezPublish i całej masy innych, pehapowych rozwiązań jest nie tylko poteżniejszy ale także niezrównanie prostszy i wygodny (po 5 minutach od instalacji, praktycznie bez czytania dokumentacji i bez znajomości Pythona, można stworzyć prosty serwis o całkiem przyzwoitej, podstawowej funkcjonalności)

2 Smalltalk posiada tylko 5 słów kluczowych i proste zasady: wszystko jest obiektem, wszystkie operacje polegają na przesyłaniu metod (nazywanych tu: wiadomościami) między obiektami. Moim zdaniem Smalltalk trochę przesadził z tą zasadą, bo nawet bo zamiast do sterowania kontrolą kodu używane są także wiadomości. Może jest jest spójne, ale trochę dziwnie wygląda. Osobiście bardziej podobają mi się możliwości Smalltalka ale wyrażone w składni …Rubiego. :) Zobacz też Ruby Instead of Smalltalk

3 Kontynuacje są jedną z wbudowanych cech Rubiego o której może być za jakiś czas głośno. Umożliwiają bowiem budowanie tzw. internetowych serwerów kontynuacyjnych, które w pełni zachowują stan pomiędzy requestami i ogromnie upraszczają prace programistów. W tej chwili najlepiej opracowanym frameworkiem tego typu jest smalltalkowy Seaside.

4 DRY to skrót od ang. Dont’t Repeat Yourself. Railsy zostały napisane z wręcz obsesyjną ;) cechą unikania powtarzania kodu. Mniej powtórzeń to nie tylko mniej niepotrzebnej, dodatkowej pracy ale także mniejsze ryzyko popełniania błędu.

Posted in , ,  | Tagi , ,  | 32 comments

Comments

  1. Avatar michuk powiedział about 11 hours later:

    “wszystkie operacje polegają na przesyłaniu metod (nazywanych tu: wiadomościami) między obiektami.”

    Boże, jakim “przesyłaniu metod”?? Jak już to “wołanie metod” chyba. Nigdzie ich przecież nie przesyłasz :P

    I tak dla informacji: wiadomość to standardowa nazwa na wywołanie metody w UML. Można więc mówić o wiadomościach zarówno w Smalltalku, Javie czy Ruby.

    Co do artykułu – strasznie dużo gadania, strasznie mało konkretów. Nie dowiedziałem się na przykład jakie są zalety Ruby’ego w porównaniu do javowego SpringFramework…

  2. Avatar Jarosław Zabiełło powiedział about 13 hours later:

    Celem artykułu nie było drobiazgowe porównywanie Railsów z resztą świata, ale zwrócenie uwagi na niezwykle silne powiązania Rubiego ze Smalltalkiem i możliwości przekształcania języka, co tłumaczy dlaczego Rails nie może żyć bez Rubiego. I to tłumaczy dlaczego próby sklonowania Railsów w innych językach to porażka.

    W terminologii Smalltalka nie mówi się o wywoływaniu metod, ale raczej o wysyłaniu wiadomości do obiektu:

    Wiadomości są to instrukcje rozumiane przez obiekty, zaimplementowane w tych obiektach w postaci metod. Na przykład wiadomość sin jest rozumiana przez instancje klasy Number i oznacza żądanie obliczenia sinusa z wartości będącej odbiorcą tej wiadomości.

    Wiadomość składa się z nazwy metody i argumentów i jest wysyłana do odbiorcy wiadomości. W wyrażeniu 9 raisedTo: 2 odbiorcą wiadomości jest liczba 9, nazwą metody jest raisedTo:, a argumentem jest liczba 2.

    Każda wiadomość zwraca jako rezultat swojego wykonania jakiś obiekt do obiektu wysyłającego daną wiadomość. W powyższym przykładzie metoda raisedTo: zwraca instancję klasy SmallInteger, czyli liczbę 81.

    Spring to nie język, więc nie ma sensu porównywać go z Rubym (jeśli już, to raczej z Railsami). Zalet Railsów jest sporo. M.in. znacznie szybsza pętla sprzężenia zwrotnego, mniej kodu bez szkody dla czytelności (jak w Perlu), mniej plików konfiguracyjnych, DRY i konwencje ponad konfiguracjami dające razem znacznie większą produktywność w tym środowisku. Railsy realizują (znacznie lepiej niż inne frameworki) prosty cel: stworzenie frontona współpracującego z relacyjną bazą danych. Nic więcej, nic mniej. Naginianie Javy do zastosowań do których nie została dobrze zaprojektowana jest ślepą uliczką. Zachęcam do przeczytania książki Więcej niż Java. Jest bardzo interesująca. Zobacz też Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite

    A jeśli chcesz porównać hybrydową Javę z rzeczywiście w pełni obiektowym językiem to zajrzyj np. do tych porównań Smalltalka z Javą. zobacz też Smalltalk w pigułce.

    Jeśli chodzi o samego Rubiego, to przejrzyj 10 Things Every Java Programmer Should Know About Ruby. Polecam też blog Martina Fowlera (tego od wzorców projektowych i metodyk adaptacyjnych (agile))

    Zobacz też artykuł Technologies to Watch: A Look at Four That May Challenge Java’s Development Dominance na onjava.com.

  3. Avatar Adamh powiedział 1 day later:

    Musze przyznac, ze to bardzo ciekawy artykul. Mialem przyjemnosc poznac SmallTalka i faktycznie ma mnostwo wspolnego z Rubym – najwazniejsza wspolna cecha: Wszystko jest obiektem.

    Swoja droga marzy mi sie CMS o mozliwosciach eZpublish/Plone napisany w Railsach (chocby w Django:))

  4. Avatar Jarosław Zabiełło powiedział 1 day later:

    Jeśli chodzi o CMS, to nie spotkałem na razie nic lepszego od Plone. Bardzo prosty aby zacząć i ma bardzo potężne możliwości jak ktoś chce zaszaleć.

  5. Avatar hirman powiedział 1 day later:

    Istotnie Plone posiada imponującą funkcjonalność prosto z pudełka.

    Do jego wad można zaliczyć zasobożerność, sporą liczbę dodatków (products) w wersjach 0.x alpha – czyli praktycznie bezużytecznych, kłopoty z interfejsem, choćby z menu po dodaniu do niego nowych elementów.

  6. Avatar Tomek powiedział 2 days later:

    Zgodnie z tym co pisal Paul Graham wiele lat temu, jezyki programowania staja sie coraz bardziej podobne do Lispa i Ruby jest po prostu kolejnym stadium ewolucji :)

    Wiec podniecanie sie tym co Lisp potrafi od jakichs 20 lat dla mnie wyglada dosc smiesznie :>

  7. Avatar elo powiedział 3 days later:

    Lisp sux i hoi

  8. Avatar lopex powiedział 3 days later:

    lisp od grubo ponad 40u ;)

  9. Avatar Adamh powiedział 5 days later:

    Tomku.. dlaczego zatem nie programujesz w Lispie (chyba, ze programujesz:))? Wszystko co potrafi Ruby mozna osiagnac za pomoca prawie kazdego obiektowego jezyka zaryzykuje nawet, ze da sie tego dokonac za pomoca prawie kazdego jezyka programowania – wszystko rozbija sie o forme. Dlaczego ludzie przesiadaja sie z jednych jezykow na inne? Oczywiscie powodow jest wiele ale zazwyczaj chodzi o to, ze forma danego bardziej pasuje do tego co akurat chca w nim zrobic.

  10. Avatar Adamh powiedział 5 days later:

    Jesli chodzi o Plone to troche o nim czytalem ale studiowac Zope tylko dla tego systemu – nie wierze w to, ze kiedykolwiek mialbym mozliwosc uzycia tej wiedzy w innym kontekscie. Poki co czekam na Rails/Django-based CMS.

  11. Avatar Jaroslaw Zabiello powiedział 5 days later:

    Twórcy Django stworzyli swój CMS. Nazywa się Ellington. Niestety, ta aplikacja jest płatna. I co gorsze, nie ma żadnej wersji demo ani nawet filmu aby zobaczyć jak to działa i wygląda. :(

    W RoR już napisano kilka CMS: Eribium, RailFrog, RCMS czy TrivialCMS. Niestety są cienkie gdy się porówna z przykładowo pehapowymi: ezPublish czy Drupalem. Twórca RailFroga to wręcz się reklamuje że nie jest programistą…

    Może powstanie coś mocniejszego, jednak wątpię aby komukolwiek udało zbliżyć się do Plone. Sama idea, na której oparty jest Plone jest doskonała: system jest w pełni obiektowy i zbudowany z obiektowych klocków. Za pomocą archetypów można błyskawicznie dodać kolejny obiekt/komponent i włączyć go do systemu. Oczywiście, Plone to tak naprawdę “produkt” (czy moduł) do Zope. Aktualna wersja jest oparta na starym, Zope2. Ale jak wyjdzie Plone oparty Zope3 to może być to rzeczywisty pythonowy “killer application”. Zope3 jest szybszy i znacznie lepiej zaprojektowany niż Zope2. Jest oczywiście trudniejszy niż RoR czy Django, ale jeśli chodzi o CMS, to może być nie do pobicia. Nie sądzę też aby w RoR szybko udało się stworzyć serwer aplikacyjny który mógłby nawiązać walkę z Zope3. To inna klasa aplikacji.

    (BTW, aktualna wersja Plone pożera tyle samo pamięci co pythonowy Mambo, jest więc dużo lepiej niż kiedyś)

  12. Avatar Adamh powiedział 6 days later:

    PHPowy Mambo jak mniemam:)

    Znam te projekty CMSow w Railsach i poki co nie ma o czym mowic (szansa w Eribium ale potrzeba duzo wiecej rozmachu). Railfrog obserwuje od czasu zalozenia projektu i poki co widze rozmowy i nie sadze by kiedykolwiek powstal z tego projektu gotowy system. Django w porownaniu z Railsami ma dwa wielkie plusy – wydajnosc i tworzenie “admin area” (swoja droga dzialajaca genialnie funkcjonalnosc). Dlatego do wydajnego Enterprise CMSa Django wychodzi na prowadzenie. Wiem, ze istnieje Ellington i na tym wiedza o tym systemie sie konczy (do tego zniechecily mnie ceny: miedzy $10k a $15k).

    Sam preferuje eZpublisha niz Plone’a – w sumie sama idea jest bardzo podobna: umieszczanie w odpowiednich miejscach odpowiednich obiektow. eZ jesli chodzi o interfejs jest moim zdaniem duzo bardziej przejrzysty – fakt, ze w Plone’a nie wgryzalem sie tak bardzo jak w eZ.

    Jesli chodzi o Zope to moim zdaniem nigdy nie zyska takiej popularnosci jaka zyska Rails czy Django – glownie dlatego, ze do nauczenia sie tego frameworka potrzeba ogromna ilosc czasu i stopien jego skomplikowania jest o wiele wiekszy (zgadzam sie oczywiscie, ze tworzony byl dla zupelnie innej “publiki”)

    Zawsze pozostaje stworzenie tego czego brakuje… mysle, ze rozsadnie zaprojektowany Rails/Django CMS moglby byc w pewien sposob przelomowy.

  13. Avatar Tomek powiedział 7 days later:

    Adamh – programuje w Lispie kiedy tylko moge… Ale pisze programy dla duzych klientow, gdzie technologia musi byc “enterprise” (nie wnikam co to dokladnie oznacza) i Ruby, Lisp czy Python nie maja szans na akceptacje.

    Co do formy, to masz oczywiscie racje, bo wszystko sprawadza sie do kodu maszynowego. Ale roznica pomiedzy Lispem a innymi jezykami jest taka ze Lisp ma forme odpowiednia do wszystkiego – po prostu bardzo latwo mozesz ja stworzyc – jesz ciastko (dostajesz odpowiednia forme) i nadal masz ciastko (elastycznosc Lispa).

    Ja nie mowie ze Ruby jest be, pewnie (nie programuje w Ruby chociaz planuje sie nauczyc – przynajmniej dla praktyki i poszerzenia horyzontow) jest super :) Ale zauwazam tylko ze ludzie przesiadaja sie na jezyki coraz blizsze do Lispa i Ruby wydaje mi sie kolejnym przystankiem.

  14. Avatar Piotr (pirat) Mąsior powiedział 9 days later:

    Czy nie wydaje wam się że rozpoczęła się pewna nowa epoka? Wszyscy piszą nagle frameworki, Cms-y. Powracają do starych języków i odkrywają kolejną amerykę. Php ma zadyszkę, Ror świetny start. Java rozrosła się do tego poziomu, że zaczyna wypluwać jak karabiny maszynowy z siebie coraz to nowsze “wynalazki koła”. A to wszystko pod szyldem “Dont Repeat YOURSELF!!!” – brakuje już tylko do tego Magbeta. Kiedyś sprawa była prosta… teraz trudno jest zaplanować sobie czego i w jakim stopniu należy się uczyć, aby nie zostać w tyle… jedno rozwiązanie lepsze od drugiego… szkoda tylko, że aby się o tym przekonać – potrzebny jest czas…

  15. Avatar Adamh powiedział 9 days later:

    Frameworki tworzone sa od samego poczatku (zbiory funkcji, zbiory klas itp – klarujace sie w polaczone wieksze twory).

    PHP nie ma zadyszki a duze problemy poniewaz pojawiaja sie rozwiazania, ktore wrecz deklasuja uzywanie PHP (bez rozsadnego frameworka), CMSy byly od bardzo dawna – zarzadzanie trescia jest zazwyczaj konsekwencja powstania tresci. Potrzeba bylo tylko naglosnienia tego tematu i wielu projektow darmowych i komercyjnych by management poczul, ze temat musi byc traktowany powaznie.

    Co do wynajdywania kola to chyba nie do konca tak… powiedzialbym raczej, ze zmienia sie forma i wszystko idzie w strone postepu. Kazdy web-framework sluzy do tego samego… wazne jak pozwala cel zrealizowac.

    Aby przekonac sie o trafnosci kazdego wyboru potrzebny jest czas… wczesniej mozna stawiac na przeczucie to dokladnie tak jak z graniem na gieldzie (poniekad to jest piekne w zyciu, prawda?:)).

  16. Avatar Adamh powiedział 9 days later:

    Tomku… Ruby i Rails czy Python (choc tu nie do konca sie zgodze) i Django to jeszcze nie rozwiazania klasy “enterprise” ale tak jak PHP trafilo do tej klasy tak duzo szybciej i one trafia. Jak wiadomo na poczatku ery tej nobilitacji jest duze zapotrzebowanie na nowe technologie i rozwiazania poniewaz wiekszosc firm chcialaby byc uznawana za rewolucyjne lub chociaz podazajace za najnowszymi trendami. Pomijajac przyczyny takich zmian… uwazam je za dobre (nie wierze w zasade: lepsze wrogiem dobrego).

    Co do Lispa… nie twierdze, ze to zly jezyk – nawet go nie znam – nie spotkalem sie jednak z dobrym fameworkiem do tworzenia aplikacji WWW a tym sie zajmuje (chodzi o konkretne zastosowania).

  17. Avatar Jarosław Zabiełło powiedział 9 days later:

    Tomek, nie zgodzę się. Pythonowy Zope to już jest zdecydowanie klasa enterprise. Używają tego rządy, duże firmy, organizacje pozarządowe. Poza tym, Zope Corporation oferuje także płatne rozwiązania oparte na Zope dla firm i przedsiębiorstw. Zobacz ich Zope Enterprise CMS czy Zope4Intranets.

  18. Avatar Toszcze powiedział 2 months later:

    A ja nie znalazłem w tym tekście jednej istotnej (moim zdaniem) kwestii – kwestii wydajności RoR. A może to przysłowiowa “pięta achillesowa”, o której nikt nie chce mówić/pisać? ;)

  19. Avatar Jarosław Zabiełło powiedział 2 months later:

    Z tą niską wydajnością Railsów to ja bym nie przesadzał. Zobacz mój artykuł: “Skalowanie RoR” który przed chwilą napisałem (zainspirowała mnie do tego Twoja wypowiedź :)

  20. Avatar Toszcze powiedział 2 months later:

    Ciekawy tekst, ale nie porusza on kwestii wydajności RoR, a jedynie przedstawia możliwości skalowania aplikacji napisanych z jego użyciem. Nie mówię, że to nie ma znaczenia – ma, i to spore. Natomiast ja miałem na myśli co innego. ;)

    Średnio trafione (moim zdaniem) jest również porównanie RoR i Symphony. Dlaczego akurat Symphony? ;)

    Na koniec (żeby nie było niejasności) – nie jestem jakimś przeciwnikiem RoR. Wręcz przeciwnie – uważam, że to świetny framework. Przez swój pierwszy komentarz chciałem jedynie zaznaczyć, że wydajność jest sprawą istotną, a RoR (podobnie zresztą jak większość frameworków opartych o model MVC) nie jest demonem prędkości. ;) Zresztą prawda jest taka, że każdy “pudełkowy” (czy raczej “uniwersalny”) framework spowalnia aplikację (w porównaniu z aplikacją napisaną w “czystym języku”). Ale to już temat na dłuższą dyskusję. ;)

  21. Avatar Jarosław Zabiełło powiedział 2 months later:

    Dlatego Symphony, bo to dosyć zaawansowany framework naśladujący Rails. Chodzi o porównanie mniej więcej podobnych aplikacji.

    Co do szybkości, to jeszcze parę lat temu nikt nie brałby na poważnie języków interpretowanych jako alternatywy dla kompilowanych. Popularność interpreterów rośnie bo zostałą przekroczona masa krytyczna wydajności sprzętu. To, że Rails jest wolniejszy nie ma aż takiego znaczenia (1) dla firm, które moga łatwo dostawić kolejny serwer, oraz (2) dla tych, gdzie liczy się bardziej produktywność niż czasowo większa wydajność aplikacji. Tą można przyśpieszyć za pomocą hardware’u. Produktywności zaś nie da się tak łatwo przyśpieszać.

  22. Avatar Toszcze powiedział 2 months later:

    Przyznam szczerze, że nie znam zbyt dobrze Symphony (czytaj: nigdy nic nie zrobiłem przy użyciu tego frameworka), ale bardziej mi tutaj by pasował CakePHP. ;) Ale mogę się mylić.

    Z drugą częścią wypowiedzi zgadzam się w prawie 100%. :) Prawie, bo nie jesteś w stanie namówić np. Onetu (to tylko przykład – chodzi o skalę) do korzystania z RoR czy jakiegokolwiek innego tego typu frameworka – oni stawiają głównie na wydajność i taka przesiadka spowodowałaby konieczność dostawienia nie jednej czy dwóch, ale (jak mniemam) kilkunastu nowych maszyn. ;)

  23. Avatar Jarosław Zabiełło powiedział 2 months later:

    CakePHP wygląda na bardziej niedopracowany w porównaniu z Symphony. Ale być może to i tak nie ma znaczenia i byłoby podobnie z wynikami wydajności.

    Co do Onetu, to być może baliby się RoR, ale już Django na pewno by zadowoliło ich wymagania wydajnościowe, bo jest nie tylko znacznie lepszy od rozwiązań PHP ale także znacznie od nich szybszy i zdolny do obsługi bardzo złożonych witryn (co widać na przykładach portali jakie używają Django).

    RoR dopiero wchodzi w fazę optymalizacji wydajnościowej. Django od początku to brał pod uwagę.

    Dużo jednak może zmienić ukończenie YARP’a czyli wirtualnej maszyny Rubiego (tak jak dla Javy) z natywną obsługą wątków. Z tego, co czytałem, to już teraz daje przyśpieszenie kodu Rubiego nawet 10x.

  24. Avatar rsz powiedział 4 months later:

    Na jakiej podstawie twierdzisz, że Django jest “znacznie szybszy” od PHP?

  25. Avatar Korkenstein powiedział over 2 years later:

    Witam! Zgadzam się w całości z artykułem. Pracuję jako senior programmer php. Tzn. już nie php. Odkąd się przerzuciliśmy na Rails (co było bardzo łatwe) prace idą szybko, pracuje się wygodniej. Przede wszystkim człowiek się nie męczy ze skretyniałymi problemami typu: czmu to znowu niedziała. W Rails po prostu – wszystko działa i co najważniejsze jest logiczne. Programista z miesięcznym stażem zrozumie skrypty w Ruby’m. Rails jest chyba najlepszym frameworkiem wszechczasów.

  26. Avatar Korkenstein powiedział over 2 years later:

    PS – Nie ma porównania np. Zend Framework vs Rails. To tak jakby porównywać rower i mercedesa.

  27. Avatar szymon powiedział over 2 years later:

    Ta… tak samo pisali kiedyś o PHP, o nic nie trzeba się martwić. Teraz zachwycają się Rubim i Pythonem, bo Django jest takie super i Railsy też… ciekawe co będzie następne, erlang, lisp, może brainfuck. Co nie zmienia faktu, że wygodnie się tam pisze, aktualnie klikam sobie w Django.

    Jeśli o mnie chodzi to nie podoba mi się podejście Railsów do bazy danych, robienie triggerów, kluczy obcych czy kaskadowego działania kluczy obcych w kodzie to jakaś pomyłka. No ale przeważnie nie da się inaczej, bo przecież 99% super profesjonalnych stron chodzi na MySQLu z enginem MyISAM więc tam nikt nie martwi takimi pierdołami, nawet danymi się nikt nie martwi, bo transakcji też przecież nie ma.

  28. Avatar Korkenstein powiedział over 2 years later:

    Aby móc subiektywnie ocenić sprawę RoR, można poświęcić kilka wieczorów na jego sprawdzenie. Zapewniam, że więcej czasu nie będzie potrzebne.

  29. Avatar szymon powiedział over 2 years later:

    Sugerujesz, że nie poświęciłem na to chociażby tych kilka wieczorów? Co miałbym sprawdzać, to że zalecają używanie triggerów kodzie? Czy może to, że migracje nie mają kluczy obcych, no chyba, że trzeba doinstalować sobie jakis plugin żeby to wymusić. Określenie w modelach że tabela jest powiązana z inną naprawdę nie powoduje, że baza o tym w jakikolwiek sposób wie.

  30. Avatar Jarosław Zabiełło powiedział over 2 years later:

    @szymon: Klucze obce, i co tam chcesz, możesz bez problemu sobie dodać w migracjach bo masz tam pełny dostęp do SQL’a.

    Ogólnie filozofia kontrolowania danych na poziomie obiektowym nie jest taka zła. Niektóre mechanizmy są nieosiągalne, ba niewidzialne, dla RDBMS. Np. Active Record pozwala dynamicznie dodać przezroczyste powiązania między tabelami (tzw. relacje polimorficzne) bez zmieniania czegokolwiek w bazie.

    Rails to dobry framework, ale moim zdaniem, jeszcze lepszy jest Merb (szybszy i ma większe możliwości).

  31. Avatar szymon powiedział over 2 years later:

    @Jarek Tak, klucze mogę dodać, ino wtedy tracę przenośność orma w tym sensie, że na bazie gdzie są klucze, zostaną utworzone, a gdzie ich nie można zrobić to nie zostaną. No ale oczywiście można dołożyć plugin, który to zrobi, napisać sobie itd, tylko nie tędy droga, framework jest do dupy jeśli trzeba dołożyć mu albo napisać tonę różnych rzeczy żeby był cool.

    Filozofia kontrolowania danych nie jest zła, ale np. takie klucze obce pozwalają prościej utrzymać spójność bazy niż robienie kilkunastu zapytań w callbackach modeli, a już klucze, które sprawdzają poprawność nie przy każdym zapytaniu, ale na końcu transakcji pozwalają bardzo to usprawnić.

    No i jeszcze jeden problem: trzymanie całej logiki w aplikacji ma tę wadę, że dorobienie osobnego modułu chociażby do importowania danych, nie można zrobić w innym języku, bo trzeba koniecznie wykorzystać dokładnie te same modele, które potrafią cokolwiek sobie ustawić co oznacza, że jak ma się importer, który można by użyć, ale jest napisany np. w perlu, to tak naprawdę użyć go nie można. Przecież utrzymywanie callbacków modeli w perlu i rubym jednocześnie to jakaś pomyłka, za dużo możliwości na błędy.

    A te większe możliwości merba to co takiego, bo nie zauważyłem? Działa to tak jak Railsy, filozofia ta sama, część rzeczy się inaczej nazywa, dokumentacji prawie nie ma, wersja nadal jest całkiem rozwojowa, niektóre pluginy średnio działają, jak dla mnie to nic specjalnego, ale może takie moje zboczenie, nie znalazłem jeszcze frameworka, który by mi się podobał. Oczywiście szybciej działa, ale szybsze działanie to nie są większe możliwości.

  32. Avatar Jarosław Zabiełło powiedział over 2 years later:

    @szymon: Do pracy z legacy databases chyba lepiej nadaje się Sequel lub DataMapper niż Active Record. Nie obwiniaj cały framework za jeden ORM (tu AR). Jak ci nie pasuje, użyj inny. Fakt, że w Merbie jest to łatwiej, bo AR jest dosyć mocno zrośnięty z RoR. Generalnie, poważniejsze bazy może i powinny jakoś bronić swojej integralności, ale są gdzieś granice paranoi. Niby możesz bazę pokryć siecią kluczy obcych, triggerów i procedur składowanych ale nie zawsze to ma sens. Znacznie łatwiej jest to zrobić w Ruby i nie trzeba do tego callbacków. AR ma w budowane walidacje. Oczywiście łączenie Ruby i Perla to jakiś żart. Z drugiej strony baza z nawalonymi procedurami składowymi też specjalnie przenośna nie jest. Widziałem jak SQL Server z jednej wersji nie był w stanie zmigrować się do wyższej z tego powodu.

    Importowanie danych nie ma związku z modelami. To nie ta warstwa. Modele tylko nakładają na bazę swoją obiektową abstrakcję. Oczywiście przerzucanie specyficznych i bardziej zaawansowanych rzeczy jak funkcje i procedury składowane z oczywistych powodów nie będzie przenośnie między różnymi bazami. Jednakże do zwykłego przerzucenia danych można użyć czegokolwiek. To nie ma znaczenia dla modeli w Rails. Możesz więc przewalać dane Perlem a używać modeli AR w Rails. Nie powinno to mieć żadnego znaczenia.

    Jeśli chodzi o Merba, to przede wszystkim posiada silne wsparcie komponentowe (parts i slices). Dowolną aplikację Merb’a możesz zamienić w slice, slice w gem i z takich klocków składać kolejny projekt. Pluginy w Merbie też zwykłe gemy, więc łatwiej nimi zarządzać, aktualizować itp. Merb potrafi odpalać akcje kontrolera asynchronicznie (można np. zapuścić ładowanie pliku asynchronicznie, i bez blokowania kontynuować pracę w kontrolerze) Rails by się tu blokował. Poza tym każda akcja kontrolera po prostu zwraca String do browsera. A jak zwróci uchwyt do pliku to Merb automatycznie wysyła strumień danych. W Rails tak nie ma i łatwo popaść w double render error. Merb pozwala też tworzyć mikroprojekt w stylu mikroframeworków takich jak Sinatra, Camping, Mack czy Waves, co się przydaje do bardzo małych rzeczy zamiast PHP, który zwykle się tu by użyło. Taki mikroprojekt potem można rozbudować w miarę potrzeb. Dużo by pisać. :) Z dokumentacją do Merba nie jest wcale źle. Tworzone są 2 książki, jedna w PDF jest w PeepCode, kolejna jest tworzona jako open source, Wiki się szybko rozrasta, na Githubie widać już wysyp różnych slices. Co ważniejsze, API Merba jest bardziej przejrzyste niż Rails, jest prostsze, krótsze, z podziałem na część publiczną i prywatną. W Merb 2.0 ma dojść panel al’a Django, API do ORM’ów i inne rzeczy.

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz