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]

Czemu od razu miszczu?

[PHP] pobierz, plaintext 
<?php
 
function shutdown() {
 
	if(($error = error_get_last())) {
		ob_clean();
		echo('Blad: '.$error['message']);
	}
}
 
register_shutdown_function('shutdown');
 
function jakis_kod() { return null; }
 
    $obj = jakis_kod();
    $obj->not_existing();
 
?>
[PHP] pobierz, plaintext 

Muszę o 5 wstać więc tak pisane na szybkiego.

[hipertracker]

register_shutdown_function('shutdown');

No dobrze, zwracam honor. Jednak coś w końcu dodali. Dziwne jak mało ludzi jest tego świadomych. W dosyć dużej firmie pehapowej w jakiej miałem okazję pracować, oni wciąż bawili się w analizę logów przekonani, że nie ma możliwości napisania kodu ktory by jakoś wyłapywał takie cięższe błędy i wysyłał informację o tym w inne miejsce.

Narzekając, mogę dodać, że znowu coś dodali, ale byle jak. Tą metodą nie da się wykonać przekierowania na stronę wyświetlającą ładnie sformatowaną informację dla usera. Musisz więc w ten handler upchnąć całą odpowiedź.

Czytam ten temat i nie mogę wyjść z podziwu nad tym, jak można doprowadzić do perfekcji stosowanie chwytów erystycznych (w tym negatywnym znaczeniu). Marketingowcy Ruby i Rails opanowali to naprawdę znakomicie.

Jaki marketing, jaka erystyka? Pleciesz coś bez sensu zamiast napisać coś merytorycznego.

tylko w sumie 3 języki mają jakieś dowiązania: C++, Smalltalk i Java. Spośród nich C++ ma najgorsze. Dodatkowo każdy z tych (i nie tylko tych) języków pozwala na samodzielne napisanie takiej bazy w zależności od wymagań projektu, więc to nieco dziwne by uznać ów przykład za wadę/wyższość jednego języka nad innym.

Wyższością języka zgodnego z JVM jest możliwość podpięcia się do tych wszystkich rzeczy. PHP tego nie potrafi, bo nie ma dobrej implementacji na JVM.

Źle zaprojektowana aplikacja i trzymanie złych nawyków, złych wzorców rozłoży każdy projekt i sprawi, że będzie nieczytelny do granic możliwości.

Owszem, jednak jakimś dziwnym zbiegiem okoliczności złe praktyki takie jak spaghetti code są najczęściej domeną pehapowców. Każdy javowcy uczy się wzorców projektowych, railsowcy są prowadzeni za rękę przez swój framework, więc omijają parę problemów trochę w sposób nieświadomy. Rails

tutaj plus dla języków, które mają pewne mechanizmy wbudowane. Nie wiem jak w Rubym to jest zrobione, ale zapewne nie jest to "out of box" i sam to musisz oprogramować by działało jak opisujesz.

W Django i web2py to jest dokładnie out of box. W Rails nie, ale łatwo to dodać. W najproszczej implementacji wystarczy założyć pułapkę na wszystkie wyjątki i już. W Ruby nie ma kategorii fatal errorów (no chyba że błąd składni, ale taki kod się po prostu w ogóle nie uruchomi). Wszelkie błędy są spójnie zgłaszane za pomocą systemu wyjątków. Zatem można je obsłużyć w jednolity, prosty sposób.

[RUBY] pobierz, plaintext 
begin
  # jakiś kod co się zwalił
rescue
  # mogę obsłużyć dowolny wyjątek
  # wysłać maila, przekierować na inną stronę, itp
ensure
  # tu zawsze przejmę sterowanie bez względy na to czy był wyjątek, czy nie
  # np. mogę upewnić się że zostanie zamknięty plik, albo połączenie z bazą
end
[RUBY] pobierz, plaintext 

W PHP natomiast, mimo wprowadzenia obsługi wyjątków, funkcje wbudowane w ogóle nie są tym objęte. To bardzo komplikuje wyłapywanie tych błędów. Skoro dodali wyjątki to powinni nimi objąć także wszystkie funkcje wbudowane. A dla wstecznej kompartybilności dodali by jakaś flagę dla ini_set'a i już. Proste?

Nie ma takiej aplikacji, która klienta nietechnicznego by "nauczyła posługiwać się" informatycznymi terminami lub przetworzyła język naturalny na specyfikację techniczną. Są tylko tego mniej lub bardziej udane próby.

Akurat Cucumber to dosyć udana próba i aktualnie główny sposób pisania specs dla Ruby. Na dodatek obsługuje nie tylko jęz. angielski, ale także inne języki narodowe. Wyobraź sobie że ten poniższy kod to jest nie jakaś beletrystyka, ale dokładnie kod testu, tak się pisze testy behawioralne w Ruby. I jeśli ktoś sobie życzy, mogą być po polsku, bo nie każdy klient musi znać angielski. Przykład za http://github.com/aslakhellesoy/cucumber/t...18n/pl/features

Kod

# language: pl
Właściwość: Dodawanie
  W celu uniknięcia głupich błędów
  Jako matematyczny idiota
  Chcę sprawdzić wartość sumy dwóch liczb

  Szablon scenariusza: Dodaj dwie liczby
    Zakładając wprowadzenie do kalkulatora liczby <liczba_1>
    Oraz wprowadzenie do kalkulatora liczby <liczba_2>
    Jeżeli nacisnę <przycisk>
    Wtedy rezultat <wynik> wyświetli się na ekranie

  Przykłady:
    | liczba_1 | liczba_2 | przycisk | wynik  |
    | 20       | 30       | dodaj    | 50     |
    | 2        | 5        | dodaj    | 7      |
    | 0        | 40       | dodaj    | 40     |

Właściwość: Dzielenie
  W celu uniknięcia głupich błędów
  Kasjer musi znać się na ułamkach

  Scenariusz: Zwykłe liczby
    Zakładając wprowadzenie do kalkulatora liczby 3
    Oraz wprowadzenie do kalkulatora liczby 2
    Jeżeli nacisnę podziel
    Wtedy rezultat 1.5 wyświetli się na ekranie

A tu jest kod Ruby'ego który powyższy DSL przetwarza:

[RUBY] pobierz, plaintext 
# encoding: utf-8
begin require 'rspec/expectations'; rescue LoadError; require 'spec/expectations'; end
require 'cucumber/formatter/unicode'
$:.unshift(File.dirname(__FILE__) + '/../../lib') 
require 'calculator'
 
Before do
  @calc = Calculator.new
end
 
After do
end
 
Zakładając /wprowadzenie do kalkulatora liczby (\d+)/ do |n|
  @calc.push n.to_i
end
 
Jeżeli /nacisnę (\w+)/ do |op|
  @result = @calc.send op
end
 
Wtedy /rezultat (.*) wyświetli się na ekranie/ do |result|
  @result.should == result.to_f
end
[RUBY] pobierz, plaintext 

W dynamicznym środowisku webowym, gdzie mogą następować przełączania serwerów, częste zmiany osłabiają znaczenie dynamicznej kompilacji.

Jakie przełączanie? Chyba masz na myśli wyłączanie. To jakiś nonsens. Serwer jest po to aby uruchomiony wykonywał obsługę wielu requestów a nie restartował się przy każdym. Stąd JVM idealnie nadaje się do zastosowań serwerowych, do desktopowych trochę gorzej.

Ten post edytował hipertracker 7.09.2010, 02:08:49