Zend Framework dostarcza ogrom gotowych komponentów, które pokrywają zapotrzebowanie większości programistów. Pośród nich, można znaleźć m.in. Zend_Mail. Jest to komponent odpowiedzialny przede wszystkim za wysyłanie wiadomości e-mail. Znajdują się w nim również klasy odpowiedzialne za pobieranie poczty. Klasy te umożliwiają sprawdzenie, czy na wskazanym koncie znajdują się nieprzeczytane wiadomości e-mail bez konieczności korzystania z Zend_Gdata (który swoją drogą nie oferuje bezpośredniej możliwości sprawdzania poczty). W zasadzie wszystkie niezbędne informacje można znaleźć w dwóch miejscach – dokumentacji Gmaia oraz dokumentacji Zend_Mail.

Zanim będzie można sprawdzić, czy na wskazanym koncie znajdują się nowe wiadomości, należy włączyć w Gmailu obsługę IMAP. Można to zrobić w “Ustawieniach”, w zakładce “Przekazywanie i POP/IMAP”. W sekcji “Dostęp IMAP” wystarczy zaznaczyć opcję “Włącz IMAP”. Resztę pracy wykona Zend_Mail.

Kod sprawdzający czy na koncie Gmail znajdują się nowe wiadomości, jest bardzo prosty. Składa się na niego utworzenie nowego obiektu Zend_Mail z odpowiednimi parametrami oraz pętla foreach, w której zliczane są nieprzeczytane wiadomości. Całość wygląda następująco:

$mail = new Zend_Mail_Storage_Imap(
	array(
		'host' => 'imap.gmail.com',
		'port' => 993,
		'user' => 'nazwa.uzytkownika@gmail.com',
		'password' => 'haslo.uzytkownika',
		'ssl' => 'SSL'
	)
);

$i = 0;
foreach($mail as $message) {
	if($message->hasFlag(Zend_Mail_Storage::FLAG_SEEN)) continue;
	$i++;
}
echo $i;

Gwoli wyjaśnienia. Tablica przekazana do konstruktora zawiera parametry wymagane do  połączenia się z Gmailem. Pętla natomiast sprawdza czy pośród wszystkich wiadomości, znajdują się nieoznaczone flagą “przeczytane”. Jeśli tak, to dla każdej takiej wiadomości zwiększany jest licznik, który zawiera liczbę nieprzeczytanych wiadomości,

Dzisiaj chciałem podzielić się z Wami na temat kilku przemyśleń dot. type hinting i alternatywnego sposobu implementacji tego ficzera. Po co w ogóle type hinting ? Jak dla mnie type hinting spełnia trzy role:

• dokumentacja
• walidacja wejścia
• lukier składniowy

Dzięki roli dokumentacji wiemy jaki typ argumentu należy przekazać do funkcji by działała ona w sposób przewidziany przez jej autora. Dzięki walidacji wejścia autor funkcji upewnia się, że dostaje właściwe parametry, których użyje aby wyprodukować wynik. Natomiast dzięki lukrowi składniowemu jaki dostarcza typ hinting, zamiast pisać przydługawe if-y takie jak:

function foo($bar, $baz, ...){
    if(is_int($bar)){
//...
    }
    if(is_string($baz)){
//...
    }
}

piszemy po prostu function bar (int $bar, string $baz){//...} co znacznie skraca zapis. Generalnie w obecnych wersjach języka, jedyną rzeczą jakiej brakuje jest owy cukier składniowy. Dokumentowanie istnieje dzięki tagom phpDoc, sprawdzić argumenty możemy dzięki wyżej wspomnianemu if-owi. Czyli tak naprawdę type hinting wiele nie wnosi.

Mogłby jednak wnosić bardzo wiele, o ile umożliwiłby nie tylko sprawdzanie typów ale „grubszą” walidacje np. na wyrażenia regularne, czy obecność pewnych kluczy w tablicy. Szalone ? Nie możliwe ? Oczywiście, że nie! Poniżej przykładowa implementacja w Pythonie który umożliwia takie rzeczy a poniżej wytłumaczenie:

from ctypes import ArgumentError
from re import match
 
class param:
    def __init__(self, type, name):
        self.__type = type
        self.__name = name
    def __call__(self, function):
        def decorated(*args, **kwargs):
            if self.__type.__class__.__name__ == 'str':
                test = match(self.__type, kwargs[self.__name])
                if  test == None:
                    raise ArgumentError('Argument: >>' + self.__name + '<< must match pattern >>"'+self.__type + '"<<')
            else:
                arg_type = kwargs[self.__name].__class__.__name__
                proper_type = self.__type.__name__
                if arg_type != proper_type:
                    raise ArgumentError('Expected object of type >>'+proper_type + '<< for argument >>' + self.__name + '<<')
            function(*args,**kwargs)
        return decorated
 
@param(int, 'bar')
@param('ala.','baz')
def foo(bar, baz):
    print bar, baz
 
foo(bar = '1', baz='ala ma')

Co ten kod robi ? Kod ten używa ficzera Pythona zwanego dekoratorami funkcji. Pokrótce mówiąc, jest to cukier składniowy dzięki któremu można w łatwy sposób przekształcać funkcje.

@param(int, 'bar')
@param('ala.','baz')
def foo(bar, baz):
    print bar, baz

Zapis jest podobny do phpDoca więc powinniście go rozszyfrować – @param(int,'bar') oznacza, że parametr bar funkcji foo powinien być inte-em, natomiast @param('ala.','baz') oznacza, że parametr baz powinien spełniać wyrażenie regularne ‘ala.’

Działa to w ten sposób, że pisząc @param(parametr1, parametr2 ...) przed deklaracją funkcji jest ona przekazywana do wcześniej zdeklarowanej klasy ‘param’, która w konstruktorze bierze argumenty dekoratora(parametr1, paramtr2) a w funkcji __call__ która jest odpowiednikiem php-oweg __invoke robi coś z nimi oraz naszą funkcją i zwraca przekształconą funkcję. W naszym przypadku przeprowadza walidacje parametrów i jeżeli jej nie pasują to wyrzuca wyjątek a jeżeli jest wszystko ok to wywołuje naszą oryginalną funkcje.

I co o tym wszystkim sądzicie ?

Google wypuścił na świat nowy serwis. Tym razem nie jest to żadne “rewolucyjne” narzędzie do komunikacji, ani kolejny dodatek do poczty, kalendarza, czy dokumentów. HTML5 Rocks, bo o nim mowa, jest serwisem, w którym web developerzy znajdą wszystkie niezbędne informacje na temat tworzenia stron w nowym standardzie.

Swoistym pokazem możliwości jest interaktywna prezentacja, z której dowiemy się o zmianach jakie wprowadza HTML5, przy czym HTML5 oznacza tutaj HTML + CSS + Javascript Web API. Prezentacja została wykonana w całości w HTML5, dlatego też nie będzie działać w przeglądarkach nieobsługujących tego standardu, np IE8.

Drugim ciekawym elementem serwisu jest piaskownica, w której mamy możliwość wprowadzać zmiany do przykładowego kodu i obserwować na żywo efekt tych zmian.

Ostatnim elementem serwisu są tutoriale. W chwili obecnej jest ich tylko 9, jednak z czasem ich liczba będzie rosła. Tutoriale te będą się głównie skupiać na opisywaniu krok po kroku nowych możliwości HTML5.

źródło: blog.chromium.org

I stało się. Dzisiaj wyszło (przez przypadek) na liście internalsów, że został usunięty safe mode z trunka, co oznacza, że nie będzie go już w przyszłych wersjach. Long live php! . W końcu spełnia się sen niektórych o wywalaniu zaszłości.

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 ?