autorzy: Mika Tuupola (tuupola@appelsiini.net), Pierre-Alain Joye (paj@pearfr.org), tłumaczenie: Robert Janeczek (rashid@php.net)
Od tego tygodnia rusza nowa sekcja nowinek tygodniowych PEAR - "Pakiet tygodnia". W tym tygodniu omawiamy APD autorstwa George Schlossnagle, profiler/debugger "pełną gębą".
Listy mailowe były dosyć spokojne. Konsekwentnie wzrasta ruch w CVS i ukazuje się więcej wydań niż zwykle. Podczas pisania tego podsumowania nowych wydań w tym tygodniu było 14.
Omówimy szczegóły obsługi błędów w konstruktorach, nowych cech phpDocumentora, kolejny tutorial dla Mac OS X i siedem proponowanych pakietów.
George rozpoczął pracę na systemach UNIXowych 12 lat temu od pisania procedur do analizy różniczkowej w FORTRANIE. Z webem zaczął się bawić 8 lat temu, a od pięciu lat zajmuje się tym zawodowo. Aktualnie jest konsultantem w OmniTI Computer Consulting, firmie działającej w branży konsultingu technologicznego, specjalizującą się w budowie i zarządzaniu skalowalymi systemami web i email.
Jedyną rzeczą, której żałuję w związku z publikowaniem apd w PECL jest to, że nie zrobiłem tego wcześniej. Z punktu widzenia zarządzania kodem i wersjami praca w PECL nie różni się od pracy nad lokalnie zarządzanymi projektami. Narzędzia do publikowania PEAR czynią publikowanie kolejnych wersji bardzo prostymi. Oprócz tego obserwuję zwiększone zainteresowanie projektem ze strony społeczności PHP. Dowiedzenie się, że apd zostało łatwo zainstalowane pod 4.3 za pomocą instalatora PEAR (bez wysiłku z mojej strony) jest naprawde bardzo przyjemne.
Sądzę, że PEAR i PECL są przyszłościowymi rozwiązaniami w kwestii rozszerzania PHP i zarządzania pakietami. Poprzez oddzielenie wersji PHP od wersji rozszerzeń możemy zwiększyć szybkość, jakość i częstość wydań PHP. Osobiście mam nadzieję na zwiększony nacisk na testy poszczególnych modułów i pakietów PEAR/PECL (moje własne pakiety bardzo tego potrzebują). Dodanie testów powinno ułatwić przerabianie i zmniejszyć ryzyko potrzeby zmian w innych pakietach, które są od nich zależne. Jako, że testowanie modułów w procesie buildowania php staje się coraz dojrzalsze i coraz więcej rozszerzeń jest przenoszonych do PECL, mam nadzieję zauważyć poprawę kompatybilności międzyplatformowej wielu sPECLowanych rozszerzeń.
apd jest zend_extension, które dodaje możliwości profilowania i debugowania do Zend Engine. apd miał skromne początki. Mój kolega - Dan Cowgill - był bardzo sfurstrowany brakiem pełnych możliwości śledzenia stosu wywołań (to było w czasach 4.1, długo przed pojawieniem się debug_backtrace()). Po dodaniu tej możliwości, stało się oczywiste, że stworzony przez nas engine ma znakomity interfejs do tworzenia informacji do profilowania skryptów.
Możliwość profilowania okazała się bardzo przydatna do pracy, którą w tym czasie się zajmowałem. Wymagałą ona podniesienia wydajności środowiska produkcyjnego dla kilku stron - kod miał kilka milionów linii kodu. Bez możliwości profilowania optymalizacja skryptów była jak zgadywanka. Po uruchomieniu wersji pre-0.1 apd, potrafiliśmy zwiększyć na części stron wydajność o 500%.
Tuż po wstępnym wydaniu, Thies Arntzen zgłosił potrzebę zaimplementowania udostępniania informacji profilujących nie w formacie przydatnym dla człowieka, a czymś użytecznym dla narzędzia gprof. Trochę to zajęło, ale wraz z wersją 0.3 format 'pprof' został standardowym i wśród plików umieściliśmy narzędzie 'pprofp' do jego odczytu. To był znaczący krok, ponieważ pozwalał łatwo przeprowadzić przetwarzanie po śledzeniu (wyświetlanie grafów wywołań, wyświetlanie przy użyciu różnych metryk czasowych itp.)
apd ma również inne ciekawe możliwości. Najbardziej zauważalne jest wsparcie dla w pełni interaktywnego debuggera, które zostało napisany przez Alan'a Knowles. To pozwala środowisku programistycznemu na wykonywanie skryptu krok po kroku a także ma możliwość wyświetlania i modyfikacji zmiennych w każdym kroku. Jedynym środowiskiem o którym wiem, że wspiera to w pełni jest niesamowity phpMole Alan'a, które to narzędzie polecam wszystkim zainteresowanym dobrym php ide.
Kilka możliwości nie jest powszechnie używanych, należą do nich funkcje rename_function() i override_function(), które pozwalają na podmianę istniejącej funkcji w tablicy symboli na jakąś inną. Miło by było zintegrować funkcje podobne do tych z Zend Engine. Inne właściwości prawdopodnobnie się przeterminują z czasem. Polecenia do śledzenia stosu zostały dodane jako debug_backtrace i debug_print_backtrace, a funkcje do przeglądu tablicy symboli nie są specjalnie użyteczne.
Miliarda dolarów... mwahaha!
A tak na poważnie, to kiedy zacząłem pisać oprogramowanie open
source w 1999, mylnie sądziłem, że stworze projekt i ludzie
się będą zabijać, żeby dodać funkcjonalność, której potrzebuje. To
zdecydowanie nie tak działa. W rzeczywistości, podobnie jak większość
programistów open source, których znam, spędza conajmniej tyle samo
czasu dodając funkcjonalność, której potrzebują inni ludzie, co
dodając to, czego się potrzebuje samemu. Moim celem podczas
pisania apd było przede wszystkim utworzenie narzędzia, które
pomoże mi w mojej pracy a na drugim miejscu pomagać innym w wykonywaniu
podobnych zadań. Jeśli apd pomaga ludziom pisać szybszy i lepszy kod,
to projekt jest sukcesem jak dla mnie.
Chciałbym podziękować społeczności użytkowników apd za:
Tutorial opisujący korzystanie z PEAR na Mac OS X wspomniany w poprzednim wydaniu jest obecnie również opublikowany na MacDevCenter. Ponieważ ta strona jest częścią O'Reilly Network o PEAR będzie nieco głośniej dzięki temu artykułowi.
Jeśli ktokolwiek z was wyczyta gdzieś artykuły, czy newsy o PEAR - chętnie umieścimy odnośniki do nich w weekly news, wystarczy nam je podesłać (pear-dev@lists.php.net).
Ostatnio miała miejsce krótka dyskusja na temat sugerowanego sposobu obsługi błędów w konstruktorach. Odpowiedź jest naprawdę prosta: mimo tego, że jest możliwe ustawienie $this na instancję PEAR_Error, to odradzamy użycie tej nieudokumentowanej możliwości. Zachowanie to zmieni się w PHP5. Lepszym sposobem jest unikanie wszelkich zawodnych operacji w konstruktorze i użycie osobnych metod w miejscach gdzie może być potrzeba zwrócenia błędu. Dobrym przykładem takiej metody powinna być dowolna metoda wzorca factory.
Grupa rozwijająca phpDocumentor zaimplementowała nowe tagi w ich narzędziu dokumentacyjnym. Są wśród nich taki takie jak @source, @internal, @filesource, @example czy @internal. W poszukiwaniu większej ilości informacji przeczytaj release notes.
Dzięki tym ludziom wykryto kilka nowych błędów: Ondrej Jombik, Andres Käver, Patrick O'Lone, Bruno Pedro and Samuli Tuomola
Lorenzo Alberton przeniósł DB_QueryTool Wolfram'a Kriesing tak, aby współpracował z MDB.
Kubo Atsuhiro zaproponował Net_UserAgent_Mobile, który może być używany do odczytu właściwości wyświetlania telefonu komórkowego keitai. Wspierane systemu to i-mode NTT DoCoMo, EZweb KDDI i J-Sky J-PHONE.
Yavor Shahpasov zaproponował nowy kontener dla Auth. Umożliwia on autentykację przy użyciu serwerów POP3.
Michael Bretterklieber, opiekun PECL::radius, zaproponował kilka pakietów związanych z autentukacją. Auth_RADIUS jest nakładką na PECL::radius. Crypt_CHAP jest używane do generacji pakietów CHAP dla różnych wersji CHAP. Auth_Container_Radius jest nowym kontenerem dla pakietu Auth.
Bertrand Mansion zaproponował pakiet SearchEngine_Mnogosearch, który jest interfejsem PHP do popularnej wyszukiwarki mnoGoSearch.
Ruch w CVS w tym tygodniu odbywał się w następujących pakietach: HTML_Template_Flexy, Cache_Lite, PECL::Radius, PEAR, DBA, DBA_Relational, HTTP_Header, MDB, Net_SMTP, Mail, Log, File, I18N, SpreadSheet_Excel_Writer, MDB_QueryTool, Payment_Clieop, PECL::bcompiler, Tree, DB_QueryTool, HTML_Template_Xipe, DB_DataObject, HTML_QuickForm, PECL::imagick, Auth, SearchEngine_Mnogosearch, Net_URL, HTTP_Request i PECL::apd.