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

Przeglądarka na telefon

Wyobraźmy sobie świat, w którym nie istnieją przeglądarki dla telefonów komórkowych. Pewnego pięknego dnia przeglądając stare szpargały przypadkowo ocierasz starą lampę. Wychodzi z niej dżin i mówi, że uczyni dla Ciebie możliwym korzystanie z jednej z desktopowych przeglądarek na Twoim telefonie. Którą byś wybrał? Moje myślenie byłoby takie.

Internet Explorer? Nieee. Jest przecież za wolna i wszyscy piszą na nią w kółko wirusy. Po za tym są lepsze, bardziej zgodne ze standardami. Może Firefox? Ale kto chciałby czekać tyle czasu i zamulać telefon Firefoxem? Hmm Safari. Co Safari ma takiego czego nie ma konkurencja, poza tym - to dla maniaków Apple i iPodowców - nie dla mnie. No to co?

W moim przypadku na polu walki zostaje Opera i Chrome. Obie są szybkie, innowacyjne, tworzone z dużym przykładaniem się do look & feel klienta.

Obecnie Opera jest często najrozsądniejszym wyborem w przypadku przeglądarek internetowych na telefon. Jednak nawet gdyby istniała równie mocno rozwinięta konkurencja i tak byłaby w moim przypadku na drugim miejscu :)

Moje życie z Google Chrome

Dzisiaj zainstalowałem na VirtualBox Ubuntu 10.04. Pierwsze po zainstalowaniu Guest Additions było wyszukanie jakiegoś Google Chrome. Na początku trafiłem na wiekowe Chromium w repozytorium. Potem w jakiś komentarzach trafiłem na informację, że można ściągnąć paczuszkę ze strony Google.

Fajnie to zrobili bo dodaje się do systemu repozytorium z którego pobierane są aktualizacje.

Właściwie uświadomiłem sobie, że o ile na codzień pracuję na Windows 7 to Ubuntu było mi potrzebne tylko po to aby zainstalować sobie Google Chrome i to było wszystko co mi do szczęścia było potrzebne. Doświadczenia związane z korzystaniem z Google Chrome są dla mnie tak pozytywne że wręcz chciałbym aby stało się dla mnie podstawowym środowiskiem pracy.

To wygląda tak, jakby Chromium OS było dla mnie idealnym systemem. Ciekawe czy tak rzeczywiście będzie.

Trywialny błąd we wtyczce Chrome Frame

Właśnie przygotowuję wykłady na Politechnikę i chciałem dzisiaj pokazać Chrome Frame. Zawiodłem się gdy wtyczka zamiast pokazać ramkę z propozycją instalacji dodatku zawiesiła na moment Internet Explorer a po chwili wyrzuciła błąd. Ostatecznie problem okazał się banalny:

W skrypcie CFInstall.js linia 173 wyglądała:

var installUrl = '//www.google.com/chromeframe';

zamiast

var installUrl = 'http://www.google.com/chromeframe';

Po zmianie tego odnośnika :) zaczęło działać :) Mam nadzieję, że komuś się przyda.

Rozszerzenia w Google Chrome - framework rewolucja

Ostatnio zostałem wiernym czytelnikiem strony developerów implementujących rozszerzenia do Google Chrome. Pewne elementy API są zaimplementowane już w całości, inne tylko w części. Jedną z dostępnych już dziś funkcjonalności jest ładowanie content scripts - elementów rozszerzeń napisanych z użyciem JavaScript.

Ich działanie opiera się na ładowaniu do przeglądarki dowolnego skryptu js działającego na stronie. Pisanie dużych ilości kodu w JavaScript jest bardzo żmudnym zadaniem, ale od czego są narzędzia i biblioteki pokroju jQuery ?

Postanowiłem zrobić mały eksperyment i nieco zmodyfikować przykład z dokumentacji. Na początku ściągnąłem i w pierwszej kolejności do mojego skryptu załadowałem plik jquery.js, dopiero w drugiej właściwy skrypt JavaScript podmieniający rysunek z google.com na logo komiks "Windows to Chrome" jednak pisząc skrypt z wykorzystaniem składni jquery. Efekty możecie obejrzeć poniżej lub spróbować sami.

Efekt działania skryptu.

Kod plików stanowiących trzon rozszerzenia

Jeżeli chcesz spróbować samemu uruchomić rozszerzenie jego kod znajdziej pod tym linkiem. Jedyne co musisz zrobić to wypakować je do jakiegoś folderu i podać ścieżkę do katalogu, w którym znajduje się manifest.json. Powiedzmy, że był to C:\chrome_comics. Wtedy polecenie, które musisz wykonać w zależności od tego gdzie w Twoim systemie zainstalowal się Google Chrome będzie wyglądało mniej więcej tak:

C:\Users\Username\AppData\Local\Google\Chrome\Application\chrome.exe
--enable-extensions --load-extension="C:\chrome_comics"

Co z tego wynika ? Możliwość wykorzystywania w pisanych przez siebie wtyczkach takich bibliotek jak jQuery, Mootools, Dojo, Qooxdoo, Prototype biorąc pod uwagę ich możliwości, ilość dostępnych wtyczek, sposób wjaki przyspieszają i ułatwiają pisanie kodu JavaScript oraz stworzone na ich bazie biblioteki, ogrom tego wszystkie daje pojęcie jak wielki potencjał tkwi w GoogleChrome. Już na samym początku, Google bez wysiłku daje developerowi rozszerzeń ogromne pole do popisuj po raz kolejny genialnie wykorzystując istniejące już, wszystkim dobrze znane, lubiane, dojrzałe i świetnie mające się dziś biblioteki JavaScript. Moim zdaniem genialne posunięcie.

Domyślam się iż zaraz odezwą się użytkownicy GreaseMonkey, którzy powiedzą, że "to już było". Dla mnie osobiście jest to odkrycie nie z tej ziemi. Pytanie tylko czy Google widząc potencjał takiego rozwiązania pozostawi dołączanie kodu bibliotek do wtyczek developerom czy też wyposaży w nią przeglądarkę. Biorąc pod uwagę zasadę DRY oraz fakt iż nie lada marnotrastwem byłoby ładowanie do powiedzmy co 3 wtyczki jquery do co 5tej mootools to dość rozsądne wydaje się wyposażenie w najnowsze wersje przeglądarki albo stworzenia API, gdzie samemu można wgrać skrypty ogólnodostępne dla wszystkich wtyczek.
Biorąc pod uwagę iż przeciętny user będzie posiadał około 10 wtyczek załadowanie 3 bibliotek jQuery i 2 Mootools, przez każdą wtyczkę z osobna pamięci miija się z celem.

Google Chrome on Linux - 437 MB żywych źródeł (aktualizacja)

Postanowiłem sprawdzić czy uda mi się odpalić google chrome na Linuksie. Trafiłem na stronkę: http://dev.chromium.org/developers/how-tos/build-instructions-linux gdzie pokazane było jak zbudować przeglądarkę ze źródeł. Na początku zdziwiło mnie, że snapshot mega wolno się ściąga ... Myślę sobie 400 coś KB ... hmm ... pewnie serwery są zapchane... Spróbuję przez svn. Przez svn leciało szybko, jednak zacząłem mieć po 3 minutach wrażenie, że ściągam całe google: cygwin, jakieś webkity ... do licha co jest. Wtedy przyjrzałem się jednostce stojącej przy liczbie danych ściągniętego snapshotu. CO ?! 437 MB - źródeł ...Po prostu zwaliło mnie z nóg. Nie wiem jak długo się to cudo będzie budować, ale chyba pierwszy raz poczuję na sobie oddech użytkowników Gentoo ... Poczekamy zobaczymy.

Źródełka zbudowały się dość szybko i - bez problemów. Jednak po wylistowaniu wszystkich plików uruchamialnych wczytałem się ponownie w instrukcję na stronach google i zobaczyłem to. W czerwonej ramce było napisane, że poodpalać to sobie mogę - testy do przeglądarki, ale o surfowaniu nie ma mowy.