Techniczna dokumentacja pythonowych API nie jest typowym miejscem dla wzmianek dotyczących historii Polski. Dlatego poniższy fragment (z dokumentacji biblioteki pytz) jest dość zaskakujący:

Napisałem kiedyś notkę o tym, co jest fajnego w informatyce. Po latach – drobne uzupełnienie.

Na jeden z zeszłorocznych wyjazdów zabrałem, dość przypadkowo zresztą (głównie ze względu na niewielki rozmiar), książeczkę Pawła Jasienicy Rozważania o wojnie domowej. Nie będę tutaj ani jej recenzował, ani rozpisywał się o ciemnych stronach Rewolucji Francuskiej, chciałbym natomiast wynotować dwa cytaty z szerszych rozważań autora, które wydają mi się warte zastanowienia. A może raczej – regularnego zastanawiania.

Upgrade do Ubuntu 16.04 oznaczało zmianę upstart na systemd. Z perspektywy szarego używania zmiana nie ma ma jakiegoś odczuwalnego znaczenia ale pod spodem jest oczywiście inaczej. Ja musiałem zdecydować, co zrobić ze skryptami zadań użytkownika, czyli jak teraz uruchamiać moje pomocnicze aplikacje, tunele SSH itp.

Okazało się, że uruchamianie nie-systemowych programów pod kontrolą systemd również jest dość łatwe i przyjemne, przy pomocy nietrudnej konfiguracji można zapewnić automatyczne uruchomienie zbioru potrzebnych programów i samoczynne ich restartowanie gdyby uległy awarii.

Zachwalałem parę lat temu racjonalny układ klawiatury Marcina Wolińskiego. Nadal z dużą przyjemnością go używam, a zdecydowałem się przypomnieć, bo instalacja jest dziś dużo prostsza.

Przez techniczne serwisy przeleciała ostatnio informacja o poważnym błędzie w kodzie Gita (w Polsce pisał o nim choćby Niebezpiecznik). News jak news, różnorakie usterki są odkrywane na pęczki ale jako uczestnik świętej wojny Gita z Mercurialem rzuciłem okiem. Błąd okazał się całkiem ciekawy i … potrącił interesującą mnie sprawę.

Zdecydowałem się zacząć robić porządek w kodzie który już opublikowałem i który publikować zamierzam. Efektem jest strona:

     mekk.bitbucket.io

która stanowi tematyczny indeks mojego otwartego kodu.

Napisałem ostatnio parę rozszerzeń do Mercuriala. Nic szczególnie skomplikowanego, rozwiązania codziennych uciążliwości (np. grupowe definiowanie aliasów albo automatyczne poprawianie numeru wersji przy tagowaniu).

Skoro już zdecydowałem się je opublikować, przydałoby się jakoś zapewniać jakość. A to oznacza przeprowadzanie podstawowych testów funkcjonalności przed każdym release. Co więcej, testy te warto by wykonać na różnych wersjach Mercuriala a nawet na różnych wersjach Pythona.

Przećwiczyłem w tym celu kilka narzędzi, które mogą być przydatne nie tylko w tym zastosowaniu (i nie tylko przy programowaniu w Pythonie).

Od czasu gdy chwaliłem wygodę korzystania z Compiza, trochę się zmieniło.

Compiz na gorsze. Autorzy uznali, że (bardzo dla mnie wygodna) konwencja rzucania okien po siatce skrótami klawiszowymi jest zbyt konfudująca dla części użytkowników – i drastycznie ją ograniczyli (działa tylko rzut do połówek i ćwiartek, nie ma efektu wyboru kolejnych rozmiarów przez powtarzanie naciśnięć klawisza).

Na lepsze zmienił się mój monitor w pracy. Mam szerszy, na którym naturalne jest rozmieszczenie obok siebie trzech okien edytora.

Przez mniej więcej rok korzystałem z Awesome. Kilka miesięcy temu je, z pewną ulgą, porzuciłem ale doświadczenie było ciekawe i parę spraw zanotuję.

Strach bierze się ze złej jakości. Narasta gdy brak zaufania do kodu, wiary w stojący za nim pomysł, w kompetencje autorów. Na chybcika sklecona szopa może się rozsypać od byle podmuchu. Na łapu-capu sklejone oprogramowanie rozleci się od byle zmiany - czy to w samym kodzie, czy w kontekście jego wykorzystania, czy nawet środowiska wdrożenia. Lepiej nie ruszać!