Zeznania programisty

Witam! Do jednego z projektów które realizuje zachciało mi się używać Zend Framework. Pożałowałem tego już nie jeden raz. Ale od początku. Kolega polecił mi Zend Framework. Zend Framework to zbiór bibliotek PHP5, które mają się przydać programiście podczas tworzenia aplikacji WWW. Zend Framework kojarzę po nazwie z firmą, która tworzy PHP – to powinno gwarantować jakość. Niestety tak nie jest. Zend Framework klepany jest bez mocnego przemyślenia. Świadczą o tym zmiany, jakie zachodzą pomiędzy kolejnymi wersjami tego szkieletu aplikacji. Kolejne wersje nie są kompatybilne wstecz, a dokument pomocy pisane dla starszych wersji nie są przydatne w wersji aktualnej. Miarka się przebrała, gdy doszedłem do klasy Zend_Translator. W dokumentacji jest obietnica tworzenia własnych rozszerzeń tej klasy, tymczasem jej błędna implementacja zabrania tego. Wspomnę tylko, że błędna implementacja tłumaczeń opartych na plikach pseudo CSV uniemożliwiła mi ich wykorzystanie. Spróbowałem napisać własną implementację plików CSV i podpiąć ją pod translatora, ale się to nie dało. Tak skończyła się moja cierpliwość. Nie po to mam framework, żeby go patchować. Zend Freamework 0.9.2 Beta jest bardziej Beta niż 0.9. Jestem pewny, że kolejne edycje nie będą kompatybilne wstecz. Uważam że Zend Framework to dobry pomysł, który idzie w złym kierunku. Programiści starają się dostarczyć coraz to nowych funkcjonalności, zamiast zrobić dobrze te, które już są i są podstawą framework. We frameworku nie muszę mieć implementacji np “Audioscrobbler”, zamiast tego chciałbym po prostu działający i dający się rozbudować moduł tłumaczeń. Na chwilę obecną odradzam użycie Zend Framework jako szkieletu aplikacji. A ja wracam do pracy, niestety, bo muszę napisać własny moduł tłumaczeń.

Kodowanie plików w Eclipse można ustawić w wielu miejscach:

1. Window / Preferences / General / Workspace
2. Window / Preferences / General / Contenty Types / Text
3. Project Explorer / _file_ / Properties

Co ciekawe, z koniecznością ustawienia Content Types spotkałem się tylko pracując z projektami PHP.

Czasami niestety zachodzi konieczność, przechowywania identyfikatora sesji w adresie URL. Ostatnio troszkę częściej – za sprawą nowych wymysłów w IE i problemu z ramkami. Dawno, dawno temu, gdy wymyślono ciasteczka, okazało się, że nie wszyscy je lubią. Niektóre języki programowania WWW umożliwiały więć przechowywanie ciasteczka (identyfikatora sesji) w adresie URL. I tak na przykład PHP, po wprowadzeniu zmian w konfiguracji:

session.use_cookies 1
session.use_only_cookies 0
session.use_trans_sid 1
url_rewriter.tags "a=href,area=href,frame=src,input=src,form=,fieldset="

przed wypluciem strony modyfikuje wszystkie linki znajdujące się na stronie doklejając identyfikator sesji jako parametr zapytania. To działa, ale nie zawsze. Gdy na stronie jest dużo JavaScriptu, konieczne jest inne rozwiązanie. Proponuję coś takiego: 1. Modyfikukejemy adres URL, ale zamiast parametrów modyfikujemy ścieżkę, np.:

index.php?PHP_Session=XXX
/PHP_Session.XXX/index.php

Możemy to zrobić na przykład poprzez Header( "Location: ..." ); 2. Piszemy odpowiednie regulu dla mod rewrite:

RewriteEngine On
RewriteRule ^(.*)(PHP_Session\.([^/]+))/(.*)/(.*) $1$4/$5 [L]
RewriteRule ^(.*)(PHP_Session\.([^/]+))/(.*) $1$4?PHP_Session=$3&%{QUERY_STRING} [L]

oraz wyłączamy niepotrzebne już nam trans_sid. I to wszystko. Dzięki temu nasz identyfikator sesji będzi wisiał jako część adresu URL. Paskudne (patrz XSS), ale czasami nie da się zrobić nic lepszego.

Debugowanie skryptów PHP jest sprawą mało przyjemną. Kluczem do poprawy jakości jest zapytanie w Google o “vim php debugger”. Po wielu godzinach instalacji wszystko zaczęło działać poprawnie. Straciłem na to wiele godzin, bo mój system jest skompilowany trochę inaczej, niż standardowy. Dzięki zgromadzonej wiedzy, cały proces instalacji można by skrócić do 1 godziny.

1. Zacznijmy od instalacji języka programowania Python. Testowałem dla wersji 2.4. Domyślna konfiguracja jest wystarczająca.
2. Warto pobrać najnowszą wersję VIM: “VIM 7″. Następnie skompilować go z obsługą pythona: ./configure –help | grep python ./configure –enable-pythoninterp make make install
3. Ze strony: http://www.vim.org/scripts/script.php?script_id=1152 pobieramy skrypt debuggera dla VIMa. Archiwum rozpakowujemy do katalogu ~/.vim/plugin/
4. Następnie należy zainstalować Xdebug: http://www.xdebug.org/install.php#source. Pobieramy źródła, kompilujemy: phpize ./configure –enable-xdebug make Kopiujemy moduł xdebug.so do katalogu który widzi Apach. W php.ini dopisujemy linię: zend_extension=xdebug.so Restartujemy Apacha. Polecenie phpinfo(); powinno przywitać nas informacją o zainstalowanym module Xdebug.
5. Budujemy plik .htacces dla programu, który chcemy debugować: php_value xdebug.remote_autostart On php_value xdebug.remote_enable On php_value xdebug.remote_handler dbgp php_value xdebug.remote_host localhost php_value xdebug.remote_mode req php_value xdebug.remote_port 9000
6. Odpalamy VIM, F5, szybko nawigujemy przeglądarką na nasz program i wracamy do VIMa. Przywita nas informacja o nawiązaniu połączenia. Teraz F2 i miodzio.

Ruszam do boju z nowym debuggerem PHP w VIMie. Aktualizacja: 30-maj-2006. Niestety debuger nie radzi sobie z dużymi aplikacjami www.

Jakieś 6 lat temu zacząłem programować w PHP. Język ten uważałem wtedy za technologie przyszłości, (przynajmniej mojej przyszłości), gdyż:

• technologia PHP jest za darmo
• programiści PHP są tanią siłą roboczą
• programowanie w PHP jest szybkie i tanie

Dziś moja ocena środowiska PHP jest negatywna. Gdy zaczynałem programować nie uwzględniłem niestety kilku ważnych aspektów tworzenia aplikacji. Patrząc dalekowzrocznie (10 lat) PHP jest bardzo złą technologią, otóż:

• brak kompatybilności wstecz
• utrudnione łączenie aplikacji
• konkurencja jest z przodu

Za najważniejszy problem związany z PHP uważam brak kompatybilności wstecz pomiędzy wersjami PHP4 i PHP5. Ten jeden czynnik dyskwalifikuje PHP w każdym projekcie, o którym myślimy dalekowzrocznie. Pisanie oprogramowanie w PHP5 wymusza ponowną analizę kodu stworzonego dla języka PHP4. W informatyce możemy łatwo policzyć czas potrzebny na napisanie nowej funkcji. Praktycznie nie możliwe jest określenie czasu potrzebnego na usunięcie błędu. Koszt portowania aplikacji do PHP5 jest bardzo trudny do wyceny. Obawiam się, że kolejne wersje tego języka także będą cierpieć na problemy wstecznej kompatybilności. Programowanie w PHP jest szybkie i tanie, ale tylko w krótkiej perspektywie. Dokładnie tak, jak w dowcipie o roztargnionym malarzu: Malarz dostał zadanie pomalowanie pasu na jezdni. Położył wiaderko na poboczu i pierwszego dnia pomalował 100 metrów, drugiego 50 a trzeciego 10. Gdy szef spytał co jest grane odpowiedział: wiaderko z farbą jest coraz dalej. Powtórzę to jeszcze raz. PHP jest tanie na krótką metę. Jestem pewny, że pisząc za 10 lat aplikacje w PHP7 nie będziemy mogli wykorzystać kodu napisanego 5 lat temu dla PHP4. Jeżeli ktoś może pozwolić sobie na takie marnotrawstwo, to proszę bardzo. Kolejnym problemem w pisaniu aplikacji w PHP jest to, że nie da się zrobić naprawdę dużego zintegrowanego systemu. Nie da się łączyć aplikacji. Powodem jest wiele: Najważniejsze to: brak jasno określonych standardów kodowania, brak specyfikacji dla bibliotek, brak przestrzeni nazw. Dla przykładu weźmy dwie aplikacje: czytnik poczty i forum. Chcemy je połączyć w jedną większą całość. Prawie na pewno napotkamy na następujące problemy: osobne i różnorakie bazy danych z kontami użytkowników, różne i niekompatybilne systemy szablonów (smarty,phplib), konflikty w nazwach obiektów i funkcji, a być może nawet to, że aplikacje będą oczekiwały sprzecznych ustawień dla zmiennych środowiskowych (magic_quotes_gpc). Po przeanalizowaniu tych problemów okaże się, że taniej będzie napisać aplikacje od nowa zamiast próbować łączy dwie już istniejące. Problem łączenia aplikacji jest dużo szerszy. Ciężko jest mi połączyć własne aplikacje napisane na przestrzeni kilku lat. Znacznie trudniej będzie połączy aplikacje napisane przez różne zespoły. Tworzenie dużych aplikacji w PHP jest po prostu nie możliwe. Gdy zaczynałem programowanie w PHP konkurencja w zasadzie nie istniała. Nie było takich technologii jak: .net, rubby-on-rails, zope (lub ich nie znałem). Inne dopiero raczkowały: J2EE. Od tego czasu technologia J2EE zrobiła ogromny postęp zakończony specyfikacją EJB3. Kodowanie dla platformy J2EE 6 lat temu wymagało 5 razy więcej kodu niż teraz i 10 razy więcej pracy niż w PHP. Dziś różnice się zatarły. Nadkład kodu w Javie rekompensują znakomite IDE. Przez ostatnie lata PHP wprowadziło wersje PHP5. PHP5 jest znakomity leksykalnie językiem, o możliwościach przekraczających Javę i zbliżonych do Pythona. Aczkolwiek z powodu braku wstecznej kompatybilności mało kto chce tego języka używać. Java swoją słabość składniową nadrobiła specyfikacjami Bean, EJB, JSR-*. Narodziło się programowanie aspektowe. PHP zrobiło duży krok w bok. Java olbrzymi krok do przodu. Dziś zdecydowanie odradzam pisania aplikacji w PHP. W ciągu 6 lat zmieniłem moją opinię na temat tego środowiska. PHP tak jak roztargniony malarz działa dobrze pierwszego dnia.