Zend Framework to jeden z najpopularniejszych frameworków PHP, który poznawałem jako jeden z pierwszych. Z wersji na wersję przybywało w nim funkcjonalności, zamieniając go ze zbioru luźno związanych komponentów w pełnoprawny framework MVC (z małym przymrużeniem oka). Od ponad roku programiści z niego korzystający czekają na wersję oznaczoną numerem 2, która ma przywrócić blask nieco zaśniedziałej chwały. Czy to się uda? Ciężko stwierdzić. Obecnie mamy możliwość sprawdzenia jak sobie radzi trzecia beta Zend Frameworka 2. Niestety dokumentacja jest tak samo kiepska jak w przypadku ZF 1 i większość informacji musimy wyszukiwać w sieci lub kodzie.
Co się zmieniło? Wszystko. Jeśli znacie aktualna wersję Zend Frameworka, to i tak będzie musieli uczyć się go na nowo, a aplikacje napisane w oparciu o pierwszą wersję, nie będą działać z wersją drugą. Jest tak dlatego, ponieważ ZF 2 został podzielony na moduły, które w pierwszej wersji były traktowane po macoszemu. Od drugiej wersji każdy moduł, to niezależny byt, który można bez żadnego problemu wyjąć z jednej aplikacji i wstawić do innej. Co więcej, moduły można pakować do archiwum phar, przez co ich utrzymanie i użycie będzie jeszcze prostsze. Moduły stały się pojemnikami na wszystko co chcemy zamknąć w obrębie jednej przestrzeni nazw. I tak, moduł może zawierać specyficzne biblioteki, zasoby (css, javascript, pliki graficzne), całą aplikację MVC, konfigurację – wszystko jest niezależne od innych modułów. Pozwoli to na budowanie klocków, z których będzie można tworzyć modułowe aplikacje.
Spore zmiany zaszły również w obsłudze requestu od momentu jego przesłania do aplikacji, do wygenerowania odpowiedzi. Pamiętacie jak to wyglądało w ZF 1? Pluginy, action helpery, metody w kontrolerze, boostrap i cała magia z tym związania. W ZF 2 już tego nie ma. Teraz mamy eventy, przy pomocy których możemy podpiąć się pod większość etapów obsługi żądania. Od strony programisty za wiele się nie zmieni. I tak trzeba napisać kod, który robi coś w określonym momencie, ale od strony “bebechów”, twórcy ZF 2 odwalili kawał dobrej roboty.
Podobnie wygląda sprawa wstrzykiwania zależności. Z wierzchu nie widać za bardzo co się zmieniło, ponieważ nadal musimy bawić się wielowymiarowymi, zagnieżdżonymi tablicami przekazywanymi do jakiegoś obiektu. Jednak jeśli zajrzymy pod maskę, znajdziemy coraz popularniejsze w PHP DI (dependency Injection). Podobnie jak w przypadku eventów, DI również zostało dobrze przemyślane.
Kolejną sporą zmianę zauważymy w widoku. Teraz akcja kontrolera zwraca obiekt typu ViewModel, który odpowiedzialny jest za ustawienie szablonu, pliku widoku i przekazanie zmiennych. Ciekawie wygląda opcja zagnieżdżania, pozwalająca osadzić jeden ViewModel wewnątrz innego, co w rezultacie pozwoli na wpływanie na zawartość dowolnego elementu szablonu.
Przejrzałem Zend Frameworka 2 dosyć pobieżnie, przebrnąłem przez Quick Start i stworzyłem kilka modułów w ramach treningu, jednak już teraz mogę powiedzieć, że szykuje się nam porządnie wykonany framework. Nie przeprowadzałem żadnych testów wydajnościowych, w końcu cały czas mamy do czynienia z betą, obawiam się jednak, że ZF 2 może być wolniejszy od swojego poprzednika. Jest to mocno subiektywne odczucie i nie powinniście się nim sugerować podczas wybierania frameworka. Ogromnym plusem ZF 2 jest podzielenie wszystkiego na niezależne moduły, co na pewno przyczyni się do powstania ogromnej bazy paczek podobnych do gem-ów powszechnie wykorzystywanych w Railsach. Przynajmniej taką mam nadzieję. Ile poczekamy na stabilną wersję ZF 2? Nie wiem. Zgaduję, że chłopaki czekali na PHP 5.4 i w jednej z kolejnych wersji beta zobaczymy rozbudowany komponent Zend_Tool, pozwalający na uruchomienie aplikacji opartej na ZF 2 bez konieczności posiadania jakiegokolwiek serwera. Nieważne jaka by nie była przyczyna opóźnień, czekam na finalną wersję z niecierpliwością.
Już niedługo, bo za niecały miesiąc, odbędzie się czwarta edycja konferencji 4Developers. Miałem okazję uczestniczyć w dwóch poprzednich edycjach i bardzo chciałbym wziąć udział w tym roku, niestety z powodu kilku drobnych zawirowań, muszę tym razem odpuścić sobie tę przyjemność. Bardzo tego żałuję, ponieważ w tym roku interesujących tematów na pewno nie zabraknie. Do najciekawszych moim zdaniem można zaliczyć między innymi Tworzenie i wdrażanie z użyciem strategii chmur hybrydowych, Jak wybrać odpowiednią bazę NoSQL, REST i ograniczenia hypermediów, czy Hadoop w Hurtowni Danych nk.pl. Oczywiście nie są jedyne interesujące sesje, których pełną listę znajdziecie na stronie poświęconej konferencji. Podobnie jak w zeszłych latach i tym razem do wyboru są 4 ścieżki. Są to Java, Zarządzanie projektami IT, Wydajność i skalowalność oraz PHP. Oprócz samych sesji wykładowych na uczestników czekają warsztaty oraz konkursy z nagrodami.
Ale do rzeczy. Mam dla Was wejściówkę dla jednej osoby. Co trzeba zrobić, aby ją wygrać? Napiszcie w komentarzu na jaką sesję chcielibyście najbardziej pójść i dlaczego? Komisja egzaminacyjna w tajnym składzie zadecyduje o zwycięzcy. Na odpowiedzi macie czas do końca weekendu (wiem, wiem – ładna pogoda, a ja wymyślam jakieś zadanie na weekend), czyli do północy 25 marca. I nie zapomnijcie, że w ten weekend przestawiamy zegarki o godzinę do przodu.
Strona konferencji – 4developers.org.pl.
Ostatnimi czasy, mam okazję tworzyć dość duże ilości testów jednostkowych. Zwykle tworze je do cudzego kodu, co pozwala mi w pewnym sensie ocenić jego jakość. Zapytacie może, jak proces pisania testów jednostkowych do istniejącego kodu pozwala ocenić jego jakość ?
Otóż, pewna stara programistyczna fama głosi, że gdy kod jest łatwo testowalny, to prawdopodobnie jego jakość, a przynajmniej architektura będzie wysokiej jakości. Automatycznie na myśl przychodzi takie proste rozwiązanie, że skoro kod ma być łatwo testowalny, to najlepiej by było zacząć jego tworzenie od napisania testów. Takie podejście nazywa się TDD (Test Driven Development). Pewnie wielu z Was słyszało o takim podejściu, natomiast jeżeli pracujecie w typowej firmie wytwarzającej „stronki”, to pewnie nie mieliście wielu okazji by zastosować takie podejście.
Oczywiście nie koniecznie jest to grzech – w prostych projektach zastosowanie TDD może być dyskusyjne ze względu na narzut czasowy jaki generuje. Znając jednak życie, prosty projekt zwykle przeradza się w projekt skomplikowany, którego skali nikt nie przewidział.
Abstrahując jednak od TDD, chciałbym się podzielić z Wami, moimi spostrzeżeniami na temat typowych „wzorców” w kodzie, które znacząco obniżają jego testowalność. Przy okazji zaproponuje sposoby ich rozwiązania poprzez refaktoring kodu oraz omówię konsekwencje jakie niosą za sobą poszczególne antypatterny.
Tak więc, jeżeli spotkasz jeden z podanych poniżej przypadków – wiedz, że coś się dzieje 
Kilka przykładów kodu, żeby było wiadomo o co chodzi:
Przykład nr. 1:
class Bar(var i: Int) {}class TestSubject1 { def doFoo(bar: Bar){ bar.i = 10 } }def testCase1() { val bar = new Bar(0) val testedObject = new TestSubject1 testedObject.doFoo(bar) if(bar.i == 10){ println("true") } else { println("false") } }view raw gistfile1.scala This Gist brought to you by GitHub.
Mamy zdefiniowane dwie klasy – Bar, która ma property „i” oraz klasę TestSubject1 która jest testowana przy użyciu funkcji testCase1. Co jest złego w tego rodzaju kodzie ? Przede wszystkim następuje niejawna manipulacja obiektem klasy Bar. Poza tym, jako, że metoda ma typ void (w tym przypadku w Scali jest to Unit), programista, który chce użyć takiego kodu, tak naprawdę nie wie jaki jest efekt jego działania. Kod po refaktoringu:
class TestCase1refactored { def doFoo(bar: Bar): Bar = { val result = new Bar(bar.i + 10) return result } }def testCase1refactored() { val bar = new Bar(0) val testedObject = new TestSubject1refactored() val result = testedObject.doFoo(bar) if(result.i == 10){ println("true") } else { println("false") } }view raw gistfile1.scala This Gist brought to you by GitHub.
Jak widać, metoda po refaktoringu zwraca jakąś konkretną wartość, poza tym zamiast zmieniać stan obiektu, tworze nowy ze zmienioną wartością, dzięki czemu unikam modyfikowania globalnego stanu.
Przykład nr.2:
Kanał ATOM
