Continous integration i Python?

Czy ktoś widział może kiedyś budowanie projektu pisanego w Pythonie?

Może nie jestem czegoś świadom, albo myślę zbyt szablonowo ale: continous-integration jest dobrze zdefiniowane dla projektów, które trzeba kompilować. Wiadomo. Developer nie kompiluje kodu sam. System CI sam sprawdza za niego czy kod pozytywnie przechodzi etap kompilacji i wysyła powiadomienia.

Ale jak odnieść się do tego w świetle Pythona. No dobra, wyciągamy kod źródłowy z repozytorium - i co? Przecież go nie skompiluję. Wszystko, na stać moją wyobraźnię na dzień dzisiejszy, to hmm... scan pylint, pychecker, pep8, odpalanie metody .compile() na każdym module? Jeżeli już zdecydujemy się na skany: to jak zachować się w przypadku jakiś komunikatów. Kod nie musi być źle napisany, zresztą zakładamy, że przeszedł review, ale wtedy co? Sfailować build tylko dlatego, że kod Pythona programisty nie odpowiada pylint. To niczego nie udowadnia.

Piszę ten post w związku z sytuacją jaka miała miejsce kilka dni temu. Rozumiem, żeby w trakcie budowania projektu Pythonowego odpalać testy w ramach. W moim przypadku nie mam nawet czasu aby je pisać więc nie ma co odpalać. Przyjmuję argument, że to co wychodzi na produkcję powinno być numerowane. To bardzo pomocne i użyteczne. Jednak w Python 2 wszystko co sobie wyobrażam to otagowywanie kolejnych wersji w repozytorium. Podmienianie egga, który wywala serwer Apache ponieważ przestają mu się zgadzać sumy kontrolne - to jakaś porażka. To nie wiem co innego mógłbym robić? Dodawać komentarz z numerem buildu w jakimś umówionym pliku? Dodam jeszcze, że to aplikacja internetowa pisana w Django.

Jeżeli ktoś jest w temacie to jestem bardzo zainteresowany wymianą doświadczeń w tym temacie.

Webdevelopment i unit testy

Kilka tygodni temu zacząłem developować webowy frontend dla projektu gitolite o nazwie glboard. Gitolite to warstwa abstrakcji pozwalająca na kontrolę dostępu do repozytoriów systemu git podczas dostępu do serwera przez ssh.

Glboard od samego początku pisany był z myślą o testach, dlatego wraz z kodem publikowane były unit testy do udowadniania poprawności metod, klasy, która stanowi trzon funkcjonalności.

Podczas oglądania prelekcji "State of Pylons/Turbo Gears2/repoze.bfg", moją uwagę przykuły zarzuty postawione unit testom w web-developmencie.

W tym okresie spędziłem sporo czasu, w glboard, na poprawianiu unit testów. Jeżeli padłem ofiarą zbyt wczesnego testowania - to jaki sens ma Test Driven Development?

Podczas zmieniania głównej klasy, obsługującej operacje na repozytorium gita, uzyskałem pewien ciekawy efekt - witryna działała i mogłem dzięki niej wykonać wszystkie operacje - natomiast testy failowały. Wszystkie. Powód był prosty: klasa przyjmowała teraz nowy argument w metodzie __init__.

Wspomniana prelekcja uświadomiła mi jedną rzecz. Jeżeli nie wystawiasz czegoś na zewnątrz, nie wystawiasz API lub biblioteki, nie będziesz zobligowany do zachowywania wstecznej kompatybilności z jakimś stworzonym przez siebie interfejsem, które kiedyś udostępniłeś, tylko dlatego, że używają go klienci - nie używaj unit testów. Pisanie unit testów do elementów, które zostają w twoim projekcie i nie wychodzą w żaden sposób na zewnątrz - to strzelanie sobie w stopę.

Moim zdaniem pisząc aplikację we frameworku webowym to co powinno się testować - to działanie przez przeglądarce. Testy funkcjonalne wydają się wystarczające. Może są troszkę bardziej kosztowne niż unit testy, ale w gruncie rzeczy, dobrze napisane, testują dokładnie to co powinny. Nie skupiają się na API konkretnej klasy, funkcji, metody, ale na tym czy witryna działa - nie ważne jest jak.

Odnosząc się do narzekań na Selenium i długiego czasu trwania testów w nim napisanych: myślę, że możemy spodziewać się rewolucji w świecie testów web-aplikacji dzięki PhantomJS. Nie znam jego wydajności, ale funkcjonalność jest w tej dziedzinie bardzo obiecująca i daje znacznie więcej możliwości niż zwykłe funkcyjne testy. Równocześnie nie używa całego niepotrzebne osprzętu jakie ładuje przeglądarka.

Wszystko co w tej chwili mi pozostaje to usunąć unit testy z glboard i napisać functional testy :)

Co w językach programowania i web developmencie piszczy

Od czasów, kiedy skończyłem studia bardzo interesowałem się rozwojem języka C++. Na początku bibliotkę Boost, w której ląduje co ciekawsze pomysły, które mają w przyszłości zagościć w języku a potem wersją C++0x. Dzisiaj spojrzałem na wsparcie dla składni C++0x w gcc-4.6 i powiem szczerze, że nie mogę się doczekać kiedy Ubuntu i Debian zostaną skompilowane na tym właśnie kompilatorze. Na razie nie jest dostępny na żadnej dystrybucji - niestety brak go również w paczkach Ubuntu 11.04, ale użycie tego kompilatora będzie szalenie ekscytujące.

Lista wszystkich zaimplementowanych nowinek jest dostępna tutaj: http://gcc.gnu.org/gcc-4.6/cxx0x_status.html

Mnie cieszą dwie: składnia dla for znana z python - gdzie iteruje się po elementach, nie po indeksach oraz lambdy - czyli funkcje nienazwane, które można przekazywać jako parametry.

W sumie powiem szczerze, że mam szaloną chęć napisać coś w C++ :) na przykład stronkę - jest framework Web Toolkit więc czemu by nie spróbować :] Jak się patrzy na listę możliwości to pojawia się UTF-8 i 16, HTML 5 native, async I/O, VML, SVG, PDF, PNG/GIF, SSL, TLS właściwie wszystko czego dusza zapragnie, a czym nie chwalą się żadnej inne frameworki należące do języków skryptowych, które borykają się z różnymi problemami w tej dziedzinie (ostatnio szczególnie frameworki Pythonowe). Można deployować przez FastCGI, postawić na dedykowanym serwerze dostarczonym z frameworkiem albo podpiąć do IIS. Brzmi super :)

C++ staje się naprawdę fajnym językiem, może mniej fajnym niż Go (z frameworkiem web.go) :) ale naprawdę wartym uwagi. Pozostaje czekać tylko czym będzie język Noop i cieszyć się z tego co przyniosą najbliższe lata :)

Jeżeli zaś ktoś chciałby popróbować development na wirtualnej maszynie to przychodzą mi na myśl wyłącznie Lift z języka Scala i z troszkę innej beczki :) ExpressJS dla języka Node.JS.

Jako ciekawostkę dodam, że jeżeli ktoś chce się nauczyć, w jakimś subiektywnym aspekcie języka "idealnego" to istnieje świetny kurs do języka Haskell pod tytułem "Learn You a Haskell for Geate Good!" . Web Development też jest wtedy możliwy - dzięki frameworkowi Snap.

O zapomniałbym. Ostatnio (no już trochę czasu minęło) Zed Shaw stworzył (ten gość chyba się po prostu nudzi) Tir - framework do web developmentu w języku skryptowym Lua. Co więcej wszystko w ramach projektu Mongrel2, który jest jeszcze bardziej imponującą kontynuacją znanego developerom Ruby On Rails serwera Mongrel - tym razem, w drugiej wersji wspiera chyba każdy język programowania.

Przy okazji - dla tych, którzy siedzą wciąż w świecie Python i Ruby. Jeżeli szukacie jakiegoś hiper wydajnego frameworka to nie tylko najnowszym i najnowocześniejszym w architekturze, ale również ewidentnie najszybszym jest Pyramid - jeżeli wierzyć wynikom z artykułu "The great web technology shootout – Round 4: Pyramid vs Django vs TG vs Rails 2 & 3" - bije na głowę dosłownie wszystko. Jednak jest to framework stricte w filozofii i podejściu wykorzystywanym w Pylons - i jego sukcesorem. Co miłe jest to "najszybciej wydany" framework w dziejach macro-frameworków jakie w życiu widziałem bo development zaczął się w Grudniu 2010 a pod koniec Stycznia 2011 wyszła stabilna wersja 1.0 - chociaż to troszkę naciągane bo projekt nie startował od zera ale był adaptacją już wcześniej wydanego Repoze BFG.

Zdradzę jeszcze, że dowiedziałem się iż na PyCon 2011 US, który odbywa się w Marcu odbywają się sprinty, które mają na celu portowanie Pyramid na Python 3 tak więc możemy mieć pierwszy framework działający na Py 3k :) Czy to nie ekscytujące?

Co w ostatnich tygodniach.

Dawno nie pisałem na blogu. Gdy jeszcze dzieliłem czas na studia i pracę starczało mi czasu na wszystko. Obecnie obcowaniem z komputerem staram się ograniczać do siedzenia przed nim w pracy, a wieczory i weekendy spędzać w inny sposób.

Ćwiczę Angielski. Umiałem go świetnie przed maturą, jednak studia inżynierskie skutecznie uwsteczniły mnie w tej materii. Jakiś już czas temu, bo w zeszłym roku, mój manager widząc braki, zorganizował spotkania z lektorką dzięki czemu wtorki i czwartki zaczynam lektoratem z języka angielskiego :) co skutecznie poprawia mi humor na pozostałą część tygodnia.

Co do języków programowania - wciąż używam Pytona, ze względu na jego znajomość zostałem zatrudniony i przez ostatnie 1,5 roku zostawiłem po sobie na tyle skryptów i aplikacji zapisanych w tym dialekcie, że ciężko codziennie się z nim nie stykać. Jednak moje marzenia i pasje kierują się w stronę Node.JS oraz wciąż zagadkowego dla mnie języka Scala.

Node.JS chciałem rozpocząć od przebrnięcia przez fantastyczny podręcznik do JavaScript "Eloquent JavaScript". Niestety, silnie funkcyjne podejście autora do sprawy skutecznie utrudnia mi przyswojenie lektury, a problemy zaczęły się już w rozdziale 4.

Co do Scala jest lepiej. Wiele zawdzięczam prelekcji Mikołaja Sochackiego Aplikacje webowe w Scala i Lift wygłoszonej na Zimowisku TLUGu. Sama prezentacja, jak i późniejsza wymiana doświadczeń w prywatnej rozmowie z prelegentem, pozwoliły mi dojść do wniosku, że trzeba przestać przejmować się, że "czegoś" nie rozumiem i opanować Scalę na miarę swoich możliwości - z czasem poznając ją może po prostu lepiej.

Tak też narodził się pomysł na prostego bloga, z przykładowymi aplikacjami w języku Scala, które skupiałyby się na konkretach i w prosty sposób pozwoliły na zapoznanie się z językiem. Co z tego wyjdzie - zobaczymy. Obecnie robię rozeznanie w silnikach, na których warto byłoby taki "blog" postawić. Z dotychczasowych poszukiwań wszystko wskazuje na Joggera - chyba, że znajdą się jakieś fundusze na zakup i utrzymanie domeny - wtedy będzie to Wordpress. Przy okazji trafiłem na Polski Portal Scala, na którym już w tej chwili można zapoznać się z niemałym zbiorem przykładów kodu w tym języku.

Jednak pierwszeństwo przed projektem Scalowym ma stworzenie Planety Pythona, którego podjąłem się niedawno w ramach mojej działalności w Polish Python Coders Group - wszak na koszulkę jakoś trzeba sobie zasłużyć :). Twarzą w twarz poznałem większość ekipy dopiero na PyCon.pl 2010 i co tu dużo gadać - są genialni. Kocham tych chłopaków za kawał dobrej roboty jaki odwalają, szczególnie na IRCu i Forum - uważam, że mamy fantastyczną scenę Pythonową w Polsce jakiej można tylko pozazdrościć i każdy kto chce zacząć przygodę z tym językiem nie mógłby sobie wymarzyć lepszej społeczności niż obecna.

Wracając do Zimowiska Linuksowego TLUG - było naprawdę fajnie. Dzięki zakwaterowaniu w Puckim HOMie czułem się jak na wczasach, do tego urok małego miasteczka jakim jest Puck - genialnie. Prelekcje były zróżnicowane, poziom wielu z nich naprawdę wysoki i profesjonalny. Szczególnie dało się to odczuć w prezentacjach Piotra Macuk, Tomasza Torcz (wiem, że gdzieś prowadzi bloga, ale nie mam adresu), Roberta Jaroszuk, Grzegorza Borowiak oraz Dariusza Puchalak. Subiektywnie jednak bardziej interesują mnie technologie webowe i ten charakter konferencji, która moim zdaniem była zaadresowana głównie do administratorów systemu Unix, nie przypadł mi specjalnie do gustu.

Co do spędzania czasu po pracy zagospodarowuję go w znacznej mierze treningami Aikido w Shoshin Dojo. I grubsza tyle z nowinek - wracam chorować :]

Pyramid - następca Pylons

Kilka dni temu Kevin J. Smith napisał na grupie dyskusyjnej pylons-discuss, że jako użytkownik Pylons, czuje się troszkę zmieszany ponieważ pierwszy raz trafia na informacje o Pyramid.

Szybko okazało się, że developerzy Pylons zaczęli pracować już nad następcą Pylons - jednak nie ogłosili tego światu. Tak oto przypadkiem świat dowiedział się o Pyramid.

O kierunkach jakie przyjmie Pylons 2.0 można było przeczytać już kilka tygodni temu na blogu Bena Bangerta we wpisie Why Extending Through Subclassing (a framework’s classes) is a Bad Idea. Było to preludium do kierunku jakim podąży Pylons 2.0 - a właściwie powinienem powiedzieć Pyramid.

Pierwsze - Pyramid "połączyło się" z zespołem repoze.bfg. Połączyło się, a raczej stwierdziło, że dotychczasowy model tworzenia kolejny aplikacji (poprzez tworzenie podklas WSGIController) jest ślepym zaułkiem - przed czym zostali ostrzeżeni przez sławę CherryPy Boba Brewera. Aby nie wymyślać koła na nowo obecnie Pylons tworzony jako adaptacja repoze.bfg. Tak zostało wydane ogłoszenie iż obecnie repoze.bfg staje się projektem Pyramid i będzie wydawane pod tą nazwą. Dwa fantastyczne zespoły połaczyły siły aby na bazie już dobrze ukształtowanego repoze.bfg oraz posiadającego swoich fanów Pylons powstał jeszcze lepszy framework dla języka Python.

Dzięki temu połączeniu, oraz faktowi iż kod Pyramid posiada dobrze ugruntowaną bazę w postaci kodu repoze.bfg już dziś możemy cieszyć się Pyramid 1.0a dostępnym przez Python Package Index.

Te informacje napawają optymizmem. Wszystko wskazuje na to, że następca Pylons wyjdzie szybciej niż ktokolwiek by się spodziewał i będzie to naprawdę fantastyczny framework. Oby w parze z postępami w kodzie pojawiały się artykuły, a dokumentacja rosła :) Nic tylko czekać na Pyramid Book :)

PyCons

Tydzień po powrocie z polskiego PyCona zacząłem oglądać konferencje z konferencji pythonowych, które odbyły się w innych częściach świata. Fantastyczną nowiną jest fakt iż większość z nich zamieszcza nagrania wideo prelekcji (nie tylko slajdy) więc można po prostu wysłuchać i zobaczyć prelekcję - taką jaka była - w zaciszu własnego domu.

Tematy poruszane w różnych zakątkach świata są bardzo różne :) i dobrze. Można się naprawdę wiele nauczyć i wybrać sobie te tematy, które odpowiednio pasują do naszego obecnego poziomu lub po prostu zainteresował nas temat. Tutaj pierwsza uwaga.

Temat konferencji czasami kompletnie nic nie mówi o jej treści. To smutne, ale widzisz temat i nie wiesz - warto to w ogóle odpalać, czy lepiej odpuścić sobie. Bo co na przykład mówi tytuł "Dude, Where's My Database?". Na szczęście są (przy większości tematów) opisy mówiące o treści konferencji. Bezcenne.

Druga rzecz - jakość materiałów. Chyba najlepiej zorganizowane są na stronie PyCon Atlanta. Naprawdę super. Łatwy dostęp do wszystkiego. Natomiast materiały wideo z UK czy Europy są tragiczne. Co z tego, że mają nagranie wideo skoro ani nie słychać na nim prowadzącego wykład ani nie widać wyraźnie slajdów. Po prostu ... bezużyteczne.

Osobiście czytanie dokumentacji ze zrozumieniem przychodzi mi z trudnością i nigdy nie mogę wyłapać w niej niuansów i szczegółów implementacyjnych. Takie prelekcje są dla mnie jak znalazł. Głównie dlatego, że ludzie w nich skupiają się na tym co jest ważne, dają przykłady i pokazują "big picture", który czasem ciężko samemu dostrzec. Te trzy aspekty sprawiają, że takie konferencje to dla mnie kopania wiedzy :) Polecam każdemu!

Jak kupiłem mIRCa

Tak. Wczoraj zakupiłem mIRCa. Zapłaciłem $24 - te $4 to podatek z Polski. Dlaczego?
Na IRCu wiele nie siedzę. Natomiast zamierzam trochę więcej niż wcześniej aby wesprzeć społeczność PPCG choćby odpowiadając na pytania początkujących.

To nie jest tak, że nigdy wcześniej nie używałem IRCa. Jak byłem chyba jeszcze w podstawówce to pamiętam moją siostrę, która siedziała na jakiś kanałach i opowiadała o jakiś ludziach, którzy też tam siedzą - totalny bezsens. IRC - narzędzie dla zakompleksionych, dla których jedyną drogą przetrwania stała się akceptacja przez wirtualną społeczność. Tak to wtedy postrzegałem.

Potem trafiłem na książkę "Dziennik Hakera" albo coś podobnego gdzie było napisane, że Hakerzy też używają IRCa. No tak - też odludki - to sobie siedzą. Potem była jakaś era wchodzenia na czaty Onetu i wszelkiej różne inne, zakładanie własnych czatów przez jakieś skrypty i tak jakoś to bez refleksyjnie obok mnie przeszło.

Dla mnie IRC stał się czymś wartościowym kiedy odkryłem freenode - czyli sieć gdzie są wartościowe kanały dotyczące języków programowania, w których koduję. Wejść na kanał, zapytać o coś, dowiedzieć się więcej, wziąć udział w jakiejś dyskusji. Wtedy IRC stał się dla mnie czymś użytecznym.

Dlaczego mIRC? Chłopaki z PPCG rzucali setkami pomysłów, ale żaden nie wpadł na pomysł aby kupić mIRCa. Jest to jedyny klient, który mi się podoba. Naprawdę. Wiem, że jest Quassel i IRSSI i dużo innych klientów, ale żaden darmowy mi nie podpasował. mIRC to jedyne co mi się naprawdę spodobało.

Mam nadzieję, że kupno mIRCa będzie inwestycją, nie wyrzuconymi pieniędzmi w błoto :] Zobaczymy - czas pokaże.