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.
... zmierza powoli ku szczęśliwemu zakończeniu.
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ł:
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.
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.
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++,
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:
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.
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.
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.
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
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:
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.
W komentarzach można używać znaczników Markdown. Na przykład:
[tekst linka](http://linko.wana.stro/na.html)
Jakiś *wyróżniony tekst*
> Cytat z artykułu lub
> innego komentarza
Lista:
- kilku
- elementów
Przykład kodu (4 spacje wcięcia):
int i = 7;
int j = 8;
Subskrybuj
RSS
Email
Chciałbym sprostować to co napisałeś o virtualenv i buildout. Buildout nie jest alternatywą dla virtualenv. Buildout automatyzuje tylko instalacje pakietów. Domyślnie korzysta z systemowego interpretera pythona i w momencie instalacji najpierw szuka eggów w systemowym site-packages i jeżeli tam znajdzie dany pakiet to korzysta z tego pakietu a nie pobiera go do katalogu gdzie odpalony był buildout. Wiec jeżeli raz się użyje pakietu w wersji X a będzie on już w systemie to ten pakiet będzie użyty, a jeżeli do kolejnego projektu użyje się tego samego pakietu ale w wersji Y to buildout pokaże komunikat o konflikcie zależności.
Virtualenv powoduje natomiast że instalowane pakiety instalowane są w odrębnym środowisku z odrębnym interpreterem. Jednak nie automatyzuje instalacji pakietów, wszystko trzeba instalować ręcznie.
Dlatego właśnie połączenie virtualenv i buildout. Spowoduje to że wszystkie instalowane eggi będą instalowane z wykorzystaniem lokalnego interpretera pythona a nie przez systemowy interpreter. Dzięki temu wszystkie eggi będą instalowane przez buildouta, nie będą wykorzystywane eggi które już są zainstalowane w systemie.
Postaram się porządniej odnieść do tego w przyszłości ale w skrócie: przy dopieszczeniu buildouta virtualenv nie powinien być już potrzebny bo buildout sam sobie poradzi. No i brzytwa Ockhama ;-)
Dalszą polemikę proponuję trochę odłożyć, jeśli czas pozwoli, spróbuję opisać problem szczegółowo.
Cała relacja ciekawa, fajnie się czyta :) Mam tylko pytanie: co nieintuicyjnego jest w tych przykladach pythona? Pytam, bo się zdziwiłem, że to co według mnie powinno się pojawić na STDOUT, się pojawiło... i nie wiem o co chodzi ;)
W drugim przykładzie wiele osób oczekuje tylko for i jest zaskoczonych pojawieniem się else
No i właśnie taką semantykę for/else można znaleźć w różnych systemach templejtkowych a chyba też w paru językach programowania. Na szybko wspomnę perlowe For::Else oraz FOREACH/ELSE z Template::Toolkit.
Literowka "Gay Steele" -> Guy Steele
lol
PS Poprawiłem.
Cieszę się, że się podobało. Nie byłem w najlepszej dyspozycji po drinking session z kolegami z QXL. ;)
"Niestety - dostaliśmy tylko ogólną informację o celach buildout i przykład prostego skryptu budującego aplikację Django. [...] autor niezbyt przekonująco wypadł też w sesji pytań".
Cóż... ja się czegoś nowego dowiedziałem. Poznałem wady i zalety rozwiązania, a dalej będę drążyć sam.
Bardzo mocno subiektywny (jak sam autora zaznaczył) jest ten blog. Z jednej strony promuje konkrety a z drugiej coś, co można było przedstawić w 5 minutach bez opowiadania o odsysaniu a później unikania odpowiedzi na pytania. Ogólna zasada pisania recenzji na tym blogu jest prosta: "To co było dla mnie nowe, było ok. Wszystko schodzące poniżej mojej wiedzy, było zbyteczne".
Z innej beczki, chciałbym zaznaczyć, że zadawanie prelegentowi pytań poniżej pasa i podważanie jego wiedzy w trakcie prelekcji nie jest na miejscu. Kilka osób zachowało się bardzo nietaktownie. To że wiedzą więcej, nie daje im prawa do (wręcz) ataków.
Kończąc mój komentarz chciałbym jedno zaznaczyć. Autor bloga ma pełne prawo do wyrażania przy jego pomocy własnego zdania, ale mam nadzieję że nie stanie się on opiniotwórczym.
Ech, odwieczny dylemat. Jeśli piszesz cukierkowo, to opinia nie jest nic warta, jeśli do czegoś odniesiesz się krytycznie, to zawsze kogoś urazisz.
Tak, mój blog jest subiektywny (ja zresztą w ogóle nie wierzę w obiektywne relacje). Tak, ta relacja jest subiektywna. Napisałem co mi się podobało a co nie. Prawdę mówiąc jestem trochę zawiedziony niewielką ilością innych notatek z pycona, sam jestem ciekawy jak odbierały go osoby o innych niż moje doświadczeniach i oczekiwaniach - a niestety mało jakichkolwiek notek, mało...
Co do pytań - domyślam się, do której sytuacji pijesz i też uważam, że delikatności faktycznie tam zabrakło, choć nie byłbym tak jednoznaczny w ocenie motywów. Z drugiej strony, prelegent ma pełne prawo powiedzieć w tej chwili na to pytanie nie odpowiem, wolałbym o tym porozmawiać w kuluarach czy wręcz nie wiem i jest to lepsza metoda zamknięcia kłopotliwego pytania niż wikłanie się w dyskusję na grząskim gruncie. A trudne pytania warto zadawać, bo a) czasem prelegent na nie odpowie b) czasem ciekawie odpowie na nie ktoś z sali (przypomnę choćby udział Honzy w sesji pytań po intro do pinaksa) c) czasem wreszcie ktoś podrzuci coś ciekawego post factum w kuluarach (miałem dwie pogawędki nawiązujące do pytań jakie zadawałem).
Zdania o ogólnej zasadzie pisania recenzji nie będę komentował.