PHP: Kategoria poświęcona w całości technologiom server-side, a w szczególności PHP. Uwaga: starsze wpisy o tej tematyce znaleźć można także w "Programowaniu", ponieważ ta kategoria jest relatywnie nowa.
PHP: Kategoria poświęcona w całości technologiom server-side, a w szczególności PHP. Uwaga: starsze wpisy o tej tematyce znaleźć można także w "Programowaniu", ponieważ ta kategoria jest relatywnie nowa.
Rekurencja definiowana jest jako odwoływanie się funkcji lub definicji do samej siebie. Od strony programisty jest bardzo wygodnym narzędziem upraszczającym wiele algorytmów, lecz dla komputera oraz interpreterów stanowi niezły pożeracz zasobów. W tym wpisie pragnę skupić się na języku PHP, gdyż od pewnego czasu "odrekurencyjniam" Open Power Template'a, w związku z czym mam świeży materiał badawczy :).
Przeglądając ostatnio forum php.pl natknąłem się na kolejny już temat, w którym autor miał problemy z układaniem ścieżek dostępu do plików w dość rozbudowanej strukturze katalogowej swego projektu. Sprawa niby wydaje się banalna: ot, wpisać ścieżkę i tyle. Gdy jednak dodamy do tego sprawy związane z rozwijaniem kodu oraz systemu plików (katalogi robocze i te sprawy), okaże się, że bez przemyślanej strategii i jakiegoś zarządcy po prostu zginiemy. Co tu dużo mówić - przyjemny temat na artykuł.
Dzisiaj pragnę przedstawić małą kwestię związaną z hermetyzacją danych w PHP, a konkretniej jawnym dostępem do danych prywatnych jednego obiektu z poziomu innego obiektu. Myślę, że może się to komuś przydać, gdyż dokumentacja wspomina o tym tylko pośrednio (podobnie jak typowa książka o PHP) i czytelnik przy pierwszej lekturze niekoniecznie musi się natychmiast zorientować, co naprawdę oznaczają zawarte tam słowa.
Pod koniec zeszłego roku montowałem sobie silnik w PHP, lecz prace nad nim wstrzymałem z powodu OPT. Postanowiłem go wczoraj uruchomić na nowopostawionym FastCGI ot tak, żeby sprawdzić, jak się trzyma. Okazało się, że kod się niesamowicie sypał. Nie działało wykrywanie środowiska pracy, translacja adresów w routerze oraz kilka innych rzeczy. Szybki rzut oka wystarczył, by zorientować się, że "awaria" dotknęła wszystkich komponentów, które opierały swoje działanie na dostarczonych z serwera danych o żądaniu.
Z powodu porządków na stanowiskach pracy postanowiłem dla próby zainstalować sobie Lighttpd zamiast Apache'a. Z serwerem tym miałem już wcześniej do czynienia podczas stawiania serwera, lecz z powodu braku niektórych możliwości musiałem wtedy z niego zrezygnować. Natomiast na domowy komputer - czemu nie, tym bardziej że pamiętałem łatwość, z jaką uruchamia się na nim FastCGI.
Nie cierpię używać gotowych skryptów innych, niż biblioteki, wszędzie tam, gdzie potrzebuję dwujęzycznej strony WWW. Niemal całe tego typu oprogramowanie jest napisane przez Anglosasów, a oni z racji, że ich język ma dominującą pozycję w Internecie, mają o tym ZEROWE pojęcie. W sumie nie dziwię im się - jak robią jakiś projekt, wystarczy, że zrobią stronę po angielsku i już mają ustrzelony zarówno rynek krajowy, jak i narodowy. A tymczasem co ma w tej sytuacji zrobić Polak?
Opracowanie rozwiązań mających służyć przez długie lata bez konieczności wprowadzania większych zmian lub wywalania dotychczasowych osiągnięć na śmietnik jest czasochłonne. Niezbędna jest umiejętność planowania oraz przewidywania. Obecnie tworzę taki właśnie skrypt, który ma z założenia wytrzymać w użyciu dłużej, niż rok. Nie poprzestaję jedynie na elastycznej strukturze, lecz staram się także wdrożyć rozwiązania przyszłościowe bądź dostępne wyłącznie tzw. "garstce wybrańców". W tym wpisie pragnę omówić kilka z nich.
Domyślne rozwiązania zaimplementowane w systemie szablonów OPT powinny w zupełności wystarczyć większości jego użytkowników. Mogą oni po prostu skopiować kilka plików do swojej struktury katalogowej i zacząć kodować. Są jednak sytuacje, kiedy trzeba pokusić się o lekkie zmodyfikowanie działania OPT tak, aby dostosować je do naszych potrzeb. Niedawno sam znalazłem się w takowej, gdyż zaszła konieczność takiego zmodyfikowania mechanizmu wybierającego szablony, aby przeszukiwał kilka katalogów, a nie jeden zdefiniowany domyślnie w dyrektywie root.
W poprzednim wpisie porównywaliśmy szybkość odczytu różnych formatów danych dostępnych w PHP, a także ich możliwości. Ponieważ jednak po jego opublikowaniu pojawiły się nowe pytania, zdecydowałem się napisać kontynuację, w której postaram się je wyjaśnić. Przyjrzymy się kompilowanemu rozszerzeniu Syck do parsowania YAML w PHP, które znalazłem w repozytorium PECL - jednak więc takie coś istnieje, tyle że w wersji beta, a wyszukiwarka niestety nie pomaga w jego znalezieniu, jeśli nie zna się tej nazwy. Ponadto porównamy szybkość SimpleXML oraz DOM. Procedura testowa pozostaje ta sama.
Napisałem już trochę kilobajtów kodu nowego silnika, lecz wciąż nie zdecydowałem się na jeden, konkretny format przechowywania konfiguracji oraz plików informacyjnych. Podstawowe pytania to: jakich możliwości od danego formatu oczekuję oraz jak przedstawia się sprawa wydajności. Dlatego postanowiłem zrobić mały benchmark i uszeregować wszystkie formaty, jakie zdołałem do czasu napisania wpisu wymyślić w kolejności od najszybszego do najwolniejszego. W szranki stanęły: zserializowane tablice, same skrypty PHP, pliki INI, XML oraz YAML. Pierwsze cztery obsługiwane są "sprzętowo" przez interpreter, w ostatnim przypadku trzeba zadowolić się napisanym w PHP parserem Spyc.
