Pycon 2009 - relacji część czwarta i ostatnia

Ostatnia część relacji z polskiego Pycona (pierwsza jest tutaj, druga tutaj a trzecia tutaj). Słowo się rzekło, kobyłka u płotu, rozpoczęte dzieło trzeba zakończyć a Pycon z to-do, blogerowi lżej.

Do omówienia zostały wykłady niedzielne, opisuję też co uważam za najważniejsze własne wnioski z konferencji.

Subiektywna kronika wydarzeń

... zmierza powoli ku szczęśliwemu zakończeniu.

Adam Słodowy a WSGI

Django jest złe, bo służy do robienia CMS, więc musi obsysać. Pylonsy obsysają. TurboGears2 obsysa na maksa, bo jest oparte na Pylonsach. TurboGears1 obsysa generycznie. WebPy, Web2Py, Web3Py, Web4Py obsysają po prostu. Tornado obsysa, bo nie jest na Twisted. Twisted obsysa, bo wymaga ponad godziny nauki. No - jedyna alternatywa to napisać coś samemu.

Jarosław Zgoda przeprowadził prezentację, która być może obrośnie legendą, a na pewno znacząco wpłynie na popularyzację dźwięcznego czasownika obsysa. Spora sztuka - utrzymując się w konwencji żartu przekonująco mówił o rzeczach istotnych.

Właściwa treść była dwojaka. Z jednej strony autor przekonywał, że mimo złudnej prostoty specyfikacji WSGI, pisanie frameworków ramówek webowych jest trudne. I jest to trudność, której nie da się ominąć, mająca swoje korzenie w stanie protokołu HTTP jako takiego i modelu działania aplikacji. Z drugiej - pokazał swój kod, w którym wykorzystując kilka dostępnych komponentów (Werkzeug, Beaker, Jinja2, WTForms, MongoDB) zbudował własny stosik i oparł na nim działającą aplikację (kończąc zresztą stwierdzeniem, że była to czysta strata czasu). A na boku podrzucił nazwy wielu istotnych bibliotek.

Są dostępne slajdy i kod prezentacji. Slajdy:

a kod można pobrać tutaj.

Ciekawy wykład, bo dobrze trafiający w obecną sytuację - wśród pythonowych narzędzi do budowy aplikacji webowych kipi jak w garnku, wszystkie (może poza Django i częściowo Plone) przeżywają gwałtowne zmiany, coraz to pojawia się coś nowego, obierając dowolny ustabilizowany pakiet narzędzi za moment czyta się, iż są przestarzałe. No i pokusa, by samodzielnie gonić króliczka, jest bardzo mocna.

Aha: lista blogów, do których czytania Jarek zachęcał:

• Armin Ronacher (Werkzeug, Jinja, Zine, ...)
• Graham Dumpleton (mod_wsgi, specyfikacja WSGI)
• Ian Bicking (Paste, WebOb, ...).

Sesja pytań była z konieczności króciutka, objęła kilka objaśnień do prezentowanego kodu, ponadto Jarek przyznał, że profesjonalnie wykorzystuje głównie Django.

Zastosowanie buildout do projektów Django

Prezentacja Dominika Szopy.

Niestety - dostaliśmy tylko ogólną informację o celach buildout i przykład prostego skryptu budującego aplikację Django. Wątpliwości budził pomysł użycia virtualenv (który jest pod wieloma względami rozwiązaniem alternatywnym dla buildouta, choć reprezentującym inną filozofię), autor niezbyt przekonująco wypadł też w sesji pytań (które chyba wykraczały poza jego własne doświadczenia). Ogólnie - sytuacja trochę podobna do piątkowej opowieści o Django i Pinaksie: elementarno-popularyzatorska prezentacja zderzona z istotnie większymi oczekiwaniami uczestników konferencji.

W ramach sesji pytań zgłaszano trochę problemów z domyślnymi receptami (min. usztywnianie ścieżek i kłopoty z zarządzaniem plikami konfiguracyjnymi), nie zanotowałem tu żadnych konstruktywnych wniosków.

Sam postawiłem pytanie o stosowane formy dystrybucji aplikacji do klientów czy też na maszyny produkcyjne - pliki .egg nie zawsze się do tego nadają. Padły dwa interesujące głosy z sali:

• administrator z MegiTeam rekomendował Puppet (do systematycznego zarządzania złożonymi instalacjami) oraz Func (do jednorazowych operacji administracyjnych przeprowadzanych na wielu maszynach równocześnie),

• kolega z SensiSoft opisał proces stosowany w jego firmie: budują standardowe pakiety linuksowe (.deb) (używając samodzielnie przygotowanych skryptów) - i w tej formie dystrybuują i instalują aplikacje na docelowych systemach.

Zastosowanie Python-Ogre do tworzenia gier

Ciekawa prezentacja dotycząca tworzenia gier, a dokładniej - ich graficznego interfejsu.

Marek Gajda nie krył, że opowiada o zabawie czysto hobbistycznej (profesjonalne gry powstają inaczej, wykorzystywane są biblioteki bezpośrednio sprzęgane z układami kart graficznych, jest to trudne i kosztowne), niemniej jednak prezentowane narzędzia były interesujące i efektowne. Pisząc kilka wierszy kodu autor uzyskał trójwymiarową scenę z symulacją poruszania się głównego bohatera w świecie gry, przy pomocy około setki wprowadził bardziej złożoną scenerię oraz wędrujące roboty reagujące na kliknięcia.

A przed demonstracją było trochę informacji wprowadzających.

Programista Pythona ma do dyspozycji następujące silniki do tworzenia interfejsu gier:

• PyGame - składanie prostych obrazków (zastosowania: platformówki, pacman, arkanoid),

• Panda3D - silnik od Disneya (sama implementacja w C, sterowanie Pythonem), darmowy ale nie open-source, używany przez producenta do pisania gier promujących filmy,

• Soya3D - nie udało mi się tego użyć (a demo bardzo trąci myszką),

• Python-Ogre (dawniej PyOgre) - główny temat prezentacji, interesująca biblioteka o rozbudowanej funkcjonalności (pythonowy wrapper dookoła Ogre), zmiana nazwy wiąże się z zmianą metody komunikacji z kodem C++,

• Blender

W komercyjnych zastosowaniach oprócz Disneya Pythona stosuje także SiGames (autorzy min. civilization) - używając go do sterowania przebiegiem gry. Właściwa biblioteka obsługująca grafikę jest napisana w C++.

Zaletami Python-Ogre są przenośność - obsługiwane są Windows, Mac OS/X oraz Linux, może być stosowany i Direct/X i OpenGL, dobra dokumentacja oraz możliwość stosowania różnych języków programowania (można bezpośrednio kodować w C++, są interfejsy do Javy - ogre4j oraz do .net - mogre).

Przenośność przenośnością, niemniej jednak Marek pokazał benchmarki w myśl których wersje Windows z Direct/X działały kilkukrotnie wydajniej niż Linuksowe z OpenGL. Trzeba je traktować z odrobiną dystansu (używał archaicznego Ubuntu 6.04) ale na pewno - brać pod uwagę.

Typowy cykl pracy nad grą obejmuje:

• przygotowanie modeli w Blenderze,
• implementację logiki gry przy pomocy Python-Ogre,
• dystrybucję przy pomocy py2exe.

Autor mocno akcentował przyjmowanie przez Python-Ogre dobrych wartości domyślnych. Podczas gdy zainicjowanie Direct/X wymaga lektury kilku rozdziałów tutoriala i rozbudowanego kodu, dla Python-Ogre wystarczy:

import ogre.renderer.OGRE.sf_OIS as sf
app = sf.Application()
app.go()

(skrót sf oznacza sample application). Podobnie, dla złożonego przykładu kod Pythonowy okazał się o połowę krótszy od równoważnego kodu w C++ (używającego Ogre).

Ciekawostka: do wykrywania trafienia robota Marek zastosował raytracing.

Lighning Talks (5)

Maciej Konieczny pokazał, że Python nie zawsze jest intuicyjny. Zrobił to pytając co zrobi następujący kod:

for i in []:
    print "for"
else:
    print "else"

a następnie co zostanie wypisane przez:

for i in [1]:
    print "for"
else:
    print "else"

Aby nie psuć zabawy, odpowiedzi na razie nie podam. Zachęcam do próby zgadnięcia przed przetestowaniem.

Pożegnanie

Organizatorzy wstępnie zapowiedzieli przyszłoroczny PyCon na 8-10 października 2010. Poszukiwali też chętnych do prowadzenia prezentacji na konferencji ... użytkowników PHP.

Zebraliśmy rzeczy, pożegnaliśmy się i rozjechaliśmy do domów.

Zanotowane w kuluarach

Treści rozmów kuluarowych spisywać oczywiście nie będę ale podzielę się dwoma konkretami. Oba dotyczą sprawy, która mnie ostatnio interesowała.

Pierwszy to - podobno (jeszcze nie obejrzałem) - przykład bardzo dobrej prezentacji. Guy Steele Jr - Growing the Language:

Drugi to wartościowa książka o prezentacji danych: Alan Fletcher - The Art of Looking Sideways.

Zabieram dla siebie

Konferencja jako taka dała mi trochę świeżej motywacji (będę pisał testy, I swear; mam się czego uczyć, ...), pozwoliła poznać parę wartościowych osób i zacząć rozpoznawać parę dalszych, być może zdobyć paru nowych subskrybentów bloga.

Z różnorakich wątków technicznych do listy zadań wrzucam:

• poznać, przynajmniej wstępnie, Orange,
• obejrzeć repoze.bfg i rozważyć przetestowanie go na jakimś małym projekcie,
• przypomnieć sobie ZCA i brać te idiomy pod uwagę przy tworzeniu złożonego kodu,
• poczytać kod elli, djangosnippets i filmastera, przyprawić to Pinaksem i spróbować wyrobić sobie na tej podstawie pogląd jak wygląda dobrze napisana aplikacja Django.

Na listę książek do ewentualnego kupienia trafiają obie książki o wizualizacji.

Zachowuję w pamięci oba warianty programowania w parach, może kiedyś trafi się szansa wypróbowania któregoś zawodowo.

A pozatechnicznie - aktywuję wreszcie konto na Filmasterze. Co prawda czasu na kino ostatnio nie miewam ale chociaż porobię sobie trochę apetytu.