Pierwsze kroki w Pythonie

Python to już od dłuższego czasu bardzo popularny język do wszelakich zastosowań. Oprócz pisania w nim samodzielnych programów lub aplikacji webowych, jest on też często używany jako język skryptowy rozszerzający możliwości programów, czego chyba najbardziej znanym przykładem jest Blender. Istnieje więc duża szansa, że niezależnie od dziedziny IT, którą się zajmujemy, prędzej czy później przyjdzie nam zetknąć się z tym językiem.
W takim przypadku często dobrze jest wybiec przed szereg i zapoznać się z Pythonem już teraz, co by nie obudzić się potem w wielkim zaskoczeniu ;-) Na szczęście doświadczenie pracy z tym językiem należy raczej do przyjemnych, co oczywiście nie zmienia faktu, że dobrze jest co nieco o nim wiedzieć.

Dlatego też postanowiłem napisać krótką instrukcję paru kroków, które powinny pomóc wszystkim zainteresowanym w rozpoczęciu przygody z Pythonem. Chodzi tu przede wszystkim o przygotowanie kompilatora interpretera, narzędzi pomocniczych oraz środowiska programistycznego. Nie jest to, na całe szczęście, bardzo trudne:

1. Zaczynamy od zaopatrzenia w sam podstawowy pakiet Pythona, czyli w interpreter i pakiety biblioteki standardowej języka. Jeśli korzystamy z jakiejś użytkownikowo-przyjaznej dystrybucji Linuksa (np. Ubuntu), to pewnie będziemy już takie coś posiadali. W przeciwnym razie wybieramy się na stronę Python.org i wybieramy wersję dla swojej platformy. Jeżeli jest to Windows, to zalecam wybranie wersji 32-bitowej niezależnie od bitowości samego systemu – inaczej możemy mieć problemy ze współpracą z pomocniczymi narzędziami.
   Aktualnie w obiegu są dwie edycje Pythona: seria 2.x i 3.x. W dalszych krokach zakładam używanie serii 2.x głównie ze względu na większą przenośność jej i narzędziowych aplikacji.
2. Niemal niezbędnym programem pomocniczym przy korzystaniu z Pythona jest easy_install, będący częścią pakietu setuptools. Pozwala on na łatwe instalowanie dodatkowych pakietów, trochę tak jak apt-get na debianowych Linuksach. Jest to bardzo wygodne i skutkuje np. tym, że aplikacje napisane w Pythonie potrafią same rozwiązać swoje zależności podczas instalacji i ściągnąć pakiety wymagane do swojego działania.
3. Jeśli nie zostało to zrobione za nas, powinniśmy dodać katalog instalacyjny Pythona (zawierający plik wykonywalny interpretera) oraz podkatalog Scripts (zawierający program easy_install) do zmiennej środowiskowej PATH. Ułatwi to między innymi późniejszą konfigurację środowiska programistycznego.
4. Opcjonalnie możemy zaopatrzyć się w DreamPie – shell dla Pythona, który jest o wiele wygodniejszy i potężniejszy niż wbudowany IDLE, że o systemowej konsoli nie wspomnę. Korzystanie z shella jest dość częste; dzięki niemu możemy bezboleśnie sprawdzić działanie funkcji i konstrukcji językowych, używanych w naszych programach.
5. Wreszcie, czas zaopatrzyć się w środowisko programistyczne, czyli IDE. Tu do wyboru mamy kilka możliwości, zależnie od używanej platformy i preferencji, o czym szczegółowo informuje nas oficjalne wiki. Jeśli przypadkiem używamy już któregoś z dwóch popularnych, uniwersalnych IDE – czyli Eclipse lub NetBeans – możemy użyć wtyczek rozszerzających je o możliwość współpracy z Pythonem (odpowiednio PyDev oraz NBPython). Alternatywą jest użycie samodzielnych IDE do Pythona takich jak PyScripter.

Co dalej? No cóż, to już zależy od tego, do czego chcemy Pythona używać. W celu znalezienie inspiracji możemy na przykład przeglądnąć posortowane tematycznie drzewko dostępnych pakietów i wybrać coś, co nas interesuje. Następnie możemy zainstalować nowe pakiety za pomocą programu easy_install, podając po prostu nazwę paczki, lub ściągnąć je w postaci archiwum i uruchomić skrypt setup.py z parametrem install.
A co zrobić w celu nauczenia się samego języka?… Jeżeli nie odpowiada nam studiowanie samej dokumentacji, możemy spróbować poszukać w sieci odpowiedniego tutorialu, takiego jak np. dostępna za darmo ksiażka Dive Into Python.

Triki z PowerShellem #17 – Stan baterii

Wykonywałem ostatnio skomplikowane akrobacje z bashem, plikiem /etc/rc.local, modułami kernela i innymi linuksowymi wynalazkami, aby uruchomić system spod znaku pingwina na swoim laptopie. Problem leżał w posiadaniu przezeń dwóch kart graficznych, działających w trybie hybrydowym, z których jedna (zintegrowana) działa zawsze, natomiast druga (zewnętrzna) budzi się na żądanie w celu obsłużenia bardziej skomplikowanych aplikacji graficznych i gier. Naturalnie Linux nie jest przygotowany do współpracy z tą technologią. więc o bezproblemowym działaniu X-owych okienek (poza trybem recovery) nie mogło być mowy.
Rozwiązaniem było całkowite wyłączenie zewnętrznej karty i to w niezbyt delikatny sposób, bo poprzez... pozbawienie jej zasilania za pomocą odpowiedniego polecenia modułu acpi. O tym, czy polecenie to faktycznie coś dało, mogłem się natomiast przekonać przy pomocy obserwacji szybkości rozładowywania się baterii, dostępnej w pliku /proc/acpi/battery/BAT1/state i wyglądającej mniej więcej tak:

Tak to właśnie wygląda na systemie, który podobno "po prostu działa" ;-) Żarty żartami, ale powyższy raport nt. stanu zasilania jest zbiorem całkiem interesujących informacji, które byłyby pożyteczne także i w systemie Windows. Pomyślałem więc, czy i tam nie udało by się pozyskać podobnych danych. Odpowiedź - jak można się domyślić - jest oczywiście pozytywna.

Odchudzanie lisa

Jak można przeczytać tu i ówdzie (a potem sprawdzić u źródła), premiera czwartej wersji przeglądarki Firefox przesunie się z końca tego roku na początek przyszłego. Zwolennicy tzw. bardziej nowoczesnych przeglądarek zapewne skorzystają z okazji, by używać tego faktu jako argumentu na rzecz tezy, że Ognisty Lis pozostaje w tyle pod względem szybkości, zgodności z sieciowymi standardami oraz estetyki i komfortu interfejsu.
Nawet jako jego użytkownik muszę przyznać, że przynajmniej ostatni z tych zarzutów faktycznie może być zasadny - ale tylko pod jednym zastrzeżeniem, które w przypadku Firefoksa jest po prostu nie fair. O ile bowiem FF3.6 out-of-the-box jest faktycznie dość siermiężny, o tyle nadrabia to z nawiązką możliwościami konfiguracji, których nie można w uczciwym zestawieniu pominąć.

Standardowy interfejs Firefoksa

Żeby jednak nie być gołosłownym pozwolę sobie pokazać, jak w kilku krokach możemy ów niezbyt imponujący, standardowy interfejs przekształcić w coś bardziej 'nowoczesnego'. Mój opis można będzie potem potraktować jako swego rodzaju konstruktywną ripostę w świętych wojnach przeglądarkowych :)

Partycja na plik wymiany

Instalując ostatnio Linuksa zauważyłem, iż standardową praktyką tego systemu jest wydzielanie zupełnie osobnej partycji na plik stronnicowania (pagefile), zwany też potocznie plikiem wymiany. Mówiąc zresztą ściślej, Linux nie tworzy tam żadnych plików i zamiast tego korzysta z partycji bezpośrednio jako źródła miejsca dla pamięci wirtualnej.

Skąd taki pomysł, skoro Windows domyślnie radzi sobie całkiem dobrze, trzymając swoje dane stronnicowania w zwykłym pliku?... No cóż, to jest jedna z tych rzeczy, które Linux akurat robi lepiej. Umieszczenie pliku wymiany na innej partycji niż systemowa ma bowiem uzasadnienie wydajnościowe. W najlepszym wypadku ona sama powinna zresztą znajdować się na zupełnie osobnym dysku, dzięki czemu możliwe byłoby równolegle korzystanie z pliku wymiany i "normalnych" danych. Oczywiście nie zawsze jest to możliwe, zwłaszcza w komputerach przenośnych, siłą rzeczy dysponujących tylko jednym fizycznym dyskiem.

Co dokładnie daje umieszczenie pliku wymiany na jego własnej partycji? Myślę, że nietrudno się tego domyślić: chodzi o brak fragmentacji. Ponieważ brak jest kontaktu z jednostkami alokacji innych rodzajów danych, możliwe jest zachowanie integralności pliku wymiany, który w dodatku położony będzie zawsze blisko początku swojej partycji. To zaś przyspiesza do niego dostęp.
Znaczenie ma również położenie samej partycji na dysku. W idealnym przypadku powinna być ona na samym początku dysku, ale niestety jest to właściwie nie do osiągnięcia, jako że tam zwykle znajduje się już system operacyjny. Jeżeli nie chcemy go reinstalować, to dobrym rozwiązaniem jest umieszczenie partycji swap pośrodku dysku, między częścią systemową a partycją z danymi. Minimalizujemy wtedy drogę głowicy do pliku wymiany, jeśli już znajduje się ona nad którąś ze wspomnianych dwóch części. Wadą tego rozwiązania jest kłopotliwe powiększanie którejś z nich, jeśli kiedyś okaże się, że potrzebujemy więcej miejsca na system kosztem danych lub odwrotnie. Nie ma bowiem wtedy innej opcji jak usunięcie partycji wymiany i stworzenie jej na nowo.

Papier 2.0

Od kilku miesięcy popularność na świecie (w znacznie mniejszym stopniu w Polsce) zdobywają tzw. tablety, czyli komputery przenośne bez klawiatury, a jedynie z ekranem dotykowym. (Ich najbardziej znanym przykładem jest oczywiście iPad). Jako jedno z ich (niezbyt licznych) zastosowań podaje się możliwość wygodnego przeglądania stron internetowych, czytania kolorowych magazynów w wersji elektronicznej oraz e-booków, czyli książek. Co do pierwszych dwóch, mógłbym się ewentualnie zgodzić. Ale co do ostatniego - absolutnie nie, co nie powinno w sumie zaskakiwać. Długotrwałe męczenie oczu podążaniem za jednorodnym tekstem książki na dużym, świecącym i połyskliwym ekranie - połączone z trzymaniem w rękach urządzenia o nietrywialnym przecież ciężarze - trudno bowiem kojarzyć z jakimkolwiek komfortem.

Do czytania potrzeba więc urządzenia zarówno mniejszego, jak i bardziej do tego przystosowanego - choćby pod względem rodzaju wyświetlacza, bardziej imitującego rzeczywisty papier. Odpowiednie technologie istnieją już od ładnych kilku lat i zostały zastosowane w kilku produktach - z różnym skutkiem. Świeżym przykładem jest Kindle 3, którego to ostatnio sobie sprawiłem i w związku z tym pozwolę sobie podzielić się wrażeniami z jego użytkowania :)
Ale najpierw odpowiem na nasuwające się zapewne pytanie: a po co komuś coś takiego? Posiadanie przenośnego czytnika dokumentów tekstowych (w tym e-booków) okazuje się jednak bardzo przydatne, jeśli czytamy ich dużo lub jeśli często zdarza nam się przymusowe oczekiwanie w warunkach niepozwalających na wyciągnięcie "cięższego sprzętu" elektronicznego (przykładem takich sytuacji są chociażby przejazdy komunikacją miejską). Mogę z pełnym przekonaniem stwierdzić, że możliwość lektury e-booka, dokumentacji, zachowanych wcześniej notek z blogów czy artykułów z sieci w komfortowej, niemęczącej oczu i rąk formie jest doprawdy bardzo wygodna.

Wśród urządzeń, które na to pozwalają, Kindle prezentuje się przy tym bardzo pozytywnie. Wrażenia wzrokowe po dłuższej lekturze są mniej więcej takie, jak po czytaniu kolorowego albumu drukowanego na śliskim papierze. Nie jest to jeszcze matowość kart książki znalezionej u dziadka na strychu, ale fakt ten w niczym nie przeszkadza :) Sam zastosowany tu e-papier posiada doskonały kontrast i ostrość obrazu, a jedyne obserwowalne odblaski (niezbyt duże) pochodzą jedynie z jego plastikowej osłonki. Ogólnie z urządzenia można korzystać tak, jak z tradycyjnej książki.
Lista formatów dokumentów, które Kindle obsługuje bezpośrednio lub pośrednio, jest ponadto całkiem długa. Są na niej zarówno pozycje specyficzne dla czytników (np. MOBI), jak i bardziej znane PDF czy HTML (ten pierwszy odczytywany jest z marszu). Wreszcie jest tu także łączność WiFi (opcjonalnie też 3G) i przeglądarka stron WWW oparta na silniku WebKit (tym od Safari lub Chrome) o zaskakująco dużych możliwościach. Dzięki niej - oraz za pomocą usługi Read It Later i autorskiego skryptu w PHP - udało mi się na przykład znaleźć eleganckie rozwiązanie pewnego use case'a, który pojawia się niemal natychmiast po rozpoczęciu korzystania z czytnika. Chodzi mianowicie o szybkie zachowanie artykułu znalezionego w sieci (na zwykłym komputerze) do późniejszego przeczytania z użyciem Kindle. Oferowany w tamtejszej przeglądarce tryb Article Mode potrafi bowiem niezwykle skutecznie pozbyć się ze strony wszystkiego, co nie jest głównym tekstem, a samą treść sformatować w sposób eliminujący konieczność przewijania w poziomie.

Obecność w pełni funkcjonalnej przeglądarki przestaje być zaskakująca, gdy weźmiemy pod uwagę to, że Kindle - podobnie jak większość urządzeń elektronicznych bardziej złożonych od mikrofalówki - działa pod kontrolą odpowiednio zmodyfikowanego Linuksa. A to od razu rodzi pytanie co do ewentualnego... tworzenia aplikacji na tą platformę :)
Odpowiedź jest tu także dość typowa i brzmi: albo zhakuj urządzenia i zdobądź prawa roota (z wiadomym skutkiem dla gwarancji), albo użyj autoryzowanego SDK. Ta druga opcja na razie jest dostępna niestety tylko dla wybranych, gdyż SDK (zwane KDK) jest obecnie w fazie na wpół zamkniętej bety. Miejmy nadzieję, że prędko zostanie ono wydane publicznie - albo że przynajmniej moje zgłoszenie chęci udziału w testach zostanie rozpatrzone pozytywnie ;P

Rozproszone systemy kontroli wersji

Z systemami kontroli wersji (w skrócie VCS) zetknął się każdy programista i dla niemal wszystkich jest to oczywiste narzędzie pracy. Dla wielu jednak wciąż jeszcze kojarzą się one z jednym, centralnym miejscem zawierającym zawierającym bazę kodu projektu (czyli repozytorium) oraz z licznymi kopiami roboczymi, nad którymi pracują programiści. Kiedy zaś chcą połączyć swoje zmiany, wówczas wykonują tylko operację znaną jako commit.

Tak jest w systemach typu CVS czy Subversion, ale obecnie sporą popularność zyskały też inne, działające na nieco innej zasadzie. Nazywają się one rozproszonymi (distributed version control system - DVCS) i zgodnie z tym określeniem ich główną cechą jest brak wydzielonego, centralnego repozytorium. Zamiast tego może być ich dowolna ilość, która w rzeczywistych projektach może łatwo urosnąć do setek, a nawet tysięcy. Najczęściej bowiem swoje własne repozytorium ma na przykład... każdy pracujący nad projektem programista.
Obłęd? Niezupełnie. Wszystko opiera się bowiem na operacji synchronizacji dwóch repozytoriów, którą nazywa się - w zależności od punktu widzenia - push lub pull. Push oznacza wprowadzenie poprawek z naszego repozytorium do innego, zaś pull oznacza ściągnięcie zmian z innego repozytorium do własnego. Jak nietrudno zauważyć, operacja ta jest symetryczna. I chociaż techniczne wszystkie repozytoria są równoważne, w praktyce jedno z nich jest zwykle bazą projektu, zawierającą jego "autorytatywną" wersję. Ponadto z każdym repozytorium można też pracować "normalnie", tj. przy pomocy znanych i lubianych operacji commit i update.

Działanie rozproszonych systemów kontroli wersji

Po co taka zmiana? Przydaje się ona zwłaszcza w dwóch sytuacjach:

• Dla projektów typu open source umożliwia względnie niezależne opracowywanie poprawek do projektów. W tym celu wystarczy sklonować główne repozytorium, a następnie w spokoju pracować nad uzyskanym kodem, korzystając z jego kopii. Chcąc następie uczynić zmiany obowiązującymi, możemy wykonać push - ale tylko wtedy, jeśli mamy do tego prawa. Jeśli nie, możliwe jest stworzenie łatki (patch), zawierającej nasze modyfikacje i przekazania jej osobie zarządzającej projektem. Ta zaś może - zapewne po przetestowaniu zmian na własnej kopii repozytorium - wprowadzić je wreszcie do bazy kodu. Podobny akceptowania poprawek występował w projektach open source już od dawna, ale dopiero rozproszone systemy kontroli wsparły go od strony technicznej.
• Jeśli pracujemy wyłącznie lokalnie nad własnymi projektami, możemy stworzyć sobie takież repozytorium, które będzie przy tym jedynym. Nie synchronizujemy wtedy zmian z żadnym innym repozytorium, ale wciąż możemy korzystać ze standardowych funkcjonalności systemów kontroli wersji.

W średniej skali (takiej, jak przedstawiona na obrazku powyżej) systemy rozproszone sprawdzają się natomiast nieco gorzej - zwłaszcza, gdy częstotliwość zmian jest duża. Wówczas często zachodzi potrzeba łączenia (merge) różnych ścieżek tworzenia aplikacji.

Tym niemniej warto się zainteresować tego rodzaju systemami kontroli wersji, by przekonać się, że poza Subversion też coś istnieje :) Przykładami rozproszonych VCS-ów są np. Mercurcial i Git.

Windows co zna 64 bity

Ze sporym opóźnieniem i nie bez kłopotów zrobiłem wreszcie, co planowałem uczynić od dawna: pozbyć się Visty z komputera stacjonarnego i zamiast tego sprokurować tam sobie Windows 7. A że przy okazji mogłem ów nowy system zainstalować w wersji 64-bitowej, postanowiłem tak właśnie uczynić. Jakie są rezultaty tego eksperymentu?... Niestety dość kiepskie.

Nie znaczy to na szczęście, że 64-bitowy system na 64-bitowym procesorze jest nieużywalny - no nie, tak źle to nie jest :) Wydaje mi się, że istnieje tylko niewielka szansa, że podwojenie liczby systemowych bitów zaowocuje problemami z uruchomieniem jakieś aplikacji, która wcześniej działała dobrze. Jak wiadomo jest tu emulacja trybu 32-bitowego, która sprawdza się bardzo dobrze.
Skąd to wiem? Ano stąd, że okazji do jej wykorzystania jest mnóstwo - i w zasadzie to właśnie jest problem. Wersji aplikacji dedykowanych do x64 nie jest znowu tak dużo, a jeśli już da się takie znaleźć, to często są one pod znacznie gorszą opieką developerską i można mieć uzasadnione wątpliwości co do ich stabilności. Przykładem jest chociażby Firefox, którego 64-bitowa wersja jest tylko na wpół oficjalna i dostępna jedynie w angielskiej wersji językowej. W sumie więc mój Menedżer zadań pokazuje zdecydowaną większość procesów z dopiskiem * 32, zaś pozostałe to albo usługi systemowe, albo aplikacje zarządzane .NET lub Javy.

O ile jednak cudów po aplikacjach nie ma sensu się spodziewać (zwłaszcza tych przeznaczonych dla użytkowników domowych), o tyle 64-bitowe sterowniki do urządzeń byłyby bardzo wskazane. I tu może spotkać nas niemiła niespodzianka, gdyż ich także często brakuje. W moim przypadku z zadania wywiązała się jedynie NVidia, dostarczając sterowniki w wersji x64 zarówno do karty graficznej, jak i chipsetu płyty głównej. Ale już np. Microsoft nie uważał za stosowne zapewnienia drivera dla firmowanej przez siebie myszki Sidewinder X5, wykręcając się kompatybilnością jego 32-bitowej wersji, opracowanej z myślą o Viście.
To zresztą typowy scenariusz i można się tylko cieszyć, że te vistowe sterowniki działają bez problemów. Nie można tego natomiast powiedzieć o ewentualnym oprogramowaniu dodatkowym, dołączanym do różnych sprzętów. Jego zainstalowanie wymaga co najmniej kombinowania z trybem zgodności. oszukującym je co do rzeczywistej wersji systemu. W niektórych przypadkach (jak chociażby wspomnianego gryzonia) i to nie jest wystarczające, gdyż system blokuje instalację aplikacji, tłumacząc się - cytuję - "znanymi problemami ze zgodnością" ;P

Konkluzja jest więc taka, że 64 bity to wciąż żadne udogodnienie, a jedynie konieczność powodowana oczywiście chęcią wykorzystania większej ilości RAM-u niż ok. 3GB obsługiwane przez systemy 32-bitowe. Doświadczenie korzystania z systemu x64 przypomina używanie aplikacji w wersji Release Candidate: żadnych błędów nie znajdziemy i rzecz zasadniczo będzie działać, ale widoczne będą jakieś zgrzyty, o których wiadomo już, że zostaną naprawione dopiero patchami do wersji finalnej - jeżeli w ogóle. Wydaję mi się, że dopóki 4GB RAM-u nie będą standardem dla komputerów w cenowej strefie średnio-niskiej, wsparcie dla x64 ze strony producentów oprogramowania może być w dużym stopniu dobrowolne.
A kiedy coś takiego może stać?... Cóż, prawdopodobnie dopiero wraz z kolejną wersją Windows.