I mamy Gallery 3

W końcu, po wielu latach ciężkiego developmentu doczekaliśmy się Gallery 3. Skrypt w wersji drugiej był niesamowicie wolny i nie poddawał się w niemal żaden sposób żadnym zabiegom optymalizacyjnym. Mapowanie każdego pliku graficznego na skrypt PHP przez regułkę .htaccess w celu sprawdzenia uprawnień było najwęższym gardłem całego narzędzia.

Na ten dzień czekałem kilka miesięcy codziennie zaglądając na tracka projektu i badając ilość bugów pozostałych do releasu. W końcu nadszedł: nowa, bezpieczna, szybka, nowoczesna wersja jedynego w swoim rodzaju skryptu do obsługi galerii. Cieszy fakt, że jeden z twórców czerpał wiele inspiracji ze swojej fascynacji mistrzostwem z jakim został zaprojektowany Drupal. Tym bardziej jestem przekonany o jakości ostatecznego rozwiązania.

Pozostaje tylko się cieszyć i szykować na upgrade ZHRowej multigalerii :] Zachęcam wszystkich do pobrania :]

P.S. Skórek o dziwo nie brakuje :) jest już kilka do wyboru - niektóre naprawdę fajne :D

PHPize 5.3.1 i --prefix=""

Od kilku dni tworzę high-end webstack dla pewnego rozwiązania działającego na systemie opensolaris. W związku z tym musiałem skompilować ręcznie również PHP i modułów do niego.
W trakcie zacząłem dostawać różne dziwne błędy. Zacząłem szukać po forach, bugtrackach, forach dyskusyjnych... Problem objawiał się komunikatami błedu "sed-a" podczas uruchamiania skryptu phpize dla XCache. Wyglądało to mniej więcej tak:

PHP Api Version: 20090626
Zend Module Api No: 20090626
Zend Extension Api No: 220090626
First RE may not be null
autoheader: error: AC_CONFIG_HEADERS not found in configure.in

Problem okazała się trywialny. Podczas kompilacji podałem przełącznik --prefix="". Z jakiś przyczyn PHP zamiast wstawić do skryptu phpize prefix pusty to w ogóle stwierdziło, że go nie potrzebuje i nie stworzyło takiej zmiennej w bashu przez co wyrażenie regularne podane jako parametr seda było puste i reszta już sama ładnie się sypała. Teraz, po podaniu wartości prefix, wszystko zdaje się ładnie działać:)

Trendy polskie a praca na świeci

Nie wiem co mnie dziś tknęło ale postanowiłem sprawdzić pewną rzecz.

Przeczesując zasoby polskiej sieci, w poszukiwaniu informacji na temat tworzenia witryn internetowych, trafiamy głównie na kursy Ruby On Rails albo Django. Dzisiaj postanowiłem zobaczyć jak sprawa się ma jeżeli chodzi o "jobtrends" na świecie. Wyniki z serwisu Indeed.com/jobtrends poniżej.

O ile popularność Railsów mnie nie zszokowała (może co najwyżej jej skala) o tyle fakt iż Drupal stoi znacznie wyżej niż dziesiątki razy opisywany w polskiej sieci Django - mocno mnie zdziwiło. Czyżby Django przegrywało w świecie biznesu z Drupalem? Może to jakaś wskazówka? Szczególnie, jeżeli planujemy naszą przyszłość w perspektywie pracy programisty. I jak sytuacja ta ma się do polskich warunków pracy? Pytania pozostawiam bez odpowiedzi.

Drupal 7 zaczął maleć

Przez ostatnie kilka tygodni Drupal 7 rósł. Dosłownie Od około 1,54 MB wzrósł do 1,95 MB. Wszystko posuwało się do przodu. Aż do "teraz". Jakiś czas temu zauważyłem spadek, który na dzień dzisiejszy zatrzymał się na poziomie 1,91 MB. Czyżby przyszedł czas na usunięcie starych funkcji, przeczyszczenie niekompatybilnego kodu i "refactoring size"? Ciekawe. Obserwując ten, jakże świeży trend, można wnioskować, że został ukończony pewien duży etap. Pytanie, czy to już koniec? Drupal 7 ma zostać wstępnie wydany najpierw "dla firm", dopiero później usłyszy o nim świat. Kto wie, czy za kuluarami nie nastał już właśnie ten moment? Z jednej strony ilość ticketów w bugtrackerze sugeruje iż przed developerami jeszcze długa droga. Nikt jednak nie wie nic "na pewno" a niejasna i niezgłębiona myśl releaserów Drupala nie pozwala przeniknąć się i odkryć etapu, na którym znajduje się projekt. Ciekawe.

Framework's killers*

Rozdzielczość wykresu jest umowna i nie stanowi żadnej faktycznej miary mówiącej o skali różnić w czasie projektowania.

Tworzenie witryn na bazie Drupala, w kolejnych projektach, zajmuje coraz mniej czasu. Godziny mu poświęcone zwracają się znacznie szybciej niż te zainwestowane we frameworki. Tyle z teorii - czas na fakty.

Niewdzięczny start

Początki to przedzieranie się przez kolejną dokumentację. Opis klas, funkcji, doczytywanie szczegółów. Wewnętrzna walka nakazująca szukać rozwiązania we frameworku nie zaś w samym języku programowania.

Wiele zależy tu od naszych zdolności, jakości dokumentacji, dostępnych materiałów, aktywności społeczności na forach i grupach dyskusyjnych. W obydwu przypadkach wszystko zaczyna się mniej więcej od tego samego poziomu.

Framework-bajka

Rozpoczynający swoją pracę z frameworkami doznają szokujących usprawnień.

Granicząca z cudem autonomiczność warstwy baz danych (ORM shock!). Drastycznie zwiększona kohezja kodu po rozmieszczeniu go w kontrolerach (controllers' code improvement). Wszystko-ułatwiające helpery wykonujące dokładnie to czego potrzebujemy (helpers exactly).

Zaczynamy z wolna czuć się jak Alicja w Krainie Czarów, której nagle pokazano wejście do króliczej nory. Pozornie ciemne i ciasne, jednak kryjące w sobie cały nowy świat. Świat, w którym ciężko jest znaleźć zadanie wymagające napisania więcej niż 7 linii kodu.

Oszczędność czasu we frameworkach

W następnych projektach - zaczynamy wykorzystywać stworzone przez nas rozwiązania ponownie. Prawo lenistwa.

Do kolejnych projektów przenosimy klasy, funkcje, z czasem kontrolery, modele a nawet całe biblioteki. Od czasu do czasu coś modyfikujemy, dodajemy kilka nowych opcji, poprawiamy znalezione błędy.

Godziny poświęcane na tworzeniu strony zaczynamy liczyć w wykonanych instrukcja copy/paste. Jedyne usprawnienia stanowi używanie skrótów klawiszowych zamiast opcji menu kontekstowego. Po pewnym czasie przestają działać nam klawisze [CTRL], [X], [C] i [V] a w koszta projektu zaczynamy wliczać nową klawiaturę.

Magiczny świat CMS'ów

Wczoraj był u Ciebie klient. Zamówił witrynę. W nocy miałeś sen. Rozmawiałeś z wróżką. Mówiła o jakimś fantastycznym rozwiązaniu. Posiada wszystkie zalety framework'a. Większość standardowych klas ktoś zaprogramował za Ciebie. Witryna jest już praktycznie gotowa. Twoim jedynym zadaniem jest dostosować wszystko do Twoich potrzeb.

Drupal - gotowi start !

W Drupal'u dostajemy wszystko to, a nawet więcej. Z punktu widzenia developera. Gdzieś na spodzie funkcjonuje sobie zwykły framework. Taki z abstrakcją dla baz danych, helperami, systemem templatów i innymi featurami.

Na nim dopiero napisane są klasy do CMS'a. Tutaj dostajemy kilkanaście mechanizmów ekstra: ACL'e, klasy użytkowników, newsów, system rejestracji i logowania, raportowanie... Wymieniać można naprawdę długo.

Poza klasami - system szablonów: formularze, panele administracyjne, tabelki, domyślne CSS'y. Do tego kilka autorskich bibliotek JS dzięki, którym interfejs stylizuje się (sic!) na aplikację webową.
Z punktu widzenia użytkownika - gotowa strona, developera - wymarzony punkt startu.

Gdzie oszczędzamy czas ?

Zyskaliśmy już czas na projektowaniu i adaptacji standardowych elementów witryny. Systemu użytkowników, newsów, ACL'e, menu - są już gotowe. Doinstalowanie dodatkowych modułów, autorskich czy też pobranych z witryny projektu, zajmuje kilka chwil. Znacznie mniej niż wkoponowywanie ich do strony na poziomie kodu. O to dba Drupal.

Tworzymy wyłącznie to czego nam brakuje, ewentualnie modyfikujemy istniejące rozwiązania. Możliwość jakie dają 144 funkcje (Drupal 7) pozwalające wpiąć się w niemal każdy mechanizm przygotowanych przez twórców - są nieograniczone. Wolno nam wszystko: od modyfikowania pól formularzy po przeprojektowywanie zapytań SQL.

Stworzenie zwijanego pola fieldset, sortowania drag & drop, przyklejonych nagłówków tabel, poziomych zakładek. Wszystko wymaga dodania parametru przy wywołaniu helpera lub nadania odpowiednich klas CSS. JavaScript ? A co to jest ?

Podsumowanie

Znacznie szybciej modyfikuje się gotową witrynę, aniżeli pisze na nowo. Szczególnie łatwo w przypadku Drupal'a, który do takich przeróbek został stworzony. API pozwalające zmieniać każdy aspekt działania aplikacji. Obszerna tutoriale dla developerów. Świetnie udokumentowane API. Czytelny, jednolity kod. Setki funkcji i gotowych bibliotek. Bibliotek które od lat sprawdzają się na dziesiątkach tysięcy witryn internetowych.

Barierę stanowi pomyślenie o CMS'ie w funkcji środowiska developerskiego - nie gotowej aplikacji. Przyjrzenie się na ile modyfikowanie jest szybsze od tworzenia. O ile łatwiej jest zmieniać dobrze zaprojektowane rozwiązania w miejscu ich tworzenia. Jednak ostrzegam - być może już nigdy więcej nie sięgniesz do żadnego frameworka.

* Wpis traktuje o Drupal'u ponieważ jest najlepiej znanym autorowi, od strony developerskiej, CMS'em. Nie wyklucza on faktu iż równie dobre, a nawet lepsze, efekty można uzyskać w przypadku innych, dobrze zaprojektowanych systemów zarządzania treścią.

Drupal - what the stuff !

Jestem pod wrażeniem. Chyba główną wadą tego fantastycznego CMSa jest fakt iż został napisany w PHP. Poza tym ideał.

Projekt, który obecnie realizuję podjąłem się napisać w Drupalu. Używam go jak frameworka i korzystam z faktu iż wiele rzeczy jest już w nim napisane. Tworzę głównie moduły, które rozszerzają lub modyfikują już istniejącą funkcjonalność. Jestem pod kolosalnym wrażeniem.

Jednym z początkowych miłych zaskoczeń były fantastyczne hooki. Nie wiem czy tłumaczyć to na polski, ale mechanizmy wpinania się w już stworzone i działające razem trybiki Drupala są fantastyczne. Doświadczyłem tego dodając do już istniejących - dowolnie skonfigurowanych formularzy rodzajów treści swoje własne pola.

Formularz tworzy się w sposób niemalże banalny. Wszystko z czym do tej pory zetknąłem się w Drupalu to tablice. Formularz, Schematy tabel, Router (o ile tak można to nazwać), który tam nazywany jest i wymieszany z systemem menu - są to po prostu ogromne tablice danych ... które posiadają swoją składnie i do których każdy moduł może coś dodać.

Używanie całego wyposażenie Drupala (sticky headers, sorting tables) jest banalne choć czasem wymaga zrozumienia temat dość dogłebnie jak na przykład we wspomnianym sorting tables - mechanizm jest bardzo rozbudowany. Wszystko jednak działa naprawdę świetnie. CMSa rozszerza mi się o nowe funkcjonalności bardzo przyjemnie i łatwo :)

Czuję że chciałbym zacząć używać Drupala jako frameworka w tworzonych przeze mnie projektach. Jego twórcy zrobili na dole świetną skrzynkę z narzędziami za pomocą którego zrobili fantastycznego CMSa, a używanie tej skrzynki z narzędziami to naprawdę prawdziwa przyjemność i masa różnych zaskoczeń co do tego jak "coś tam zrobić".

Wszystkim, którzy będą musieli kiedyś zrobić witrynę z dość nietypową funkcjonalnością polecam Drupala !

Konfigurujemy VPS - komentarz

Dziś natrafiłem na szalenie ciekawą serię artykułów zatytułowaną Konfigurujemy VPS

Bardzo ciekawy temat, z przykładowymi obrazkami i rzetelnymi wyjaśnieniami. Szalenie zainteresowało mnie php-fpm. Muszę się mu przyjrzeć.

Odniosę się tutaj do Shared Hostingu. Zastanawiam się, czy ktoś bawi się w VPS na Apache. O ile w przypadku Shared Hostingu Apache jest po prostu - najlepszym wyborem o ile dla mnie wybór na VPSa jest oczywisty (na pewno nie Apache).

Fantastycznie zareklamowane postawienie na wejściu nginxa z przekierowywaniem ruchu do Apache - trzeba spróbować :) Co do PHP - wspomniał bym o kilku drobiazgach. Primo. Przyśpieszyć go można używając np. XCache lub APC. Do VPSa są po prostu świetne (APC okazuje się słabsze przy serwerze, z kilkoma tysiącami kont, na których po prostu wysiada).

Jeżeli o spawnowanie procesów FastCGI chodzi - dla wielu kont zżerają znacznie więcej pamięci niż mod_php na Apache i niestety przy użyciu do nich dodatkowo suexec po prostu serwer musiałby być maszyną rodem z TASKu, żeby móc to obsłużyć.

Gdyby chcieć mieć shared hosting ze spawnowanym PHP vis user z XCachem dla każdego usera z osobna - potrzebna byłaby POTWORNA maszyna.

Komentarz do MVC - czyli frameworki PHP

Dziś przeczytałem świetny wpis wyjaśniający o co chodzi w MVC. Osobiście chciałem dodać do niego mały komentarz, który mam nadzieję pojawi się również na blogu autora.

Ja dzisiaj - nie wyobrażam sobie tworzenia stron internetowych inaczej. Osobiście jednak - nie pisałem nigdy własnego Frameworka - raz tylko pomagałem koledze, gdyż uważam, że pisanie własnego MVC to wynajdywanie koła na nowo.

O Kohana nigdy nie słyszałem. Osobiście zaczynałem od CodeIgniter i jest to prosty framework. Jego zaletą, która jest ważna dla początkujących, jest fakt iż posiada dobrą dokumentację i można naprawdę szybko połapać się co gdzie jest.

Na kolejny ogień poszedł CakePHP. Tam dowiedziałem się co to jest scaffolding. Z cech, które przemawiają za CakePHP moim zdaniem jest na pewno obsługa drzew i ACL, których nie spotkałem w żadnym innym frameworku. Szczególnie widać to w wersji 1.2, w której pojawiło się wsparcie dla internacjonalizacji. Szalenie również podoba mi się mechanizm "elements", który moim zdaniem bardzo ułatwia tworzenie szablonów, z różnych powtarzalnych komponentów, pod, które możemy podkładać różne dane, co szalenie skraca pracę w tworzeniu szablonów. CakePHP posiada w najnowszej wersji mnóstwo innych bibliotek i wygląda mi na to, że obecnie jest to najlepszy framework.

Obecnie tworzę projekt z użycie Symfony. CakePHP w wersji 1.2 na pewno chciał doścignąć Symfony. Moim skromnym zdaniem - przypadkiem go prześcignął. Co do symfony. Posiada mnóstwo pluginów i dużą społeczność. Używa Propel, modele są więc generowane i dostępne ad-hoc - bez pisania jakiegokolwiek kodu. Dzięki użycia Propel modele generowane są w bardzo inteligentny sposób. Na koniec - bez pisania nawet połowy linijki kodu - dostajemy gotowe klasy w PHP, które obsługują między innymi CRUD oraz posiadają metody automatycznie pobierające dane z innych tabel używając złączeń. Dodatkowo są one szalenie elastyczne. Kolejna rzecz to scaffolding,który jest naprawdę piekielnie użyteczny i pozwala w 1 minutę(naprawdę właśnie w tyle) stworzyć funkcjonalny panel administratora do prostej aplikacji. W moim przypadku problemem okazało się korzystanie z dokumentacji, która z racji niekompletności,rozstrzelenia oraz braku opisania każdego modułu od A do Z (istnieje tylko kompletny opis API) jest nieużyteczna. Z tej przyczyn prawdopodobnie do czasu aż to się nie zmieni - będę korzystał z innych frameworków. Na obronę powiem tylko, że dokumentacji, która istnieje obecnie jest dużo, niemożna narzekać na jej brak czy na nie opisanie jakiś komponentów.Projekt jest jednak tak kolosalny, że stworzenie do niego dobrej dokumentacji to nie lada wyzwanie. Na razie, w moim mniemaniu jeszcze nie udało się temu wyzwaniu sprostać.

Innym ciekawym moim zdaniem framerowkiem jest Akelos, który jak możemy wyczytać na stronie internetowej, jest portem Ruby On Rails napisanym w PHP.Tyle z moich doświadczeń. Może okażą się dla kogoś pomocne w dalszej przygodzie z MVC. Chciałem przy okazji polecić swój artykuł, w którym również swojego czasu opisałem MVC na blogu Matriksa.