To chyba jedna z ostatnich notek na temat CI którego porzuciłem na rzecz  Kohany (choć  parę projektów na CI stoi więc jeszcze warto sprawdzać co jakiś czas co  u CI słychać).  Autorzy CI  ogłosili, że w SVN znajduje się już beta wersja 1.6.0, proszą o pobranie i testy przed oficjalnym wydaniem.  Zajrzałem do  changeloga i tak jak podejrzewałem wiele ciekawego tam nie znalazłem. Połowę wpisów zajmują różnego rodzaju bugfixy zgromadzone przez ostatnie kilka miesięcy, druga część to właściwie zmiany w nazewnictwie funkcji ActiveRecordu oraz  nowa  biblioteka DBForge do zarządzania bazami/tabelami.  Poza tym  jest (od dawna dostępny w SVN)  autoload  modelu,  poprawki biblioteki session (dodane tzw. flash data) oraz parę innych  drobnych, wręcz moim zdaniem mało istotnych, dodatków. Tak na prawdę w CI niemożna się spodziewać niczego nowego bez totalnego przepisania tego frameworka, a na to na razie się nie zanosi. No i dlatego mamy Kohanę

Parę dni temu ruszył polski support dla KohanaPHP framework. W obecnej chwili zostało uruchomione forum oraz strona na której są przetłumaczone teksty i poradniki z oficjalnej strony frameworka. Dodatkowo są zaczątki planety czyli agregatora wpisów z blogów na temat tego softu. Jak to z początkami for bywa - jest pusto, ale jestem przekonany, że razem z rosnącą popularnością samego frameworka i to się zmieni. Trzymam kciuki za tą inicjatywę, także dlatego, że jestem już trochę zmęczony poziomem jaki niestety oferuje nam forum.php.pl.

Krótki techniczny wywiad z Piotrem Karwatką odpowiedzialnym za kod nowej wersji blogfroga.

N: Jakie frameworki były brane pod uwagę przed przystąpieniem do pisania nowego BlogFroga i dlaczego został wybrany CodeIgniter?

PK: Po ostatecznym wyborze PHP 5 jako platformy, myślałem o kilku popularnych zrębach - m.in. Zend, Agavi, Cake PHP. Czynnikiem decydującym o wyborze CI okazała się jego szybkość i mały narzut (wygrywał wszystkie benchmarki jakie udało mi się wtedy wyszukać). CodeIgniter nie jest tak kompleksowym rozwiązaniem jak inne dostępne biblioteki - ale odbieram to jako jego zaletę. Programista otrzymuje pomoc w rozwiązaniu większości powtarzających się problemów, a jednocześnie nadal ma dużą kontrolę. Przy blogfrog.pl CI wystarczył w zupełności do implementacji frontowej strony - dopisać należało tylko kontrolki cacheujące (wykorzystałem Zend_Cache ze względu na jego dużą elastyczność) oraz dodać obsługę logowania użytkowników której CI domyślnie nie obsługuje.

N: Co zostało użyte do napisania backendu (robot) i dlaczego?

PK: Do pisania robota wykorzystałem niektóre z bibliotek wchodzących w skład Zend_Framework (tj. Zend_Cache, Zend_Feed), obsługi bazy danych PDO oraz indeksu wyszukiwania SPHINX Search. W pierwszej wersji blogfrog korzystał z parsera MagpieRSS - w nowej postawiłem na Zend - wydaje mi się dużo bardziej elastycznym rozwiązaniem oraz bardziej stabilnym - nie ma też problemu z uzyskaniem supportu. PDO jest powszechnie uważane za najszybszą bibliotekę do obsługi baz danych w PHP - po pracy nad spiderem wydaje mi się, że to prawda Zend_Cache pomaga spiderowi natomiast nie pobierać wiele razy tych samych danych, co jest szczególnie ważne przy dużej ilości feedów do sprawdzenia - wybór ze względu na elastyczność i stabilność/wsparcie rozwiązania. Co do indeksu wyszukiwania początkowo chciałem użyć Lucene w implementacji Zenda. Niestety okazało się, że jest to rozwiązanie strasznie wolne, głównie przez implementację w czystym PHP. Dlatego skorzystałem ze Sphinx Search. Silnik ten potrafi indeksować do 10MB tekstu na sekundę, a średnie wyszukiwanie trwa 0.001 s Dodatkowo autor sphinxa zapewnia niesamowity support tego rozwiązania - przy jego pomocy wraz z administratorem rozwiązaliśmy problem m.in. z NFS w ciągu… 2 godzin. Myślę, że nikt inny nie zapewniłby nam takiego wsparcia, które jest potrzebne przy serwisach o krytycznej dostępności.

N: Jak CI sprawdza się w zakresie wydajnościowym? Ile serwerów obsługuje ten projekt?

PK: CI sprawdza się bardzo dobrze, ponieważ ma mały narzut. Wąskie gardło tego rodzaju serwisów to operacje bazodanowe - które staram się cacheować. Blogfrog jest utrzymywany aktualnie na 2 serwerach połączonych w mini cluster i zostaje mu spory zapas mocy. Głównym problemem wydajnościowym nie była strona główna tylko robot - który musi zapewniać świeże notki na stronę. Robot był projektowany i pisany z myślą o minimum 10 000 blogów. Przeskanowanie 2000 blogów zajmuje aktualnie ok 1. minuty - a mam jeszcze kilka pomysłów jak to można przyspieszyć. Myślę, że najważniejsze to pamiętać o wydajności od samego początku projektowania, a potem podczas programowania i ciągle testować wybierane rozwiązania - wtedy głowa nie będzie bolała

N: Bogatszy o wiedzę nabytą podczas pisania BlogFroga możesz poradzić innym programistom na co warto zwrócić uwagę?

PK: Warto spoglądać na problem z różnych perspektyw i zadawać samemu sobie “trudne pytania” - jeśli coś nie korzysta z wielowątkowości do przyspieszenia działania - pytanie dlaczego i co stanie się gdy z tego skorzystamy; co z cachem itd.
Aby system działał optymalnie nie można przypominać sobie o wydajności na końcu - trzeba o niej pamiętać na każdym kroku i optymalizować co tylko się da (oczywiście gdy to coś już działa). Dobrze jest posługiwać się metodą “pocisków smugowych” w tworzeniu oprogramowania tego typu - pozawala łatwiej trafić w potrzeby użytkowników. Warto stawiać na proste rozwiązania które zapewniają nam to co potrzebujemy, a nie więcej

–

Piotrku dzięki za poświęcenie czasu na odpowiedź. Ktoś ma jakieś pytania? Zapraszam do komentarzy.

Z racji zboczenia zawodowego podczas przeglądania nowych stron przyglądam się nie tylko treści i grafice ale interesuje mnie także sposób budowy serwisu. Nie inaczej było i tym razem gdy na tapetę wrzuciłem nową wersję BlogFroga. I jakie było moje zdziwienie gdy po chwili zauważyłem kilka charakterystycznych dla CI elementów Kilka testów, zabawna z URLami i tak, wniosek końcowy, BlogFrog został napisany w oparciu o CodeIgnitera. Przynajmniej frontend dla użytkowników. Co jest w backendzie agregującym informacje - ciężko powiedzieć (no może oprócz tego, że “żabiasty” robot przedstawia się jako “zend_http” co by mogło sugerować użycie klasy Zend(pseudo)Frameworka). Autorzy BlogFroga całkowicie olali moje maile więc nie udało mi się dowiedzieć niczego ciekawego w tej sprawie.

Dlaczego o tym piszę? Dlatego, że takie informacje są bardzo interesujące dla innych programistów, co rusz na forach ktoś pyta o przykłady zastosowania danego frameworka w praktyce, powstają także listy takich aplikacji (serwisy oparte na: CodeIgniter, cakePHP, Prado, Symfony).

ps. Okazuje się, że jednak była odpowiedź ze strony blogfroga, a całą korespondencję nie pierwszy raz wcięło Progreso. Za parę dni więcej szczegółów w temacie BlogFroga i CI.

Dzisiaj ukazała się nowa wersja PHP oznaczona numerkiem 5.2.4. I pewnie o tym bym nie napisał (bo przecież nie śledzę z wypiekami na twarzy, kiedy to nowa wersja się pokaże) gdyby nie to, że cały wczorajszy dzień i noc spędziłem na @$#%# (ocenzurowano) właśnie z powodu PHP. Otóż pomimo odpowiednich ustawień w konfiguracji fast-cgi w Lighttpd oraz wpisów w php.ini (fixpath), PATH_INFO zawsze było puste co niestety skutkowało “wykrzaczeniem” się w całości serwisów opartych na frameworkach korzystających z PATH_INFO do routingu (jest jeszcze np. REQUEST_URI ale za długo by opisywać jakie zmiany w routingu poczyniłem, że PATH_INFO stało się niezbędne). Nienawidzę kombinacji na serwerach produkcyjnych. Wczoraj przed północą nawet udało mi się na 20 minut “wykrzaczyć” serwer starając się znaleźć rozwiązanie tego problemu. A tu dzisiaj rano taka niespodzianka: nowe PHP i do tego jeszcze opis poprawek i m.in.

Fixed bug #31892 (PHP_SELF incorrect without cgi.fix_pathinfo, but turning on screws up PATH_INFO).

PHP 5.2.4 changelog

Tak więc pełen nadziei zabieram się do kompilacji. Trzymajcie kciuki

ps. I rzeczywiście działa, błąd poprawiony. Więc jeżeli ktoś z was jedzie na PHP 5.2.3 na cgi-fcgi to niech się zastanowi nad updatem