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.

[SHiP]

@hipertracker: ale wzorzec spagetti(o ile można to wzorcem nazwać) sam w sobie nie jest czymś złym. Ja popieram zdanie mike. Po prostu jest niewygodny w użyciu. Były sytuacje, że się pisało za ich pomocą aplikacje(np. commodore64 i basic w nim wbudowany), bo sprzęt na wiele nie pozwalał. Do tej pory masz skoki w asemblerze i nikt z tego powodu nie płacze. Równie dobrze można napisać, że cały paradygmat obiektowy jest badziewny, bo bardzo komplikuje sytuację programisty. Funkcyjny już mniej. Ale wszystko zależy od zastosowań, przyzwyczajeń oraz maszyny na której odpalamy daną aplikację.

Nie lubię się przypominać, ale napisze mi ktoś w końcu to jedno, krótkie zdanie na temat tego co potrzebuję aby zacząć pisanie sklepu w Ruby? Co do frameworku podałem RoR bo tylko jego znam i w tym temacie był podawany. Po prostu jestem zielony w tym temacie.


EDIT: dzięki za info (IMG:style_emoticons/default/winksmiley.jpg)


Ten post edytował SHiP 3.09.2010, 10:52:32

[Radarek]

Nie lubię się przypominać, ale napisze mi ktoś w końcu to jedno, krótkie zdanie na temat tego co potrzebuję aby zacząć pisanie sklepu w Ruby? Co do frameworku podałem RoR bo tylko jego znam i w tym temacie był podawany. Po prostu jestem zielony w tym temacie.

Potrzebujesz:
- ruby w wersji klasycznej (tzw. MRI, Matz Ruby Interpreter) bądź REE (Ruby Enterprise Edition - proszę się nie sugerować nazwą, to taki żart autorów) - REE jest forkiem MRI, który poprawia dosyć zużycie pamięci i co za tym idzie wydajność
- serwera aplikacyjnego, np. apache bądź nginx (polecam ten 2, ale jak ktoś ma już gotowy setup z apache to też jest ok)
- serwera aplikacyjnego, np. mongrel, thin, unicorn (oba serwery przy okazji są też serwerami www więc można je używać do developerki bez stawiania apache bądź nginx)
- frameworka, tutaj raczej RoR bądź Sinatra (ten pierwszy większy, z wieloma ficzerami, ten drugi bardziej lekki)
- baza jaką sobie życzysz (postgresql, mysql to najczęściej używane, ostatnio modne są też bazy nosql jak mongodb, couchdb, cassandra)
- memcache - bez problemu (o shmp nie słyszałem, a google nic mi nie zwracają chyba że chodzi Ci o shm to też podejrzewam nie ma problemu)

linki:
MRI http://www.ruby-lang.org/pl/downloads/ (najłatwiej jednak zainstalować z paczek, np. apt-get)
REE http://www.rubyenterpriseedition.com/


W przeciwieństwie do hipertrackera nie polecam od razu jrubiego. Dlaczego? Dlatego iż uważam, że takie rozwiązania jak jruby/maglev/ironruby (inne implementacje rubiego) są fajne, ale jak się ma konkretne potrzeby (np. chcę łatwej inteegracji z instniejącym systemem w javie to użyję prawd. jrubiego).

[hipertracker]

Potrzebujesz:
- ruby w wersji klasycznej (tzw. MRI, Matz Ruby Interpreter) bądź REE (Ruby Enterprise Edition - proszę się nie sugerować nazwą, to taki żart autorów) - REE jest forkiem MRI, który poprawia dosyć zużycie pamięci i co za tym idzie wydajność
- serwera aplikacyjnego, np. apache bądź nginx (polecam ten 2, ale jak ktoś ma już gotowy setup z apache to też jest ok)
- serwera aplikacyjnego, np. mongrel, thin, unicorn (oba serwery przy okazji są też serwerami www więc można je używać do developerki bez stawiania apache bądź nginx)
- frameworka, tutaj raczej RoR bądź Sinatra (ten pierwszy większy, z wieloma ficzerami, ten drugi bardziej lekki)
- baza jaką sobie życzysz (postgresql, mysql to najczęściej używane, ostatnio modne są też bazy nosql jak mongodb, couchdb, cassandra)
- memcache - bez problemu (o shmp nie słyszałem, a google nic mi nie zwracają chyba że chodzi Ci o shm to też podejrzewam nie ma problemu)

linki:
MRI http://www.ruby-lang.org/pl/downloads/ (najłatwiej jednak zainstalować z paczek, np. apt-get)
REE http://www.rubyenterpriseedition.com/


W przeciwieństwie do hipertrackera nie polecam od razu jrubiego. Dlaczego? Dlatego iż uważam, że takie rozwiązania jak jruby/maglev/ironruby (inne implementacje rubiego) są fajne, ale jak się ma konkretne potrzeby (np. chcę łatwej inteegracji z instniejącym systemem w javie to użyję prawd. jrubiego).

Też myślę, że nie ma co od razu rzucać się na JRuby. Po JRuby sięgają ci co są świadomi potrzeb i potrzebują czegoś więcej niż to, co dostarcza (bogata) biblioteka standardowa Ruby'ego.

EDIT: Nie bawiłbym się w Ruby MRI, bo to jest Ruby 1.8. REE to też 1.8. Lepiej od razu zainstalować Ruby 1.9.2. Jest znacznie szybszy i ma większe możliwości (choćby porządny Unicode)

Jednak co do instalacji Ruby'ego to zdecydowanie zalecam używanie RVM. Jeśli nie Rails, to zamiast Sinatry lepiej użyć Padrino, jest oparty na Sinatrze czyli też lekki, ale ma więcej możliwości. Dzięki RVM możesz sobie zainstalować równocześnie izolowane środowiska REE, Ruby 1.9.2 czy JRuby. I w prosty sposób się między nimi przełączać. RVM rządzi.

Radarek nie wspomniał o najprostszej z opcji. Ja bym się nie bawił w żadnego mongrela ani thina, przynajmniej nie na produkcji. Najłatwiej zainstalować Passengera. Działać będzie podobnie prosto jak mod_php. Nie trzeba nic odpalać w tle, pilnować aby się podnosiło podczas startu serwera itp.

Ewentualnie na początek możesz skorzystać z darmowej chmury serwerów Heroku. Jest trywialna w obsłudze i mają tam darmową opcja do niewielkich aplikacji. Na początek może być. Wtedy w ogóle nie musisz stawiać żadnego serwera.

Oczywiście do pracy nad kodem, nie trzeba żadych serwerów, bo Rails ma wbudowany prosty serwer HTTP. Ewentualnie można sobie zainstalować Unicorn'a i odpalać pod nim, bo jest szybszy od tego wbudowanego. Nie trzeba jednak żadnych Apache'y ani Nginx'ów do tego aby pracować i testować sobie kod.

Ten post edytował hipertracker 4.09.2010, 02:14:28