Boty są złe

Od pewnego czasu obserwuję social media i dochodzę do wniosku, że boty są złe. Przynajmniej w social mediach. Przynajmniej niektóre.

Pisząc o botach mam na myśli rozwiązania, które cyklicznie biorą aktualny stan, zamieszczają go w formie wpisu w social mediach. Klasycznym przykładem jest aktualna pogoda czy też jej prognoza w danym mieście. Ale może to być też zużycie energii w jakimś kraju. Pomijam – przynajmniej na razie, przynajmniej w tym wpisie – boty, które informują jednorazowo o pewnych wydarzeniach, jak np. zamieszczenie wpisu na blogu.

Dlaczego to jest złe? Powodów jest kilka. Po pierwsze, zamieszczane w ten sposób dane tylko pozornie są aktualne. Być może nawet będą aktualne w momencie zamieszczania, ale to wymaga od użytkownika (bardziej: obserwatora) obserwacji non-stop. Czyli karmią FOMO. Jeśli użytkownik zajrzy na nie po jakimś czasie od zamieszczenia, dane będą nieaktualne. Lepiej by uczynił, sprawdzając je u źródła.

Po drugie, tylko pozornie tworzona jest historia. Owszem, jest to jakiś zapis, który jakoś można sprawdzić, ale… jest to skrajnie nieefektywne w porównaniu z dedykowanymi sposobami prezentacji zmian w czasie. Takim jak np. wykres. Czy dostarczania danych źródłowych, takimi jak np. plik CSV. Szczególnie prawdziwe dla większych częstotliwości zamieszczania danych.

Nieeleganckie odpytywanie i przetwarzanie przez cały czas, niezależnie od rzeczywistej potrzeby, zamiast na żądanie – czyli generowanie zbędnego ruchu – to już detal. Wspominam o tym tylko ze względów porządkowych.

Ostatecznie doszedłem do wniosku, że dane dostarczane przez boty informacje tylko zaśmiecają timeline. Przy okazji zużywając energię na przekładanie nieaktualnych danych z miejsca na miejsce.

Sprawdziłem obserwowane konta prowadzone przez boty na Mastodonie (którego aktulanie głównie używam jako platformy social media) i wśród obserwowanych 205 kont mam:
https://pl.fedimeteo.com/szczecin
https://pl.fedimeteo.com/poznan
https://fedi.stfn.pl/@energetykapolska
Czy też raczej: miałem. Dodatkowo wyciszyłem https://mastodon.social/@icm_meteo bo pojawiało mi się na timeline z powodu obserwowanych przeze mnie tagów. Jeśli dobrze liczę, razem daje to 26 zbędnych wiadomości dziennie mniej.

Piszę to z perspektywy czasu, bo kiedyś idea botów wydawała mi się fajna. Obserwowałem boty pogodowe, zużycia energii. Nawet zdarzyło mi się dołożyć cegiełkę. Tylko dotarło do mnie, że to niepotrzebne. Less is more.

LinkedOut

Konto na portalu LinkedIn założyłem dawno temu. Miało być trochę takim CV online, trochę miejscem gdzie można „pokazać się” i dać się znaleźć pracodawcom. Szybko okazało się, że nie do końca to działa i głównie zbieram ludzi, z którymi zetknąłem się zawodowo. I znajomych, których znam niekoniecznie zawodowo, ale też uczelnie itp. Wszytko niby zgodnie z założeniem, bo edukacja, umiejętności, doświadczenie zawodowe, ba, nawet to CV online/historia zatrudnienia coś tam pokazuje. Czy też może raczej pokazywałoby, gdybym tylko przyłożył się do uzupełniania.

Ciekawe oferty pracy? No powiedzmy, że coś tam było, ale takich naprawdę ciekawych i dopasowanych – mało. Szczególnie przez pryzmat lat. Faza, gdy zdecydowałem się przejść do rozmowy rekrutacyjnej – może kilka razy w historii. No ale też nie miałem parcia na to. Więc powiedzmy, że w kwestii zawodowej LinkedIn jako tako daje radę. W kwestii socjalnej (choć nie taka wg mnie jest rola) było dość przewidywalnie i nudno. Chwalenie się osiągnięciami, zmianą pracy, szkoleniami, rocznicami. Not great, not terrible.

I jakiś czas temu to wszystko zaczęło się zmieniać. Niekoniecznie na lepsze. Zaczęło pojawiać się więcej treści zbliżonych do Facebooka. Nie czysto zawodowych, niekoniecznie prawdziwych, obliczonych na zaangażowanie. To, co kiedyś było na FB na grupach tematycznych, albo po prostu na FB, zaczęło się pojawiać na LinkedIn. Narzekania na usługi firm, promowanie własnych usług przy pomocy wymyślonych historii i czego nauczyło mnie to o prowadzeniu biznesu. Rzyg.

Tyle jeśli chodzi o użytkowników i ich podejście, ale sam portal nie pozostaje w tyle. Pojawiły się jakieś mało sensowne gry w które rzekomo grają znajomi z firmy (przy czym każdy pyta, kto gra, bo on nie). Obliczone oczywiście na wywołanie zaangażowania i otwarcie aplikacji. Która, po otwarciu, już coś podsunie. Czy to więcej powiadomień o postach znajomych, czy po prostu treściach, które są trending.

Wiele sensownych organizacji z mojej bańki (niekoniecznie firm, choć firmy także) używa teraz combo w postaci Discord plus LinkedIn jako podstawowego sposobu informowania o organizowanych wydarzeniach. Nie jest to dla mnie niezrozumiały wybór, bo edukacyjnie/zawodowo czy nawet hobbystycznie ma sens. Ma też sens ze względu na nakład pracy z utrzymaniem – LinkedIn czy Discord oznaczają niewielki narzut. Zarówno po stronie zamieszczających, jak i odbiorców. Choć nie wiem, na ile pewne jest informowanie poprzez LinkedIn – algorytm może ukryć, a wiara, że ludzie korzystają może być zbyt optymistyczna. Istnieje co prawda ryzyko konieczności płatności lub odcięcia kanału, ale… mało prawdopodobne (odcięcie) i zapewne akceptowalne (płatności). No i teoretycznie wygodne dla użytkowników, bo zwykle mają już te platformy. Dla pozostałych jest – czy raczej: bywa – RSS lub lista mailowa.

Złapałem się na tym, że większość nieinteresujących powiadomień na telefonie pochodzi z serwisu LinkedIn[1]. Szczególnie irytujące były te o grach. Myślałem o wyłączeniu powiadomień zupełnie, jednak skoro portal stał się jednocześnie trochę feedem o eventach, to nie chciałem tego tracić. Pewnie FOMO, bo tak naprawdę o eventach i tak dowiaduję się z innych źródeł. Postanowiłem sprawdzić, czy mogę wyłączyć tylko powiadomienia push z LinkedIn dotyczące gier. Okazało się, że tak. Przy okazji zobaczyłem, że ustawienia dotyczące powiadomień w aplikacji są bardzo rozbudowane i granularne.

Wyłączyłem te o grach i… nie pomogło. Tzn. pomogło częściowo. Te o grach przestały przychodzić, ale nadal za większość powiadomień odpowiada LinkedIn. Zacząłem grzebać w ustawieniach i wyłączać kolejne rzeczy. Na pierwszy ogień poszły powiadomienia push. I znowu – niezbyt to pomogło. Mimo wyłączenia powiadomień push w większości kategorii, nadal przychodzą. Kolejnym krokiem jest wyłączenie powiadomień pochodzących z aplikacji. Stopniowo to robię – staram się, by każde nietrafione powiadomienie skutkowało wyłączeniem kolejnego w ustawieniach. Nie wykluczam, że wkrótce wyłączę powiadomienia z LinkedIn na telefonie zupełnie, czyli 2026 może być u mnie rokiem bez LinkedIn (na telefonie).

Tymczasem wpadłem na pomysł, jaki system powiadomień byłby rozsądny. Po prostu każda aplikacja powinna mieć obowiązek udostępniania maksymalnej liczby powiadomień w ciągu dnia/tygodnia. Oczywiście powiadomienia transakcyjne, potwierdzanie logowania i alerty bezpieczeństwa wyłączone z limitu. I wtedy określalibyśmy, że drogi serwisie, możesz mi wysłać w ciągu tygodnia 5 powiadomień, kombinuj, by były jak najbardziej wartościowe. Co by to dało? Totalną zmianę pozycji. Serwis musiałby dobierać interesujące treści, agregować treści. Użytkownik nie mógłby być bombardowany nadmierną ilością powiadomień.

Można to zaimplementować oczywiście inaczej, na poziomie systemu. Tyle, że wtedy jest ryzyko pominięcia powiadomień transakcyjnych itp. Jednak nie każda appka takie posiada, więc coś takiego też bym chętnie zobaczył. Pewne możliwości ustawień powiadomień już istnieją w systemie Android. Zacznę od uruchomienia historii powiadomień… (Settings -> Notifications -> Notification history).

UPDATE: Dobrzy ludzie podpowiedzieli, że nie trzeba włączać historii powiadomień. Wystarczy wejść w Settings -> Apps i dla każdej aplikacji można sprawdzić, ile powiadomień wysłała. Twarde dane potwierdzają, że appka LinkedIn jest u mnie w ścisłej czołówce. I to w porównaniu z appkami, których aktywnie używam i chcę z nich powiadomienia. W dodatku po częściowym wyłączeniu powiadomień…

[1] Swoją drogą, jeśli appka LinkedIn jest u mnie najbardziej agresywną, to czuję, że i tak mam mało powiadomień. Ale tak, nie mam np. FB na telefonie.

GitHub backup

Od dłuższego czasu poruszany jest w różnych miejscach temat niezależności technologicznej od firm z… innych obszarów prawnych, że tak to ujmę. W szczególności chodzi o firmy spoza Europy. Jest też – nieco niezależny, choć w praktyce często zbieżny – temat uniezależnienia się do wielkich korporacji. Bo jakoś tak się złożyło, że wielkie korporacje nie są europejskie.

Przyznaję, że kibicuję obu tematom. I o ile nie czuję, że muszę koniecznie już teraz przenieść wszystkie zabawki do Europy, to… chcę mieć w razie czego taką możliwość. Pomału się rozglądam, wykonuję pewne drobne – póki co – ruchy. W szczególności jeśli z jakiegoś powodu rezygnuję z jakiejś usługi, to szukam alternatywy w Europie.

Tyle kontekstu, ale przecież miało być o backupie GitHub. Jak powszechnie wiadomo, jest to usługa Microsoftu, czyli podlegająca prawu USA. I w dodatku należąca do jednej z największych korporacji na świecie. Znaczy mogą zrobić z kodem co chcą, w tym… zniknąć go. Zamknąć dowolne konto. Usunąć dowolne repozytorium (i wszystkie jego forki). Bo tak.

Zapewne się to nie wydarzy, jeśli chodzi o moje repozytoria ale… Nie wiadomo. Bo już różne rzeczy były z GitHub usuwane. Więc ktoś kiedyś może wpaść na pomysł, że np. bruteforce PESELi to groźne narzędzie i trzeba repozytorium – albo i całe konto – usunąć. Wolę więc mieć możliwość przywrócenia swojego kodu z backupu. Backup serwerów i tak robię, wiele własnego kodu nie mam. Więc zrobienie kopii repozytoriów do katalogu, który jest objęty backupem wygląda jak proste, lekkie rozwiązanie.

Jeśli chodzi o ewentualne zastępstwo dla GitHuba, wybrałem popularną alternatywę w postaci europejskiego Codeberg.org[1]. Na którym i tak założyłem już wcześniej konto z uwagi na pewien pull request, który chciałem zrobić.

Repozytoriów trochę mam, są one publiczne, więc postanowiłem zautomatyzować robienie backupu, żeby nie musieć pamiętać o dodaniu każdego nowego repozytorium do skryptu robiącego backup. Po prostu robię backup wszystkich publicznych repozytoriów należących do danego użytkownika GitHub. Oczywista konsekwencja – i wada rozwiązania – jest taka, że jeśli zrobię fork jakiegoś większego projektu, to także on trafi do backupu. Jednak nie jest to częsta sytuacja, a nawet te większe projekty nie są aż tak duże, żeby mi to przeszkadzało.

Skrypt github-backup jest – jak widać – bardzo prosty. Wymaga zewnętrznego programu git i tylko jednej biblioteki – requests. Zasada działania skryptu github-backup jest prosta. Przechodzimy do katalogu ze skryptem. Podajemy usera jako parametr. W katalogu, w którym jest uruchamiany skrypt, najpierw tworzony jest katalog o takiej nazwie, jak nazwa użytkownika[2]. Następnie pobierana jest lista publicznych repozytoriów użytkownika. A w końcu dla każdego z nich tworzona jest kopia przy pomocy zewnętrznego polecenia git clone –mirror. I tyle. Tak utworzone kopie można przywrócić na innym serwerze przy pomocy git push –mirror. Przykład w readme.

Skrypt ma wady, których nie potrzebowałem poprawiać. Po pierwsze, robi mirror do bieżącej lokalizacji. Nie jest to problem przy planowanym użyciu, czyli z użyciem cron – po prostu wcześniej trzeba zmienić katalog. Po drugie, nie obsługuje prywatnych repozytoriów. Cóż, trochę nie miałem takiej potrzeby. Poza tym, o ile dodanie klucza, który ma do nich dostęp w trybie odczyt nie jest problemem, to nad listowaniem musiałbym się zastanowić[3]. Może kiedyś, bo jak wspomniałem, obecnie nie mam takiej potrzeby.

Plany rozwoju skryptu? Dodanie obsługi innych platform przydało by się najbardziej, bo żaden dostawca ani jurysdykcja nie dają gwarancji, że konto czy repozytorium nie zniknie. Przy czym pewnie w najbliższej przyszłości skończy się na Codeberg, bo tylko tego aktualnie używam i będę miał jak przetestować. Może jednak dodanie obsługi prywatnych repozytoriów?

W każdym razie jeśli rozwiązanie komuś się przyda, to zachęcam do używania. I oczywiście robienia backupów, w tym przypadku własnego kodu. Niezależnie od metody.

UPDATE: To naprawdę prosty skrypt i główną zaletą jest brak potrzeby jakiegokolwiek uwierzytelniania, jeśli ktoś potrzebuje więcej, to istnieje np. ghorg.

[1] Ogólnie jest to serwis godny rozważenia, choć community o wiele mniejsze.
[2] Uwaga, najpierw jest usuwana cała zawartość katalogu o takiej nazwie, jeśli istnieje!
[3] No dobra, sprawdziłem, wystarczy dodać obsługę PAT (personal access token) i stosownie skonfigurować ich uprawnienia.