Advent of Code

Dowiedziałem się, że jest coś takiego jak Advent of Code. Czyli kalendarz adwentowy, tylko zamiast łakoci są zadania programistyczne do rozwiązania. Dwa dziennie, liczy się i fakt rozwiązania, i czas. Rozwiązywać można w dowolnym języku, weryfikacja rozwiązania jest przez podanie wyniku.

Podobno maja być z różnych dziedzin i o różnym poziomie trudności – dziś były bardzo proste. Zrobiłem w Pythonie, potem lepszą wersję, potem jedno w Perlu, jako krótki oneliner.

Jest rywalizacja globalna, ale można też tworzyć prywatne rywalizacje i porównywać się ze znajomymi. Ja bawię się z ludźmi z pracy, choć sporo z nich utrudniło sobie wyzwanie i poznaje przy okazji nowy język. Ale ja nie jestem programistą… 😉

Trochę skojarzenie z konkursami programistycznymi, którymi bawiłem się na studiach. Żeby nie było samych zalet – mimo, że każdy uczestnik ma inne dane wejściowe, to czas rozwiązania liczy się od publikacji zadania, które ma miejsce o północy w dziwnej strefie czasowej, co pewnie faworyzuje niektóre lokalizacje geograficzne. Ale nie ma to większego znaczenia w przypadku zabawy ze znajomymi.

Polecam zerknięcie – można sobie odświeżyć umiejętności programistyczne, poćwiczyć i przede wszystkim pobawić się.

SEO przy zmianie domeny bloga

To ostatni wpis nawiązujący do Blox, przynajmniej techniczny, bo być może pojawi się jeszcze jeden o tym, jak Agora ma w głębokim poważaniu wolność słowa (określając to górnolotnie) i że ważniejsze jest parę złotych.

Po przeniesieniu bloga, o którym nieco pisałem, przyszedł czas na przeniesienie pozycjonowania w Google w nowe miejsce, czyli zabawę z SEO, aby ludzie wchodząc z wyszukiwarki trafiali w nowe miejsce. Przyznaję, że motywację miałem nikłą – nie zarabiam na wejściach, bo ani nie służy on do sprzedaży produktu, ani nawet nie ma podpiętych innych, pośrednich form zarobku.

Po przeniesieniu treści postanowiłem poczekać. Zwyczajnie i po prostu, nie robiąc nic, poza daniem informacji Google, że blog jest i jak interpretować zawarte na nim dane. Zresztą akurat miałem co innego na głowie. Znaczy ograniczyłem się do wypełnienia Data HighliterWebmaster Tools. Stan taki trwał jakiś miesiąc albo dwa.

Z braku kontroli nad nagłówkami pomysł przekierowania w nowe miejsce przy pomocy kodu odpowiedzi 301 odpadł w przedbiegach, choć to najprostsza, automatyczna i zalecana – także z punktu widzenia SEO – forma przekierowania ruchu w nowe miejsce.

Trochę czasu minęło, ilość wejść na nową lokalizację była szczątkowa, choć miałem nadzieję, że Google zacznie ogarniać sytuację samodzielnie. Niestety tak się nie stało, więc postanowiłem zacząć działać, choć miałem świadomość, że to praca, która się nie automatyzuje. Pierwsze co przyszło mi do głowy, to ustawienie link canonical dla wybranych, najczęściej odwiedzanych wpisów z nową lokalizacją jako celem. I tu okazało się, że Blox przewidział sytuację i… stosowne elementy HTML znikają po dodaniu ich w edycji źródła[1].

Z braku lepszych pomysłów dodałem w najpopularniejszych wpisach namiar na nowe miejsce, poprawiłem też linki do bloga w większości miejsc, gdzie były one umieszczone i… postanowiłem jeszcze poczekać. Poczekałem kwartał, ale nie wydarzyło się nic specjalnego. Statystyki wg Webmaster Tools wyglądały na koniec kwartału następująco:

ostanie 28 dni: impr: 2250, CTR 0,84%, avg pos 33,7. 130 wizyt

Delikatnie mówiąc szału nie ma.

Postanowiłem więc podziałać inaczej. Skoro nie mogę przekierować wyszukiwarki Google, to postanowiłem przekierować przynajmniej żywych ludzi, licząc, że Google w jakiś sposób to zauważy i odpowiednio zinterpretuje. Skoro nic nie działa, to co zadziała na pewno i czego nie można zablokować? Oczywiście JavaScript. Malware korzystający z niego ma się dobrze dzięki obfuskacji, zablokować całkowicie wykorzystania JS na stornie nie bardzo można, bo masa funkcjonalności z niego korzysta. Użyłem następującej wersji przekierowania z jednej lokalizacji na drugą (dla najpopularniejszych wpisów):

<script>
window.location.replace('https://zakr.es/blog/2017/09/goodbye-yanosik/');
</script>

Oczywiście powyższy JS był tylko w odpowiadającym wpisie na starym blogu, a URL w skrypcie to URL na nowym blogu.

Zadziałało nadspodziewanie dobrze. Nadspodziewanie, bo przy wejściu na URL kategorii zawierającej wyświetlany wpis z przekierowaniem, także przekierowywało. Co gorsza przekierowywało przy wejściu na stronę główną, bo także znalazł się tam wpis z przekierowaniem. Może i więcej ruchu przez to, ale niezupełnie o to chodziło i mało to precyzyjne… Dla wpisów z głównej dokonałem więc stosownej korekty w stylu:

<script>
var stringPathName = window.location.pathname;
if (stringPathName == "/2018/02/Waze-jako-nawigacja.html") {
  window.location.replace('https://zakr.es/blog/2018/02/waze-jako-nawigacja/');
}
</script>

Poczekałem miesiąc, wyniki w statystykach były zauważalne, zacząłem więc dodawać tego typu przekierowania dla kolejnych, popularnych linków. Po dwóch miesiącach od dodania przekierowań w JS, wyniki wyglądały następująco:

28 dni: impr: 10450, CTR 4,46%, avg pos 18.8, 490 wizyt

Jak widać wzrost wszędzie. Uznałem, że jest sukces, zacząłem – dla pewności – usuwać większość treści wpisów na starym blogu. Nie było negatywnego wpływu, nastąpił nawet dalszy, równie znaczący wzrost wskaźników, choć zakładam, że wynika on po prostu z upływu czasu.

Największym zaskoczeniem jest dla mnie, że Google przy pozycjonowaniu uwzględnia JS do tego stopnia. Wiedziałem, że radzi sobie z treścią w JS i umie odczytać URLe, ale w tym przypadku wygląda, że poprawnie interpretowany jest fakt przekierowania.

Co można było zrobić lepiej lub inaczej? Całość działań można było zamknąć w mniej niż dwa miesiące, gdybym od razu wiedział co robić i działał zdecydowanie. Oczywiście lepsze efekty byłyby, gdyby zmiany dotyczyły wszystkich wpisów, ale jest to żmudna, ręczna praca, której poświęcałem kilka minut dziennie przy porannej kawie. Powyższy sposób przekierowania nie jest jedynym dostępnym w JS, miałem w planach sprawdzenie różnych, ale ten sprawdziłem jako pierwszy i zadziałał powyżej oczekiwań, więc nie testowałem innych.

Na koniec jeszcze garść cyferek. Ingerowałem ręcznie w ww. sposób w 40 wpisów. Wg Matomo nowy blog ma obecnie ok. 4-5 razy większą ilość wizyt, niż stary. Czyli ładny podział zgodnie z zasadą Pareto.

Co dalej? Dodawanie przekierowań w kolejnych wpisach i usuwanie z nich treści. Ostatecznie pewnie usuwanie przekierowanych wpisów, ale póki co nie mam na to ciśnienia.

[1] Tu zniknęła moja wątpliwość w celowość działań Blox w celu przywiązania użytkowników do swojej platformy. Przypominam: technicznie mają kontrolę nad nagłówkami i domeną – to jakby naturalne i cena za korzystanie ze współdzielonej platformy. Do tego wyłączyli parę lat temu – rzekomo tymczasowo – API. Ale jak widać dodatkowo jeszcze celowo ingerują w treść HTML.

Wrocław (Hala Stulecia)

Zupełnie na przyczepkę w trakcie urlopu, którego głównym punktem było wrocławskie zoo było w planie krótkie zwiedzanie Ogrodu Japońskiego oraz Hali Stulecia. W obu przypadkach zakończone porażką – pierwszy z obiektów nie jest dostępny do zwiedzania od końca października, choć z zewnątrz wygląda akceptowalnie. Bonusowo: całą drogę były drogowskazy, o godzinach otwarcia można się dowiedzieć dopiero po dotarciu na miejsce. Nie jest to problem, bo to raptem kilkaset metrów, a trasa ładna, ale koncepcyjnie fail.

Zwiedzanie Hali Stulecia wewnątrz było niemożliwe z powodu trwającej próby do przedstawienia. Na osłodę obejrzeliśmy z zewnątrz oraz ciekawą wystawę poświęconą Hali Stulecia. Co ciekawe, nadal widoczne są kompleksy(?) związane z niemieckim, militarnym charakterem Hali. Nie tylko na wystawie, która okres nazizmu podczas II WŚ pomija na filmie dosłownie jednym zdaniem, ale również na Wikipedii, gdzie wersja polska mówi jedynie o układzie hali i krzyżu greckim:

Układ hali jest w rzucie kolisty, oparty symetrycznie na greckim krzyżu, na którego trzech końcach znajdują się małe hale wyjściowe, a na zachodnim, skierowanym w stronę centrum miasta – dwupoziomowa owalna hala wejściowa.

Natomiast wersja angielska wspomina już o motywie Żelaznego Krzyża na sklepieniu.

Photos taken looking up at the centre of the structure without the fabric covering clearly show the Iron Cross motif.

Czy to nadinterpretacja? Niekoniecznie, bo odznaczenie to zostało ustanowione właśnie w okresie upamiętnionym powstaniem hali. Nieźle oddaje to zdjęcie linkowane przez Wikipedię:

hala stulecia wnetrze
Źródło: http://4.bp.blogspot.com/-CNG4fQkG0k8/Ue-1V0wPnbI/AAAAAAABEeI/KuXdT02PUCQ/s1600/hala+stulecia+wnetrze.jpg

Z drugiej strony ciężko zrobić sklepienie z ośmioma żebrami, które nie będzie się – przy minimalnym wysiłku – z krzyżem kojarzyć.

Warto o tym wiedzieć, bo ciekawie jest oglądać zdjęcia z okresu PRL z różnymi elementami zasłaniającymi sklepienie – wygląda, że wtedy również raczej doszukiwano się nawiązującej do Żelaznego Krzyża interpretacji.

Gdyby ktoś z czytelników miał wrażenie deja vu, to tak, poprzedni wpis podzieliłem na dwa.

Wrocław (zoo)

Korzystając z zalegającego urlopu oraz sprzyjającej prognozy pogody postanowiliśmy odwiedzić Wrocław. W zasadzie wypad stał pod znakiem zoo, ale nieco miasta liznęliśmy.

Coś mi się kołatało w głowie, że Wrocław to korki i słabo się po nim jeździ samochodem. Co prawda początki z Poznaniem miałem takie, że stwierdziłem, że auto w nim to nieporozumienie, więc liczyłem, że może być tylko lepiej, ale… chyba nie jest lepiej. Mimo dnia powszedniego i jazdy poza szczytem, korki gdzieniegdzie były. Kierowcy jeżdżą raczej agresywnie – kilka stłuczek plus częste klaksony. Wolę nie sprawdzać jak to wygląda w godzinach szczytu. Na szczęście tramwaje jeżdżą często i nie trzeba się przejmować biletami – wszystkie tramwaje, którymi jechaliśmy mają kasowniki zintegrowane z czytnikiem kart płatniczych, czyli nie trzeba kupować żadnej karty PEKA czy biletów, można płacić bezpośrednio. Bilety są na przejazd i czasowe.

Na zwiedzanie wrocławskiego zoo warto sobie zaplanować cały dzień.  Teren nie jest tak rozległy, jak w Poznaniu, ale atrakcji jest wiele. Chodziliśmy ile sił starczyło, czyli od 10:00 do 15:30. Pogoda też dopisała – niby listopad, ale warunki raczej jak we wrześniu – i w miarę ciepło, i trochę słońca. Dodatkowo poza sezonem we wrocławskim zoo było raczej niewielu ludzi, co oznacza spokój i dobry dostęp do wszystkiego. Znaczy idealnie.

Afrikarium wypadło bardzo dobrze. Co prawda spotkałem się z opiniami, że przereklamowane, ale IMO robi robotę. I to nawet nie sam tunel, ale już same szyby umożliwiające zajrzenie pod wodę są rewelacyjne. Zaskoczyła mnie głębokość zbiorników – do tej pory spotkałem się z podglądem powiedzmy 1-1,5 metra od lustra wody, natomiast tu szyby znajdują się znacznie głębiej – stawiałbym na ok. 3 metry. Efekt jest rewelacyjny, zarówno jeśli chodzi o ryby, jak i inne zwierzęta – kotiki i manaty też wyglądają ciekawie. W ogóle jeśli chodzi o „foki”, to oglądanie ich tylko z góry, jak w poznańskim zoo jest w porównaniu zwyczajnie słabe. I ponownie podkreślę, że brak tłumu przy szybach zdecydowanie poprawia efekt i odbiór, więc warto tę część zoo zwiedzać poza sezonem lub w odpowiednich, mało tłocznych godzinach. Przykładowy pingwin:

pingwin we wrocławskim zoopingwin we wrocławskim zoo
Źródło: fot. własna

Jeszcze jedna rzecz – karmienie zwierząt. Samodzielnie zwierząt nie można karmić (wyjątkiem są pawiany i automat z odpowiednią karmą), natomiast są podane godziny podawania posiłków. Harmonogram był napięty, więc generalnie odpuściliśmy, albo – jak w przypadku rekinów – nie trafiliśmy, bo karmienie nie jest codziennie, natomiast byliśmy na karmieniu kotików i… bardzo je polecam. Spodziewałem się co prawda jakiejś interakcji, natomiast to co zobaczyłem to był praktycznie cyrkowy pokaz.

Nieuchronnie pojawia się pytanie czemu zoo ma służyć. Z jednej strony rozrywka dla zwiedzających, z drugiej strony jest to miejsce, gdzie zwierzęta po prostu żyją. Niektóre bez szans na inną egzystencję, bo w środowisku naturalnym gatunek przestaje występować. We wrocławskim zoo aspekt ten jest podkreślany przez wszechobecne tablice dotyczące stanu zagrożenia gatunku i powodu wymierania. Jeśli chodzi o rozrywkę dla zwiedzających, wrocławskie zoo wygrywa zdecydowanie, jeśli zaś chodzi o warunki dla zwierząt, wydaje mi się, że poznańskie jest lepsze. Po prostu zwierzęta mają więcej przestrzeni.

gnu we wrocławskim zoo
Źródło: fot. własna

Szczególnie dotyczy to starej części wrocławskiego zoo. W pamięci utkwił mi pawilon szympansów, z grubymi kratami. Jeden z szympansów darł się rozdzierająco i kiwał w przód i tył, następnie urządził bieg przez różne klatki, trzaskając kratami (są otwierane). Skojarzenia z więzieniem lub raczej szpitalem psychiatrycznym pogłębiała wystawa prac szympansów w postaci rysunków. Zdaję sobie sprawę, że zamysł wystawy był pewnie inny, a ja mogę źle interpretować zachowanie szympansów. Zdecydowanie lepiej jednak oglądało się zwierzęta pływające w przestronnych basenach czy na dużych wybiegach.

Z innych rzeczy – udało się zaliczyć wyspy na Ostrowie Tumskim wieczorową porą, ładnie podświetloną katedrę i trochę rynek. Bardziej przy okazji posiłków, niż zwiedzając, ale było na co popatrzeć – gdybym miał określić jednym słowem, to Wrocław prezentuje się przyjemnie. Wydawało mi się, że Poznań się poprawił, ale po latach, architektonicznie, jako miasto Wrocław przemawia do mnie nadal znacznie bardziej. Zwiedzanie krasnali odpuściliśmy – co prawda kilka znaleźliśmy, ale bez nastawiania się na nie.

Część dotyczącą Hali Stulecia przenoszę do kolejnego wpisu. Dodałem zdjęcia robione smartfonem. Wiem, fatalnie wychodzą, ogólnie aparat to pięta achillesowa tego modelu. Raczej ze względu na RMSowy kontekst robione i dodane. 😉

Chromium w Debianie unstable nie startuje

Gdyby komuś w Debianie unstable przestało działać chromium, a przy uruchomieniu polecenia w konsoli pokazywało się coś takiego:

$ chromium 
[4278:4278:1113/085947.509811:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
#0 0x562ca49ba9ee <unknown>
#1 0x562ca492699c <unknown>
#2 0x562ca55b8f90 <unknown>
#3 0x562ca45f9365 <unknown>
#4 0x562ca45fe5ce <unknown>
#5 0x562ca45f7e5a <unknown>
#6 0x562ca2d09e95 ChromeMain
#7 0x7fbb5a4f6b17 __libc_start_main
#8 0x562ca2d09d3a _start

Received signal 6
#0 0x562ca49ba9ee <unknown>
#1 0x562ca49b9433 <unknown>
#2 0x562ca49ba965 <unknown>
#3 0x7fbb633dc8e0 <unknown>
#4 0x7fbb5a509f3b gsignal
#5 0x7fbb5a50b2f1 abort
#6 0x562ca49ba905 <unknown>
#7 0x562ca4926a76 <unknown>
#8 0x562ca55b8f90 <unknown>
#9 0x562ca45f9365 <unknown>
#10 0x562ca45fe5ce <unknown>
#11 0x562ca45f7e5a <unknown>
#12 0x562ca2d09e95 ChromeMain
#13 0x7fbb5a4f6b17 __libc_start_main
#14 0x562ca2d09d3a _start
r8: 0000000000000000 r9: 00007ffe7d2f0920 r10: 0000000000000008 r11: 0000000000000246
r12: 00007ffe7d2f0da0 r13: 00007ffe7d2f0f60 r14: 000000000000016b r15: 00007ffe7d2f0ba0
di: 0000000000000002 si: 00007ffe7d2f0920 bp: 00007ffe7d2f0b70 bx: 0000000000000006
dx: 0000000000000000 ax: 0000000000000000 cx: 00007fbb5a509f3b sp: 00007ffe7d2f0920
ip: 00007fbb5a509f3b efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.

to sprawa jest znana, błąd jest zgłoszony i wystarczy doinstalować pakiet chromium-sandbox.

Trzy lata, sześć miesięcy i dwa tygodnie

Rzadko coś mnie zadziwia do tego stopnia i wielowymiarowo, jak to, o czym dowiedziałem się dziś. Chodzi oczywiście o błąd w Google+. No dobrze, nie sam błąd mnie zadziwił, bo ten był raczej mizerny. Poszło o to, że jeśli użytkownik Google+ udostępnił jakiejś aplikacji dostęp do danych publicznych swojego konta Google+, to aplikacja miała też dostęp do danych prywatnych. Z bardziej krytycznych – w świetle choćby RODO – do adresu email, imienia, nazwiska.

Chodzi o 500 tys. użytkowników, dane nie są super wrażliwe, udostępnione tylko aplikacjom. Oczywiście błąd pozostaje błędem, ale ten w dodatku został wykryty samodzielnie, nie na skutek wycieku. Ogólnie niezły potencjał na opowieść, którą nawet jeśli nie można się pochwalić, to nie ma się co wstydzić.

I tu pojawiają się tytułowe trzy lata, sześć miesięcy i dwa tygodnie, które jeżą włos na głowie. No dobrze, nie wszystkie. Trzy lata, to czas, kiedy podatność była dostępna. Tak naprawdę, powinny być dwa i pół, ale lepiej pasowało do clikcbaitowego tytułu. W dodatku zupełnie nie ma znaczenia ile czasu podatność była obecna – prawdopodobieństwo wykrycia nie rośnie z każdym dniem.

Ciekawe są dwie kolejne wartości. Sześć miesięcy to czas, przez który Google zataiło informację o podatności, bojąc się reakcji opinii publicznej. Wykryto ją w marcu 2018, ogłoszono wczoraj. W dodatku twierdzą, że w sumie nie wiedzą, czy podatność została wykorzystana, bo logi API mają z tytułowych dwóch tygodni, a nie trzymają ich dłużej, bo szanują prywatność użytkowników. Poważnie tak uzasadnili, w informacji o wycieku, która jest niejako przy okazji. Bardzo ładne zagranie PR-owe, ale jedyny komentarz, który przychodzi mi do głowy to:

Źródło: https://imgflip.com/i/2jpigy

Prędzej uwierzyłbym, że nie mają tych logów, bo im się na dyskach nie mieściły. 😉

Nie wiem, czy tak właśnie wygląda the right thing w świecie security, ale po graczu wielkości Google spodziewałem się jednak większej transparentności.

Kolejne zaskoczenie to reakcja rynku. Czy też może właśnie brak tej reakcji. Akcje Alphabet symbolicznie spadły, szybko odrobiły. Nie stało się nic… Przynajmniej na razie, zobaczymy jeszcze jak zareagują urzędy regulujące różnej maści, ale póki co wszystko wskazuje na to, że ani prywatność, ani transparentność nie są dzisiaj w cenie.

UPDATE: Po dokładniejszym zbadaniu, 10 grudnia, Google oznajmiło, że chodzi o 52 mln użytkowników więcej. Tzn. tylu więcej podobno dotyczył bug. O logach ani słowa. 😉

Lynis – narzędzie do audytu bezpieczeństwa systemów Linux

Czasem zdarza się, że znajdę jakieś stare, fajne narzędzie, którego nie znałem wcześniej. Tak jest w przypadku Lynis – programu open source napisanego przez CISOfy służącego do audytu bezpieczeństwa systemu na podstawie bieżących ustawień. Przypadkiem, na komórce w tramwaju mignął mi wpis o nim gdzieś w sieci, opis był ciekawy, więc postanowiłem dać szansę, choć od dłuższego czasu nie interesowałem się podobnymi programami. Kiedyś, na początku przygody z Linuksem bawiłem się Bastille Linux i to w zasadzie wszystko, jeśli chodzi o automaty.

Działanie Lynis sprawdzałem tylko na Debianie i Ubuntu – działa bardzo sprawnie, generuje sensowne raporty z uwzględnieniem specyfiki dystrybucji. Przy każdym raporcie jest link do krótkiego opisu z wytłumaczeniem danej opcji. Dla początkujących jest to dobra okazja do poczytania nt. ustawień i ich wpływu na bezpieczeństwo systemu, dla zaawansowanych automat, który sprawdzi, czy czegoś nie przeoczyliśmy lub nie zapomnieliśmy włączyć np. po testach.

Program jest dostępny jako pakiet, więc instalacja sprowadza się do:

apt-get install lynis

Uruchomienie audytu również jest proste:

lynis audit system

Polecam dodanie przełącznika -Q. Program jedynie generuje raport, niczego nie zmienia w systemie, więc uruchomienie jest bezpieczne. Wynik wyświetla na ekran oraz do logu, znajdziemy tam zarówno znalezione błędy, ostrzeżenia, jak i wskazówki do hardeningu systemu.

Narzędzie ma zastosowanie raczej dla systemów, prywatnych,  utrzymywanych ręcznie – te konfigurowane automatycznie raczej nie mają miejsca na powstanie błędu, a forma raportu jest raczej przyjazna dla ludzi, niż maszyn.

Oczywiście przy domyślnej konfiguracji zgłosi także odstępstwa od normy, które są zamierzone albo nieistotne, więc wynik będzie nieco przegadany. Mimo to polecam wypróbowanie samodzielnie.

Jak wykręcić 500+?

Nie mogłem się powstrzymać przed clickbaitowym tytułem, ale tym razem nie będzie o państwowych dotacjach na dzieci, tylko podsumowanie sezonu rowerowego.

W maju zapowiadałem, że biorę udział w wyzwaniu Kręć kilometry. Właśnie sobie uświadomiłem, że dziś jest ostatni dzień września, a wyzwanie zostało zaliczone już jakiś czas temu. Znaczy mam taką nadzieję, bo pisze, że 100%, ale czy kilkuset metrów nie brakuje – nie mam pojęcia. W każdym razie za ostatni rok pokazuje mi 512 km, a było parę km przejechanych bez rejestracji, stąd plus w tytule.

Wyzwanie okazało się prostsze, niż myślałem. We wrześniu już prawie nie jeździłem – przejechane raptem 27 km. Przeważyły względy logistyczne – nie mogłem brać swojego roweru, a Nextbike to jednak nie to samo.

Nie ukrywam też, że mam problem z pogodą i była głównym czynnikiem powodującym, że jeździłem mniej, niż bym mógł. Nie lubię jeździć ani jak jest bardzo gorąco, ani jak jest zimno. Dlatego odpuszczałem dojazd rowerem w największe upały, wybierając śmierdzące wówczas tramwaje – smutne, ale niektórzy mają problem z higieną, a w upały się to potęguje. Z kolei wrzesień to już chłody. Ręce jeszcze nie kostnieją, ale w uszy zimno. Być może rozwiązaniem są nauszniki, jakoś nie sprawdziłem.

Natomiast największym sprzymierzeńcem był nawyk. Do pracy jeździ się całkiem miło i poza częścią urlopową i paroma dniami deszczowymi mógłbym jeździć niemal codziennie, co oznacza, że teoretycznie mógłbym celować nawet w dystans dwukrotnie dłuższy…

Skutek uboczny: zacząłem trochę biegać. Weekendowe bieganie dobrze się łączy z dojazdami do pracy rowerem w tygodniu. Taka powiedzmy synergia.

Banana Pi i ekran LCD podłączony po i2c

Dawno temu NAS został wyłączony, ale zmierzam do jego reaktywacji. Po głowie chodziło mi zamknięcie wszystkiego (zasilacz, dysk, Banana Pi) w zgrabnej, tym razem dedykowanej do elektroniki, obudowie.

Trochę z myślą o programie do przełączania łącza internetowego, a trochę o pomiarze temperatury przy pomocy komputera, przyszedł mi pomysł, by sygnalizować stan różnych rzeczy w sposób nie wymagający łączności sieciowej, czyli najdoskonalszy, analogowy: migając diodą. Oczywiście szybko doszedłem do wniosku, że jedna dioda nie wystarczy, wbudowane diody to trochę mało, ale przecież w Raspbery Pi i analogach mamy GPIO, możemy tych LEDów podłączyć kilka…

Nie wiem jak dokładnie doszło do tego, ale podczas poszukiwań szybko wpadłem na ekrany LCD z serii 1602, które również można podłączyć przez GPIO. Skoro tak, to pomyślałem, że nie ma się co ograniczać. Zamiast prostej sygnalizacji stanu i konieczności pamiętania która kombinacja co oznacza można po prostu wyświetlać dowolny tekst. Niezbyt długi, ale nadal jest to znacznie większa ilość informacji, niż z kilku czy nawet kilkunastu LEDów. W dodatku cena takiego jest bardzo przystępna, czego o różnych ekranach dotykowych czy e-ink powiedzieć nie można.

Pierwotnie chciałem podłączyć LCD do Orange Pi zero, ale niestety, nie ma on pinów GPIO – są wyprowadzenia, ale trzeba by lutować, co pewnie docelowo zrobię, ale bardziej chodziło mi o sprawdzenie sterowania, a mam pod ręką Banana Pi. Gdy szukałem schematu jak podłączyć ekran do Banana Pi, natknąłem się na coś znacznie ciekawszego – wersję ekranu LCD ze sterownikiem podłączanym przez interfejs i2c. Dzięki podłączenie temu jest bardzo proste – raptem cztery przewody, nawet nie trzeba lutować, o ile używa się gotowych przewodów z końcówkami. Dodatkowo – i to najlepsza część –  całością daje się w elegancki sposób sterować za pomocą Pythona.

Efekt końcowy wygląda tak:

LCD 1602
LCD 1602 Źródło: fot. własna

Zdjęcie zrobione telefonem, po ciemku. Z tyłu płytki jest potencjometr pozwalający na regulację kontrastu. Poziom podświetlenia jest stały, można tylko włączyć i wyłączyć LED, zarówno hardware’owo (zworka), jak i programowo. Ekran LCD bierze bardzo mało prądu – przy pomocy watomierza nie udało mi się zarejestrować różnicy, czyli całość zużywa poniżej 0,1 W.

Jak to zrobić? Powtórzę instrukcje, z których korzystałem. Instalujemy dodatkowe pakiety:

apt-get install i2c-tool python-smbus

Następnie podłączamy ekran i sprawdzamy adres przy pomocy polecenia:

i2cdetect -y 1

Otrzymaną wartość należy wpisać w skrypcie (stała ADDRESS, linia 29 w przytoczonym przykładzie).

Następnie możemy sterować ekranem z poziomu języka Python. Na przykład wywołanie efektu widocznego na ekranie można zrobić przy pomocy polecenia:

python test_lcd.py "Pomiedzy bitami" "https://zakr.es/"

Gdzie test_lcd.py ma zawartość:

import sys

from i2c_lcd import *

display = lcd()
display.lcd_display_string(sys.argv[1], 1)
display.lcd_display_string(sys.argv[2], 2)

Biblioteka pozwala na dużo więcej, między innymi na własne znaki, ale tym się póki co nie bawiłem. Wyświetlony tekst pozostaje na ekranie po zakończeniu programu do momentu wpisania nowego lub skasowania poprzedniego. Jeśli do ekranu będzie dostarczone napięcie, to wyłączenie Banana Pi nie wpływa na wyświetlany tekst. Dlatego jeśli chcemy monitorować, czy nasz komputer się nie zawiesił, musimy zmieniać okresowo tekst – w innym wypadku zawartość LCD nie świadczy o niezawieszeniu się komputera.

Sterowanie włączaniem i wyłączaniem podświetlania to:

display.backlight_on(False)
display.backlight_on(True)

Wyświetlać można cokolwiek – temperaturę, zajętość dysku, opóźnienia/straty na sieci, kurs BTC (pozdro dla L.!), adres IP (po starcie!), informacje o nowych mailach…

Pozostało mi wymyślenie, w jaki sposób zrobić sensowne sterowanie. Po głowie chodzi mi demon, który będzie pobierał informacje do wyświetlenia z jakiejś kolejki, w zależności od ich priorytetu, czasu ostatniego wyświetlenia i pory dnia sterował oświetleniem i wyświetlał informacje. A może już jest coś takiego?

I garść linków pomocnych przy tworzeniu ww. rozwiązania AKA źródła:

  1. pinout Banana Pi
  2. LCD i2c dla Raspberry Pi
  3. Banana Pi i urządzenia i2c
  4. Skrypt w Pythonie
  5. Biblioteka Python do obsługi ekranów LCD po i2c

UPDATE Dla zainteresowanych kupnem – ekran z modułem do komunikacji i2c kosztuje ok. 12 zł na Allegro. Na zdjęciu jest wersja zielona, ale istnieją też wersje niebieskie, gdzie tło jest ciemne, a napisy jasne.

Polecenie su – zmiany

Jakiś czas temu zauważyłem, że mój Debian unstable na domowym desktopie zmienił zachowanie. Na koncie root przestał działać skrypt do aktualizacji systemu i usypianie.

Szybko sprawdziłem i oczywiście chodziło o PATH. Dopisałem pełne ścieżki do poleceń i prawie zapomniałem o sprawie, przypuszczając, że chodzi o jakiś chwilowy błąd w którymś z pakietów.

Jednak problem nie zniknął, więc postanowiłem sprawdzić dokładnie, co się wydarzyło. Na pierwszy ogień poszło sprawdzenie /etc/profile, w którym znalazłem spodziewane:

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"

Również w /etc/login.defs wszystko wyglądało poprawnie:

# *REQUIRED* The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Skończyły mi się pomysły, więc udałem się na kanał #debian-next z pytaniem, czy to błąd, czy może były ostatnio jakieś zmiany. I okazuje się, że zmiany były, grubsze, dotyczące polecenia su.

Uprzednio, wydanie „gołego” polecenia su zmieniało użytkownika na root oraz ustawiało należną mu ścieżkę. Obecnie należy podawać su – (forma niezalecana) lub, lepiej, su -l, aby osiągnąć ten efekt.

I jeszcze co ciekawsze fragmenty dokumentacji (man su). Było:

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the
superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.
[...]
-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.

Aktualnie jest:

For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME
if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing envi-
ronments.
[...]
-, -l, --login
Start the shell as a login shell with an environment similar to a real login:
o clears all the environment variables except TERM
o initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH
o changes to the target user's home directory
o sets argv[0] of the shell to '-' in order to make the shell a login shell

Więc gdyby komuś w jakiejś debianopodobnej dystrybucji niebawem su przestało ustawiać PATH, to najprawdopodobniej chodzi o tę zmianę.

Szybkość polskich stron internetowych cz. 2

Opisywany w poprzednim wpisie nt. badania szybkości polskich stron internetowych system trochę okrzepł, skończył się miesiąc, więc pora na konkrety. Co prawda listę badanych serwisów było widać na zrzucie ekranu, ale nie było dostępu do danych , więc teraz to naprawiam.

Zdecydowałem, że nie będę się bawił w wyciąganie średnich miesięcznych itp.  Jeśli ktoś jest zaintersowany, to w historii są linki do danych źródłowych (CSV), można sobie wyciągnąć samodzielnie. O ile ktoś będzie potrzebował, bo to, co domyślnie daje GTmetrix, z ładną wizualizacją, jest IMO w zupełności wystarczające.

Tak więc badanie wywoływane jest dla 10 wybranych serwisów (najpopularniejsze polskie oraz ecommerce, przy czym znaczenie miała domena) co 12h,  wykonywane z Londynu, przy pomocy Chrome, bez AdBlocka i na nielimitowanym paśmie.

Oto serwisy, po kliknięciu linka dostęp do wszelkich zebranych danych:

Jest jeszcze pomysł na uruchomienie testów za pośrednictwem innego serwisu, ale pozostaje to w sferze pomysłów, póki co bez planów na implementację.

UPDATE: Pomysł wyglądał fajnie, ale tylko przez miesiąc. Po pierwsze, okazało się, że dostępne są dane tylko z miesiąca, mimo obiecujących wartości „1y” i „all” w historii. Po drugie, skrypt wymaga poprawki – przez parę dni dane się nie zbierały, potem samoistnie zaczęły. Pewnie do poprawy obsługa wyjątków plus dodanie wysłania powiadomienia, choć założenie, że mógłbym coś zrobić i że by mi się chciało jest mocno optymistyczne. Po trzecie i najważniejsze, zmieniły się linki do raportów, powyższe już nie działają, co oznacza, że nawet wersja miesięczna jest średnio używalna dla kogokolwiek poza mną. Pomyślę jak to wszystko rozwiązać, pewnie skończy się na powrocie do oryginalnego pomysłu i zbierania danych samodzielnie.

Pomiar szybkości polskich stron internetowych

Podczas pewnej dyskusji nt. kondycji stron internetowych powołane zostało jako argument badanie szybkości stron internetowych robione przez firmę Hostersi. Jest to ciekawe badanie, prowadzone od lat ale… ma wady.

Pomiarów niby jest dużo, ale są one przeprowadzane przy pomocy autorskiego narzędzia uruchamianego ad hoc, przez tydzień, samo badanie publikowane raz na rok. Wszystko to powoduje, że wyniki trudno jest weryfikować samodzielnie, a jakaś zmiana na stronie obecna w danym tygodniu, czy chwilowe problemy wydajnościowe serwisu mogą zaburzać wyniki dla całego roku. Co widać nawet w raporcie po niektórych dziwnych danych.

Dla jasności – szanuję wykonaną pracę, ale gdyby to zależało ode mnie, wolałbym mieć dane częściej, choć może rzadziej zbierane. I tak narodził się pomysł, żeby zbierać i publikować w miarę na bieżąco dane dotyczące szybkości działania polskich stron internetowych samodzielnie, hobbystycznie, w sposób umożliwiający każdemu chętnemu samodzielną weryfikację wyników pomiarów.

Stawianie własnej infrastruktury oczywiście odpadło w przedbiegach. Zbyt zasobochłonne, zarówno jeśli chodzi o koszt, jak i o samą czasochłonność utrzymania. Poza tym, odpadnie możliwość peer review. Jednak serwis GTmetrix daje ciekawe możliwości badania szybkości ładowania stron i daje API, postanowiłem z niego skorzystać, co sprowadza pracę do napisania prostych skryptów w Pythonie. Dodatkowo pozwala dzielić się zebranymi danymi przy pomocy udostępniania unikatowych URLi.

Niestety, w wersji darmowej można robić tylko 20 zapytań po API dziennie, co wymusiło ograniczenie się do jednej lokalizacji (Londyn, jako najbliższy Polsce), jednej przeglądarki (Chrome bez AdBlocka), okrojenia liczby badanych serwisów do 10 (wybrane na podstawie raportu Hostersi z najpopularniejszych i ecommerce) i wykonywania dla każdego 2 testów dziennie. Wybrałem okolice godziny 8 rano oraz 20. Z doświadczenia o 8 jest już jakiś – choć niewielki – ruch w sieci, a 20 to szczyt. Wyniki planuję publikować co miesiąc, jako średnie wartości z danego miesiąca.

Badane strony w GTmetrix

Póki co, uruchomiłem skrypt, który przy pomocy crona robi „taktowanie”, czyli zleca uruchomienie testów. Dane zbierają się od paru dni. Pomyślę jeszcze, czy zamieszczać jakieś statystyki co miesiąc, czy po prostu ograniczyć się do zbierania. Raczej stanie na tym drugim… Stay tuned!

Zmiany w czasie

W odpowiedzi na inicjatywę obywateli Komisja Europejska przeprowadza ankietę dotyczącą ew. zmian w zmianach czasu z letniego na zimowy. W skrócie – każdy obywatel UE może się wypowiedzieć, czy woli obecny model, czy pozostanie przez cały rok przy jednym czasie. A jeśli pozostanie przy jednym, to przy którym. Zachęcam do głosowania – ankieta trwa do 16. sierpnia.

Źródło: https://pixabay.com/en/business-time-clock-clocks-257911/

Nie jest to pierwsza próba jakiejś tam reformy, zupełnie niedawno czytałem wpis, który niechcący przybliżył mi ideę Swatch Internet Time. Temu projektowi nie wróżę akurat sukcesu z powodu przywiązania do firmy, ale niesie on jeszcze jedną zaletę – likwidację stref czasowych. Oznacza to, że podanie czasu wg SIT jest jednoznaczne dla całego świata; czy to Tokio, Nowy Jork, czy Warszawa @833 oznacza ten sam moment.

Osobiście wolałbym po prostu jeden czas na całym świecie, ale w formie tradycyjnej. Pewnie UTC. Czemu? Prostota, odpada przeliczanie, a coraz więcej wydarzeń ma charakter globalny. Notowania akcji, transmisje na żywo wydarzeń kulturalnych i sportowych. Wydaje mi się, że strefy miały sens, gdy większość wydarzeń była lokalna, ograniczona powiedzmy do jednego kraju, a to się nieco zmieniło.

Tak czy inaczej, uważam rezygnację ze zmiany czasu za krok w dobrym kierunku.

UPDATE: Są wyniki. 84% ludzi, którzy wzięli udział, opowiedziało się za zniesieniem zmiany czasu. Szczegóły tutaj.