Pycon 2009 - relacji część druga

Subiektywna kronika wydarzeń - ciąg dalszy

Python w komputerowych systemach pomiarowych

Wykład prowadzony przez Pawła Nitę - doświadczalnego fizyka z UMCS, opowiadającego o wykorzystywaniu Pythona w laboratorium badawczym.

Była to dla mnie opowieść niesłychanie egzotyczna (system pomiarowy kontrolujący proces epitaksji z wiązek molekuralnych w komorze MBE) ale przez samo to bardzo zajmująca. Czujniki ciśnień, wagi kwarcowe, termometry, silniki krokowe - wszystko to połączone rozmaitymi interfejsami (USB, RS-232, LPT) z komputerem, wykorzystywanym do zbierania danych, generowania raportów a także sterowania zachowaniem wybranych urządzeń.

Autor prezentacji, wraz z kolegami, pokusił się o samodzielne napisanie w Pythonie narzędzi do tego celu - zamiast wykorzystywać drogie komercyjne programy takie jak TestPoint albo LabView.
Uzyskał imponującą funkcjonalność, choć zarazem ... skarżył się na częste problemy techniczne (głównie związane z koniecznością równoległej komunikacji z wieloma różnymi urządzeniami działającymi na różnych interfejsach - min. częste timeouty).

Najważniejsze wykorzystywane elementy:

• Python(x,y) - specjalizowana dystrybucja Pythona przeznaczona do zastosowań naukowych i inżynieryjnych, obejmująca samego Pythona, Eclipse, QT i całą masę pythonowych bibliotek wspomagających pracę matematyka lub fizyka,

• PyVISA - właściwa obsługa komunikacji z urządzeniami pomiarowymi, czyli standardowego dla nich protokołu VISA (Visual Instrument Software Architecture - nie, nie chodzi o karty płatnicze),

• SCPI - język poleceń umożliwiający sterowanie urządzeniami pomiarowymi,

• matplotlib - znakomita biblioteka do robienia wykresów,

• NumPy i SciPy - obsługa obliczeń.

W trakcie dyskusji po wykładzie pytałem o wskazówki dotyczące tworzenia dobrych wykresów. Autor zachwalał matplotliba jako techniczne narzędzie ale wskazówek metodycznych udzielać się nie podjął (stosowane przezeń wykresy i diagramy są po prostu standardem de facto w jego dziedzinie). Za to pojawił się głos z sali - zachwalający książkę The Visual Display of Quantitative Information autorstwa Edwarda Tufte jako znakomity zbiór wskazówek dotyczących wizualizacji danych.

Lightning Talks (3)

Radomir Dopieralski pochwalił się Hatta Wiki - stworzonym przez siebie engine wiki zachowującym zmiany w repozytorium Mercuriala.

Piotr Kasprzyk miał ciekawą i sprawnie pokazaną mikroprezentację (opartą o fragmenty prezentacji Gregora Lingla) dotyczącą biblioteki xturtle. Sporo imponujących grafik generowanych niewielkimi skrawkami kodu - z których na mnie największe wrażenie zrobił obrazek przygotowany (oprogramowany) przez jedenastoletnią dziewczynkę.

Norbert Wójtowicz wykorzystał dostępność prądu i pokazał jak wygląda BizCarder. A następnie zdążył jeszcze pochwalić Simple Quickcheck - generator testów oraz coverage - narzędzie do mierzenia stopnia pokrycia kodu testami.

Python i Orange

Nazywam się Marcin Mierzejewski i zajmuję się przewidywaniem przyszłości. Dobry start bardzo dobrej prezentacji poświęconej złożonej analizie (eksploracji) danych z wykorzystaniem Orange.

Marcin zdążył zmieścić w swoim wystąpieniu zarówno trochę teorii (rodzaje zastosowań, klasy algorytmów, etapy przetwarzania danych), jak demonstrację interfejsu Orange i dyskusję o sposobie jego używania. Udostępnił swoją prezentację, dlatego ją po prostu wkleję. Mówione było więcej, niż widać na slajdach, ale i same slajdy są warte przejrzenia.

Parę uwag wynotowanych przeze mnie w czasie pytań po prezentacji:

• przy praktycznym stosowaniu modele trzeba stale, nawet codziennie, przebudowywać - warunki się zmieniają (także sami je zmieniamy stosując wcześniej uzyskane wyniki),

• trzeba mieć solidne know-how z dziedziny problemu i krytycznie podchodzić do tego co się wyliczyło (piękny przykład: sieć neuronowa do rozpoznawania obiektów militarnych nauczyła się że gdy jest ładna pogoda - są czołgi a gdy brzydka - nie ma ich), nieraz robi się i testuje tysiące modeli,

• trzeba też pamiętać o ograniczeniach budowanych modeli (tu sztandarowym przykładem jest sprawa wyceny złożonych produktów finansowych - link mój),

• jedna z metod testowania modeli to wykorzystanie 90% danych do budowy modelu a pozostałych 10% do jego testowania - w Orange służy do tego Confusion Matrix,

• generacja modeli odbywa się w przypadku Orange w pamięci, akcentuje się raczej wybór i przetwarzanie mniejszej puli reprezentatywnych danych niż przerzucanie ogromnych ilości, do bardzo dużych zbiorów pisze się raczej wsadowe programy w C/C++,

• zbudowanych przez Orange modeli (np. drzew decyzyjnych) można używać w czasie rzeczywistym, sama budowa modeli trybu inkrementalnego nie ma (a czas nauki zależy od ilości danych i algorytmu, może trwać ułamki sekund, może i wiele godzin),

• w Polsce nie ma rynku na zaawansowane analizy danych, firmy interesują się tylko prostymi CRM-ami oraz stawiają na marketingowe badania grup klientów,

• inne interesujące oprogramowanie do eksploracji danych to Weka (Java),

• ciekawy projekt politechniki poznańskiej: Carrot2 (wyszukiwarka z inteligentnym grupowaniem danych w tematy).

Dalsze lektury polecane przez Marcina:

• EksploracjaDanych.com
• Czytelnia StatSoft
• KDNuggets

O niektórych z używanych w Orange algorytmów analizy danych można także poczytać w książce Tobiego Segarana.

Zope Component Architecture

Michał Węgrzynek miał fajny pomysł na prezentację - starał się pokazać, że wzorce projektowe z projektu Zope można stosować w oderwaniu od aplikacji webowych a interfejsy, adaptery, rejestry komponentów mogą służyć do organizowania nie związanych z Zope projektów pythonowych. Przy tym prezentowane definicje i metody podpierał przykładami własnego kodu (wyciętego z realnego projektu).

Temat bardzo duży i z konieczności omówiony dość pospiesznie, po autorze troszkę było widać brak wprawy w prowadzeniu prezentacji (slajdy z kodem nieco wolniej zmieniać proszę a kluczowe tezy warto by mocniej uwypuklić i parę razy do nich wrócić) ale całość interesująca i bliska temu, co chciałbym widywać na takich konferencjach - nietrywialny temat, kompetentny autor, realne przykłady kodu.

Szczegółów zdecydowałem się tu nie opisywać, bo musiałbym przepisać całą prezentację.

Do poczytania:

• A Comprehensive Guide to Zope Component Architecture - szczegółowy opis ZCA, czyli cała niezbędna teoria,
• zca_demo.zip - kod źródłowy przygotowany i udostępniony przez Michała.

Parę notek z sesji pytań:

• ZCA jest istotne przede wszystkim gdy piszemy frameworki, to nie jest narzędzie do robienia prostej aplikacji (uwaga Maćka Dziergwy),

• nie ma żadnego powiązania między mechanizmem entry-pointów a ZCA, techniki programowania wypracowane w Zope są niestety mało znane reszcie świata pythonowego, to jeden z przykładów,

• nie ma żadnej biblioteki dobrze znanych interfejsów, ich hierarchie definiują konkretne frameworki lub aplikacje,

• z ZCA korzystają min. Zope3, Grok oraz repoze.bfg,

• repoze.bfg jest warte poznania, jest to interesujący nowy framework mieszający komponenty Zope z innymi (min. stosujący WebOb a nie Zope do obsługi HTTP) i pozwalający na elastyczny dobór komponentów,

• Zope3 raczej się nie rozwinie dopóki nie przejdzie na nie Plone, a Plone ciągle używa zope2 (oraz Five - portu wielu technologii wypracowanych dla Zope3 na Zope2),

• Zope Toolkit to po prostu spakowany zbiór zgodnych ze sobą bibliotek wywodzących się z projektu Zope w wersjach gwarantujących zgodność i poprawną współpracę.

Filmaster

Adam Zieliński opowiadał o projekcie Filmaster - zbudowanym przez niego do spółki z Borysem Musielakiem serwisie dla miłośników kina, którego wyróżnikiem są spersonalizowane rekomendacje (Filmaster zna wasz gust) oraz akcent na ambitne, niekoniecznie najnowsze, filmy.

Bardzo fajna prezentacja, w której autor z zapałem opowiadał o swoim projekcie, dzieląc się rozmaitymi doświadczeniami. Poniżej trochę wynotowanych przeze mnie ciekawostek - w kolejności nie do końca zgodnej z przebiegiem prezentacji i bez rozdzielania na wykład i pytania (jedno płynne przechodziło w drugie).

Żartobliwy model biznesowy: 1. Otwieramy kod. 2. ??? 3.Profit ewoluuje w stronę współpracy z kinami, zwłaszcza tymi bardziej ambitnymi (bez popcornu). Filmaster ma już takie kontakty w kilku większych miastach, reklamuje ciekawe seanse, za to kina promują serwis, z czasem być może przybierze to formy dające dochód. Na dzisiaj zarabiają reklamy (Adtaily), zapewniając pokrycie kosztów hostingu (50 euro/mies) i minimalną premię. Nie nastawiali się na zarobek, projekt powstał z braku (Borys nie miał gdzie pogadać o dobrym kinie).

Technicznie Filmaster wykorzystuje Pythona, Django, PostgreSQL i Apache. Jako framework autorzy rozważali PHP, Ruby on Rails, Django i Pylons. PHP odrzucili, bo już je znali, a chcieli poznać coś nowego. Ruby on Rails odpadło gdy po przerobieniu tutoriali nie potrafili zrozumieć, czemu powstały kod działa i gdzie ma początek a gdzie koniec. Django uznali za najbardziej dynamicznie rozwijający się framework pythonowy, ponadto przez pewien czas rozważali stosowanie App Engine. A PostgreSQL polecił Borysowi depesz ze względu na pozytywne doświadczenie na gronie.

Pozytywy Django:

• prostota i respektowanie DRY (np. 404 rzucane po nie znalezieniu rekordu w bazie danych albo dekorator @login_required),

• dużo dobrych aplikacji zewnętrznych z których intensywnie korzystali (tagowanie, wątkowane komentarze, profile, ... - zbierane z Pinaksa, djangosnippets i innych źródeł), oceniają że pozwoliło im to oszczędzić co najmniej 3 miesiące.

Problemy z Django:

• brak obsługi subdomen (np. adz.filmaster.pl) - co obchodzą dedykowanym middleware, które sprawdza obsługiwany URL i wybiera na tej podstawie widok (nieelegancki kod który planują zastąpić modyfikacją urlconf w obiekcie żądania),

• brak wsparcia dla lokalizacji treści (wielu wersji językowych contentu) - aktualnie aby utrzymywać polski i angielski serwis mają dwie osobne instalacje aplikacji używające tej samej bazy danych (a odpowiednie tabele zawierają pole z informacją o języku),

• brak obsługi przez ORM własnych joinów (tj. innej niż domyślna metody łączenia tabel w złożonych zapytaniach) - tu udało im się znaleźć łatkę.

Kod serwisu jest otwarty. Adam trochę się tego obawiał (jutro ktoś będzie go oferował na Allegro) ale konsekwencje okazały się bardzo pozytywne. Zewnętrzni developerzy dodali lub usprawnili:

• wyszukiwarkę,
• import ocen z innych serwisów (Marcin Mościcki),
• integrację z facebookiem (Piotr Maliński),
• importer opisów z wikipedii (Hello, I am Osama Khalid from Saudi Arabia, could I help... i wartościowy kod po kilku dniach),
• nowe wersje językowe (francuską, hiszpańską, norweską, duńską).

Także migrację z Subversion na Mercuriala przeprowadził chętny z zewnątrz (Przemysław Muller).

Oczywiście były też przy tej współpracy problemy - trochę osób zadeklarowało pomoc ale nie zrealizowało przyjętych zadań. W ocenie Adama kluczową funkcjonalność powinien jednak rozwijać główny zespół, za to zgłaszający się pomocnicy bardzo dobrze dorabiają różne rzeczy z boku.

Inna obawa związana z open-source - możliwość wyszukiwania luk bezpieczeństwa - też się nie potwiedziła. Był jeden przypadek, gdy ktoś znalazł usterkę i od razu zgłosił ją autorom.

Jak dotychczas nie wiedzą o żadnym wykorzystaniu kodu przez inny serwis, a przynajmniej nikt się tym nie chwalił. Mieli wstępną ofertę z Indii dotyczącą spersonalizowania serwisu na potrzeby tamtego rynku (oceny aktorów Bollywood) ale rzecz się rozmyła.

Statystyki: 8 programistów, 3800 użytkowników, 9000 recenzji, 100.000 linii kodu, 350.000 ocen (na anglojęzyczną wersję .com przypada około 1/5 z tego). Projekt zaczął się w marcu 2008, do września 2008 był rozwijany niespiesznie, głównie koncepcyjnie, od września pracowali mocno, 15 stycznia 2009 uruchomili publiczną betę. Podstawową pracę wykonali we dwójkę (nie licząc graficzki i znajomego, który pociął efekty jej pracy do HTML), spędzony czas byłby równoważny około 3 miesiącom pracy od rana do nocy.

Promocja: żadna reklama nie okazała się tak skuteczna, jak dyskusje na blipie i flakerze. Obecnie chwalą sobie także plakaty i ulotki w kinach (w których dystrybucji pomagają użytkownicy serwisu).

Analizy dotychczas zebranych danych potrafi dostarczyć zaskakujących wyników - np. w Polsce jest wielu miłośników kina czeskiego z lat 60-ych i 70-ych.

Ciąg dalszy nastąpi(ł)

... w odcinku trzecim.