W przeciągu ostatnich dwóch tygodni musiałem w przyspieszonym tempie opanować framework Symfony do poziomu nadludzkiego, aby dokończyć pewien projekt. Mniejsza o szczegóły - dość, że niekompetencja i zupełny brak odpowiedzialności niektórych ludzi twierdzących, że są programistami, mogą być naprawdę porażające. Dotychczas, jeśli już, pracowałem z Zend Frameworkiem, Kohaną oraz Yii, zaś Symfony znałem bardziej z pobieżnego przeglądu. Jako że zbliża się premiera wersji drugiej tego frameworka, postanowiłem spojrzeć krytycznym okiem na to, co żegnamy.

W weekend wookieb podesłał linka do interesującej biblioteki JavaScript – Modernizr. Dzięki niej wykrycie jakie funkcjonalności obsługuje nasza przeglądarka to pestka. Co więcej, nie napiszemy ani jednej linijki w JavaScript. Jedyne co musimy zrobić, to dodać bibliotekę do strony i… cieszyć się efektami. Modernizr na podstawie wykrytych funkcjonalności, do tagu HTML doda klasy CSS jednoznacznie opisujące czego możemy spodziewać się po przeglądarce. W pliku ze stylami możemy wykorzystać nowe klasy do zastosowania rozwiązań zapasowych. Prosty przykład:

.multiplebgs div p {
  /* properties for browsers that
     support multiple backgrounds */
}
.no-multiplebgs div p {
  /* optional fallback properties
     for browsers that don't */
}

Po więcej szczegółów odsyłam na stronę biblioteki – www.modernizr.com

W Internecie pojawiła się książka, obok której nie może przejść obojętnie nikt, kto interesuje się językiem JavaScript. Mowa o “Essential JavaScript Design Patterns For Beginners”. Wbrew temu co mówi tytuł książki, nie jest to pozycja tylko dla początkujących. Wyjadacze, którzy potrafią wyczarować JavaScriptem niemal wszystko, również znajdą w tej książce wiele ciekawych informacji.

Szczegółowe informacje na temat książki oraz linki pobrania znajdziecie na blogu autora – http://addyosmani.com/blog/essentialjsdesignpatternsupdate1/

Miłej lektury!

Z serii ciekawe pluginy jQuery zapraszam do zapoznania się z jQuery Waypoints. Jest to bardzo prosty plugin, dzięki któremu mamy możliwość wykonywania funkcji w reakcji na przewinięcie strony do konkretnego miejsca na stronie. Brzmi ciekawie? To sprawdźcie dema:

• nieskończona strona
• przyklejone elementy
• statystyki przewijania strony

Dokumentację wraz z przykładami znajdziecie na stronie projektu – http://imakewebthings.github.com/jquery-waypoints/

Eclipse towarzyszył mi przez całą moją drogę programisty PHP. Poza krótkimi skokami w bok z Netbeansem oraz szybkimi akcjami z Notepad++ oraz PSPad, Eclipse był zawsze ze mną. Szerokie spektrum zastosowania utwierdzało mnie w przekonaniu, iż nie ma lepszej platformy dla programisty. Oprócz PHP, Eclipse (a raczej liczne jego odmiany) pozwalał mi na pracę z Flexem, Windows Azure, AIR (w JavaScript), a nawet przez bardzo krótką chwilę z Javą. Niedawno przekonałem się jak bardzo byłem w błędzie. Największą bolączką Eclipse’a jest jego mułowatość. Nie raz zdarzyło mu się zawiesić na podpowiadaniu składni, a instalacja kolejnych pluginów, negatywnie odbijała się na i tak nienajlepszej wydajności. Do tego wszystkiego dochodzi ogromne zapotrzebowanie na pamięć oraz dosyć wysoka awaryjność. Jednym słowem – tragedia. Dlaczego więc uparcie siedziałem na Eclipse? Ponieważ mimo swoich wad, był najlepszym IDE dla programisty PHP.

Był, gdyż przełamałem niechęć do PhpStorm (kolejne IDE napisane w Javie) i z pełną odpowiedzialnością mogę napisać, że jest to najlepsze jak do tej pory IDE dla PHP na jakim przyszło mi pracować. Wprawdzie testuję je raptem od tygodnia, jednak nie zdarzyło mu się jeszcze, przywiesić na podpowiadaniu składni. Każdego dnia odkrywam kolejne interesujące funkcjonalności, a ekranu z ustawieniami nie przejrzałem nawet do połowy.

Dlaczego PhpStorm jest taki rewelacyjny? Jego zalety zebrałem w punktach. Oto one:

• Zużywa mniej pamięci.
• Podpowiadanie składni jest niesamowicie szybkie i jeszcze mi się nie zamuliło.
• Podpowiadane są również klucze w tablicach.
• Zamiast pisać całą nazwę klasy, wystarczy napisać pierwsze litery członów jej nazwy. Czyli zamiast Zend_Form_Element_Text, wystarczy że napiszemy ZFET, a resztą zajmie się podpowiadanie składni.
• Wsparcie dla narzędzi wiersza poleceń (Zend Framework, Symfony oraz własne narzędzia). Możemy z poziomu IDE korzystać z Zend_Tool. Co więcej, PhpStorm podpowiada składnię poleceń.
• Generowanie PHPDoc wraz z typami. Typy określane są na podstawie domyślnych wartości w argumentach funkcji oraz na podstawie typu zmiennej zwracanej przez funkcję.
• Jeśli chcemy przejść do jakiegoś pliku, nie musimy już go szukać w drzewie. Wystarczy, że zastosujemy ten sam mechanizm, co w przypadku podpowiadania składni, czyli napiszemy pierwsze litery z członów nazwy klasy.
• wbudowane mechanizmy do obsługi systemów kontroli wersji – CVS, SVN, Git, Mercurial
• możliwość integracji z JIRA, Redmine, GitHub
• wbudowany debuger
• możliwość wdrożenia projektu na serwer FTP/SFTP
• możliwość połączenia się bazą danych
• refaktoryzacja kodu
• walidacja kodu pod kątem ilości argumentów przekazanych do funkcji/metody oraz implementacji abstrakcyjnych metod
• wbudowany wiersz poleceń

Już. Trochę tego się uzbierało jak na tydzień testowania. Pewnie zastanawiacie się gdzie jest haczyk? PhpStorm nie jest darmowy. Licencja dla pojedynczego dewelopera kosztuje około 350 złotych. Warto jednak wydać te pieniądze na coś tak dobrego jak PhpStorm.

Czy to oznacza, że na dobre pożegnałem się z Eclipse? Nie. Z Eclipse będę korzystał podczas pracy nad projektami związanymi z Windows Azure, chociaż na pewno spróbuję przenieść większość (a może i wszystkie) prac na PhpStorm. Przesiadki na pewno nie uda mi się zrobić z Flash Buildera, ale o tym napiszę przy innej okazji.

Podsumowując. Jeśli zależy wam na dobrym IDE, za stosunkowo niewielką cenę, zainteresujcie się PhpStorm. Nie musicie go od razu kupować. Przez 30 dni można testować jego możliwości za darmo w ramach triala.

Wykonując dzisiaj taski w pracy, natrafiłem na ciekawą rzecz, task, z wklejonym komunikatem o treści (imiona klas zostały zmienione ze względu na prośbę zainteresowanych):

Fatal error: Cannot access private property Foo::$foo in /home/www/example/Bar.php on line 75

Pierwsze co zrobiłem, to oczywiście zajrzałem do pliku Bar.php i linie 75, zastałem coś w rodzaju:

public function init(){
    $this->foo = 'foofoo';
}

Oczywiście pierwsze co mi przyszło do głowy to „pewnie w klasie w hierarchii wyżej jest ta zmienna zadeklarowana jako private”. Zacząłem przebijać się przez hierarchię klas i ku mojemu zdziwieniu deklaracji „private $foo;” nie znalazłem. Kilka razy rzuciłem kolegę dyżurnym pluszowym krabem i wpadł mi do głowy pomysł – zajrzę do kodu klasy Foo.

Zajrzałem i spostrzegłem, że wywołuje ona parent::init() z klasy Bar. Następnie zauważyłem, że ma zdeklarowane w swoim ciele szukane „private $foo”. Szybko zmieniłem private na protected i zadziałało.

Jakie z tego płyną wnioski ? Po pierwsze, warto czasami rzucić kogoś krabem. Po drugie, kwalifikatory widoczności działają w obie strony hierarchii klas. Po trzecie – jak mówi stare chińskie przysłowie – rzeka płynie tylko w jedną stronę, a jak płynie w dwie to odstaw LSD .

Ostatnio zainteresowałem się metodologią tworzenia oprogramowania BDD (Behavior Driven Development – Programowanie sterowane zachowaniem). Jest to stosunkowo nowe podejście wprowadzone około 2003 roku przez Dana Northa (polecam: http://dannorth.net/introducing-bdd/).

O co to chodzi w tym całym BDD?

Opisze jak to rozumiem. Zaczynamy od określenia i identyfikacji wymagań biznesowych klienta jako “historyjek” które będą zrozumiałe dla każdego. Do “historyjek” dodajemy kryteria akceptacji, dzięki którym możemy powiedzieć kiedy nasza praca jest skończona. Nasze historyjki są zapisane w formacie zrozumiałym dla człowieka jednak powinny być też testami czyli powinny być wykonywalne i automatyczne. Tak zdefiniowane testy/zachowania są zarazem bardzo dobrą dokumentacją. Myślę że ta metodologia pomaga nam (ludziom związanym z tworzeniem oprogramowania) lepiej zrozumieć idee którą klient ma w głowie. Jeszcze do nie dawna w PHP nie było żadnego frameworka który pozwalał by używać tej metodologi, jednak na szczęście powstał behat który wzorowany jest na frameworku “cucumber” rubiego (który moim zdaniem jest całkiem zgrabną implementacją BDD). Moim zdaniem BDD może bardzo pomóc w tworzeniu dobrego oprogramowania. W najbliższym okresie mam zamiar bardziej zapoznać się z behatem od strony praktycznej. Na pewno podzielę się wynikami.