Do napisania tego postu zainspirował mnie artykuł na 97 rzeczy pt. Stosuj zasady programowania funkcjonalnego. Każdemu polecam przeczytanie go aby dowiedział się dlaczego należy stosować te zasady. Ja w tym poście będę chciał pokrótce przedstawić jak rady zawarte w artykule można odnieść do kodu w PHP i jakie korzyści odniesiemy stosując refaktoring poszczególnych rodzajów kodu. Duchem całego programowania funkcjonalnego jest przezroczystość referencyjna – funkcja dla tych samych danych zwraca konsekwentnie ten sam wynik, aby tak było kod musi spełniać kilka zasad:

Pierwsza zasadą jest unikanie globalnego stanu. Często można natknąć się w skryptach na następujące konstrukcje „popełniane” przez początkujących:

$conn = mysql_connect();
 
function fetch_users(){
global $conn;
/**
reszta kodu
**/
}

Problem z tego rodzaju kodem jest taki, że jest on całkowicie nieprzewidywalny. Jeżeli zamkniemy gdzieś w naszym skrypcie zamkniemy połączenie do bazy, a potem wywołamy funkcję fetch_users, po prostu dostaniemy błąd. Oprócz tego, osoba postronna czytająca kod, w zasadzie nie jest w stanie wywnioskować co powinno znaleźć się w zmiennej $conn.

Są dwa rozwiązania refaktoringu takiego kodu, pierwszy:

$conn = mysql_connect();
 
function fetch_users($connection){
/**
kod
*/
}

Drugi:

class DbService {
    protected $_conn;
    public function __construct(){
       $this->_conn = mysql_connect();
    }
 
    public function fetch_users(){
         /** kod **/
    }
 
    public function __destruct(){
         mysql_close($this->_conn);
    }
}

Dzięki refaktoringowi nr.1 zyskaliśmy większą przewidywalność funkcji i czytelność. Dzięki refaktoringowi nr.2 uzyskaliśmy przewidywalność, abstrakcje i enkapsulacje.

Przykładem pogwałcenia tej zasady jest również wzorzec singleton (namiętnie używany w ZF) i rejestr.

class FooController extends Zend_Controller_Action {
 
    function barAction(){
        $baz = Zend_Registry->getInstance()->baz;
        // czym jest baz ???
    }
 
}

Jak widzimy powyżej, gdybyśmy recenzowali taki kod, nie jesteśmy bez uruchamiania skryptu w stanie stwierdzić, jakiego typu jest zmienna $baz, co więcej nie jesteśmy w stanie stwierdzić czy rejestr przechowuje coś pod tą zmienną. Refaktoring:

class FooController extends Zend_Controller_Action {
 
    function barAction(ModelUser $baz){
        $aList = $baz->getList();
        // baz jest instancją ModelUser, wiemy jakie ma metody i musi istnieć żeby ta metoda mogła być //wywołana 
    }
 
}

Oczywiście osobną kwestią jest jak wstrzyknąć zależności do kontrolera, ja bym zastosował do tego kontener IOC, ale to osobna bajka.

Drugą zasadą jest nieprzekazywanie przez referencję do funkcji:

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

Zwiń
Czytaj na blogu autora...

Nazwanie jednej klasy obserwatorem, a drugiej obserwowanym nie daje nam jeszcze wzorca "Obserwator". Z tym zgodzą się chyba wszyscy. Gdy identyczną zasadę spróbujemy zastosować do MVC, wywołamy wielką wojnę z argumentami kalibru "nie rozumiesz idei wzorców projektowych". Kursów MVC jest w sieci na pęczki, problem polega jednak na tym, że opisują one w rzeczywistości zupełnie inny wzorzec, niż twierdzą jego autorzy. W tym wpisie pragnę pokazać jego prawdziwe oblicze oraz zaprezentować eksperymentalną implementację, którą rozwijam od jakiegoś czasu.

Kolejna porcja nowości z wewnętrznej grupy dyskusyjnej deweloperów Php. Tym razem tematem przewodnim jest APC czyli Alternative PHP Cache. Dla przypomnienia powiem tylko, że APC jest rozszerzeniem do Php dzięki któremu bez zmian w kodzie można przyśpieszyć swoje skrypty o 300-400%. Dzieje się tak dzięki temu, że APC zachowuje w pamięci skompilowaną postać skryptu po pierwszym wykonaniu i przy każdym następnym uruchomieniu skrypt nie musi być od nowa parsowany.

Jeden z deweloperów zaproponował defaultowe dołączenie APC do dystrybucji Php i zintegrowanie jego kodu z kodem języka (trunkiem). Ten ruch był już uzgodniony i miało to zostać zrealizowane przy okazji tworzenia Php6. Niestety nie ma już Php6, powstała więc propozycja aby w najbliższej wersji (5.4 ?) przeprowadzić to połączenie.

Doszło do dyskusji i okazało się, że część osób nie chce takiego połączenia. Jako powody wymieniali m.in to, że trudny błąd w APC może zastopować wydawanie kolejnych wersji języka, oraz to, że istnieją również inne rozszerzenia alternatywne do APC i nieuczciwym było by promować tylko wybrane.

Natomiast zwolennicy tego rozwiązania argumentowali, że dołączenie APC nie jest przeszkodą dla używania alternatywnych rozszerzeń, poza tym dzięki temu, że będzie rozwijane w corze, będzie pod większą uwagą deweloperów.

Nasuwa się jeszcze jeden plus w integracji – APC będzie rozprowadzane w standardowej dystrybucji i dzięki temu każdy będzie mógł korzystać z przyśpieszenia bez oglądania się na hosterów czy mają zainstalowane odpowiednie rozszerzenie.

Koniec końców wyłoniły się trzy możliwe rozwiązania:

• zintegrować i domyślnie wyłączyć
• zintegrować i domyślnie włączyć
• nie integrować

Ja popieram opcje nr.1 a jakie jest Wasze zdanie ?

Każda aplikacja biznesowa posiada opcję zapisz jako CSV. Najczęściej w takim przypadku tworzony jest osobny skrypt, który pobiera dane z bazy i udostępnia je w odpowiednim formacie. Twórcy Zend Frameworka wyszli na przeciw potrzebom programistów i udostępnili helper akcji o nazwie ContextSwitch, który w skrócie można opisać jako mechanizm do zwracania danych w zadanym formacie.

Domyślnie ContextSwitch ofertuje dwa formaty. Są to JSON oraz XML. Jeśli chcemy, aby nasza aplikacja zwracała dane w innym formacie, musimy stworzyć własny kontekst. Sprowadza się to do określenia nazwy kontekstu oraz określenia dodatkowych parametrów, takich jak suffix pliku widoku, nagłówki jakie zostaną użyte w przypadku zastosowania kontekstu oraz funkcje zwrotne, które zostaną wywołane w metodzie init lub postDispatch podczas obsługi danego kontekstu. Żadna z wspomnianych wyżej opcji nie jest wymagana, jednak aby użycie kontekstu miało sens, należy ustawić co najmniej suffix. W przypadku funkcjonalności polegającej na pobieraniu danych, należy dodać jeszcze odpowiednie nagłówki:

$contextSwitch = $this->_helper->getHelper('ContextSwitch');

$contextSwitch->addContext('csv', array(
	'suffix' => 'csv',
	'headers' => array(
		'Content-Type' => 'text/csv',
		'Content-Disposition' => 'attachment; filename=nazwa-pliku.csv'
	)
));
        
$contextSwitch->addActionContext('index', 'csv')
	      ->initContext();

Drugim i zarazem ostatnim krokiem jest stworzenie odpowiedniego pliku widoku ze wskazanym wcześniej suffixem.

Obok CSV można stworzyć kontekst RSS/ATOM, vCard, PDF i wiele innych.

Przykładową aplikację korzystającą z ContextSwitch znajdziecie w repozytorium SVN.

Niektóre systemy bazodanowe takie, jak np. PostgreSQL wspierają koncepcję dziedziczenia tabel. Pozwala ona nie tylko na współdzielenie części deklaracji przez dwie tabele, ale także danych, co znacząco ułatwia realizację niektórych zadań. Choć biblioteka Doctrine obsługuje dziedziczenie od jakiegoś czasu, działało ono na zasadzie emulacji, co oczywiście jest marnotrawstwem, jeśli korzystamy z systemu, który wspiera tę funkcjonalność natywnie.

Jeśli mieliście za zadanie kiedykolwiek wykonać stronę, która będzie poprawnie się wyświetlać, na pewno korzystaliście z maszyny wirtualnej. Zwłaszcza, jeśli musieliście testować stronę w kilku wersjach IE, Fx i Opery. Pół biedy, jeśli do przetestowania jest “goły” HTML. Gorzej, jeśli trzeba przetestować działającą aplikację, zainstalowaną na serwerze.

Jest na to rada. Wystarczy odpowiednio skonfigurować hosty na wirtualnej maszynie oraz odblokować dostęp w konfiguracji Apache. Poniższy opis będzie działał dla systemu operacyjnego Windows oraz maszyny wirtualnej Virtual PC. Nie testowałem tego rozwiązania na innych systemach operacyjnych oraz maszynach wirtualnych.

Pierwszą rzeczą jaką trzeba zrobić, to dowiedzieć się z jakiego adresu IP będziemy się łączyć do serwera. W tym celu w wierszu poleceń hosta wpisujemy ipconfig /all i szukamy naszego adresu IP. Jak już go znajdziemy, w systemie na maszynie wirtualnej odnajdujemy plik hosts (znajduje się w katalogu C:\WINDOWS\system32\drivers\etc) i dodajemy nowy wiersz:

123.123.123.123	jakas-nazwa

W miejsce 123.123.123.123 wpisujemy adres IP naszego komputera, a w miejsce jakas-nazwa, nazwę, po wpisaniu której wyświetli się zawartość głównego katalogu serwera. Ostatnią czynnością jaką musimy wykonać, jest zezwolenie na łączenie się z maszyny wirtualnej do serwera zainstalowanego na hoście. Wystarczy dodać w pliku konfiguracyjnym Apache regułkę

Allow from 123.123.123.123

gdzie 123.123.123.123 jest tym samym adresem, który wpisaliśmy do pliku hosts na maszynie wirtualnej.

Jeśli korzystacie z wirtualnych hostów na serwerze (na hoście) i chcecie, by również one działały z poziomu maszyny wirtualnej, wystarczy, że jako nazwę w pliku hosts podacie ich nazwę lub alias. Pamiętajcie o dodaniu adresu IP do konfiguracji vhosta.

Część z Was pewnie wie o istnieniu listy dyskusyjnej php.internals. Jest to lista na której to core developerzy PHP rozmawiają o zmianach w języku. Jako, że praktycznie codziennie odwiedzam ową listę, postanowiłem co jakiś czas pisać post o aktualnych dyskusjach na niej oraz zapytać Was czyli społeczność o zdanie w poruszanych tam kwestiach. Ostatnio najświeższym tematem na tapecie jest usunięcie z głównej dystrybucji PHP rozszerzenia SQLite w wersji 2 na rzecz wersji 3.

Proponenci argumentują konieczność usunięcia tego rozszerzenia tym, że biblioteka (i baza) SQLite w wersji 2 nie jest już rozwijana i trzymanie tego kodu w głównej dystrybucji jest bez sensu.

Przy okazji dyskusji kilka osób zaproponowało aby usunąć również nie rozwijane rozszerzenie mssql oraz rozszerzenie mysql oparte na natywnych bibliotekach dostarczanych przez producenta bazy, a zamiast niego silniej promować mysqli i pdo. Argumentacja była taka, że rozszerzenie mssql również nie jest rozwijane i są lepsze sposoby na komunikacje z tą bazą np. w windowsie oficjalny microsoftowy driver a na linkusie odbc. Natomiast co do drivera mysql, że nie jest to natywny PHP-owy driver. Padł również argument, że powinno się ograniczać ilość dostępnych sposobów realizacji jednej rzeczy.

A Wy co sądzicie ?

Czy należy usunąć rozszerzenie SQLite2 z dystrybucji ? Czy należy pozbyć się drivera MySQL dostarczanego przez producenta na rzecz mysqli i pdo, a może zostawić obie rzeczy by była lepsza kompatybilność wsteczna ?