Sunday, September 19, 2010

Flask - Nie tylko Bottle

W poprzednim wpisie pisałem o Bottle jako fajnym microframeworku dla Pythona. Jeszcze wczoraj zupełnie przypadkiem trafiłem na Flaska.

Na pierwszy rzut oka zniechęca mnie fakt, że zbudowany jest na WerkZeug. W drugim rzucie Flask wymaga ciut więcej kodu niż Bottle:

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
return "Hello World!"

if __name__ == "__main__":
app.run()


Jednak później jest już tylko lepiej. Dostępna funkcja url_for do budowania poprawnych linków - to strzał w dziesiątkę. Dokładnie to czego brakowało mi w Bottle.

Renderowanie szablonów odbywa się tutaj bardziej w stylu Pylons. Domyślnym mechanizmem jest Jinja2.

Dokumentacja Flaska wypada o niebo lepiej aniżeli konkurenta. W dokumentacji Bottle zdażają się działy mające status todo. Tutaj nie znajdziemy nic podobnego.

Na koniec dwie rzeczy, które pozytywnie mnie zaskoczyły we Flask. Wsparcie dla Flash Messages oraz wbudowane loggery aplikacji.

Tuesday, September 14, 2010

Bottle i ZODB w jednym stali domu ...

... o swojej genialności nie mówiąc nikomu.

Wybory w Kręgu Harcerstwa Starszego Matrix - napisanie prostej ankiety. W końcu okazja, aby przećwiczyć coś nowego. Tym razem ZODB i Bottle.

Bottle wydaje się nadal rozwijany oraz w jakiś sposób subiektywnie "lepszy" niż Bobo. Posiada prosty wbudowany system szablonów. Bazuje on na założeniu, że szablony znajdują się w katalogu "views" dzięki czemu unikamy potrzeby konfiguracji (jak w Rails - convention over configuration).

W obu frameworkach brakuje mi jakiejś funkcji, która generowałaby poprawne linki - chociaż niby co to za problem zrobić sobie jednolinijkową funkcję do tego. Może tyle na temat micro-frameworków. Czas o ZODB.

O ZODB usłyszałem od mojego przyjaciela, który pracuje od jakiegoś już czasu w Plone i jest tym CM/F/S em zafascynowany. Kiedyś wracając z kina powiedział "No przypisujesz sobie jak chcesz atrybuty/klucze do obiektu i jest". Brzmiało obiecująco jednak nie okazało się tak piękne.

Plone robi bardzo dużo za nas. Pierwsze - nie wystarczy przypisać. ZODB jest bazą transakcyjną i nasze działania wymagają commitowania. Najprostsza sytuacja wygląda tak:
import transaction

#
# Tutaj sobie zmieniasz
#

transaction.commit()
Kolejna sprawa, dojście do której zajęło mi sporo czasu - ZODB wychwytuje zmiany tylko elementów korzenia. Tak więc:
# W bazie danych mamy taką strukturę:
# root.osoby = [{'id': 1, 'imie': 'Jan'}, {'id': 2, 'imie': 'Katarzyna'}]

# Łączysz się z bazą danych

root.osoby[1]['imie'] = 'Kasia'
transaction.commit()
Nie zadziała ponieważ ZODB nie przeczesuje w głąb struktur danych w celu poszukiwania zmian. Musimy więc zrobić na przykład:
osoby = root.osoby
osoby[1]['imie'] = 'Kasia'
root.osoby = osoby
transaction.commit()


Co odniesie skutek. Jak więc widać ZODB jest znacznie fajniejszy w Plone niż poza nim choć nadal jest fajny :)

Sunday, September 5, 2010

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

Sunday, August 1, 2010

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

Monday, July 26, 2010

Umarł król niech żyje król

Pisałem swojego czasu o tym jak zauroczyła mnie swoją prostotą Sinatra o Werkzeug jako analogicznym rozwiązaniu dla Pythona. Dzisiaj przyszło mi wrócić do pewnego skryptu WSGI i zacząć mocno go przerabiać. Jedna metoda wystawiona na zewnątrz z użyciem Werkzeug z wykorzystaniem kilku funkcji pomocniczych.

Dzisiaj, kiedy przyszło mi dopisać do tego kilka dodatkowych metod znajdujących się pod innymi adresami i wysłanie formularza nie wytrzymałem. Werkzeug wymagała ode mnie wklepania masy kodu do mapowania URLi, potem napisania obsługi w application, do tego dokumentacja nie odpowiedziała mi na pytanie jak wystawić metodę tylko jako GET :| Poddałem się. Ta sytuacja skłoniła mnie do poszukiwań nowej Sinatry dla Pythona.

Tak trafiłem na framework Bobo. Jestem po prostu zauroczony! Banalne, proste dekoratory (jak w Sinatra) - kilka metod, nic wyszukanego. Gdyby ktoś był ciekaw jak podpiąć do mod_wsgi polecam artykuł na blogu Grahama Dumpletona "Using bobo on top of mod_wsgi". Krótko mówiąc - umarł król niech żyje król.

Werkzeug stał się w moich oczach krową i wyleciał z sektora, w którym miał być najlepszym. Teraz to takie Django w wydaniu zrób to sam. Czyli moim zdaniem - bez sensu. Bobo jest troszkę magiczne, ale ten rodzaj magii w Pythonie jest dla mnie nie tylko akceptowalny, ale nawet pożądany. Polecam wszystkim, którzy szukają wygodnego micro frameworka dla Pythona.

Sunday, July 4, 2010

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

W Polsce nigdy nie było lepiej

W minioną sobotę miałem przyjemność odbyć bardzo sympatyczną rozmowę w przedziale pociągu TLK relacji Gdańsk Wrzeszcz - Włocławek. Rozmawiałem z ludźmi myślę, że koło sześćdziesiątki. Wspomniałem o tym, że kilkanaście dni temu obroniłem dyplom, cieszę się, że już mam pracę, odczuwam jednak dyskomfort związany z widmem brania kredyty na całe życie w celu kupienia mieszkania. Słowo mieszkanie przy realiach cen w Gdańsku sprowadza się do kawalerka.
Dyskusja zboczyła na inne tory i mogłem dowiedzieć się jak było kiedyś. Przytoczę informacje, które pozyskałem w trakcie tej rozmowy. No więc kiedyś nie było problemu z dostaniem pracy. Możliwość zatrudnienia uzyskiwała już osoba w wieku lat szesnastu - otrzymywała wtedy opiekuna w zakładzie, który za nią odpowiadała. Kończenie studiów nie było powszechne. Już technik otrzymywał lepsze stanowisko w pracy zaś osoba z wykształceniem wyższym nie musiała się w ogóle martwić o zatrudnienie - była niemal natychmiast rozchwytywana na rynku pracy. Osób takich było stosunkowo niewiele ponieważ już do samego liceum szły osoby, które chciały iść dalej na studia. Reszta wybierała zawodówki i technika. Magister, czy inżynier był chętnie zatrudniany gdyż jako członek kadry zakładowej podnosił prestiż przedsiębiorstwa. Na uczelniach dostępne były stypendia różnych zakładów pracy, które spłacało się kilku letnim stażem odbytym w danym przedsiębiorstwie po ukończeniu studiów. Pracodawcy "bili się" o ludzi z wykształceniem wyższym, których była bardzo konkretna, ograniczona ilość.
Jeżeli ktoś chciał i był zdolny - a pracował - zakład chętnie wysyłał go na uczelnię, umożliwiał sześciogodzinny tryb pracy, dawał urlopy uczelniane na czas sesji oraz udzielał wszelkiego wsparcia w ukończeniu studiów. Tak było kiedyś. Kiedy zapytałem o to tajemnicze kiedyś - okazało się, że ten idylliczny obrazek to nic innego jak czasy socjalizmu w Polsce. Czasy, w których Polska zaciągnęła ogromny dług i żyła na kredyt, czasy, w którym produkowane dobra były natychmiast wywożone na tereny ZSRR a pułki w sklepach świeciły pustką. Czasy, w którym cała Polska żyła na krechę.
Pojawiło się jednak w mojej głowie pytanie. A jak wyglądało jakieś inne kiedyś? No więc kiedyś (wcześniej - przed okresem terroru socjalistycznego) była II Wojna Światowa, która jest złym przykładem szukania jak kiedyś w Polsce było. Dużo wcześniej kiedyś była I Wojna Światowa a jeszcze wcześniej kiedyś był rozbiór, po którym Polska pojawiała się na mapie dopiero po I Wojnie Światowej. Tak więc to już nie czasy współczesne, a więc odpada. Więc co tu dużo mówić - pozostało XX-lecie międzywojenne.
Skąd to pytanie? Skoro dzisiaj narzekamy często, że w Polsce nie jest dobrze to ... kiedy w Polsce było dobrze? I czy to było bardzo dawno temu? Jak wtedy było w Polsce? A może dałoby się czegoś nauczyć, wyciągnąć lekcję na dzisiejsze czasy.
Więc Mamy nasze XX-lecie między wojenne. Kiedy pytałem dziadków jak ten okres wyglądał... Cóż. Trudno szukać w tym okresie jakiś wzorców na dni dzisiejsze. Małżeństwa dążące do połączenia majątków, mezalianse, ludzie podzieleni na kasty, wszechobecne rzemiosło.
Od Okrągłego Stołu minęło 21 lat. Tyle co od końca I do początku II Wojny Światowej. Nasza elity były przez lata eksterminowane: I Wojna Światowa, II Wojna Światowa, okres socjalizmu. W Kwietniu nastąpiła do tego katastrofa w Smoleńsku.
Ten punkt widzenia uświadomił mnie, że nikt tak naprawdę w Polsce nie wie jak powinna wyglądać, bo Polska tak długo nie istniała na mapie, że nikt kto mógłby to wiedzieć - nie przeżył. Jesteśmy jak dziecko, które uczy się chodzić na nowo, raczkuje, wywraca się, potyka i wstaje znowu. Robimy kroczek za kroczkiem i raczkujemy i nie ma w tym nic czego należałoby się wstydzić.