Pycon 2009 - relacji część trzecia

Kolejna część relacji z polskiego Pycona (jeśli ktoś nie czytał - pierwsza jest tutaj a druga tutaj). Sobotni wieczór.

Przed przejściem do meritum uwaga organizacyjna: na stronie konferencji zaczęły się pojawiać materiały, w szczególności można już przeglądać slajdy.

Subiektywna kronika wydarzeń

... czyli kolejna paczka notatek z wykładów.

Ponies - the good, the bad and the ugly

Honza Král mówił o współpracy użytkowników z projektem Django, przede wszystkim - o proponowaniu nowych funkcjonalności. Problem reagowania na uwagi mnie interesuje, więc słuchałem zaciekawiony.

Sprawa została ujęta żartobliwie (tytułowy kucyk, którego czasem można dostać a dużo częściej - nie) ale jest jak najbardziej poważna, o czym wie każdy stały bywalec list dyskusyjnych jakiegokolwiek większego projektu. Nigdy nie brakuje osób informujących że bez takiego czy innego uzupełnienia projekt jest bezużyteczny, stawiających rozmaite warunki, uporczywie eskalujących poboczne problemy czy próbujących nagiąć kształt projektu do swoich wyobrażeń. W biznesie pozytywne reagowanie może się opłacić, w projekcie open-source nadmiar hałasu stanowi kulę u nogi.

Developerzy Django najwyraźniej dojrzeli do postawienia sprawy jasno. Creating software is not something done by the crowd. We have BFDLs for that. Za rozwój projektu odpowiadają jego liderzy. Your opinions are welcome, but ... don't matter (that much). Możesz wyrażać opinie ale nie oczekuj, że będą one dla nas bardzo ważne (o ile nie zdobyłeś sobie dotychczas naszego szacunku).

Honza mówił też o cechach, jakie propozycja zmiany powinna spełniać, by mieć szanse na realizację. Oczywiście musi to być dobrze uzasadnione, użyteczne rozszerzenie, ale to nie wystarczy. Musi także mieć opiekuna, który:

• przyzwoicie przeanalizuje problem (ustali co jest a co nie jest możliwe, jakie są możliwe inne podejścia, ...),

• jest gotów aktywnie pracować na rzecz zmiany (nie musi kodować, projekt ma obecnie wielu koderów, ale musi organizować prace, przeglądać przygotowany kod i analizować, czy patche niczego nie psują),

• zyskał już zaufanie społeczności projektu (zajmuje się nim już od dłuższego czasu, wykonywał użyteczne prace, dowiódł swej odpowiedzialności).

Jednym z celów stosowania tych wymagań jest zapewnienie, że zmiana nie tylko zostanie wprowadzona, ale będzie też później przez kogoś utrzymywana.

Było też trochę o złych kucykach - zmianach, które na pewno się nie wydarzą. Są nimi elementy leżące wyraźnie poza zakresem projektu (które lepiej po prostu utrzymywać niezależnie, np. jako dodane aplikacje) a także zmiany próbujące zmienić aktualną filozofię. W szczególności - wszelkie żądania replace X with Y. SQLAlchemy nie zastąpi Django ORM, Django Template nie zostanie wymienione na Jinję, itd itp.

Przy okazji tej ostatniej sprawy padło charakterystyczne We programmers don't trust designers. We hate designers. Dlatego pozostaniemy przy restrykcyjnym, minimalistycznym języku szablonów.

Nie lubię tego podejścia, zdecydowanie wolę Mako z jego swobodą pracy nad szablonem - ale to po prostu inny model pracy. Z opinią, że projekt potrzebuje jasnej filozofii, zgadzam się w całej rozciągłości.

No i jeszcze nieco złośliwy komentarz dotyczący osób narzekających na Django na forach czy blogach. People use Django, it works, there is empirical evidence. If you claim it is not usable, you are just liar.

Później Honza pokrótce omówił nowości wprowadzone w Django 1.1 i rozważane dla 1.2. Tematy bardzo szczegółowe i zainteresowanym znane, więc nie będę ich tu przepisywał.

Sesja pytań dotyczyła głównie programowania w Django jako takiego. Zanotowałem co następuje.

• Za najsłabszą część Django Honza uważa konfigurację: pojedynczy plik settings.py, brak możliwości dystrybuowania konfiguracji wraz z (reużywalnymi) aplikacjami. Inne istotne problemy to ustalanie kolejności w jakiej odbywa się setup aplikacji a także logowanie.

• Nie ma i raczej nie będzie jednego katalogu zalecanych aplikacji. A najlepszym modułem wątkowanych komentarzy jest oczywiście ten autorstwa Honzy.

• W aplikacjach nie używających bezpośrednio baz danych (np. komunikujących się via jakieś middleware) po prostu należy zrezygnować z modelu. Jego symulowanie nie ma większego sensu.

• 1.2 powinno ułatwić zarządzanie uprawnieniami (szczegółów niestety nie zanotowałem).

• Przy planowaniu architektury dużych aplikacji Honza przychyla się do koncepcji z Practical Django Projects, tj. do dzielenia kodu na sto małych aplikacji, nawet jeśli nie będą one bardzo niezależne ani reużywalne.

• Projektami Django, których kod warto poczytać w poszukiwaniu dobrych wzorów są Django Snippets (nie same snippety ale ich kod, czyli cab) oraz dzieło samego Honzy czyli Ella (z źródłami na githubie).

• Do migracji modeli Honza stosuje South. Evolution oglądał dość dawno, poważną wadą tego narzędzia jest fakt, iż jest oparte o projekt a nie o aplikację - dla reużywalnych aplikacji wymaga wielokrotnego kopiowania.

• Django działa na Jythonie ale Honza nie zna nikogo, kto by na poważnie używał takiej konfiguracji. Można próbować ale problemy z dodatkowymi modułami i aplikacjami sa bardzo prawdodobne.

Multithreading in Python

Miałem nadzieję, że będzie to ten trudniejszy wykład gościa z USA. Niestety...

Wesley Chen zreferował API modułu threading i pokazał kod kilku prostych programów wątkowych (można go pobrać stąd), omijając zresztą trudniejsze zagadnienia (np. mechanizmy synchronizacyjne jedynie wymienił z nazwy, bez omawiania). Tak wątek tworzymy, tu wpisujemy kod, tak czekamy na jego zakończenie. A nazwę wątku możemy ustawiać albo robiąc thread.setName("nazwa") (co świadczy o nadmiernej infekcji Javą) albo thread.name = "nazwa".

Z rzeczy nieco mniej znanych - moduł Queue (w pythonie3 queue) dostarcza struktur danych które mogą być równocześnie wykorzystywane z wielu wątków - zwykłej kolejki (Queue.Queue) a od wersji 2.6 także kolejki LIFO (Queue.LifoQueue) i priorytetowej (Queue.PriorityQueue). Także collections.deque można bezpiecznie używać z wielu wątków równocześnie.

Szczególnie rozczarował mnie fragment poświęcony GIL, w którym Wesley wspomniał tylko kilka oczywistości. A pamiętajmy, że dookoła GIL toczyły się ostatnio bardzo ciekawe dyskusje (patrz też wideo).

Podobnie jak pierwszy wykład Chuna, także ten był bardzo dobrze poprowadzony. Po zorientowaniu się w tematyce zacząłem traktować go jako pokaz jak dobrze poprowadzić prezentację i pod tym względem byłem w pełni usatysfakcjonowany.

Bardzo sympatycznie wypadł także początek: Wesley pokazał treść swojej prezentacji wyświetloną w ... VIMie (w formie tekstowej wielopoziomowej listy), po czym uruchomił pomocniczy skrypt, który na poczekaniu zbudował wersję graficzną (prawdopodobnie przez DCOM, bo slajdy dodawały się do otwartego PowerPointa inkrementalnie).

Ostatni slajd zawierał linki do niestandardowych modułów wspierających równoległe lub asynchroniczne przetwarzanie: Stackless, Twisted, Greenlets i Parallel Python. Tego ostatniego udało mi się dotychczas nie zauważyć, więc w końcu coś merytorycznego wyniosłem ;-)

Losowanie nagród

Kolejnym punktem programu było losowanie nagród. Prawdziwą atrakcją było 10 sztuk Python i Django z dedykacją od (współ)autora - czyli Wesleya Chuna, oprócz nich losowano cenny bryk Python Wprowadzenie (także 10 sztuk), drobniejsze Python Rozmówki i trochę gadżetów. Niczego nie wygrałem, więc następny akapit proszę potraktować jako marudzenie pechowca.

Nie podobały mi się dwie rzeczy:

• losowanie trwało bardzo długo (można było ten czas spędzić pożyteczniej, choćby - organizując jakiś techniczny panel dyskusyjny),

• część nagród wygrali organizatorzy lub zaproszeni goście (co do uczciwości losowania wątpliwości nie mam ale po prostu uważam, że beneficjentami takich akcji powinni być wyłącznie szarzy, płacący uczestnicy).

Było też trochę radości. Mina Honzy po wygraniu Python Wprowadzenie (którą to książkę zresztą z pewnym zainteresowaniem przeglądał). Zdziwienie Wesleya, który wygrał Rozmówki (które później zwrócił do puli zamieniając na czapeczkę). A przede wszystkim - sposób, w jaki Honza zdecydował komu przekazać swoją wygraną (Whose vodka was I drinking yesterday?).

Lightning Talks (4)

Łukasz Zosiak - fizyk z Krakowa, tym razem teoretyczny (niczego nie mierzę ale mam kupę danych do opracowania) - opowiadał o SciPy. Była to cała, szybko pokazana, prezentacja - ponad 20 slajdów z informacjami o zastosowaniach biblioteki, przykładowymi wykresami i fragmentami kodu. Szczegółowych notatek zrobić nie zdążyłem, dlatego odsyłam do slajdów. Łukasz zachwalał też matplotlib podtrzymując zdanie wcześniej występującego kolegi.

Łukasz Langa kontynuował dyskusję o ciemniejszych kącikach Django, mówiąc że:

• getprofile ma istotny problem wydajnościowy a cacheowanie niewiele tu pomaga bo cache jest wiązany z instancją obiektu, a nie klasy,

• przed kaskadowym kasowaniem nie można się zabezpieczyć nadpisując metodę delete mapowanego obiektu, bo nie zadziała to dla wywołania delete na querysecie (a taki scenariusz ma miejsce min. przy zaznaczeniu wielu elementów i kasowaniu ich grupowo),

• delete najlepiej robić przez oznaczanie jakimś polem że dany obiekt jest usunięty, uzupełniając to nadpisaniem metody objects. Interfejs administracyjny używa admin_objects, tą funkcję także można nadpisać albo ... pozostawić, by skasowane obiekty były widoczne i mogły być łatwo przywracane,

• Django uważa, że istnieje wyłącznie unicode, a nie string; jeśli użyjemy stałych bez u'' możemy napotkać na nieoczekiwane problemy, zwłaszcza jeśli używamy ugettext,

• przy tłumaczeniu komunikatów bardzo trudno poprawnie traktować słowa typu name,

• domyślne filtry miewają rozmaite kwiatki, np. pracuję w FBI | title generuje Pracuję W Fbi.

Maciej Dziergwa pochwalił się kiedynaurlop - prostą usługą stworzoną gdy pokazano nam jako przykład "kiedywielkanoc", która przeżyła swoją chwilę dużego zainteresowania po trafieniu na główną stronę wykopu. Ale nie, takiej aplikacji nie da się zmonetyzować.

Jeden z kolegów (niestety pamiętam tylko, że pochodził z Rzeszowa) polemizował z wyrażoną dzień wcześniej na panelu dyskusyjnym opinią, że Python nie nadaje się na pierwszy poznawany język programowania.

Ja próbowałem w kilku zdaniach opowiedzieć ten artykuł, czyli przekonywać, że w typowym zespole kluczową różnicą między trzema generacjami narzędzi zarządzania wersjami jest podejście do konfliktów i relacja merge do commita.

Demoscena

Pogodę uznano za niesprzyjającą grillowaniu (ech, a już snułem wizje ognisk płonących na śniegu), grzańca w plastykowych kubeczkach podano do kolacji a sobotni późny wieczór wypełniła Demoscena. Czyli pokaz informatycznych dzieł sztuki - bo tak w sumie trzeba traktować te trójwymiarowe animacje wzbogacane elektroniczną muzyką.

Nazwa Demoscena wywodzi się od pojęcia demo gry, czyli wprowadzającego do gry filmiku. Z tychże zastosowań wywodzi się kultura minimalizowania rozmiaru programu.

Prowadzący pokazywali filmiki ale też opowiadali o sięgającej wczesnych wersji Amigi historii ruchu (zapadła mi w pamięć sprawa komunikacji - były to czasy przedinternetowe, materiały i informacje wysyłało się do znajomych na dyskietkach zwykłą pocztą, poważny problem stanowiło finansowanie znaczków które potrafiono odsyłać i używać wielokrotnie), organizowanych konkursach, wreszcie - procesie tworzenia tych dzieł.

Filmików nie będę opisywał - przykłady można znaleźć na scene.pl i scene.org, najbardziej efektowne prezentowane dzieła pochodziły od grupy Andromeda - wspomnę tylko o liczącym 4108 bajtów (mniej niż 4 kilobajty) programie prezentującym wyrastające miasto i uganiające się po nim kształty, wszystko to do wtóru nietrywialnej muzyki.

Zaciekawił mnie proces powstawania tych aplikacji. Uczestnicy zbierają się na 2-3 tygodnie w jednym miejscu. Muzyk tworzy warstwę dźwiękową (bez użycia studia - za to stosując programy wspomagające kreowanie muzyki elektronicznej) i miksuje ją. Graficy przygotowują tekstury i materiały. Na koniec w projekt włączają się programiści (OpenGL albo Direct/X), kodując właściwy przebieg sceny, w co wchodzą zarówno złożone obliczenia matematyczne i fizyczne, jak rozmaite sztuczki. Sposoby uzyskiwania poszczególnych efektów (w tym kod) zwykle nie są upubliczniane (to jest konkurs) choć kod starych scen jest już dostępny.

Ciąg dalszy

... nastąpił.