Minęło już półtora tygodnia od czasu jak zacząłem moją pracę w Sabre i myślę, że jest to dobry czas by pokusić się o małe podsumowanie tego jakie są moje wrażenia i czy moje oczekiwania, które przedstawiłem w poprzedniej części artykułu w jakimś stopniu miały okazję się spełnić.
Dla przypomnienia, powody, dla których postanowiłem zmienić środowisko z PHP na Javę:
Czy wobec perspektywy tych trzech powodów, zmiana miała sens ? Jak najbardziej ! Po półtora tygodnia pracy mogę powiedzieć że:
Największą różnicą między tym co dotychczas robiłem a tym co teraz robię jest przede wszystkim rozmach. Realizując projekty PHP-owe dotychczas pracowałem zwykle sam, lub maksymalnie w około 5-cio osobowym zespole, który pracował zwykle w jednym pokoju biurko w biurko.
W obecnej pracy, jestem członkiem działu (nie mylić z oddziałem), który tylko w Polsce liczy ponad 100 osób (w firmie, która tylko w Polsce zatrudnia około 1200 osób), jestem członkiem jednego z 4ech zespołów pracujących nad jednym produktem i bezpośrednio współpracuje z około 20-toma osobami. To dość duża zmiana mentalna.
Jeszcze większą mentalną zmianą jest to, że często się zdarza, że nad jednym „user story” (odpowiednik pojedynczego „ficzera”) pracuje nierzadko z kilkoma osobami. Zmienia to zupełnie sposób pracy i wymaga ciągłej komunikacji, zrozumienia i trzymania się ściśle ustalonych standardów.
Kolejnym faktem, który wiele zmienia, są Unit Testy. Pierwszy raz, rozwijam aplikację, której część biznesowa jest prawie w całości pokryta testami jednostkowymi (bo w przypadku frameworków to jest norma).
Generalnie wiele rzeczy prowadzonych jest „książkowo”, jak np. praca w metodyce Scrum. Codzienne „standupy”, iteracje i ich planowanie – uczestniczę w nich i widzę, że ma to sens.
Wracając do rzeczy czysto programistycznych mogę powiedzieć tyle, że łyknąłem już dość dużo Javy, przede wszystkim wszelakich adnotacji i typów generycznych, sposobu obchodzenia się z projektami – Maven, integracja z IDE, debbugger, Tomcat oraz frameworki JUnit oraz Mockito.
Cały czas tutaj wymieniam plusy i zalety, natomiast nie wspomniałem o kilku rzeczach, które można by nazwać wadami tej roboty. Pierwsze co od razu rzuciło mi się w oczy to dość duża biurokracja – na wstępie musiałem wypełnić 11-stronnicowy formularz. Druga kwestia to niestety nieproporcjonalność wyposażenia mojego laptopa do ogromu projektu (poranny update potrafi trwać nawet 15 minut !) – niestety nawet 4gb ramu i najnowszy Core i5 nie zapewniają w jego przypadku komfortowej pracy.
Poprzednim razem gdy zabrałem się za ocenę Symfony2, moja cierpliwość bardzo szybko się skończyła. W komentarzach nie zostawiliście na mnie suchej nitki (tylko kilka osób wykazało zrozumienie), dlatego postanowiłem nieco dłużej pomęczyć Symfony2 i jeszcze raz opisać moje wrażenia (tym razem odkładając emocje na półkę). Zatem do dzieła.
Wszystko zaczyna się na stronie Quick Tour, gdzie poznajemy podstawy frameworka. Przewodnik został podzielony na cztery części.
Sposobów na pobranie frameworka jest kilka. Ja zdecydowałem się na najprostszy z nich, czyli pobranie paczki Symfony Standard Edition. Po rozpakowaniu jej, sprawdzamy czy wszystkie wymagane rozszerzenia PHP są zainstalowane. Czego nam brakuje dowiemy się po wpisaniu do przeglądarki adresu http://localhost/Symfony/web/config.php. Niestety już na samym początku pojawiły się problemy – Install and enable a PHP accelerator like APC (highly recommended). Nie mam nic przeciwko akceleratorom jako wsparciu aplikacji działających pod dużym obciążeniem, ale jeśli akcelerator jest wymieniany jako wysoce zalecany do działa w ogóle, to źle to świadczy o frameworku.
Nie zrażając się pierwszymi zgrzytami, kontynuuję przewodnik i wpisuję do przeglądarki adres http://localhost/Symfony/web/app_dev.php/. Zgodnie z oczekiwaniami, pojawiła się strona startowa oraz pasek z debugiem, który jak się okazało zawiera wiele informacji przydatnych na etapie tworzenia i testowania aplikacji.
Następne w kolejce są podstawy działania frameworka – routing, kontrolery, szablony oraz bundle.
Ścieżki można definiować na kilka sposób i wszystko byłoby dobrze, gdyby nie możliwość korzystania z adnotacji. Dlaczego? Ponieważ w myśl zasady “skoro można tak zrobić, to tak będzie to robione”, wiele osób będzie “chowało” ścieżki w kontrolerach, skutecznie utrudniając ich odnalezienie i ewentualną modyfikację.
Poza tym, routing prezentuje się świetnie. Jest prosty w użyciu, nie wymaga znajomości magicznych zaklęć i daje nieograniczone możliwości w definiowaniu ścieżek. In plus należy zaliczyć możliwość określania typu requestu, a co za tym idzie dla jednego adresu, np. /kontakt możemy przypisać dwie akcje – jedną dla GET, drugą dla POST. Bardzo pomocne. Jeszcze bardziej pomocne jest określanie formatu odpowiedzi. Na koniec jeszcze warto wspomnieć, że parametry ścieżki są dostępne jako argumenty metody (tak jak w ASP.NET MVC).
Ponieważ debugowanie ścieżek zapisanych w kontrolerach to koszmar, Symfony2 dostarcza konsolowe narzędzie pozwalające wylistować wszystkie ścieżki i ich szczegóły.
Sercem każdego frameworka MVC jest kontroler, który obsługuje przychodzące żądanie i odpowiada na nie, najczęściej w postaci kodu HTML, rzadziej jako JSON, XML, tekst lub przekierowanie (inne typy również są możliwe). W sumie na ten temat nie da się wiele napisać. Kontroler jaki jest każdy widzi i nic nowego w tej materii nie da się wymyślić.
W mojej opinii systemy szablonów w PHP to pomyłka, ale skoro już i tak Symfony2 wszystko pakuje do cache’u to niech będą. Składnia to kalka szablonów z Django. Przynajmniej wzorują się na dobrym rozwiązaniu. Nic nie stoi na przeszkodzie, aby wykorzystać dowolny inny system szablonów.
Prawie rok temu popełniłem wpis Symfony 2 okiem zendowca. Mimo iż testowana wersja nie była finalna, wywarła dobre ogólne wrażenie. Jakiś czas temu społeczność PHP świętowała wydanie stabilnej wersji frameworka, organizując przy tym różnego rodzaju imprezy i zalewając Twittera i RSS informacjami na temat Symfony 2. Konfetti opadło, dokumentacja wydaje się być skończona, przede mną duży projekt, przyszła więc pora na sprawdzenie co w trawie piszczy.
Zaczęło się standardowo od pobrania paczki z frameworkiem i rozpakowaniu jej na serwerze. Po uruchomieniu check.php, pokazało kilka błędów i ostrzeżeń wynikających ze świeżej instalacji PHP. Po dodaniu wymaganych rozszerzeń, wszystko poszło jak po maśle. Moją uwagę przykuło groźnie brzmiące ostrzeżenie Install a PHP accelerator like APC (highly recommended). Niby nic, ale jeśli już na dzień dobry dostaję po twarzy informacją, że framework wymaga akceleratora, to zaczynam w niego wątpić.
Pamiętny ostrzeżenia, zabrałem się za konfigurację Nginx (nie korzystam z Apache od pewnego czasu). Nie będę rozpisywał się na ten temat, ponieważ dokładne instrukcje można znaleźć pod adresem http://www.zalas.eu/nginx-configuration-for-symfony-projects.
Po zainstalowaniu frameworka, odpaliłem przygotowane strony, pobawiłem się Hello Fabien! i zabrałem za przeglądanie kodu. Pierwsze zdziwienie – ogromna ilość plików cache. Co to musi być za kobyła, że wszystko leci do cache? Ok, niby dzięki temu wszystko ładnie śmiga, ale jaki jest sens tworzenia czegoś, co bez takiej ilości cache nie będzie w stanie działać (nie zapominajmy o wysoce zalecanym akceleratorze). Co mnie najbardziej zdziwiło to cache Twiga, który zapisany do postaci klasy, przy pomocy echo, wyświetla kod HTML bezpośrednio w metodzie. O tak:
Kanał ATOM
// line 15
public function block_menu($context, array $blocks = array())
{
// line 16
echo "<span class=\"label\">
<img src=\"";
// line 17
echo twig_escape_filter($this->env, $this->env->getExtension('assets')->getAssetUrl("bundles/webprofiler/images/profiler/mail.png"), "html");
echo "\" alt=\"Configuration\" /></span>
<strong>E-Mails
<span class=\"count\">
<span>";
// line 20
echo twig_escape_filter($this->env, $this->getAttribute($this->getContext($context, 'collector'), "messagecount", array(), "any", false), "html");
echo "</span>
";
}
Mój niepokój wzrósł po tym, jak w katalogu app nie znalazłem kodu aplikacji. WTF? Czy aplikacja to tylko cache, logi, konfiguracja i widoki? Gdzie reszta? Okazało się, że kontrolery (modeli się nie doszukałem) znajdują się w katalogu src. Czyżby kod Symfony2 był kompilowany ze źródeł do postaci binarnej lub jeszcze większej ilości cache? Tego nie wiem – mój limit WTF/minutę za szybko się wyczerpał.
A wyczerpał się między innymi dlatego, że routing, coś po powinno być jak najprostsze, został beznadziejnie zaprojektowany. Dlaczego? Ponieważ ścieżki można zdefiniować jako adnotacje w kontrolerze. Znaleźć takie coś w większej aplikacji musi graniczyć z cudem.
Niestety nie miałem okazji dotrwać do modeli i generatorów. Co więcej, nie udało mi się w sensownym czasie dotrzeć do tutoriali traktujących o tych zagadnieniach. Wygląda na to, że Zend Framework na długo pozostanie moim ulubionym frameworkiem PHP (przynajmniej do czasu wydania drugiej wersji).
W dzisiejszym wpisie, Sebastian Bergmann, zaproponował dodanie do PHP metody ReflectionClass::newInstanceWithoutConstructor(), która to pozwoliła by na tworzenie nowej instancji klasy z pominięciem konstruktora, podobnie jak to odbywa się w przypadku deserializacji. Osobiście jestem bardzo entuzjastyczny wobec zgłoszonej propozycji i chętnie powitałbym ją w nadchodzącej wersji 5.4 interpretera.
Zastosowań jest całe multum, natomiast chyba najbardziej przydatna jest ta funkcja dla twórców wszelakiej maści frameworków i bibliotek (szczególnie ORM). Dzięki niej, nie trzeba już będzie korzystać ze sztuczek z serialize/deserialize, by stworzyć obiekt z pominięciem konstruktora.