Przypomniałem sobie dzisiaj o polskim Pyconie i próbowałem znaleźć jakieś relacje i materiały (sam niestety w Ustroniu nie byłem, wybrałem w tym roku Front-Trends).

Zbyt wiele informacji niestety nie ma ale tym bardziej zdecydowałem się zanotować te znalezione.

Kawałek napisanego pythonowego kodu nieraz warto zamknąć jako bibliotekę i opublikować. W realizowanych czynnościach nie ma niczego trudnego ale ... wystarczy nie robić tego 2-3 miesiące, by nie pamiętać wszystkich kroków. Stąd ta notka.

Opisuję scenariusz, w którym publikuję i utrzymuję kod, który będzie można instalować przez easy_install (albo pip) i którego źródła będą dostępne dla wszystkich zainteresowanych.

Kawałek znalezionego gdzieś w sieci kodu, rzucającego przyjemny pomost między najstarszym z autentycznie lubianych przeze mnie języków programowania a tym, po który najchętniej sięgam dzisiaj.

Dla osób przesiadających się z C++ czy Javy to jedna z bardziej szokujących właściwości Pythona (a także Perla i paru innych języków skryptowych): kod programu można zmienić w locie. Można - w szczególności - dopisać albo podmienić metody istniejącej klasy czy funkcje zadanego modułu.

Technika ryzykowna, łatwo prowadząca do powstawania niezrozumiałego kodu i trudnych do interpretacji błędów. Ale zarazem bardzo przydatna, zwłaszcza gdy trzeba zmodyfikować zachowanie jakiejś biblioteki w miejscu, którego jej autor nie przewidział (np. ostatnio przypomniałem ją sobie chcąc zmienić sposób w jaki Mercurial obsługuje hasła HTTP i SMTP). Monkey-patching bardzo często przydaje się też przy testach, pozwalając zamienić prawdziwy kod komunikacyjny czy bazodanowy zaślepkami.

W tym artykule o kilku możliwych sposobach zapisywania tej operacji.

Wirtualne środowiska Pythona bez problemu można wykorzystywać także przy pracy z Jythonem (a także do przełączania się między Pythonem a Jythonem). Nie wymaga to żadnych szczególnych działań, wszystko przebiega niemal identycznie jak pod Pythonem.

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.

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

Kontynuacja rozpoczętej wczorajszym wpisem relacji z polskiego Pycona. Tym razem o chyba najlepszym fragmencie konferencji czyli o sobotnim popołudniu.

Wybrałem się na tegoroczny polski Pycon do Ustronia. Oficjalną relację zamieszczą zapewne organizatorzy, poniżej trochę moich - bardzo subiektywnych - notatek.

Istotna uwaga: bardzo dawno nie byłem na żadnej branżowej konferencji, oceniam Pycona zestawiając go z własnymi oczekiwaniami.

Najpopularniejszym narzędziem do uruchamiania testów obciążeniowych jest JMeter. Nie potrafię się do niego przekonać - organicznie nie cierpię modelowania struktury kodu (tu - testów) w formie rozwijanego drzewa, gdzie zrozumienie co robią poszczególne elementy wymaga przeklikiwania się przez nie, a niekiedy nawet otwierania okienek właściwości. Prosty kod jest zdecydowanie czytelniejszy. Podobnie, wolę napisać wywołanie funkcji niż przeszukiwać wielopoziomowe prawoklikane menu.

Dlatego opisuję interesującą, lekką alternatywę, ciekawie łączącą testy wydajnościowe z jednostkowymi.