Forum PHP.pl

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.

Jest naprawdę świetny.
99% odpowiedzi na pytanie "dlaczego przepisano wykop.pl z RoR na PHP" to - "Bo jest za mało programistów RoR i prace szły zbyt wolno".
Ale zaraz zaraz !
Przecież RoRowcy się chwalą, że ich społeczność dorównuje - i uwaga cytuję forum RoR "a nawet przewyższa ilością społeczność PHP"
(jak odnajdę ten cytat, to dodam linka).
Po za tym, "RoR jest tak doskonały, że podczas roboczogodziny programista RoR wykona kilka razy tyle backlogów (wg slangu SCRUM) co kilku programistów PHP".

Powiem szczerze, że wykop.pl to ne jedyny przypadek.
Nie mogę podawać konkretnych webaplikacji, ponieważ znajomi od których mam takie informacje (przeważnie Symfoniarze lub Zend'iarze, że się tak miło wyrażę)
powiesiliby mnie i rozstrzelali za plotkartswo, jeśli trafiliby na ten wątek.
Panoć kiedyś na jakimś blogu ktoś wymyślił nowe polskie przysłowie:
"Napisz na swojej stronie, że programujesz w Rails i PHP, a zaraz znajdą się klienci, którzy będą prosić o przepisanie czegoś z RoR na PHP".




Czy chodzi o ten punkt:
"Programista RoR MUSI być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.".

A co do sporów to podobno na jakimś spotkaniu rozstrzygnięte było przez rękoczyny (IMG:style_emoticons/default/smile.gif)



Dzięĸi za wszystkie opinie.
Mam nadzieję, że temat szybko nie umrze.

Ten post edytował Wiktor P. 10.06.2010, 18:43:45

No wiesz - marketing, to marketing - zachwalanie danego rozwiązania. Niekoniecznie musi być najlepsze.

Co do przepisywania serwisów, to nie jest to żadna nowość. Wiele serwisów jest przepisywanych na inną platformę (kiedyś w Stanach były modne migracje do ASP, .NET - bo dział marketingu wymyślił (IMG:style_emoticons/default/winksmiley.jpg) ), tworzonych od nowa etc. - pouczający artykuł http://www.webnodes.com/a-total-rewrite-co...ng-but-worth-it

Dzięki Zyx za opinię.
Zawsze napiszesz coś konkretnego.
W całym temacie boli to, że trudno znaleźć konkretne za i przeciw, jeśli
jedna ze stron twierdzi, że PHP jest be, bo tak i koniec.
Tak jak to pisał Tom Negrino, autor podręczników do Ajaxa:

" (...) przykład jednej z najbardziej irytujących cech przemysłu komputerowego: tryumf marketingu nad treścią.".

Rozmawiałem z człowiekiem, co piąte przez dziesiąte pokumał się w Railsach.
Mówię mu - opowiedz jak to działa, jak to wrzucić na serwer itp.
Czy szablony muszą być w języku Ruby ?
Czy ORM "to zestaw obowiązkowy" ?
A on do mnie, że mam mózg wyprany przez PHP, że to są pytania nie na miejscu.

Mam wrażenie, że z 5 lat temu dyskutowało się o różnych rozwiązaniach, wyciągało wnioski, podkreślało zalety i wady jakichś rozwiązań.
Za 5 lat będą nas uważać za grupę, która jak dresiarze obrzuca się wyzwiskami, bo ten jeździ BMW, a ten VW.


PS Dzięki Zyx za wielokrotne i uargumentowane wypowiedzi na tym forum dot. Linuksa.
Właściwie to przez twoje argumenty i argumenty Thek'a od około roku jestem zadowolonym użytkownikiem pinginwa (IMG:style_emoticons/default/smile.gif)

@Zyx - Są trzy warstwy.
Model (uproszczony do mixu ORM i Row Data Gateway)
Widok - elastyczny system prezentacji danych w dowolnym formacie (wraz z możliwością kodowania za pomocą komponentów jeśli bierzemy pod uwagę użycie do stron www)
Kontroler - kontroluje wyniki operacji na modelach lub na Modelu Dziedziny (jeśli ktoś się na taki skusi) i wybiera widoki lub forwarduje żądanie do innego kontrolera.

Jedyna różnica pomiędzy MVC klasycznym, a tym webowym jest taka, że w klasycznej aplikacji możesz zaprezentować widok i jednocześnie wykonywać żądania, a w webowej masz pasywny widok, który nie ma fizycznej możliwości interakcji z systemem. Można to symulować AJAXEM lub wspomnianym wcześniej programowaniem komponentowym. Nadal nie jest to jednak to samo, co w przypadku podtrzymujących proces języków. Żądanie to inicjalizacja programu. To nadal jednak jest MVC chć schemat pracy wygląda najczęściej tak:


CMV CMV CV CMV.. wysłanie dokumentu

CMV - Akcja listPosts, model Post, widok show.php
CMV - Komponent (akcja) lastVisits, Model Visitors, widok lastVisits.php (wtłoczony do show.php)
CV - Komponent myFooter, widok myFooter.php (wtłoczony do show.php, pomijam oficjalnie Model, bo np jest to tekst wklepany na sztywn)

Na mój rozum, to tu jest używany trójwarstwowy system, który posiada wszystkie elementy MVC, wiec jest to MVC. W makro i mikro skali.

Pozdrawiam

@Wiktor P.: nie tylko, ogólnie wszystkie uwagi do serwera są nietrafione. Ustawienie PHP na serwerze nie jest takie trywialne, jak to wszyscy stwierdzają, a z kolei instalator Ruby (z tego, co zaobserwowałem) nie jest jakoś przesadnie skomplikowany (IMG:style_emoticons/default/smile.gif)

http://www.goldenline.pl/forum/891204/php-...ch-programistow poczytaj bedziesz mial argumenty za i przeciw sa tam niestety fanboy'e rubiego,python'a jak i php'a ale da sie wyciagnac konstruktywne odpowiedzi.

Nic wiecej pisac nie bede bo nie widze takiej potrzeby:]

Cysiaczek ->

1. Jeśli model upraszczasz do ORM-a, to wypaczasz jedną z podstawowych koncepcji MVC, która polega na tym, że od strony zewnętrznej mamy się nie zajmować w ogóle tym, skąd model te wszystkie dane bierze i gdzie je umieszcza. A spróbuj w pierwszym lepszym frameworku zrobić model korzystający z plików, zamiast z bazy danych i nie pochlastać się przy tym.

2. Pasywny widok nie jest jedyną zmianą w warstwie V. W MVC widok powinien samodzielnie pobierać dane z modelu, w domyśle poprzez jakiś "dobrze zdefiniowany interfejs". W prawie wszystkich frameworkach tymczasem masz zrównanie widok = szablon oraz jawne pośrednictwo kontrolera w przekazywaniu danych z modelu do widoku. Może się wydawać, że to banał, ale wystarczy choć raz zrobić to tak, jak sugeruje MVC, by przekonać się, że te dwie głupoty całkowicie zmieniają sposób programowania oraz właściwości wzorca. Paradoksy, które się pojawiają:
- Kontroler jest zależny od sposobu prezentacji, ponieważ jej logika z braku laku musi wylądować właśnie w kontrolerze (logika = np. system stronicowania, obsługa sortowalnych kolumn na liście wyników i ogólnie wszystko, co wymaga jakiegoś choćby banalnego menedżera sprawującego nad tym pieczę).
- Szablony są dostosowane najczęściej tylko do generowania HTML-a. PDF-a już sobie widokiem nie wygenerujesz, tymczasem zgodnie ze wzorcem MVC powinieneś być to w stanie prosto w tej warstwie zrobić.

Samo nazwanie trzech warstw modelem, widokiem i kontrolerem nie sprawia jeszcze, że uzyskujemy MVC. Ważne jest też, jak te elementy są połączone. Tak samo nazwanie czegoś obserwatorem i obserwowanym nie daje nam jeszcze wzorca Obserwator (IMG:style_emoticons/default/smile.gif) . A tak w ogóle jak wyrzucisz bezpośrednie pobieranie danych przez widok z modelu, to taki wzorzec ma swoją fachową nazwę: Model-View-Presenter.

Przy czym ponownie zaznaczam: każdy programuje, jak mu wygodnie. Jednak jeśli powołuje się na wzorce projektowe, to niech powołuje się zgodnie z zasadami przyświecającymi wzorcom.

Ten post edytował Zyx 11.06.2010, 19:59:53

@Zyx im dłużej o tym piszesz tym bardziej jestem skłonny dać się porwać. Brakuje mi tylko jednego: przykładu. Nie ukrywam, że byłoby miło gdybyś zaprezentował model, widok i kontroler. Mam kilka wątpliwości, a taki przykład mógłby pomóc.

Rozumiem to co piszesz, ale jeśli masz chwilę, pokaż jakiś kod w PHP, demonstrujący to co opisujesz w akcji, bo ja tego, póki co, nie widzę jako możliwego do zrealizowania, a przynajmniej nie jako funkcjonalnego szkieletu dla php.

Pozdrawiam

Na szybko taką realizację MVC można zobaczyć w Joomli - niestety jest to jedyna dobra rzecz, jaką można powiedzieć o jej kodzie. Eksperymentalnie wykorzystałem tę koncepcję w jednym projekcie, więc jest to jak najbardziej realizowalne (i co ważniejsze, przy dobrym zaprojektowaniu interfejsów efekt wychodzi naprawdę fajny) - niestety ponieważ był to projekt komercyjny, a sama implementacja też była robiona na szybko i na zasadzie "wchodzenia w nieznane", nie mogę jej ot tak udostępnić z przyczyn niezależnych.

Natomiast od jakiegoś czasu pracuję już nad stosowną samodzielną implementacją i jak tylko osiągnie ona sensowny poziom, mam zamiar udostępnić ją na Githubie. Niestety trochę to trwa, ponieważ wymaga to w zasadzie stworzenia frameworka całkowicie od zera, i to w dodatku bez żadnego punktu odniesienia, przez co trzeba się zastanowić nad każdą głupotą, by to miało ręce i nogi. W międzyczasie postaram się w najbliższych dniach opublikować jakiś wpis z praktycznymi przykładami u mnie na blogu, żeby można było na podstawie kawałków kodu zobaczyć, z czym to się je.

Co do marketingu RORa - powstał jako nowa technologia/FW - ludzie ktorzy go uzywali zobaczyli ze jest dobry i aby moc w nim robic projekty ROR (czyt znalezc klientow ktorzy zgodza sie na projekt w ROR) musial byc znany - rozpoznawaly, miec wystarczajaca ilosc ludzi ktorzy by mogli przejac po kims projekt w ROR (patrz Wykop). I od tego zaczela sie ewangelizacja, promowanie, wspieranie projektow około RORowych i Ruby'owych. To chyba normalne. Jak ADobe stworzył FLEXa to pewnie tez go promowal, reklamowal, wychwalal.



Co do administracji - PHP jest bardzo popularne, hosting jest trywialny - wpoldzielone konto, dostep przez FTP - jesli ci to wystarcza ok. Ale aktualizacja duzego projektu przez FTP to koszmar, brak SCM. Brak mozliwosci odpalania dodatkowych procesow (NoSQL bazy, cache, etc.) - jestes zdany na konfiguracje serwera od uslugodawcy. W PHP latwo postawic mala aplikacje szybko. Dlatego tez umiejetnosci administratorskie nie sa tu prawie wymagane.

ROR praktycznie wymaga osobnego serwera (jak nie wiecej), odpalania dodatkowych procesow, zarzadzania nimi == wymaga wiecej administracji. Ale, jesli bedziesz wdrazal appa w PHP na dedyku to tez musisz go skonfigurowac, nim zarzadzac, odpalac dodatkowe aplikacje etc, wiec IMO bez roznicy - wszystko zalezy od sposobu deploya i wielkosci aplikacji.



Straszne, slyszalem ze wyszla wersja ROR 3 (powstawala chyba ponad rok, jako merge ROR 2 + Merba) - jakos im ta klotnia niezbyt przeszkodzila.




Nikt nie kaze ci aktualizowac RORa do najnowszej wersji. I "jakiejkolwiek" to naduzycie.
Takie symfony tez sie zmienia i musisz poprawiac zmienione ficzery.
Jesli chcesz utrzymywac dluzej aplikacje to raczej chcesz uzywac aktualnych wersji FW'a - jest poprawiany, optymalizowany itp - jak masz testy dla systemu - jest do znacznie prostsze.

(IMG:style_emoticons/default/haha.gif)

az sprawdziłem czy mi słoma z butów nie wystaje... kurcze i jedno źdźbło znalazłem, mam nadzieje że sąsiada (IMG:style_emoticons/default/sad.gif)

Ale tępa opinia.
Przypomnijcie mi: Facebook jest w PHP? (IMG:style_emoticons/default/tongue.gif)

Ale jedzie na HipHopie więc w sumie ciężko powiedzieć co to jest (IMG:style_emoticons/default/tongue.gif)