Metoda małych zwycięstw a Drupal 7

Od kilku miesięcy skrupulatnie obserwuję dział Critical Issues (D7) i powiem szczerze, że osobiście jestem przygnębiony.

Każdy kto choć odrobinę zajmował się metodologiami Agile czytał o potrzebie małych zwycięstw, które motywowałyby i podnosiły wydajność zespołu. To co dzieje się w critical issues jest dokładnym anty-przykładem.

Jak każdy wie Drupal 7 w wersji beta wyjdzie gdy ilość krytycznych błędów spadnie do zera. Wszystko pięknie jednak śledząc każdego dnia spadki i wzrosty oraz pobieżnie przeglądając statusy poszczególnych zgłoszeń jestem załamany.

Generalnie ilość zgłoszeń utrzymuje się na poziomie trzydziestu kilku. Bywają okresy, po których liczba ta spadała do dwudziestu lub nawet kilkunastu jednak był to raczej efekt mechanizmu, który po 14 dniach braku aktywności uznaje zgłoszenie za rozwiązane aniżeli faktyczne zakończenie rozwiązywania problemu.

Oczywiście mechanizm ten ma sens i zgłoszenia tak zamykane zawierały szereg łatek będących propozycjami rozwiązania problemu. Odnoszę jednak wrażenie, że proces recenzji trwa w nieskończoność i brak jakiegoś BDFL w tym całym zamieszaniu.

Wracając do małych sukcesów. Wiele projektów przyjmuje bardzo prostą i moim zdaniem słuszną zasadę - skupiamy się w danej wersji na zaimplementowaniu kilku - dwóch, trzech rzeczy i koniec. Cel jest niedaleki, do osiągnięcia w niedługim czasie i bardzo dobrze określony. W Drupalu brakuje mi dobrze określonego celu. Metoda SMART byłaby tutaj nieoceniona i znacznie przyspieszyłaby wydanie stabilne. Jednak już sam fakt braku "małych kroków" sprawia iż nie widać końca a utrzymująca się liczba bugów nie cieszy, brak jest małych sukcesów, które podniosłyby morale.

Dobrą drogą dla projektów OpenSource jest stawianie sobie malutkich celów. Dobrze widać to w przypadku Google Chrome. Niemal od samego początku wiadomo jakie nowe funkcje pojawią się w nowej wersji, każda kolejna wersja stabilna cieszy i przynosi kolejne usprawnienia. Wszystko dzięki po mistrzowsku zaprojektowanemu procesowi (Review process, continous integration, tests), używaniu nowoczesnych narzędzi (Buildbot, Review Board, coś na wzór ANT ale dla typowe dla GNOME) i jasno określonym zasadom. Drupal mógłby się tu wiele nauczyć.

Moim zdaniem po wydaniu Drupala 7 społeczność powinna przestawić się na wydania drupala 7.1, 7.2,7.3 z kolejnymi elementami przygotowywanymi przez społeczność. Projekt rozwijałby się na bieżąco, nadążał za obecnie panującymi trendami, był innowacyjny i nowoczesny. Wydanie wielkiego Drupala 8 za kolejne kilka lat pozostawiłoby ponownie siódemkę w tyle i sprawiło, że strony na niej oparte trącą myszką.

Życzę zespołowi Drupala 8 lepszego określania celów, stosowania metody małych sukcesów, małych wydań przynoszących cieszące użytkowników zmiany i rychłego wydania ósemki :)

Maszyna integracyjna dla Drupala

Od kilku miesięcy śledzę spadającą i rosnącą momentami liczbę krytycznych bugów zgłoszonych na drupal.org. Zwane beta-blockers, ponieważ są to błędy nie pozwalające wydać wersji beta, to pojawiają się to giną. Dzisiaj przyjrzałem się treściom i komentarzom do zgłoszonych problemów.

Z grubsza wygląda to tak. Jest zgłoszony bug i w pierwszych trzech komentarzach zaraz opublikowana łatka. Potem następuje seria odpowiedzi w stylu "działa", "nie działa", " a u mnie zgłasza błąd ABC", "ja dostaję Exception takie" itd... W międzyczasie ktoś jeszcze opublikuje unit test, który ma sprawdzać poprawność rozwiązania. Dlaczego o tym piszę?

Wychodzi na to, że zgłoszony problem może wydawać się naprawiony do czasu kiedy jakaś osoba stwierdzi, że u niej nie działa i nie pojawi się znowu na liście beta-blockerów. Najgorsze w tym wszystkim, że to może trwać tygodniami. Zanim ktoś odpisze, odpali u siebie testy, zgłosi swój komentarz. Architektur może być wiele i problemy mogą wynikać z różnych przyczyn. Dramat.

O ile szybciej Drupal rozwiązywałby takie problemy gdyby posiadać maszynę integracyjną, na której wszystkie testy byłyby odpalane i testowane w znanym,wspieranym środowisku? Na przykład mieć na VirtulBox kilkanaście konfiguracji z różnymi systemami, wersjami MySQL/PHP i odpalać na nich testy proponowanych łatek. Polegać na wynikach tych testów pochodzących z maszyn integracyjnych a nie temu co mówi społeczność.

Łatwo zauważyć, że w prosty sposób wydanie projektu może być sabotowane przez zgłaszanie fikcyjnego problemu. Może, nie zablokowałoby to wydania w ogóle ale na pewno je opóźniło. Bardzo pod tym względem podoba mi się rozwijanie Google Chrome gdzie infrastrukturę - choć skromną - zapewnia Google. Testy automatyczne są i działa to wszystko - powoli, ale sprawnie.

Nie wiem z czego wynika brak zdefiniowanego procesu w Drupalu - braku infrastruktury czy doświadczenia głównych członków stojących za projektem. Moim zdaniem można byłoby się pokusić o rozproszony system testów - coś na zasadzie SETI@HOME. Ja osobiście chętnie udostępniłbym po sieci jakiegoś VirtualBoxa nocami. Zobaczymy.

@EDIT

Najpierw strzelam potem pytam. Istnieje rozproszony system testów przebudowywany obecnie. Można o nim poczytać na: http://qa.drupal.org/ oraz http://groups.drupal.org/drupal-org-testing-infrastructure. Jest też wtyczka do review o nazwie Coder :)

Architektura typu plugin

Tworzyłem już naprawdę wiele stron wykorzystując frameworki MVC. Klocuszek po klocuszku, trybik po trybiku konstruowałem żmudnie kolejne mechanizmy, bloki, elementy, funkcje, klasy, obiekty, widoki, modele, kontrolery.

Jednak czy znasz to uczucie kiedy trafiasz na aplikację, która ... jest tym czego dokładnie szukałeś. Nie? Ja też nie ponieważ często trafiam na aplikację, która prawie jest tym czego dokładnie szukałem. Czasami widzisz program, który robi to co chcesz tylko, z grubsza zmieniłbyś w nim kilka drobiazgów. Co pozostaje zrobić w takim przypadku?

Można napisać bardzo podobny program od zera, jednak szlak Cię trafia że wynajdujesz koło na nowo tylko dla kilku detali.

Można spróbować przerobić toola, ale utrzymywanie swojego forka to wciąż uciążliwe i czasochłonne zadanie.

Rzadko istnieje trzecia opcja - możesz napisać plugin, który przekształci produkt pod Twoje potrzeby.

Na PHPCon 2010 dużym zainteresowaniem cieszyła się prezentacja "Wprowadzenie do Implementacji Archietktury typu plug-in". Emocje z nim związane były różne jednak mam wrażenie, że Ci, którzy nie do końca byli zadowoleni przeoczyli fakt iż moja prezentacja o Drupalu była właśnie o architekturze typu plug-in.

Drupal pozwala Ci zupełnie z zewnątrz, z poziomu własnego pluginu, zaingerować w najgłębsze mechanizmy. Wszystko dzięki dziesiątkom hooków, które udostępnia na różnych poziomach abstrakcji.

Jeżeli masz pomysł na przerobienie Drupala prawdopodobnie wystarczy, że napiszesz swój własny plugin i wszystko uda Ci się uzyskać w żaden sposób nie ingerując w oryginalny kod Drupala. Do tego nie będziesz musiał budować podstawowych mechanizmów, takich jak: użytkownicy, newsy, kategorie, menu, treści od nowa. Po prostu skorzystasz z istniejących, a miejsca, w których Ci nie odpowiadają - zmodyfikujesz.

Unikniesz w ten sposób wynajdowania koła na nowo. Polecam każdemu, kto zastanawia się czy skorzystać z gotowego CMSa czy wybrać framework, spróbować Drupala (jako frameworka programistycznego of course :))

MVC retro

Po powrocie z PHPCon nie mam już wątpliwości. Dla mnie MVC odeszło w zapomnienie. Przygotowana przez mnie prezentacja "Drupal Application Framework - metoda na aplikację sieciową" nie pozostawiła mi żadnych złudzeń - MVC jest dobre, ale moduł wtyczkowy jest genialny. Nigdy więcej standardowej witryny pisanej we frameworku - hook module rulez.

Już jakiś czas temu przeczuwałem, że model w jakim rozwija się wtyczki w Drupalu zrewolucjonizuje mój sposób patrzenia na development w PHP. Nie spodziewałem się jednak, że moje podejście zmieni się aż tak radykalnie. Dzięki "Wprowadzenie do implementacji architektur plug-in w PHP" Damiana Tylczyńskiego utwierdziłem się w przekonaniu, że MVC to za mało, a pisanie we frameworkach jest dobry wyłącznie dla bardzo customowych rozwiązań.

Wszystkim więc z tego miejsca polecam swoją Szkołę Developerów Drupala i zapoznanie się z korzyściami płynącymi z takiego modelu tworzenia oprogramowania!

Rok 2010 rokiem przełomów w aplikacjach sieciowych

To wręcz niesamowite jak wiele dzieje się w tym roku w dziedzinie aplikacji sieciowych. Być może to tylko wrażenie, jakie można mieć co roku ale moim zdaniem jest to rok przełomowy.

Dzisiaj po 2 w nocy wyszła wersja Release Candidate 1 Gallery 3. Jest to ogromny krok w dziedzinie aplikacji do przetrzymywania zdjęć. Większość dostępnych w sieci skryptów zakłada, że istnieje jeden właściciel galerii, który publikuje w niej zdjęcia. Gallery to jedyny znany mi do tej pory system pozwalający w ramach jednej galerii tworzenie wielu albumów i przydzielania uprawnień do nich wielu użytkownikom.

Gallery posiada pewne bardzo proste - acz daleko idące w skutkach założenie - jeżeli nie masz dostępu do zdjęcia - nie masz do niego dostępu wogóle, nawet poprzez bezpośredni link. Gallery w wersji 2 realizowało to poprzez przetrzymywanie obrazków poza folderami dostępnymi przez Apache zaś każde żądanie pliku PNG, JPG czy innego było tłumaczone przez mod_rewrite na wywołanie skryptu PHP, który sprawdzał uprawnienia do pliku i ewentualnie zezwalał na jego wyświetlenie.

Niestety - przy galeriach dużych rozmiarów całość znacznie rzutowała na wydajność, wygodę i szybkość korzystania.

Gallery 3 to krok milowy w każdej tych dziedzin. Dzięki modelowaniu uprawnień na poziomie plików .htaccess udało się otrzymać wydajny i szybki mechanizm bezpieczeństwa. Celem stało się utrzymanie aplikacji sprawną, lekką i wydajną. Dołożono do tego interfejs oparty o jQuery. Całość zaś oparto na fantastycznym frameworku Kohana.

Kolejne zaskoczenie to milowe w dzidzinie od lat zgłaszanych braków Django 1.2. W końcu poprawki w dziedzinie modeli, obsługa wielu baz danych, zamknięcie wielu ticketów, które od lat straszą na Djangowym bug tracku. Django w końcu przełamuje barierę "argumentu za użyciem Pylons" jakim był brak możliwości obsługi wielu baz danych co czyni go znacznie bliższym zastosowań enterprise.

Skoro już przy Pylons jesteśmy. Nigdy nie wierzyłem, że dożyję dnia kiedy zostanie wydana publicznie wersja Pylons 1.0 beta. Jednak stało się. Pylons pretenduje do wersji stabilnej z niezmiennym API i w końcu może zacząć być używany w projektach gdzie liczy się stałość i ciągłość wersji w aktualizacji 3rd party components.

Nie można też pominąć Rails 3 - chociaż tutaj nie chcę się wypowiadać to z oglądanych przeze mnie prelekcji, wypowiedzi Yehudy Katz oraz wpisów na blogach Polskich Rubystów widać, że Rails 3 jest krokiem milowym w jakości tego frameworka ku doskonałości.

Wszystko wskazuje na to, że również Drupal 7 pojawi się w tym roku. Dwa dni temu została wypuszczona wersja Alpha 2 - co oczywiście w przypadku Drupala kompletnie o niczym nie świadczy - ale zawsze to jakiś krok do przodu. Oby prace poszły szybko - bo zapowiada się naprawdę fantastyczny framework.

Prawdopodobnie jeszcze wiele zaskoczeń czeka nas w dziedzinie aplikacji sieciowych - jednak Luty i Marzec to prawdziwy wysyp. Dzisiejszy dzień to jeden z tych, w których nie mogę uwierzyć, że jest aż tak dobrze. Oby więcej takich postępów i dobrze wykonanej pracy!

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 !