Frameworki PHP vs Ruby On Rails, Skąd ten agresywny marketing w community RoR ? Opcje

[Wiktor P.]

Witam.

Będąc na etapie programisty znającego php trochę lepiej niż średnio rozgarnięty szympans,
poszukuję frameworka, który nauczy mnie dobrych praktyk programistycznych i projektowych (projektowych tzn. odnośnie
całego projektu, włączając w to projekt w UML, coś jak rysunek techniczny dla architekta, tu projekt dla aplikacji).
W grę wchodzi Symfony i Zend - bo znam ludzi, którzy mnie pokierują, doradzą etc.
Wiem, że znajome mi osoby od ww FM zrobią wszystko w swoich narzędziach, bardzo je chwalą, nie chcieli by ich zmieniać.
I tu pojawia się na horyzoncie jeszcze jeden konkurent Symfony i Zend - mianowicie Ruby on Rails.

Przedstawię argumenty pehapowców i rorowców i prosiłbym o rozsądne rozstrzygnięcie, czy argumenty obydwu grup
są cokolwiek warte (pokrywają się z prawdą).
W nawiasach przedstawię własną opinię dot. danego punktu.
Chciałbym podkreślić, że argumenty za lub przeciw dot. wyboru któregoś z frameworków
mają na celu odpowiedzieć na pytania:
- czy nauka danego frameworka wniesie coś dla programisty odnośnie programowania ogólnie (nie zależnie od języka),
- czy nauka danego frameworka przyda się w praktyce (szybkie wdrożenie, hosting).

Proszę również o swoje argumenty odnośnie Symfony, Zend i Ruby on Rails.

1. Argumenty pehapowców za PHP:
- PHP jest prosty do wdrożenia na serwer produkcyjny.
- Miliony użytkowników, wielka społeczność.
- W PHP można zrobić wszytsko - od strony www dla cioci co ma stoisko na bazarze (proceduralnie)
do najbardziej zaawansowanych projektów jakie można znaleźć w sieci.
- Jest ogromna ilość podręczników do PHP po polsku.
- PHP jest kompatybilne wstecz (w rozsądnych granicach).
- Nowoczesne frameworki do PHP oferują wszystko to co konkurencja (Python Django, RoR, Merb i inne).
- Programista nie musi być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.

1a. Argumenty pehapowców przeciw Ruby on Rails.
- Brak polskich książek (te obydwie na rynku są do wersji przestarzałych).
- Hostowanie to dodatkowa praca, dodatkowy czas, dodatkowe problemy.
- Hostowanie to koszmar i drożyzna.
- Bez sensu używać do małych projektów (czyli przez conajmniej 50% programistów).
- Kłótnie w samym sercu założycieli frameworka (odszedł twórca serwera mongrel).
- Zdarza się przepiswyanie gotowych już projektów w RoR na PHP np.
a. http://www.wykop.pl
b. http://www.oreillynet.com/ruby/blog/2007/0...ack_to_p_1.html
- Jeśli coś już pójdzie nie tak, to będziesz szukał powodu conajmniej tygodniami w źródłach RoR.
- Brak kompatybilności jakiejkolwiek wstecz. Pojawienie się nowej wersji RoR grozi powrotem do korzeni (może nie trzeba uczyć się od nowa wyświetlania "Hello World", ale trzeba
douczyć się ogromnej ilości nowych rzeczy i zapomnieć o tych starych rozwiązaniach).
- Bardzo agresywny marketing, rodem z telezakupów "Mango", tu zacytuję dla przykładu:
książka "Rails Space" M. Hartl, A.Prochazka - Helion 2008,
str. 31
"Witryna Rails Space (wykonana w RoR) będzie miała wiele elementów kojarzonych z popularnymi sieciami społecznościowymi jak Facebook".
- ZARAZ ZARAZ - Facebook jest w PHP !
str. 26
" (...)stwierdził, że gdy porządnie przyjrzał się PHP, uznał, że jest do niczego(...)".
- brak argumentów.
- Programista RoR MUSI być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.


2. Argumenty zwolenników Ruby on Rails:
- PHP to nakładka na język C.
- RoR jest w Ruby, a ten jest całkowicie obiektowy (moja uwaga: rozumiem, że programista RoR na co dzień wykorzystuje tą obiektowość
i tworzy sobie nowe klasy na bazie znaków "+", "-", "=", ";" itp. ).
- Sam język Ruby daje o wiele większe możliwości niż sam PHP ( moja uwaga: a mimo to, nikt nie używa samego rubiego bez frameworka do webaplikacji ).
- PHP ma koszmarną składnię.
- RoR daje duże możliwości w zakresie ORM, testów jednostkowych, MVC (moja uwaga: podobną funkcjonalność oferował już pięc lat temu CodeIgniter napisany w PHP4).
- Kto raz spróbował RoR nigdy nie wróci do PHP (moja uwaga: to zdanie można znaleźć wszędzie co ma związek z RoR, ale brak argumentacji).
- PHP to bajzel, PHP to zło.
- PHP jest dla dzieci i wieśniaków.
- Rorowiec zarabia więcej niż pehapowiec ( moja uwaga: jeśli zna tak dobrze RoR, że może porównac się z kimś kto np. 5 lat programuje w Zend
i na dodatek w swoim województwie uda mu się znaleźć pracę przy RoR to może rzeczywiście ).

Dziekuję za opnie, wskazówki, swoje uwagi i wszelkie komentarze.

[hipertracker]

troszke gorzej jesli ruby(konkretnie 1.8) jest tylko dodatkiem na Twoim developerskim serwerze vps (np. na ruby tylko redmine), wtedy okazuje sie ze pojedyncza aplikacja na redmine wpierdala tyle ramu(1 przeladowanie strony i 150mb ramu booyah!) ile 10 jednoczesnych requestow w aplikacji o podobnym poziomie skomplikowania(dotproject, bugzilla) dla php. Maly siege zeby sprawdzic wydajnosc rubego i serwer padl mi jak szmata (IMG:style_emoticons/default/smile.gif)

edit: chwila pracy w 2 osoby na redmine i ...
7649 xxx 20 0 200m 119m 3108 S 0 23.4 0:02.46 ruby1.8
7621 xxx 20 0 200m 119m 3112 S 0 23.3 0:02.30 ruby1.8
7554 xxx 20 0 164m 88m 3576 S 0 17.2 0:02.42 ruby1.8

trzecia kolumna od prawej to procent zjadanego ramu, przez ostatnie pare minut nikt nie korzystal z redmine, serwer ma 512 ramu. Wyglada na to ze nieuzywany w tym momencie ruby uniemozliwil korzystanie z serwera.

OK, masz konkretny problem, ale nie wiem czego konkretnie tam używasz, tzn. jak to wersja Ruby, Redmine i Rails? Być może to wina tej aplikacji readmine, nie używałem. Choć jeśli używasz starego Ruby 1.8.6, do tego starszej wersji Rails (sprzed 2.3.5) i na dodatek całość chodzi na paru procesach starych mongreli to może ci pożreć trochę więcej pamięci niż być chciał.

To co bym ci doradził, to po pierwsze pozbyć się tych 3 procesów. Użyj serwera asynchronicznego: Thin, Unicorn, Rainbows lub Zbatery. Najlepiej tego ostatniego (http://zbatery.bogomip.org/) bo jest jest co prawda oparty na asynchronicznych Rainbows i Unicorn ale używa pojedyńczego procesu z wątkami, co znacznie oszczędzi ci RAM. Wg tego co piszą na stronie Rainbows (http://rainbows.rubyforge.org/) "If you’re on a small system, or write extremely tight and reliable code and don’t want multiple worker processes, check out Zbatery, too. Zbatery can use all the crazy network concurrency options of Rainbows! in a single worker process."

Po drugie, jeśli potrzebujesz Ruby 1.8 to koniecznie użyj najnowszej wersji REE (Ruby Enterprise), który używa Ruby 1.8.7 i ma zdecydowanie ulepszone zarządzanie pamięcią. No chyba że masz możliwość odpalenia Ruby 1.9.2, ale musiałbyś sprawdzić czy ci ten Readmine z tym pójdzie.\
Warto wiedzieć, że dodatkowe optymalizacje REE są dostępne są po zarejestrowaniu klucza. o instalacji gemu możesz zobaczyć że jest skrypt passenger-make-enterprisey). Nie wiem jak teraz, ale wcześniej rozdawali kody za "co łaska". Wystarczyło dać dowolną dotację, choćby i 1 dolara i można było mieć ten kod. na pewno warto z tego skorzystać jeśli już używać REE.

Po trzecie, aktualizacja Railsów. Wersje starsze były znacznie bardziej zasobożerne.

Po czwarte, masz tu do czynienia z nadmiarowymi 2 procesami, starym Ruby, cholera wie jak starym Rails i Readmine. Czyli do pamięci ładujesz nie interpreter Ruby'ego ale cały framework + cała aplikacja. Można zrobić eksperyment i odpalić czystą aplikację rackową i porównać z tym co pożera Readmine. Bo być może, nadmierne zużycie pamięci też pochodzi z tego, w jaki sposób ktoś napisał Readmine.

Alternatywnie możesz też spróbować zobaczyć jak się zachow REE i Passengere (ale nie pod Apache lecz Nginxem). W końcu, skoro to VPS to nie powinno być problemem aby to postawić. Passengera można ustawić aby nie odpalał za dużo procesów. Zaletą Pasengera jest też to że nieużywane procesy są automatycznie usuwane po czasie z pamięci.

Jest jeszcze jedna alternartywa o której się dopiero co dowiedziałem. Pojawił się nowy Mongrel2. Najciekawsze jednak to, że jest może obsługiwać cała masę języków. Jak podają na http://mongrel2.org/home: Ruby, Python, C++, PHP, Haskell, Common Lisp, Perl, .NET, Clojure, i Lua. Nie sprawdzałem jeszcze jak to się zachowuje, ale myślę że warto się przyjrzeć

swoja droga, skoro juz idziemy w takie zachwyty jesli chodzi o przenosnosc JRuby, to nie lepiej po prostu to w Javie napisac i spokoj ?

Nie, bo w JRuby pisze się szybciej, prościej, krócej, po prostu wygodniej. Nie, jeśli chcesz użyć Rails, Padrino czy Sinatry. Większość frameworków Javy jest ciężka i nadmiernie skomplikowana. Choć to się też zmienia, np. we frameworku Play. Poza tym, JRuby kontenera serwletów Javy, więc aż tak oszczędne pamięciowo to nie jest. Choć przy pewnym poziomie obciążenia, Rails odpalony w JRuby zajmuje już mniej pamięci niż stado mongreli, bo JRuby korzysta z wydajniejszej obsługi pamięci w JVM.

Ten post edytował hipertracker 3.09.2010, 10:00:14