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.

[Daiquiri]

@Radarek
Prosiłam o realne korzyści dla klienta. Ty podałeś "miękkie" kryteria, które mogę podpiąć pod większość technologii ("zadowolony programista to programista wydajny, dokładniejszy, popełniający mniej błędów") - bo czy programista PHP jest z góry niezadowolony? Ty mówisz o przypadku hipertracker'a jako wydajniejszego w technologii, którą jak mniemam preferuje - ja nawet nie próbuję tego podważyć, bo niewątpliwie tak właśnie jest. Problem w tym, że ja szukam zupełnie innych informacji.

Pytam o to jakie realne korzyści przyniesie klientowi fakt, iż programista działa w Ruby. Czym dla klienta różni się fakt (i co na tym zyskuje), że dane zlecenie zostało wykonane przy użyciu Ruby zamiast "zwykłego" PHP.

Co do "agresywnego" marketingu RoR - zobacz jak szczęśliwie się złożyło. Autor pyta "Skąd ten agresywny marketing RoR" a pojawia się osoba, która takową "agresję marketingową" uprawia. Zbieg okoliczności? Nie twierdzę, że wszyscy korzystający z Ruby lubują się w takiej reklamie - dlatego odwołałam się do osoby hipertrackera a nie np. Twojej (IMG:style_emoticons/default/smile.gif) .

[hipertracker]

Pytam o to jakie realne korzyści przyniesie klientowi fakt, iż programista działa w Ruby. Czym dla klienta różni się fakt (i co na tym zyskuje), że dane zlecenie zostało wykonane przy użyciu Ruby zamiast "zwykłego" PHP.

1. większą elastyczność na zmienny humor klienta, który sam do końca nie jest pewien tego, jak ma wyglądać końcowy produkt. Wbrew pozorom to jest dosyć częsta sytuacja, że klient chce wprowadzać jakieś zmiany do poczatkowych założeń. A Rails jest stworzony do pracy agile.
2. mniejsze koszty utrzymania kodu, bo kod jest czytelniejszy, i jest go po prostu mniej
3. łatwiejsze nanoszenie zmian w działającej funkcjonalności lub dodawanie nowej (trochę wynika z pkt. 2 ale też z tego na ile modularnie pisana jest aplikacja)
4. większą odporność na awarie i błędy, możliwość automatycznego wyłapywania wszelkich nie obsłużonych wyjątków i wysyłanie ich natychmiast do osób, które się kodem opiekują. Dzięki temu błędy mogą być wyłapywane i naprawiane szybciej oszczędzając klientowi wstydu ("patrzcie jak im strona leży!, hahaha, hehehe"). W PHP można co najwyżej czekać aż jakiś wkurzony klient zgłosi błąd, którego nie wyłapali programiści. Ewentualnie pozostaje regularne przeczesywanie logów długo po tym jak błąd wystąpił. Mina klientów którzy, po kolejnym pehapowym fatal errorze, zobaczyli na ekranie biały ekran - bezcenna! (IMG:style_emoticons/default/laugh.gif)
5. trochę to samo co pkt. 4) większą odporność na błędy ze wzgędu na lepsze pokrycie kodu testami. Rails zawsze kładł nacisk na pokrycie kodu testami jednostkowymi i funkcjonalnymi. Ma doskonałe, eleganckie biblioteki do tego celu (RSpec, Cucumber i inne)
6. lepsze dogadanie się między klientem a wykonawcą odnośnie tego, co ma być zrobione. Zmiast pisać ciężkie wypracowania, albo przyjmować to co trzeba zrobić "na słowo", można w prosty, i czytelny dla osoby nietechnicznej, ubrać jej wymagania w formę specyfikacji BDD, zobacz Cucumber http://cukes.com
7. większa szybkość działania, aktualnie Rails jest szybszy od dowolnego frameworka PHP, a są szybsze i lżejsze rozwiązania od Rails, jak Padrino czy Sinatra.
8. brak ograniczeń rozwoju i skalowalności, klient nie musi się bać, że utknie w rozwoju bo ma zawsze możliwość podpięcia się do ciężkich systemów napisanych w technologii głównego nurtu (Java, .NET). Jeśli cokolwiek brakuje, to na pewno znajdzie się jakaś biblioteka w Javie, która dany problem rozwiązuje.
9. możliwość wpięcia się do chmur serwerów (Heruko, Google App Engine) co pozwala na elastyczniejsze kształtowanie kosztów hostingu (chmury pozwalają na czasowe zwiększanie/zmniejszanie potrzebnych zasobów w określonych godzinach dnia). Jeśli trzeba można błyskawicznie dodać 1000 serwerów na jakąś godzine szczególnie wysokiego ruchu, a zmniejszyć do paru w godzinach nocnych, czy wtedy kiedy statystyki pokazują mniejszy ruch na serwerze.

(IMG:http://zabiello.com/images/php.jpg)

Musiałbyś naprawdę bardzo nieoptymalnie pisać w C/C++ i naprawdę bardzo dobrze w innych by się ich wydajność zbliżyła do siebie.

Java ma o wiele wydajniejsze zarządzanie pamięcią od C++. Dynamiczna kompilacja może też więcej niż statyczna. Poza tym, nie sądzę aby taki Smalltalk czy Objective-C jakoś znacząco odstawał od C++. Nie słyszałem aby ktoś pokusił się o napisanie obiektowej bazy danych w C++ a w Smalltalku pod ponad 20 lat używane są takie bazy komercyjnie przez świat biznesu. O Javie nie wspomnę.

* Java vs. C benchmark
* Java vs. C benchmark #2: JET, harmony and GCJ

Ten post edytował hipertracker 6.09.2010, 20:32:54

[SHiP]

Ogólnie się zgadzam ale nie ze wszystkim

większą elastyczność na zmienny humor klienta, który sam do końca nie jest pewien tego, jak ma wyglądać końcowy produkt. Wbrew pozorom to jest dosyć częsta sytuacja, że klient chce wprowadzać jakieś zmiany do poczatkowych założeń. A Rails jest stworzony do pracy agile.

Co ma piernik do wiatraka? Agile to metodologia pracy zespołowej. Agile można również stosować w przypadku programistów php a nawet murarzy na budowie.

mniejsze koszty utrzymania kodu, bo kod jest czytelniejszy, i jest go po prostu mniej
łatwiejsze nanoszenie zmian w działającej funkcjonalności lub dodawanie nowej (trochę wynika z pkt. 2 ale też z tego na ile modularnie pisana jest aplikacja)

Kod php również jest czytelny i nanoszenie poprawek jest proste. Argument bez sensu

większą odporność na awarie i błędy, możliwość automatycznego wyłapywania wszelkich nie obsłużonych wyjątków i wysyłanie ich natychmiast do osób, które się kodem opiekują. Dzięki temu błędy mogą być wyłapywane i naprawiane szybciej oszczędzając klientowi wstydu ("patrzcie jak im strona leży!, hahaha, hehehe"). W PHP można co najwyżej czekać aż jakiś wkurzony klient zgłosi błąd, którego nie wyłapali programiści. Ewentualnie pozostaje regularne przeczesywanie logów długo po tym jak błąd wystąpił. Mina klientów którzy, po kolejnym pehapowym fatal errorze, zobaczyli na ekranie biały ekran - bezcenna! (IMG:style_emoticons/default/laugh.gif)

Tutaj widać, że nie programujesz w php (IMG:style_emoticons/default/winksmiley.jpg) . Jedynym błędem jakiego nie da się wychwycić jest "Parse Error" czyli błąd składni. Wszystko inne można wychwycić. Fakt, że php nie ma tak rozbudowanej i restrykcyjnej struktury wyjątków jak np. Java, lecz to nie znaczy, że nie da się dobrze napisać aplikacji.


Reszty nie używałem więc nie wiem.