Merb - źródła informacji

Opublikowane przez Jarosław Zabiełło Fri, 12 Dec 2008 15:55:00 GMT

Od czasu wyjścia Merb 1.0 przybywa coraz więcej dobrych materiałów n/t tego frameworka (koledzy od Pylons, ktorzy od wieków tkwią w tej swojej wersji 0.9.x mogliby to sobie wziąć do serca). Przede pojawia się coraz więcej zapowiedzi książek…

Książki

  • Merb in Action – dostępny PDF beta (książka ma wyjść w czerwcu 2009), w sumie chyba najważniejsza pozycja, bo pisana zespołowo przez twórcę i głównych developerów Merba.
  • The Merb Way – wersja Beta dostępna online dla subskrybentów świetnego serwisu “O'Reilly Safari Book Online”. Ma być wydana pod koniec maja 2009.
  • Beginning Merb – będzie wydana przez Apress (druga połowa czerwca 2009)
  • Meet Merb – książka tylko w formacie PDF, aktualizowana do Merba 1.0.

Zacząłem też pisać swoją książkę o Merbie (na razie pod roboczym tytułem “Merb – następca Ruby on Rails”). Jeśli Helion uzna że jest zapotrzebowanie na taki temat, to jest szansa żeby to wydano. Sprawa jednak jeszcze nie jest rozstrzygnięta. (Na stronie głównej Helionu, po prawej stronie, jest mały formularz za pomocą którego można wysyłać im informację o tym co chcielibyście aby wydali)

API

ORMs

Każdy z poniższych ORM’ów może być używany samodzielnie w dowolnym skrypcie Ruby’ego, a nie tylko w kontekście frameworka.

  • http://datamapper.org/ – strona domowa DataMappera, domyślnego ORM’a do Merba. Potrafi współpracować z bazami RDBMS jak i dowolnymi innymi źródłami danych, używa prepared statements, zawiera wysokopoziomowe typy kolumn (podobne do ORM w Django), pozwala przemapować nazwy kolum w modelu i używać wygodniejszych nazw bez względu na to jakie nazwy kolum są w bazie. Przybywa mu też sporo pluginów. DataMapper to bezpośredni konkurent Active Record.

Inne

Tagi , , , , , ,  | 13 comments

Comments

  1. Avatar JO powiedział about 4 hours later:

    Chciałbym nadmienić że wszyskie te informacje aktualne mozna znaleść na http://wiki.merbivore.com/ właściwie ten post jest rippem z wiki merba ;)))

  2. Avatar Hubert Łępicki powiedział 2 days later:

    Hehe, rzeczywiście te same informacje.

    Ale czego innego można by się spodziewać – w końcu są to najważniejsze informacje, więc jak dla mnie OK.

    Dzięki za post.

  3. Avatar gość powiedział 2 days later:

    taki mały offtop jeśli chodzi o ten wpis

    co sądzicie o wypowiedzi w tym wywiadzie http://antyweb.pl/zabijamy-pana-gabke-zawodowo-wraz-z-fotkapl/ cytuję: “Twitter to już chyba symbol problemów z dostępnością serwisu internetowego w tych czasach … Odpowiedz jest prosta i skalda się tylko z 3 liter: RoR.”

  4. Avatar jiima powiedział 2 days later:

    @Gość

    Ale to niestety przynajmniej w 30% prawda. Ruby ma daleko do Pythona jeśli chodzi o wydajność i szybkość, przynajmniej jeśli mówimy o MRI. Python niestety też stosuje GIL, co daje problemy ze skalowalnością, ale nie takie jak MRI. O PHP, które w ogóle nie ma wątków i w zasadzie jest podrasowaną wersją CGI nie będę się wypowiadał po raz kolejny. Natomiast fakt, że lepiej nadaje się do pewnych zastosowań niż Ruby i Python razem wzięte – jak musisz postawić na szybko stronkę, którą potem diabli i tak wezmą i pod żadnym pozorem nie planujesz jej rozwijać. Jednak czasy się zmieniają. Ruby Enterprise to jedno, YARV i Rubinius to dwa, JRuby to trzy i odpadasz ty, stare dobre MRI.

  5. Avatar jiima powiedział 2 days later:

    @Gość

    Osobna kwestia to wydajność samych RoR, którą zaczęto traktować poważnie gdzieś w okolicy wersji 2.0 (spora w tym zasługa wściekłych postów Zeda mam wrażenie, no i powstania Merba) i wciąż jest sporo do nadrobienia. Active Record to nie SQL Alchemy, a nadmiar metaprogramowania odbija się czasem czkawką.

  6. Avatar Jarosław Zabiełło powiedział 2 days later:

    Pan Rafał Agnieszczak serwuje nam tu jakieś mocno nieświeże informacje z czasow Rails 1.x. Aktualnie Rails 2.2.x jest szybszy od analogicznych frameworków w PHP, a (napisany w Ruby) framework Merb ((http://merbivore.com)) kompletnie deklasuje rozwiązania w PHP (http://www.slideshare.net/mattetti/merb-presentation-at-orug-presentation). Różnica staje się jeszcze większa w wypadku użycia JRuby (http://jruby.codehaus.org) dzięki któremu Rails i Merb mają pełny dostęp do całej architektury Javy. JRuby z wersji na wersję staje się coraz szybszy. A dzięki temu, że wykorzystuje agresywną kompilację inline JIT’a w wirtualnej maszynie Javy, może rozpędzić się do szybkości zupełnie poza zasięgiem PHP. Merb odpalony na JRuby, Glassfishu i pojedyńczej maszynie z procesorem Intel Quad Q6850 osiąga ponad 9 tys. req/s (http://blogs.sun.com/Jacobkessler/entry/it_s_over_9000) zostawiając daleko za sobą PHP czy Django.

    Co do PHP, to jest powszechnie krytykowany za fatalną niespójność języka, słabe możliwości i ostatnio coraz bardziej za słabą wydajność. Żaden akcelerator do PHP nie jest w stanie zmienić zasadniczej filozofii pracy PHP, który za każdym przeładowaniem strony musi tworzyć od nowa wszystkie obiekty. Python i Ruby tego nie potrzebują, bo działają tu podobnie jak serwlety Javy, część obiektów żyje cały czas w pamięci i nie trzeba ich co chwilę tworzyć. To w efekcie oznacza, że im większa i bardziej złożona aplikacja, tym bardziej PHP będzie zwalniał przy analogicznym projekcie w Pythonie czy Ruby.

    Być może Twitter używa jakąś starą wersję Rails (wersja 1.x była wolna i jest odpowiedzialna za mity jakie teraz się ciągną za RoR). Zdaje się, że Twitter używa również klasterow opartych na wolniejszym Mongrelu zamiast na szybszym Thin (http://code.macournoyer.com/thin/), lub znacznie szybszym, napisanym w C – Ebb (http://ebb.rubyforge.org). Być może powinni przesiąść się na JRuby i/lub Merba, który jest średnio jakieś 3-5x szybszy od Rails.

  7. Avatar Jarosław Zabiełło powiedział 2 days later:

    jiima: Ty też masz jakieś nieświeże informacje. Ruby Enterprise ma podobną szybkość do Pythona. Ruby 1.9 i JRuby potrafią już przewyższyć Pythona wydajnością. A do prostych stronek nie potrzeba PHP, wystarczy Merb stworzony w trybie --very_flat (jedna stronka!) lub analogicznie jakikolwiek z mikroframeworków Ruby’ego typu Sinatra, Camping czy Wave. Są b. szybkie i proste. Zaś dzięki mod_paasanger’owi uruchomienie frameworków Ruby’ego jest tak samo banalne jak w PHP.

  8. Avatar jiima powiedział 3 days later:

    @JZ

    Zjadło mi dłuższy post, więc krótko – mówimy o tym samym. Akurat z Ruby Enterprise nie miałem do czynienia więc się nie wypowiadam. A co do 1.9 to właśnie dzięki YARV jest on taki szybki. Wciąż jednak czekam na brak GIL, z resztą w Pythonie też.

    Co do PHP, miałem na myśli jeszcze bardziej Quick and Dirty – bez bawienia się w jakikolwiek Model 2 czy kontrolery. Z resztą wtedy (przy czystym podejściu strukturalnym) PHP jest naprawdę szybkie. Nie kocham tego języka, by rozwiać wszelkie wątpliwości.

    Co do Glassfish, jeśli mam go do dyspozycji, to czemu miałbym się bawić w tworzenie aplikacji w Rails? Myślę że czysta aplikacja JavaEE 5 będzie jeszcze wydajniejsza. Poza tym mówimy o providerach którzy byliby skłonni hostować masowo Ruby, tak jak teraz PHP, a prędzej mi kaktus wyrośnie niż pozwolą oni hostować javowe serwery aplikacyjne. Tak więc YARV/Ruby 1.9 rokuje tu dużo większe nadzieje niż (skądinąd świetna) JRuby

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

    Jakoś nie wyobrażam sobie tworzenia (a jeszcze mniej utrzymanie) większego projektu napisanego w proceduralnym PHP. A jak projekt się rozrośnie, to PHP zacznie zwalniać po prostu.

    Co do Glassfish’a, to może aplikacja JavaEE będzie szybsza, ale w JRuby pracuje się szybciej i na pewno kod będzie dużo ładniejszy. A wszystkie kluczowe dla wydajności punkty można przerzucić na jar’y.

    Co do hostingu, to nie wyobrażam sobie pracy na shared hosting. Serwery dedykowane są tanie.

  10. Avatar tomek powiedział 3 days later:

    z mod_rails/passenger nie jest tak rozowo w shared hostach – on konfliktuje np z mod_rewrite. wiec poki co np na kei tylko mongrel/thin pozostaje….

    co do dedykowanych serwerow – tych tanich – tu tez nie jest tak super, bo musisz dodatkowo je utrzymywac/monitorowac itp itd, a to zawracanie gitary jest. ja chce programowac a nie dodatkowo dbac o bezpieczenstwo linuxa, ktorego zainstalowalem

  11. Avatar Jiima powiedział 3 days later:

    @JZ I znowu mówimy o tym samym ale się nie zgadzamy. Czy ja mówię o dużym projekcie w PHP? Zabija go chociażby brak przestrzeni nazw. Choć w proceduralnym ANSI C bez przestrzeni nazw napisany jest Linux i jakoś się dało. Tylko w wypadku C są inne uwarunkowania – ciężko w językach wysokiego poziomu tworzyć jądro systemu. Próby były (jest unixopodobny kernel napisany w Javie) ale są to raczej eksperymenty i wybryki niż poważna praca.

    O PHP i JRuby powiedziałem w kontekście shared hostingu, bo w odróżnieniu od ciebie, niektórzy muszą funkcjonować w takich warunkach. Może dla ciebie serwer dedykowany (+ ludzie do obsługi) jest tani, ale dla paru moich klientów nie był, o celowości nie wspominając.

    Co do JavaEE, nigdy nie narzekałem na szybkość pracy z takim Seamem, Wicketem czy chociażby Grails. Może mówisz o czasach J2EE gdzie rzeczywiście dla jednego beana trzeba było utrzymywać dwa interfejsy i deskryptor w XML. Rails między innymi stąd wyrosło (“u nas nie ma konfiguracji w XML” jak reklamowali się w okolicy wersji 0.x), ale JavaEE też z tego wyrosła. A języki dynamiczne podobają się jednym a innym nie. Ja lubę Ruby, Pythona, Groovy i nawet JavaScript, ale znam takich co uważają je za dopust boży. Mój team leader jest fanem statycznego typowania i języków funkcyjnych, Groovy toleruje tylko z explicite podanymi typami. I rzeczywiście – jeśli ktoś nie jest przyzwyczajony do dynamicznego typowania (+ metaprogramowania), język taki jak ruby będzie mu tylko utrudniał życie. W drugą stronę podobnie.

  12. Avatar india tour travel powiedział 4 months later:

    Osobna kwestia to wydajność samych RoR, którą zaczęto traktować poważnie gdzieś w okolicy wersji 2.0… i wciąż jest sporo do nadrobienia.

  13. Avatar Jarosław Zabiełło powiedział 5 months later:

    Z wydajnością najnowszych RoR nie jest tak źle. Od jakiegoś czasu są już szybsze od dowolnego frameworka PHP, a to już coś. Mimo, że czekam na RoR 3.0 (aka Merb 2.0) który powinien przynieść znaczne ulepszenia, to zwykle i tak najczęściej wąskim gardłem jest relacyjna baza danych.

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz