Nie tylko pisanie kodu

Gdyby było to fizycznie możliwe, chętnie przeprowadziłbym następujący eksperyment. Z odległej przeszłości – na przykład z połowy lat 90. poprzedniego stulecia – sprowadziłbym w obecne czasy dowolnego ponadprzeciętnie uzdolnionego programistę. Jak szybko odnalazłby się we współczesnym koderskim środowisku pracy?… W celu redukcji złożoności problemu poczyńmy daleko idące uproszczenia i pomińmy wszelkiego typu zmiany związane z postępem technologicznym (jak choćby nieporównywalnie większe znaczenie Internetu wtedy i teraz), a także modyfikacje, które zachodzą w samych językach programowania. Interesuje mnie raczej to, czy ów przybysz z przeszłości doceniłby i uznał za przydatne różnego rodzaju czynności i narzędzia pomocnicze, niebędące edytorem tekstu (lub IDE) ani kompilatorem, i pozostające w luźniejszym związku z samym pisaniem kodu jako takiego.

Jakby bowiem przyjrzeć się dokładnie wachlarzowi tych narzędzi, okazuje się, że jest on już całkiem szeroki. Programowanie, zwłaszcza zespołowe (jeżeli w ogóle istnieje jeszcze jakieś inne) już od dawna przestało ograniczać do tworzenia kodu i czasami wydaje się nawet, że czynność ta stała się poboczną. Coraz więcej czasu zajmuje praca z takimi narzędziami jak systemy kontroli wersji, systemy śledzenia błędów (issue tracking systems), narzędzia automatyzujące proces kompilacji, programy do statycznej analizy kodu, systemy zdalnej kompilacji i pewnie mnóstwo jeszcze innych wynalazków, z którymi nie miałem dotąd okazji się zetknąć.
Między innymi dlatego nie potrafię jednoznacznie określić, czy uważam je wszystkie raczej za przydatne czy raczej za zbędne. Wiążące opinie mogę jak dotąd wyrazić tylko o niektórych.

Tym niemniej ciekawi mnie również, czy w dziedzinie wspomagania kodowania (czy ogólnie pracy nad projektami) od strony zautomatyzowanych narzędzi da się wymyślić coś jeszcze…

Więcej pulpitów

Pracując przez chwilę na Linuksie, odkryłem poważną zaletę jego interfejsu graficznego, którą Windows domyślnie nie może się pochwalić. Wirtualne pulpity, bo o nich mowa, to koncept, który w pierwszej chwili może wydawać się nieco dezorientujący. W końcu czasami ma się problem z ogarnięciem okien na jednym tylko pulpicie, więc co dopiero powiedzieć o – powiedzmy – czterech? :) Ale więcej miejsca na bałagan to także więcej miejsca na porządek i jeśli tylko potrafimy dobrze tę powiększoną przestrzeń zagospodarować, możemy znacznie zyskać na efektywności. Ograniczamy bowiem konieczność przełączania między programami za pomocą powolnych i niewygodnych metod, takich jaki klikanie w przyciski na pasku zadań czy pracowite przechodzenie po liście okien za pomocą przełącznika Alt+Tab.

To doprawdy wstyd, że Windows nie oferuje takiego mechanizmu wbudowanego w system. Jakby się jednak chwilę nad nim zastanowić, nie jest on żadnym rodzajem magii. Można go przynajmniej symulować za pomocą odpowiednio przemyślanego ukrywania i odkrywania okien na żądanie użytkownika, przechodzącego między kolejnymi “wirtualnymi «wirtualnymi pulpitami»”. Zdaje się, że właśnie na takiej zasadzie działają programy, które uzupełniają system Windows o tę pożyteczną funkcjonalność.
Rozwiązaniem wypróbowanym przeze mnie jest VirtuaWin. Jest to bardzo mała, ale całkiem zmyślna aplikacja. Bez widocznego narzutu na zasoby systemowe (kilka megabajtów w pamięci) wprowadza ona możliwość przełączania się między wirtualnymi pulpitami przy pomocy typowych kombinacji klawiszy (czyli Ctrl+Alt+strzałki). I to niemal dowolną liczbą wirtualnych pulpitów, do których można automatycznie przypisywać okna na podstawie ustalonych (bazujących np. na klasie okna lub jego tytule). Jedyne, czego tu brakuje, to ładna animacja przełączania zamiast znikających i pojawiających się okien… ale cóż, nie można mieć wszystkiego ;)

W każdym razie polecam przyjrzenie się możliwości powielenia swojego pulpitu nawet bez przyłączania dodatkowych ekranów. Opłaca się.

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 :)

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.