Jak to każdy wie i (oby!) pamięta, zmiana oznacza konieczność automatycznych testów regresyjnych, bo inaczej do kodu mogą automatycznie wprowadzić się błędy. A że mój testowy blog na Textpattern ma włączone automatyczne aktualizacje, moja poprawka ręczna po aktualizacji Textpattern zniknęła. Polskie literki z tego bloga też zniknęły. Dobrze, że produkcyjny blog nie aktualizuje się automatycznie… No cóż. Trzeba ponownie zlokalizować miejsce poprawki i zobaczyć, czy wystarczy wykonać ponownie identyczną zmianę w pliku txplib_db.php. Otóż nie wystarczy, bo kod wygląda już inaczej. Ale da się wykonać podobną operację, a łatkę zamieszczam poniżej.

257,270c257
<         if ($this->charset) {
<             mysqli_query($this->link, "SET NAMES ".$this->charset);
<             $this->table_options['charset'] = $this->charset;
< 
<             if (isset($txpcfg['table_collation'])) {
<                 $this->table_options['collate'] = $txpcfg['table_collation'];
<             } else {
<                 if ($this->charset == 'utf8mb4') {
<                     $this->table_options['collate'] = "utf8mb4_unicode_ci";
<                 } elseif ($this->charset == 'utf8') {
<                     $this->table_options['collate'] = "utf8_general_ci";
<                 }
<             }
<         }
---
> 	// removed for MariaDB installation 

Produkcyjny blog pozostawiam na razie bez zmian, na podniesienie wersji o jedną setną numeru i jej załatanie szkoda mi całej minuty roboty…

Tę instancję Textpattern instalowałem z “gotowca” z Installatron – skoro można, to po co kombinować? Tylko że jeśli najnowszej wersji aplikacji Installatron dalej nie ma, to nic się nie zaktualizuje. No ale że wreszcie się doczekałem – backup, update, próbujemy.

Natychmiast nastąpiła rozsypka. Wszystkie polskie litery diabli wzięli. Niby kodowanie UTF8 jest, ale zamiast literek mamy krzaki. Nie będę się bawić w ręczne poprawianie wszystkich znaków we wszystkich artykułach, więc trzeba poszukać informacji o podobnych problemach. Dodanie w .htaccess linii

AddDefaultCharset utf-8 

nie pomogło, ale przy okazji przeszukiwania Sieci znalazłem coś ciekawego. Otóż podobno trzeba w aplikacji poprawić plik textpattern\lib\txplib_db.php i wyciąć z niego kilka linii. Tylko których? Chwila dłubania – bo przecież podane numery linii raczej nie będą identyczne w pliku z nowszej wersji, więc trzeba się zorientować, co trzeba wyciąć – i już wiem: do wycięcia jest sprawdzenie, czy nie używamy czasem pewnych wersji bazy danych, z którymi są problemy. Tylko że kod sprawdzający wersję MySQL (w wymaganiach oficjalnych Textpattern widzimy “MySQL 5.0.3+ (version 5.5+ recommended)”) narobi nam bigosu, kiedy Textpattern uruchomimy na MariaDB 10 (u mnie: 10.3.22-MariaDB-cll-lve). Potrzebna jest zatem łatka (diff) na plik txplib_db.php robiąca coś takiego:

256,266c256,257
<         // Be backwards compatible.
<         if ($this->charset && (version_compare($version, '5') >= 0 || preg_match('#^4\.[1-9]#', $version))) {
<             mysqli_query($this->link, "SET NAMES ".$this->charset);
<             $this->table_options['charset'] = $this->charset;
< 
<             if ($this->charset == 'utf8mb4') {
<                 $this->table_options['collate'] = "utf8mb4_unicode_ci";
<             } elseif ($this->charset == 'utf8') {
<                 $this->table_options['collate'] = "utf8_general_ci";
<             }
<         }
---
>         // Be backwards compatible. 
> 	// (removed DB feature detection that doesn't work with my MariaDB 10) 

Łatka pasuje do Textpattern 4.8.1 – robimy update aplikacji, po czym łatamy i wgrywamy poprawiony plik txplib_db.php (oraz pamiętamy, że diagnostyka Textpattern będzie marudzić na tę ręczną zmianę). A po tym: jeśli temat sitemap załatwiało nam rozszerzenie rah_sitemap w tak starej wersji jak 1.3.0, to należałoby zdecydować, czy teraz zrobić mapę witryny ręcznie, w ogóle bez rozszerzenia (a podobno już się tak da), czy po prostu uaktualnić rozszerzenie. Wolałem uaktualnić, ściągnąłem bieżącą wersję rah_sitemap i wgrałem, całość “gra i buczy”. Można już z powrotem skupić się na pisaniu!

Nie mieszkając w okolicy, która byłaby w zasięgu radia DAB+, inaczej musiałem zaplanować automatyczne – i w ogóle jakiekolwiek – nagrywanie. Może i strumień sieciowy nie jest stuprocentowo pewnym źródłem sygnału, ale dla większości komputerowców będzie to dobry wybór. Przynajmniej jeśli jesteśmy podłączeni do Sieci kablem, dostęp mamy przez okrągłą dobę, no i tak samo przez okrągłą dobę może pracować nagrywający audycje komputer. Dodatkowy warunek: wiatraczki tego komputera nie będą przepędzać lokatorów.

Do nagrywania warto zaprząc program VLC (a jeszcze lepiej – system Linux, a na nim konsolową wersję powyższego, czyli cvlc), jednak pod Windows możemy tu napotkać bardzo poważny problem. Bynajmniej nie ten, że komputer musi być włączony, ktoś musi być zalogowany, trzeba uważać, żeby okienka VLC nie zamknąć ani nie kliknąć… Jeśli z komputera (albo do niego) łączymy się gdzieś przez VPN, to nic nie nagramy z sieciowego radia. Nie da się i koniec. Właściwie musimy mieć osobną maszynę. Ale że, jak mówią Anglicy, two is nice…

W domu bezczynnie walało się parę części, więc kupiłem nettopa (Zotac Zbox ZBOX-BI322-E), pamięć i dysk SSD M.2 po prostu wyjąłem z szafy, dokupiłem obudowę 2,5” z adapterem dla dysku SATA M.2, poskładałem to, Xubuntu na tym dysku już wcześniej miałem, no i… System działa. Trzeba więc doinstalować VLC, po czym zająć się skryptami, które wszystko za nas będą robić.

W dużym skrócie (i w wersji “przede wszystkim niech działa”) wygląda to tak: w wybranym katalogu umieszczamy skrypt o nazwie np. “nagrywaj” o zawartości:

#!/bin/bash
nazwanagrania="/home/user/Dokumenty/rec/$2_"`date +%F`-`date +%H`-`date +%M`".mp3"
/usr/bin/cvlc http://adres.strumienia:port/ :sout=#duplicate{dst=file{dst=${nazwanagrania}}} :no-sout-rtp-sap :no-sout-standard-sap :ttl=1 :sout-keep --run-time=$1 vlc://quit 

a potem (ustawiwszy skryptowi prawo wykonywania) wołamy

crontab -e

i na zadaną godzinę (jeśli trzeba podpowiedzi, jak tu się godzinę zadania w harmonogramie ustawia, proponuję stronę crontab.guru) dodajemy linijkę z wywołaniem naszego skryptu o zadanej godzinie

3 6 * * 5 DISPLAY=127.0.0.1:0 /bin/bash -c "/home/user/Dokumenty/rec/nagrywaj 10800 mann"

co dla strumienia z radiową Trójką da nam nagrywanie piątkowej porannej audycji Wojciecha Manna.

A właściwie dałoby, bo audycji “Zapraszamy do Trójki” już nie prowadzi Mann…

Właśnie przyszła mi do głowy kolejna warta uwiecznienia myśl, więc siadam do pisania. Coś na ten temat już raz wymyślałem i mi umknęło – dobrze byłoby, żeby nie stało się tak ponownie.

Czasem wymyśla się takie sztuczki, na przykład kiedy trzeba sobie opracować jakąś prowizorkę. Tym razem będzie to skrypt w języku Ruby. Różnych już rzeczy potrzebowałem – na przykład pracując ze starą wersją Ruby, której nie mam możliwości uaktualnić, musiałem czasem wpisywać do pliku Gemfile pożądane wersje używanych gemów, o czym może jeszcze kiedyś napiszę. No ale tym razem było na odwrót. Programik mój przetwarza dane z pewnej strony www (dokładniej: robi z linków na tej stronie kanał RSS, bo twórcy strony jeszcze nie odkryli tej technologii), co nagle przestało działać, kiedy na portalu zainstalowano certyfikat SSL i uruchomiono przekierowanie na HTTPS.

Opis problemu łatwo znaleźć – wystarczy spytać Google o “Ruby open-uri redirect forbidden”. Gem open-uri jest poprawiony dopiero w Ruby 2.4, a ja mam 2.2. I co? I kiedy nie można wybiec w przyszłość, trzeba zdobyć łatę – gem open_uri_redirections (bo to funkcja w gemie open-uri miała problem). Wykonujemy zatem w konsoli polecenie

gem install open_uri_redirections

a w programie dopisujemy linię

require 'open_uri_redirections'

Teraz możemy już poprawić niedziałające (właśnie o HTTPS się “wywalały”) wywołania funkcji open(), czyli zamiast np.

doc = Nokogiri::HTML(open(url)) 

piszemy

doc = Nokogiri::HTML(open(url, :allow_redirections => :all))  

i próbujemy ponownie. I co? I kolejny błąd:

D:/MagicalMe/Ruby200/lib/ruby/2.2.0/net/http.rb:923:in `connect': SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError)

Co teraz? Należy dokończyć konfigurację, czyli pobrać potrzebne certyfikaty i pokazać je programom. Ściągamy sobie zatem plik cacert.pem (przysiągłbym, że już kiedyś ten plik ściągałem i do czegoś wykorzystywałem, co jednak nie zaowocowało notatką), a miejsce, gdzie go nagraliśmy, wstawiamy do zmiennej środowiskowej. Może lepiej nie prostym poleceniem

set SSL_CERT_FILE=c:\MagicalMe\Downloads\cacert.pem

wpisanym w konsoli, tylko w jakiś bardziej trwały sposób. Jeszcze tylko przejrzeć poprawiany skrypt, bo może gdzieś w nim są adresy HTTP, które warto od razu zmienić na HTTPS, no i… działa! A już myślałem, żeby wykombinować mały serwerek z Ruby 2.4 specjalnie dla mojego prowizorycznego skryptu…

Firmowy tablet Samsung GT-P3100 (Galaxy Tab2 7.0) pewnego dnia odmówił posługi. Normalnie po podłączeniu ładowarki pojawia się na chwilę charakterystyczna animacja na ekranie, potem ekran gaśnie i tablet się ładuje. Kiedy tym razem zaczął tę animację włączać i wyłączać, a nie ładował się przy tym wcale… Google twierdzi, że ten model ma tak często i że trzeba na chwilę odłączyć zasilanie płyty głównej od baterii. I że aby to zrobić, należy sobie rozpruć tablet. Perspektywą tej operacji nie byłem zachwycony. Nowe plecki? No ale ruszyłem głową i… Skoro tablet nie ma już energii, żeby po wciśnięciu wyłącznika “wstać”, a sam wyłącznik do zadziałania potrzebuje energii, to może potrzymać parę minut ten wyłącznik? Chwila prawdy… Potem znów ładowarka i… działa! Prawidłowo zaczął ładowanie, naładował się, działa. Wniosek? Nie rozładowywać nigdy do zera. I przy byle problemie nie szukać od razu otwieracza do konserw.