Obecnie, aby odpalić jakąkolwiek aplikację WWW napisaną w PHP potrzebujemy serwera WWW. Może być to Apache czy też nginx. Jednakże, czasami chcielibyśmy skorzystać z czegoś lekkiego, bez ogromnych możliwości konfiguracyjnych jakie oferują nam produkcyjne serwery WWW. M.in właśnie dlatego w przypadku Django czy też RubyOnRails wykorzystywane są serwery deweloperskie, dzięki którym bardzo szybko można „postawić” lokalnie działającą aplikację.
PHP w wersji 5.4 ma posiadać wbudowany serwer developerski, ale dzięki temu że z sieci można pobrać i samodzielnie skompilować wersję alpha2, nie omieszkałem tego uczynić i na własnej skórze przetestować to rozwiązanie. Poniżej przedstawiam wyniki mojego małego R&D.
Procedurę instalacji przedstawię na przykładzie systemów POSIXowych.
Najpierw pobieramy archiwum z PHP w wersji alpha2. Następnie rozpakowujemy je, przechodzimy do wypakowanego folderu i kompilujemy. Krótki przewodnik jak skompilować PHP znajdziecie na Wikibooks. Od siebie dodam, że w tym wypadku nie zależy nam na dodatkowej kompilacji PHP jako modułu Apache’a, skoro plik wykonywalny PHP sam sobie będzie serwerem :)
Dodatkowo, domyślnie używam PHP 5.3.6, a wykonując make install ryzykowałem trochę namieszania w systemie, tak więc pominąłem ten krok. Jeśli nie będziecie używać żadnych bibliotek PEARa wystarczy Wam gotowy skompilowany plik, który znajdziecie w katalogu sapi/cli.
Dla upewnienia znajdując się w ww. katalogu wydajemy polecenie: ./php -v aby upewnić się co do wersji interpretera.
Aby uruchomić najprostszy skrypt, w dowolnym(!) miejscu systemu plików tworzymy katalog, gdzie znajdzie się nasza aplikacja, a tam tworzymy prosty plik index.php, powiedzmy z taką zawartością:
<?php $action = filter_input(INPUT_GET, 'action', FILTER_SANITIZE_STRING); switch ($action) { case 'foo': echo 'Foo action'; break; case 'bar': echo 'Bar action'; break; default: echo 'Main action'; } ?>
Następnie kopiujemy skompilowany wcześniej plik wykonywalny PHP do utworzonego właśnie katalogu. Można oczywiście podlinkować go i używać globalnie w całym systemie, ale jak pisałem, w moim przypadku nie chciałem namieszać.
Serwer odpalamy poprzez wydanie komendy:
Penny:public singles$ ./php -S localhost:1234
Pewnie zastanawiacie się co ma wspólnego Babilon z PHP i programowaniem w ogólności. Ktoś może sobie pomyśleć, że chodzi może o kryptonim jakiegoś nowego frameworka, albo też odkryłem w sobie talent prozaiczny i zamierzam pisać fantasy osadzone w czasach Hamurabiego.
Nic z tych rzeczy. Ci, którzy mnie znają bliżej, wiedzą, że często mówiłem o Javie i jej ekosystemie jako o „Babilonie”. Skojarzenie z tym historycznym państwem jest jak najbardziej na miejscu – państwo Babilońskie miało bardzo złożoną strukturę i było bardzo zbiurokratyzowane (prawie jak dzisiejsza Unia Europejska ;P ). Taka jest też Java – masa bibliotek, frameworków i mało ekspresywny język, w którym za każdym razem trzeba napisać masę „boilerplate code” – czyli powtarzalnego kodu, który musi być wklepany, żeby wszystko działało.
O co więc chodzi z kierunkiem ? Żeby się dużo nie rozwodzić to powiem tyle, że zmieniam pracodawcę. Dzisiaj podpisałem umowę z firmą Sabre Holdings, która jak może wiecie albo i nie, jest jak się to mówi „Java shopem”. Większość oprogramowania tworzy się tam w Javie z dodatkiem Javascriptu i HTML dla webowego frontendu. Taka też będzie moja praca na stanowisku Java/Web developer i głównie będę używał wspomnianych trzech języków.
W związku ze zmianą pracy nie będę miał okazji na co dzień programować w PHP. Wielu może się dziwić takiej decyzji, Radek Benkel np. zapytał mnie skąd ta decyzja, język coraz bardziej się „ogarnia”. Śpieszę więc z wyjaśnieniem.
Pierwszą kwestią, która mnie skłania do zmiany języka jest rodzaj projektów jakie się w nim tworzy. Powiedzmy sobie szczerze, rynek jest nasycony agencjami interaktywnymi, które głównie specjalizują się w robieniu „stronek”, głównie w celach marketingowych oraz informacyjnych. Blogi, fora dyskusyjne, CMS-y, mailing, na tych kilku hasłach generalnie kończy się repertuar tej klasy firm. Oczywiście zdarzają się też inne rzeczy, czasami jakieś dedykowane aplikacje, ale jest to generalnie mniejszość. W pewnym momencie człowiek ma dość „klepania” tego samego i szuka odmiany.
Drugą kwestią jest organizacja pracy, w większości firm „PHP-owych” w których pracowałem nie było żadnego sformalizowanego procesu wytwarzania oprogramowania. Minimalne specyfikacje, opierające się na makietach, niejasne oczekiwania klienta, brak projektantów czy architektów. Mam wrażenie, że firmy używające Javy, będące w dużej części korporacjami, są pod tym względem lepiej zorganizowane.
Trzecią kwestią są oczywiście zarobki i popyt na programistów. Ofert pracy w Javie jest naprawdę wiele. Co więcej nie są to oferty typu „murarz, tynkarz, akrobata” gdzie firma szuka gościa, który zrobi grafikę w Photoshopie, potnie ją do HTML/CSS w sposób idealny, oprogramuje, postawi na serwerze i jeszcze weźmie za swoją robotę 50 zł. Konkretnych ofert jest na prawdę mało.
Co do zarobków to różnica jest dość istotna. Realnie zarobki Javowca zaczynają się tam gdzie kończą PHPowca.
Podsumowując zmieniam pracę i zmieniam technologię, żeby się rozwijać. Żeby zyskać inny punkt widzenia na pewne sprawy. Myślę, że w naszym zawodzie jest to bardzo ważne. Co więcej, jako, że w przyszłości chce założyć własną firmę, uważam, że głęboki przegląd przez różne technologie obecne na rynku może się wydatnie przełożyć na mój sukces.
Na koniec chciałbym również uspokoić wszystkich, który namiętnie czytają mojego bloga (:P). Dalej zamierzam pisać o PHP i myślę, że będzie to nawet ciekawsze pisanie, bo będę mógł przy okazji porównywać go z Javą i innymi technologiami obecnymi na JVM. Nie jest to więc pożegnanie, a zapowiedź nowego rozdziału, nowej jakości 
Od razu się przyznam, że nigdy nie korzystałem z MooTools i raczej korzystać nie będę. Niemniej plugin, na który natrafiłem zrobił na mnie tak duże wrażenie, iż postanowiłem wspomnieć o nim na blogu. Tak na prawdę, jest to zwyczajny skrypt pozwalający przeciągać myszką element(y) na stronie jakich wiele. Co tak na prawdę mnie zadziwiło, to efekt maski, uzyskany poprzez nałożenie na przesuwaną grafikę tekstu wyciętego w przeźroczystym pliku png. W wyniku uzyskano niesamowicie wyglądający efekt, polegający na przesuwaniu tła napisu – http://wall.plasm.it/examples/example-the-mask/
Plugin, dokumentację do niego oraz więcej przykładów znajdziecie pod adresem http://wall.plasm.it/.
Od jakiegoś czasu w zbiorze propozycji nowych „ficzerów” do PHP znajduje się RFC pod tajemniczą nazwą „Weak references”. W czym właściwie jest rzecz i czym są owe „słabe referencje” ? Cały pomysł został zaczerpnięty przez autorów z Javy, C# i Pythona. Rozwiązuje on problem związany ze zwalnianiem pamięci i garbage collectorem. Problem, kiedy mamy zbyt dużo referencji do jakiś obiektów i nie zostają one nigdy zebrane przez GC. Słaba referencja, w przeciwieństwie do standardowej „mocnej” nie powoduje zwiększenia licznika ilości referencji, po którym GC rozpoznaje, czy może już dany obiekt usunąć z pamięci.
Kiedy się to może przydać ? Prosty przykład, stosujemy wzorzec obserwator. Obserwowany obiekt zwany też podmiotem rejestruje subskrybentów, których będzie powiadamiał o zmianie swojego stanu. Takich subskrybentów może być bardzo wielu. Może się zdarzyć, że któryś subskrybent mógłby już zostać usunięty z pamięci przez GC, gdyby nie ta ostatnia referencja, którą trzyma podmiot. W efekcie przy wielu obiektach subskrybentów, tracimy niepotrzebnie pamięć. Rozwiązaniem jest zastosowanie słabej referencji. Dzięki niej, w momencie, gdy wszystkie inne zewnętrzne referencje do danego subskrybenta wygasną zostanie on od razu zebrany przez GC.
Implementacja zaproponowana w RFC postuluje stworzenie klasy SplWeakRef. Jej zastosowanie będzie wymagało tylko przekazania do jej konstruktora zmiennej do obiektu, który ma być słabą referencją.
Kanał ATOM
class Foo {}
$foo = new Foo; //reference count 1
$bar = $foo; //reference count 2
$slabaReferencja = new SplWeakRef($foo); //reference count 2
Jestem ciekaw co sądzicie o tej propozycji ? Osobiście wydaje mi się dość ciekawa, natomiast chyba pole zastosowań jest naprawdę bardzo małe, a potencjalnie może być ten „ficzer” bardzo niebezpieczny w rękach początkujących programistów. Osobiście zamiast tego mechanizmu, wolałbym możliwość deklarowania klas tak, by ich obiekty były przekazywane przez kopię, tak jak typy proste. Moim zdaniem dużo bezpieczniejsze rozwiązanie a efekt podobny.