Dzisiaj będzie szybko, krótko, treściwie, niczym po żołniersku Jestem zakręcony z powodu kończenia kolejnego projektu dla klienta oraz poniedziałkowego wylotu do ciepłych krajów; szok, że udało mi się coś nowego napisać (ale o prokrastynacji i GTD będzie innym razem, obiecuję).

Kohana Projects to długo oczekiwany serwis (oparty na popularnym ostatnio (tfu) Railsowym Redmine) mający za zadanie w jednym miejscu zgromadzić wszystkie “okołokohanowe” projekty. Podoba mi się. Może nie sam system (bo trochę bałaganu w nim jest), ale sam fakt zebrania wszystkiego do kupy. Widzę, że ilość dodatków systematycznie wzrasta. Super.

Kohana Debug Toolbar to pierwsza perełka wygrzebana na tym serwisie. Jeżeli ktoś miał styczność z Symfony to z pewnością jest zaznajomiony z tym widokiem:

KDT to udana próba przerobienia standardowego profilera w ten znany z Symfony. Dodatek jest fantastyczny. Takie proste a tyle radości Profiler często “wykrzaczał” mi layout, wydłużał stronę i w ogóle dostarczał innych niepożądanych wizualnych efektów. Z KDT problem mamy z głowy, dane mamy pod ręką, jedynie trochę więcej musimy się naklikać

Kończąc te “kohane” wiadomości nie sposób pominąć Naszej Kohany czyli inicjatywy osób związanych z polskim forum kohany. NK to odpowiedź na ogromne zapotrzebowanie na jakąkolwiek literaturę o KohanaPHP w naszym języku. Lektura obowiązkowa dla początkujących (których ostatnio jest coraz więcej i którzy reprezentują coraz to niższy poziom wiedzy :/ ).

Dzisiaj taka mało przyjemna sprawa :/ Jakiś czas temu pewna osoba dostała maila, którego można by streścić słowami: “wasza aplikacja jest dziurawa, mam hasła do bazy, proponuje 150zł i wykonam odpowiednie poprawki bezpieczeństwa”. Śliska sprawa tym bardziej, że napisała to osoba udzielająca się na polskim forum Kohany, notabene także czytelnik tego bloga Nie chce tego komentować, za to proponuje lekturę wpisu Vagli. Skupmy się na samym problemie.

Problem dotyczy frameworka KohanaPHP od wersji (chyba 2.2) w której dodano internal cache w konfiguracji. Internal cache to solidny kop wydajnościowy uzyskiwany poprzez zbuforowanie na ustalony okres czasu całej konfiguracji frameworka oraz wszystkich ścieżek dostępu. Zserializowane tablice są zapisywane w formie tekstowej w katalogu /application/cache/. Nie jestem teraz w stanie stwierdzić czy złą konstrukcję .htaccess posiadała oficjalna paczka z tego czasu czy to jest kwestia indywidualnych zmian. Ważne jest abyście sprawdzili swoje poprzednie produkcje i mieli to na uwadze zestawiając nowe (jednocześnie zmieniając .htaccess standardowo dostarczany z frameworkiem). W każdym razie zestawienie inne niż kierowanie wszystkiego (z pominięciem np. css/img/js itp.) na index.php może spowodować to, że ów katalog z cache będzie swobodnie dostępny z poziomu przeglądarki, a tym samym dostęp do loginu/hasła do bazy danych stoi otworem

ps. to też jeden z powodów dla którego zawsze sugeruję przenoszenie katalogów z aplikacją i frameworkiem POZA katalog główny (tzw. webroot) dostępny na zewnątrz. W Kohanie jest to bardzo proste do uzyskania: edytujemy plik index.php zmieniając $kohana_application, $kohana_modules i $kohana_system na odpowiednie ścieżki (np. "../enginemojejstrony/application").

Do napisania tej notki sprowokowała mnie pewna dyskusja na GoldenLine.pl. Klientka jakiejś firmy narzeka, że dostała aplikację, która nie działa na jej hostinKu (błąd zamierzony).

Co teraz??? Mam strone, za ktora zaplacilam, ktora jest kompletnie do wywalenia, bo .. firma przyjela, ze php 5 jest obslugiwane. [...] Dostalam wiec produkt z wada.

PHP4 2000-2008 R.I.P.

Pierwsza stabilna wersja PHP4 ukazała się 22 maja 2000 roku (!!!). 31 grudnia 2007 roku PHP4 zostało oficjalnie uśmiercone, kilka dni później pojawiła się ostatnia (do dzisiaj ale o tym za chwilkę) wersja 4.4.8 z zastrzeżeniem, że support bezpieczeństwa dla gałęzi 4.x będzie trwał do 8.8.2008 (piękna data, jak widać fascynuje wiele osób ). Jak zapowiedziano tak zrobiono i wczoraj ukazała się ostatnia poprawka bezpieczeństwa PHP 4.4.9:

This release wraps up all the outstanding patches for the PHP 4.4 series, and is therefore the last PHP 4.4 release. After today there will be no more PHP 4 releases, regardless of whether there are security issues found in PHP 4. It’s time to upgrade now

Developerzy PHP podkreślają, że rozdział z PHP4 został DEFINITYWNIE zamknięty i nawet jeśli zostaną wykryte nowe dziury to NIE zostanie wydana żadna poprawka bezpieczeństwa.

Produkt z wadą?

Ale wróćmy do zirytowanej klientki. Czy w obliczu w/w faktów można mieć JAKIEKOLWIEK pretensje do firmy wykonującej aplikację? PHP4 przestało istnieć pół roku temu, równie dobrze klientka mogła by mieć pretensje, że produkt nie jest kompatybilny z PHP3! (pomijam tutaj sprawę wcześniejszego “dogadania się” oraz odpowiednich zapisów w umowach). Czasy w których wymaganie PHP5 było brane za fanaberię programisty bezpowrotnie minęły. Mam nadzieję, że w przyszłości PHP6 zostanie wprowadzone bardziej zdecydowanie i developerzy PHP nie zafundują nam już kilkuletniego horroru miotania się między wersjami i robienia jakiś dziwacznych hybryd.

“Bezpieczny” hosting

serwer, na ktorym jest dotychczasowa strona kliena obsluguje wylacznie php 4. Provider nie rpzewiduje w ciagu najblizszych co najmniej 6 miesiecy przestawienia serwera na php 5. Provider to Rubikon ;)))

Nie wiem czy najlepszym wyjściem z sytuacji nie było by wykrycie jakiejś poważnej luki bezpieczeństwa i nie złamanie się developerów PHP w swoim postanowieniu.

PHP 5.3 alfa

Przy okazji tego wpisu chciałbym zwrócić waszą uwagę na gotową betę alfę PHP 5.3. Odsyłam do oficjalnej notki, dodam tylko, że wersja ta wprowadza dosyć istotne i postulowane od lat “nowości” (czyli to co w wielu innych językach jest normą) m.in. namespaces, lambda functions and closures i wiele innych.

Czym jest Coworking?

Coworking to idea wspólnej pracy skierowana do ludzi wolnych zawodów, freelancerów pracujących dotychczas w domach. W ramach coworkingu spotykają się w jednym miejscu i każdy z nich pracuje niezależnie, ale jeśli chcą, mogą rozpocząć pracę nad wspólnymi projektami.

Coworking pozostawia więc wolnym strzelcom tak cenioną przez nich swobodę i kontrolę nad swoją pracą. Jednocześnie pozwala oddzielić sferę pracy od domu oraz daje szansę działania w twórczej atmosferze i wśród ludzi podobnie myślących.

Tyle definicji. A dlaczego o tym piszę? Otóż w końcu (bo przymiarek w różnych konfiguracjach było na prawdę wiele) ruszyło nasze wspólne biuro w Katowicach, a to za sprawą Tomka i Artura, którzy poważnie zabrali się za to i doprowadzili do końca. Nie skłamię mówiąc iż swój bardzo malutki udział miał nasz śląski barcamp - “Spodek 2.0″. Na poprzedniej edycji gościliśmy ekipę coworking.pl z Krakowa z prezentacją na temat coworkingu i spotkań jelly, wtedy też wywiązała się ciekawa dyskusja, Tomek przedstawił swoje plany co do wspólnego biura i tak “wyłowił” 3 zainteresowanych “spodkowiczów” Jak widać warto bywać na spodku

Tak więc w jednym biurze mamy 6 osób, co zabawne, jest to de facto 6 różnych “firm” (“działalności gospodarczych” mówiąc slangiem prawnym ;P). Myślę, że większość z nas potrzebowała osobnego miejsca pracy (nie w domu) - akurat w naszym fachu spotkania z klientami zdarzają się rzadko (ach ten internet można pracować nawet na kanarach - wkrótce test praktyczny ;)), a ci na ogół są rozsiani gdzieś po całej Polsce (a nawet europie).

fot. wylęgarnia startupów

Nie muszę chyba też pisać, że zupełnie inaczej pracuje się razem tworząc wspólne projekty.

Na razie skromnie ale powoli urządzamy się w przerwie między projektami

ps. uprzedzając pytania (bo już były takie): nie, to na ścianie to nie fototapeta To dzieło to ręczna robota siostry Artura Motywów chyba nie trzeba tłumaczyć Ściana idealnie współgra z ekipą zicherka.pl która siedzi przy niej

fot. tu “się robi” nowa zicherka

Kilka dni temu pojawił się nowy skrypt, który powinien was zainteresować. Pisząc “was” mam na myśli tą część, która wielokrotnie wyrażała chęć obejrzenia czyjegoś projektu napisanego w Kohanie na forum.php.pl czy też na forum.kohanaphp.pl.

Otóż system wymiany linków e-weblink.com udostępnił skrypt e-webcities służący do kolokwialnie mówiąc nabicia sobie punktów w systemie (czytaj: powiększenia zaplecza, zindeksowania, zwiększenia site: itd.). Pominę cały ten aspekt SEO (zainteresowanych odsyłam do wpisów: “E-WebCities - czyli zaplecze na wyłączność” i “Zaplecze i moje w nim nowe trendy“) i skupię się na samym projekcie.

Demo skryptu znajduje się pod adresem ewebcites.info, skrypt wraz z instalacją e-weblinka dostępny jest po zalogowaniu się do systemu. Drobna sugestia: jeżeli przygotowujecie paczkę do masowego rozpowszechniania to zadbajcie o skasowanie zbędnych plików, a tych dostarczanych domyślnie wraz z Kohaną jest sporo (tutaj widać wersję 2.1 gdzie modułów jest kilka, ale już najnowsza wersja ma ich… 11! Swoją drogą developerzy Kohany powinni katalog /modules dołączać opcjonalnie). Poza skasowaniem katalogu /modules (tego czego nie używa się w projekcie, ale to chyba oczywiste ). Warto zrobić czystki w /system/libraries (szczególnie /drivers) i /system/i18n (w większości wypadków nie potrzebujemy 14 tłumaczeń). Autor zmodyfikował nieco core frameworka (m.in. widać zmiany w funkcji config::item) więc ostrożnie z adaptacją tego do swoich projektów opartych na oryginalnej Kohanie. I to w zasadzie tyle, nie ma co opisywać, lepiej samemu spojrzeć. Myślę, że ci którzy mają problem z załapaniem MVC i pisaniem w Kohanie będą usatysfakcjonowani nową pomocą Osobiście irytuje mnie używany tam sposób routingu (tyle pisaniny dla każdej akcji, mała elastyczność) ale to są już prywatne przyzwyczajenia - dyskusja na ten temat była by tak samo bez sensu jak przy tej czy stosować camelCase czy under_line

Jeżeli ktoś ma jakieś pytania to można zostawić w komentarzach - autor pewnie zajrzy i odpowie