Miesiąc: styczeń 2022

Opublikowane w

Jak robić lepsze spotkania w Google Calendar?

Przeczytałem wpis o tym, jak telekonferencje zmieniają nasz sposób pracy. I jak jestem zdania, że praca zdalna niesie wiele korzyści, tak gdybym miał wskazywać wady, to ryzyko utraty przerw od komputera wskazałbym jako jedną z głównych. Można je zminimalizować planując skrócone spotkania.

W stacjonarnym modelu pracy okazji na oderwanie się od komputera jest wiele. Wyjście po kawę potrafi skończyć się krótką rozmową w kuchni, spotkania także są przerwą od pracy na komputerze. Przynajmniej dla większości uczestników i przez większość czasu. Czasem któraś osoba obecna na spotkaniu notuje na komputerze, albo ktoś musi sięgnąć po dane.

Dla przypomnienia: zgodnie z prawem pracy, pracownikowi przysługuje 5 minut przerwy od pracy na komputerze na każdą godzinę pracy. Nie musi być to przerwa od pracy w ogóle, ale przy pracy zdalnej raczej tak będzie, bo albo pracujemy na komputerze, albo jesteśmy na spotkaniu… na komputerze. O ile będziemy w stanie zrobić przerwę, a nie będziemy właśnie kończyć jedno spotkanie i zaczynać kolejne. Domyślnie bowiem Google Calendar ustawia koniec i początek spotkań co równe 30 minut.

Jak ustawić skrócone spotkania w Google Calendar?

Na szczęście można to zmienić. Google Calendar posiada bowiem wbudowaną opcję, która umożliwia domyślne ustawianie krótszych spotkań. Krótszych, czyli spotkań nie kończących się o pełnej godzinie.

W wersji angielskiej Google Calendar krótsze spotkania ustawimy poprzez
Settings -> Event settings -> Speedy meetings

Natomiast w polskiej wersji Kalendarza Google będzie to
Ustawienia -> Ustawienia wydarzeń -> Szybkie spotkania

Następnie możemy wybrać łączny czas trwania spotkań w trakcie każdej godziny.

Wady rozwiązania

Rozwiązanie nie jest idealne. Po pierwsze, mamy w ten sposób wpływ tylko na spotkania organizowane przez siebie, nie wszystkie, w których uczestniczymy. Przydałaby się choćby sugestia, że zapraszane osoby korzystają z trybu skróconych spotkań.

Kolejna wada to brak możliwości wybrania 55 minut spotkań, czyli wartości odpowiadającej wprost prawu pracy, w ciągu godziny. Dostępne są jedynie predefiniowane wartości. Najbliższa polskiemu prawu pracy jest wartość 50 minut. Daje ona co prawda więcej, bo 10 minut wolnego od spotkań na godzinę, ale nie jest to duża różnica. Dodatkowo świetnie sprawdza się przy spotkaniach półgodzinnych.

Osobiście za największą wadę uważam brak możliwości wyboru, czy spotkanie powinno być skracane z dołu, czy z góry. System przewiduje tylko wcześniejsze kończenie spotkań. Tymczasem bardziej naturalne wydaje się ustawienie późniejszego ich rozpoczęcia.

Opublikowane w

Co w 433 MHz piszczy?

Wpis na blogu o termometrach zewnętrznych przypomniał mi o pewnym zakupie, który jakiś czas temu poczyniłem. Chodzi o termometr bezprzewodowy z Jula. Nieco spontaniczny zakup, by mieć pretekst do zabawy urządzeniami pracującymi w paśmie 433 MHz. Z drugiej strony nawet gdyby nie udało się dobrać do danych z komputera, to jakaś tam potrzeba poznania temperatury w różnych miejscach w mieszkaniu była.

Do zabawy nie doszło, nie pamiętam dlaczego. Z tego co pamiętam chciałem pójść bardziej w stronę dedykowanego odbiornika (i transmitera…) 433 MHz, nie SDR. I trochę utknąłem na zakupie, a w zasadzie na zastanawianiu się nad podłączeniem tego – lub czegoś podobnego – do zwykłego komputera, najchętniej przez USB.

rtl_433

W każdym razie wpis zwrócił moją uwagę na program rtl_433 i możliwość odczytu danych przez SDR. Wersja docelowa to może nie będzie, w rozmowie ze znajomymi z pracy mieliśmy nieco obawy co do jakości sygnału, ale skoro tak łatwo dostępne, to warto spróbować. Okazało się, że pakiet rtl-433, który jest dostępny w Debianie SID, mam już zainstalowany. Zupełnie nie przypominam sobie, bym go używał, ale może to z czasów kiedy instalowałem wszelki soft do SDR?

Uruchomiłem i… to działa, po prostu, od kopa. Okazało się, że termometr z Jula, który kupiłem, jest wspierany. Okazało się także, że podobny czujnik jest gdzieś w okolicy. Najciekawsze zaś jest, że wykrytych zostało sporo innych czujników. Z których wiele udostępnia nie tylko dane o temperaturze, ale także o wilgotności.

Ilość widocznych czujników naprawdę mnie zaskoczyła. Z fabryczną, biedną anteną ustawioną w losowym miejscu na biurku SDR widzi kilka. W tym – sądząc po nazwach – trochę czujników temperatury i ciśnienia powietrza z samochodów.

Zastosowanie

W oparciu o Raspberry Pi lub podobną płytkę można łatwo można zrobić sobie własną stację pogodową, z dowolną ilością czujników. Wariant udostępniający dane po WWW jest trywialny i zapewne w tę stronę pójdę. Nic nie stoi jednak na przeszkodzie by dołożyć wyświetlacz i na nim prezentować dane, tworząc odpowiednik prawdziwej stacji.

Dodatkowo opisywane rozwiązanie daje możliwość skorzystania z danych z cudzych czujników. Mój czujnik zdalny jest w innym pomieszczeniu, niż stacja. Trochę miałem dylemat, czy nie umieścić go za oknem. Ale skoro sąsiad ma na zewnątrz, to ja już nie potrzebuję… Tracimy co prawda kontrolę nad umiejscowieniem czujnika, który może np. znajdować się w nasłonecznionym miejscu, ale darowanemu koniowi w zęby się nie zagląda.

Rozglądam się teraz i myślę jaki termometr bezprzewodowy kupić. Póki co znalazłem ładny moduł do stacji pogodowej za 34 zł, kuszą jednak inne moduły do stacji pogodowych, które zapewniają pomiar wilgotności. Co prawda nie mam pewności czy będą obsługiwane przez rtl_433, ale zakładam, że tak. Ewentualnie można dopisać ich obsługę.

Opublikowane w

Noworoczne porządki

Postanowień noworocznych brak, ale zmiana roku na 2022 to dobry moment na porządki informatyczne z jednej strony, a na ich zapowiedź – w roli motywatora – z drugiej.

PUM

Zaczęło się od informacji na IRCu, że PUM przestał działać[1]. Przyczyną okazała się cicha zmiana API przez Uptime Robot. API v2 to większe zmiany, niż sądziłem – część danych przekazywana jest teraz w payload w POST, pojawił się limit zapytań w czasie, lekkie zmiany formatu danych. Nie wiem, czy pierwsza wersja umiała zwracać dane w JSON, v2 potrafi. Rzut oka na Perla i wiedziałem, że raczej do przepisania na Pythona[2], przy okazji parę zmian i… trochę utknąłem. Mam „większą połowę” zrobioną, obecnie jestem rozdarty między chęcią zachowania dokładnej starej funkcjonalności, a napisaniem tego bardziej elegancko. W ogóle trochę uderza mnie oglądana z perspektywy zwięzłość Perla.

Zrobiłem. Nie jestem w 100% zadowolony, ale pum.pl is dead, long live pum.py!

Nextbike

Monitoring ilości rowerów Nextbike na stacjach zacząłem w roku 2013. W roku 2017 skrypt został przepisany na zgrabniejszego Pythona. O ile na początku zaglądałem regularnie, to obecnie praktycznie nie korzystam. Powód jest prosty: rzadko kiedy korzystam z rowerów na stacjach. Odkąd pojawiły się rowery z odbiornikiem GPS, niemal zawsze w praktyce biorę rower „z ulicy”, nie ze stacji. I tak go zostawiam. Po prostu niemal zawsze bliżej mam jakiś rower luzem. No i rzadko moja trasa kończy się na stacji Nextbike.

Co się udało w tym projekciku? Całkiem sporo: działał i był użyteczny, przynajmniej dla mnie, przynajmniej przez pewien czas. Pozwoliły poćwiczyć Pythona i zapoznałem się w praktyce z jinja2. Nauczyłem się, ile (nie)warte są „darmowe” domeny (tu: .tk).

Co się nie udało? Liczyłem, że stanie się popularniejszy. Nie udał się eksperyment z automatycznym SEO. Liczyłem, że dobrze otagowane strony z konkretnymi informacjami trafią wysoko w pozycje w wyszukiwarce Google. Nie było całkiem źle, ale gorzej, niż liczyłem, biorąc pod uwagę otagowanie metadanymi. Chęć zachowania maksymalnej prostoty i automatyzacji spowodowały, że nie dodawałem dodatkowej treści, mogącej pozytywnie wpłynąć na pozycjonowanie.

Wkrótce projekt przestanie istnieć – skrypt zostanie wyłączony i zapewne trafi na GH.

Hosting

Szykuje się zmiana platformy, na której utrzymuję hosting. VPS w Aruba Cloud podrożał jakiś czas temu i od tamtego czasu rozglądałem się niespiesznie za czymś innym. W zasadzie decyzja już zapadła i była pierwsza próba, niestety, weryfikacja kart w nowym miejscu jest lekko przesadzona. Ma szansę być szybciej, bo znacznie większe zasoby, ma szansę być wesoło, bo szykuje się przesiadka na architekturę ARM. Nie rozwijam tematu, bo zapewne zasłuży na osobny wpis.

Tyle z większych planowanych zmian. Od dawna wisi temat lekko przestarzałego softu do tworzenia Planety Joggera, ale na razie się nie pali – póki co system posiada jeszcze wsparcie.

[1] Tak, jest pomysł na drobną modyfikację we wszystkich skryptach tak, by przy błędzie wykonana powiadamiały np. mailem. Bo nie jest to pierwszy raz, kiedy o padzie czegoś z powodu zmian po stronie źródła dowiaduję się po długim czasie. Inna sprawa, że to nic krytycznego.
[2] Nazwa zostanie bo Perl Uptime Monitor -> Python Uptime Monitor.