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.

Instalacja

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.

Uruchomienie

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

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

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

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

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ą.

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.

Na pewno pamiętacie, jak pod koniec maja pisałem o rozpoczęciu prac nad organizacją kolejnej edycji największej w Polsce konferencji poświęconej językowi PHP i związanym z nim technologiom - PHPCon 2011. W tamtej chwili głównym zmartwieniem organizatorów było znalezienie odpowiedniej liczby prelegentów wraz z prezentacjami na jak najwyższym poziomie. Teraz śmiało można powiedzieć, że etap ten [...]

Ten Linkdump jest zdecydowanie spóźniony - to chyba pierwszy wpis, z którym "nie wyrobiłem" się w ciągu dwóch dni względem Harmonogramu. Tak to jednak jest, jak się ma tyle pracy, że po tych kilkunastu godzinach człowiek już nawet nie myśli o tym, że gdzieś w Internecie istnieje jakaś strona, którą się zarządza, a tym bardziej, [...]

Zapraszam do zapoznania się z moją prezentacją pt. RESTful Symfony2, którą można obejrzeć na xlabie http://xlab.pl/2011/08/restful-symfony2/

ul { list-style-type: decimal;}O tym, czym są wyjątki można przeczytać w wikipedii lub na php.net. Ogólnie rzecz biorąc wyjątki powinny być wyrzucane wtedy, gdy w jakiś sposób nasza aplikacja podejmie próbę wykonania niedozwolonej operacji lub nie będzie w stanie wykonać operacji.Od wersji 5 PHP jest dostarczany z bardzo ciekawą biblioteką SPL, która narzuca pewną hierarchię wyjątków i dzieli je na dwie główne grupy:

• RuntimeException - są to wyjątki, które powinny być wyrzucane, gdy aplikacja z pewnych względów nie może poprawnie działać np. zerwanie połączenia z bazą danych.
• LogicException - są to wyjątki, które powinny być wyrzucane, gdy aplikacja próbuje wykonać operacje, które są błędne np. wywołanie nieistniejącej metody na przekazanym obiekcie.

Szerszy opis wszystkich wyjątków, które są dostarczone wraz z biblioteką SPL znajdziecie tutaj.Dobra, po trochę przydługim wstępie, wracam do głównego wątku:) A więc po co tworzyć własne wyjątki? Przecież można z łatwości wpisać odpowiedni message do konstruktora tego bazowego (Exception) i po sprawie. Oczywiście, że tak można, ale tylko do momentu, gdy wyjątki są rzeczywiście tylko i wyłącznie kontenerem na jakąś informację. Oczywiście powodów stosowanie wyjątków jest kilka, ja jednak pozwolę sobie skupić się na, moim zdaniem najważniejszym, czyli utrzymywaniem spójnej logiki tzn. jeżeli mam klasę Product, Product_Factory, Product_Collection etc. to dobrze jest mieć jeszcze Product_Exception, który będzie wykorzystywany w tych właśnie klasach i tylko w tych. Dzięki temu już po samym typie wyjątku wiem, gdzie się wysypała aplikacja, a do dokładniejszego określenia miejsca załamania powinno się wykorzystywać wartość $message.Oczywiście można tutaj popaść w pewną skrajność i zacząć tworzyć wyjątki dla wszystkiego i tak dostajemy: Product_Exception, Product_Factory_Exception, Product_Collection_Exception etc., gdzie każdy wyjątek jest wyrzucany jeden, no góra dwa razy w całym kodzie. I po co to? Niestety jest to częsta przypadłość programistów, którzy dopiero odkryli tą cudowną możliwość dziedziczenia po klasie Exception - po prostu zapominają o tym, że wyjątek posiada jeszcze argument $message.Niestety złotego środka nie ma i już we własnym zakresie trzeba zdecydować, czy to już powinien być kolejny typ wyjątku, czy jeszcze ten sam, z odpowiednią wiadomością. Granica jest płynna, ważne jest to, aby pamiętać o dwóch rzeczach:

• Dziedziczyć po klasie Exception jest w PHP dozwolone.
• Konstruktor klasy Exception posiada możliwość przyjmowania parametrów m.in. $message i $code.