Na ogół daruje sobie informować o sprawach, które są na ustach wszystkich ale widzę, że ta informacja dzisiaj jakoś bezszelestnie przeszła przez branżowe media Firma Sun Mirosystems ogłosiła dzisiaj, że zakupiła (zakupiła/przejęła, za gotówkę/w akcjach - nie jestem biegły w tych sprawach więc odsyłam do oficjalnego oświadczenia) szwedzką firmę MySQL AB za miliard dolarów. Ładna sumka. Polecam też przeczytać opinie Tima O’Reilly. Czyli co, został nam tylko PostgreSQL?

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.

No i wykrakałem wczorajszym wpisem Jest oficjalna wersja 2.0, jest i nowa strona www. Ciekawie został rozwiązany dział download. Można pobrać dwie wersje:

• Tiny Flower (Minimal) – zawiera biblioteki: Session, Validation, oraz helpery: array, cookie, form, html, security, url, validation.
• Naked Babe (Standard) – dodatkowe biblioteki: Archive, Database, Encryption, Pagination, Profiler. Dodatkowe helpery: date, download, feed, inflector, text.

Dodatkowo można pobrać z zewnętrznymi projektami przystosowanymi do pracy z Kohaną:

• Markdown
• SwiftMailer (choć w tym momencie jest błąd przy pobraniu z SwiftMailerem )
• HTMLPurifier

Na razie za dokumentację robi wyciąg z komentarzy w formacie NaturalDocs. Dla początkujących być może problem, użytkownicy CI nie powinni mieć problemów z oswojeniem się z nowym frameworkiem. Razem z Kohaną jest dostarczany kontroler zawierający kilka przykładów.

Pojawiają się pierwsze zgłoszenia usterek, pierwsze opinie czy też sugestie co do następnej wersji, SVN przestawił się już na support numerka 2.1 Trzymam kciuki za ten projekt.

Ważne: ta notka przeleżała w brudnopisie prawie miesiąc, czekając aż zostanie skończona. Niestety jestem w trakcie pracy nad bardzo dużymi nowymi projektami i nie miałem czasu jej skończyć. Z uwagi na to, że lada dzień zapowiadane jest “zamrożenie” stanu z SVN i wydanie wersji stabilnej, postanowiłem opublikować to co mam

Sposób prowadzenia projektu CodeIgniter od dawna był mocno krytykowany (w tym i przeze mnie). Nowe wersje, o ile się pojawiały to były to tylko kosmetyczne zmiany i poprawki większych błędów (błąd, który zgłosiłem w helperze “date” chyba pół roku temu, do dzisiaj nie został poprawiony). Developerzy CI pozostawali głusi na sugestie społeczności tego frameworka, nie można było się doprosić istotnych poprawek czy też nowych funkcjonalności. Chyba najbardziej dobijający był fakt, iż oficjalnie CI nie ma zamiaru być przepisane pod kątem PHP5 (być może problemem jest silne związanie CI z innym, komercyjnym produktem - ExpressionEngine), a informacja o końcu supportu dla PHP4 nie zrobiła na panach z EllisLab wrażenia. W pewnym stopniu ich rozumiem: trzeba z czegoś żyć i na czymś zarabiać, a w/w zmiany wymagały by przepisania CI w zasadzie od zera. Z drugiej strony, z upływem czasu będzie im coraz trudniej, w pewnym momencie może się już okazać, że jest za późno.

I stało się. Siła tzw. ‘community’ czyli społeczeństwa zorganizowanego wokół tego projektu była tak duża, że spowodowała “oderwanie się” najbardziej aktywnych użytkowników i powstanie nowego projektu, którym jest, tada (fanfary): KohanaPHP (w tej chwili pod tym adresem jest stara, nieaktualna już wersja strony projektu, informacji należy szukać na forum).

Czym jest Kohana? To tzw. fork CodeIgnitera. Start projektu zaczął się od wersji CI 1.5.4 w okolicach czerwca br. Chwilę później została wydana wersja 1.0, która stanowiła most pomiędzy CI a Kohaną. Trochę dziwię się tej numeracji, gdyż tak na prawdę w tej wersji został nakreślony nowy “core” frameworka oraz przepisano kilka bibliotek. Co najwyżej mogła to być wersja 0.1 Projekt zaczął od kodowej nazwy “Blue Flame”, która ze względu na zbyt dosłowne nawiązanie do CI (logo CI) została potem zmieniona na Kohana. W międzyczasie rozwój projektu został wstrzymany ze względu na problemy prawne (interpretacja dziwnej licencji CI), ba, nawet pojawiła się informacja, że w obecnej formie projekt może przestać być rozwijany. Na szczęście sprawy prawne zostały w miarę szybko rozwiązane (nastąpiło też jakieś porozumienie z EllisLab czyli właścicielami CI) i nastąpiła praca nad pierwszą stabilną wersją oznaczoną jako Kohana 2.0 (eh, ta numeracja).

Czym Kohana ma się różnić od CodeIgnitera?

• przede wszystkim PHP5 - całkowicie od zera zostało wszystko przepisane, poczynając od samego core, a kończąc na helperach
• pełne wsparcie dla UTF8 (CI płata straszne figle w tym temacie, szczególnie jeżeli chodzi o funkcje routera i bazujące na tekście)
• wyeliminowaniem wszystkich kretyńskich błędów CI, zarówno jeżeli chodzi o PHP jak i warstwę użyteczności
• rozwijaniem projektu - wydaje się, że to oczywiste, przykład stojącego w miejscu (a w zasadzie cofającego się) CI pokazuje, że nie dla każdego

Widać, że programiści Kohany postawili nie jeden serwis na CI i poznali wszystkie jego wady. Wiele drobnych ale na prawdę istotnych rzeczy zostało zorganizowane w inny sposób lub zostały inaczej napisane, choćby logiczniejsza struktura katalogów i dodatków, lepsze rozwiązania w bibliotekach np. paginacji czy konfiguracji, lepiej rozplanowane pliki konfiguracyjne itp.

Ideologia CI (dzięki bogu) została zachowana. Czyli nadal chodzi o bardzo lekki framework MVC, nie narzucający ostro specyficznej dla siebie konwencji pisania i nie zmuszający do korzystania z “jedynie słusznego” sposobu na rozwiązanie danego problemu. Ciesze się, że deweloperzy Kohany nie starają się na siłę uraczyć nas jakimś ORM (choć w SVN pojawił się moduł podobny w działaniu do tego z cakePHP), propelem, yamlami czy kopiowaniem rozwiązań z innych frameworków (RoR). Kto ma używać Symfony, cakePHP czy Prado, ten dawno używa i zmieniać nie będzie. To kwestia podejścia do pewnych rozwiązań, a nie tego co “jest lepsze” (ale to już temat na zupełnie inną notkę).

Od miesiąca obserwuje zmiany w SVN Kohany. Ilość commitów jest imponująca, w zasadzie codziennie jest coś nowego. Starałem się już napisać coś w oparciu o aktualną wersję jednak wszystko tak szybko się zmienia, że jak dla mnie zdecydowanie nie jest to wersja stabilna. Co gorsza, brak jest dokumentacji, a jak wiadomo ta z CI jest bardzo dobra. I tym bardziej zdziwiła mnie informacja sprzed kilku dni, że 8 listopada pojawi się stabilna wersja 2.0. Z jednej strony, moim zdaniem, do stabilności jeszcze daleko, z drugiej, jeżeli nie wypuści się oficjalnej wersji to nigdy to się nie rozwinie i nie będzie odzewu od ludzi, nie zacznie się rozwijać nowa społeczność. Mogli by tylko popracować nad numeracją

Cieszę się, że powstał taki projekt. Wypełnia on dziurę na “rynku frameworków”, jest dla ludzi takich jak ja, którzy chcą mieć bardzo elastyczne narzędzie pracy, a jednocześnie nie są entuzjastami rozwiązań forsowanych przez inne frameworki.

Na koniec informacja, która nie nadaje się na osobny wpis: kilka dni temu powstał polski support CodeIgnitera - www.code-igniter.pl, nie wiem czy w obliczu tej notki autor się nieco nie pospieszył (lub patrząc z innej strony: spóźnił). Może dodatkowy dział dla Kohany?

ps1. To pierwsza wzmianka o Kohanie w polskim internecie (wg. Google.pl)

ps2. wpis ten był po 10 minutach w indeksie googla

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.