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 :)

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 :))

Drupal 7 w cieniu Buzzr

Wczoraj natrafiłem na genialną prezentację projektu o nazwie Buzzr.



Zrobiła na mnie ogromne wrażenie. Buzzr to frontend zbudowany na Drupalu 6. Szalenie podoba mi się jego "Wordpressowość". W końcu coś przyjaznego, z ikonkami. Dzięki silnemu wykorzystaniu Drag&Drop oraz podzieleniu wszystkiego na kroki można naprawdę w genialnie prosty sposób konfigurować witrynę. Pomysły chłopaków z Lullabot uważam wręcz za rewelacyjne a wykonanie za naprawdę dobre.

Drupal 7 koncentruje siły developerów głównie na poprawianiu i porządkowaniu.
Dużo pracy zostało włożone w usunięcie pewnych niewygodnych funkcji obsługi plików. Wiele hooków posiada swoje bardziej wyspecjalizowane wersje. Niektóre ogólne zostały podzielone na kilka miejszych (tak np. hook_node_api czy hook_form_alter) inne zaczęły żyć własnym życiem (weźmy choćby hook_schema).
Drupal 7 korzysta już z PDO więc developerzy nie muszą się już martwić o implementowanie driverów do baz danych - będą obsługiwać ich tyle ile PDO obsłuży. API bazodanowe w ogóle zostało znacznie usprawnione. W końcu można w Drupalu korzystać z transakcji a nawet tabele w bazie MySQL tworzą się jako InnoDB.

To wszystko pięknie, ale odczują to raczej developerzy modułów (ja odczułem i muszę powiedzieć, że wprowadzone zmiany są naprawdę fantastyczne), ale nie zwykli użytkownicy (obecnie D7 i tak jest wolniejszy od D6). Właśnie tutaj zastanawiam się co jest grane.
Buzzr to ewidentna rewolucja. I moim zdaniem genialna rewolucja. Rozumiem, że D7 woli iść drogą ewolucji. Wiele funkcjonalności zewnętrznych modułów zostało wessane do samego Drupala. Na pewno pozwoli to lepiej je zintegrować, zrobić większy porządek.
Tak jak Drupal 6 ukierunkowywał się na nody tak Drupal 7 ukierunkowuje się na pola. Wygląda to jakby D7 miał wbudowane CCK i jest w tym dużo prawdy bo D7 znaczną część CCK wciągnął do siebie.

Nowinki znowu idą w stronę zaawansowanych technologii i performance. Bo kto dzisiaj wykorzysta wsparcie Drupala dla RDF poza naprawdę świadomymi firmami (choć moim zdaniem to świadczy o Drupalu jako poważnym graczu na rynku Business i Enterprise) czy chociażby możliwość w końcu przyśpieszenia Drupala Varnishem, który przez nieprzemyślaną metodę obsługi ciasteczek w D6 nie mógł praktycznie nic cachować?

A czemu skoro pojawił się już pasek u góry to nie tak fajny, ładny i przyjazny jak ten z Buzzr? Dlaczego nikt nie wpadł na pomysł nowego procesu instalacyjnego (takiego jak ten z Buzzr) czy uproszczenia do bólu tak podstawowych akcji jak zmiana podstawowych elementów strony (jak ten w Buzzr).
Do tej pory dzieliłem CMSy nad banalnie prostego Wordpress-a i zaawansowanego Drupala. Chłopaki z Lullabot pokazali, że można genialnie pogodzić ogień z wodą. Buzzr moim zdaniem swoją prostotą bije na głowę Wordpressa równocześnie posiadając wszystkie aspekty potęgi jaką dysponuje Drupal.

Mam nadzieję, że Drupal wiele nauczy się od Buzzr i postawi w końcu na "look and feel", które w Drupalu wciąż boleje i jest toporne.

Top 3 look & feel & simple usability & user friendly

1. Buzzr


2. Wordpress


3. Drupal

Geniusz developerów Drupala i ich kunszt w pisaniu bijącego swoją epokę kodu w PHP oraz prostata bijąca na głowę Wordpressa... Lepiej nikt nie mógł tego wymyśleć.

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.