kutzowsky / blabprezent Goto Github PK

Może się zdarzyć, że ktoś poda komendę z dwukropkiem, wtedy bot jej nie rozpozna.

dodaj: Anna Maria Smutna 22-111 Ma twarz

Nic specjalnego, ale można dodać wywalanie go albo w ogóle usuwanie znaków specjalnych z komendy.

Może jakiś ORM zamiast zahardkodzonych SQLek w jednej klasie?
https://ponyorm.com wygląda bardzo ładnie. Chyba baza danych SQLite potrafi się zbudować w locie na podstawie klas modelu - można pominąć dumpy, czy władanie bazy żywcem do repo.

Pomyśleć, czy nie przyspieszyć całej akcji, żeby ludzie dostawali książki przed świętami.
Może też wydłużyć czas na wszystko (był taki głos w ankiecie z 2019, w 2018 trochę wszystko było skrócone, bo w 2017 jakieś rozlazłe).

Co i jak, gdy chce się pomóc i coś dopisać, bo ja wiem, ale inni już niekoniecznie. Rozbudować readme
Wspomnieć o:

• git flow i do której gałęzi robić PR,
• TDD,
• nie wiem, czym jeszcze.

Ustalić plus minus cenę prezentu - żeby były jakieś wyrównane, bo potem mogą być dziwne sytuacje albo niektórzy ludzie głupio się czują, że dali "za tani" prezent w stosunku tego, co dostali.

Może zorganizować ankietę przed i wybrać jakąś sensowną wartość?

Chyba lepiej by było mieć wszystko w jednym miejscu i przenieść się ze stroną z instrukcjami dla userów na gh pages.

Przerobić message handlera tak, żeby przyjmował tryb działania jako parametr, który będzie wcześniej pobierany z pliku konfiguracyjnego.

Jak mi się zachce, to zrealizować jedną z 3 opcji:

• przepisać to na Pythona 3,
• dodać do tego, co jest obsługę Pythona 3 (2 z obsługą 3),
• przepisać na 3 z obsługą 2.

2 i 3 chyba się od siebie trochę różnią. Skłaniam się ku 3.

Fajnie by było przed ogarnąć dobrze testy i Travisa (#3)

Bot mógłby linkować do wpisów danej osoby na tagu #biblioteczka po wydaniu odpowiedniej komendy.

• zastanowić się jaka to mogłaby być komenda,
• pomyśleć nad implementacją - programowe przeszukiwanie taga jest równie upierdliwe co ręcznie - jakiś cache w lokalnej bazie? jak często go odświeżać?

Gdy np. ktoś wpiszę "Dodaj" bot już nie zrozumie.

Przykład w kodzie tutaj:
https://github.com/kucyk/BlabPrezent/blob/master/commandhandlers/addinghandler.py#L16

Dość istotne, bo na urządzeniach mobilnych domyślnie autokorekta podpowiada pierwszy wyraz zdania wielką literą. Przejrzeć inne komendy.

TravisCI się skomercjalizował i trzeba się prosić o darmowe kredyty na open source albo płacić. Po co się w to bawić, jak są darmowe alternatywy, które umieją więcej.

Testy BDD z użyciem behave. https://behave.readthedocs.io/en/stable/

Testy wszystkich scenariuszy logiki biznesowej z użyciem samego "core" prawie bez integracji z niczym zewnętrznym, czyli wywoływanie metod na instancji messagehandlera a później badanie odpowiedzi i zawartości bazy danych.
Na ten moment, plik z bazą można kopiować gdzieś tymczasowo i przywracać pustą bazę po teście.

Wymaga: #35 żeby móc też testować tryb zbierania potwierdzeń.

Bot łyka jak pelikan potwierdzenia od wszystkich i jeszcze im za to dziękuje.
To chyba regresja, bo kiedyś działało prawidłowo, ale nie mam pewności.

Gdy wysyłający zapomni potwierdzić wysyłkę i zrobi to po tym, jak odbierający ją odebrał, to odbierający dostanie powiadomienie już po fakcie.
Fix: sprawdzać przy powiadomieniu o wysyłce, czy czasem prezent nie został już odebrany i jeśli tak, to nie powiadamiać.

Link do śledzenia przesyłki podawany przy potwierdzeniu wysłania.

Do przemyślenia, czy obowiązkowy, czy jako opcja.

Był taki pomysł na ficzer żeby po tym jak ktoś potwierdzi wysłanie/otrzymanie prezentu, druga strona (odpowiednio obdarowywany i obdarywowu... ten drugi... dający prezent) miała informację w postaci wiadomości prywatnej, że ma oczekiwać na przesyłkę/przesyłka szczęśliwie dotarła.

Do rozważenia jak to zrobić, bo to zmieniałoby obecną logikę w stopniu dość znacznym.

• Wydzielenie bibliotek pomocniczych do osobnego katalogu,
• Testy do osobnego katalogu.
  - [ ] Podział na katalogi "tematyczne" związane z poszczególnymi fazami loterii: zbieranie chętnych, losowanie itd (?),

Jakaś komenda pozwalająca na podgląd danych w celu weryfikacji i czy w ogóle taki user jest w bazie.
Raczej ma sens tylko w fazie zbierania danych teleadresowych, bo docelowo statusy wysłania i odebrania będą szły zarówno do nadawcy jak i odbiorcy (patrz: #5).

Opcja, jeśli ktoś preferuje audiobooka - dopisać do regulaminu przykład.

Przy dodawaniu określanie typu prezentu np. przez dopisek do maila.

Komenda wysyłająca jeszcze raz dane wylosowanej osoby.

Feedback z ankiety po.

Gdy minie ustalony czas, bot może spamować wiadomościami z pytaniem, czy już się wysłało/odebrało przesyłkę. Upierdliwo-wkurzające, ale nie chce mi się robić co roku za księgowego.

Luźne przemyślenia jak zrobić różne rzeczy lepiej.

• dump sql bazy zamiast pliku binarnego w repo,
• jakieś repozytorium/repozytoria do bazy zamiast jednego datamanagera na wszystko,
• tryb bota (zbieranie danych/zbieranie powiadomień) do konfiguracji,
• wysyłanie komunikatów kto komu wysyła prezent do bota zamiast osobnego skryptu (który jest jego kopią niemalże),
• ścieżka pliku loga do konfiguracji,
• przejrzeć poziomy logowania,
• logować niepoprawne komendy od userów do osobnego pliku żeby szybko namierzać ludzi, którzy nie rozumieją instrukcji,
• wiadomości jako obiekty z treścią i adresatem, a nie jako stringi

Skrypt bashowy?
Ansible notebook przygotowujący maszynkę?
Kontener Dockera?
Wszystko powyższe?

To plus config supervisord do repo.

WebsiteParsingBot zapisuje najnowszą wiadomość żeby przy następnym sprawdzeniu wiedzieć, które są od niej nowsze. Gdy ktoś usunie tak oznaczoną wiadomość, bot będzie sprawdzał do 10 strony w historii aż nie wywali się wyjątkiem, który trafi do logów.
W praktyce trwa to dość długo i objaw jest taki, że się "zatkało".

Miejsce w kodzie:

Opakować wszystkie polecenia w jedno wspólne z różnymi parametrami. Będzie milej, prościej i przyjemniej. Pamiętać o zaktualizowaniu readme/instrukcji potem.

1. Zbierać od userów numery telefonów w celu podawania ich kurierom.
2. Pobierać przy potwierdzeniu wysłania numer przesyłki i/lub realizującego przesyłkę i/lub link jej śledzenia.

Zastanowić się nad tym jak to sensownie i bezpiecznie przechowywać oraz walidować,

Trzeba wymusić inną wersję protokołu - inaczej nie połączy się z serwerem XMPP.

[..]
import ssl

[...]

class Bot(ClientXMPP):
    def __init__(self, bot_configuration):
        [...]

        self.ssl_version = ssl.PROTOCOL_SSLv23

Miło by było mieć Travisa żeby budował, testował na różnych wersjach pajtona i odpalał testy.
Ze względu na to ostatnie, to chyba dobrze jest zrobić, gdy testy dorobią się katalogu (#2).

Żeby Travis sobie radził, to trzeba najpierw wygenerować requirements.txt.

Budować kontener Dockera jakoś. Kiedyś.

Przydałoby się jakieś readme co ten projekt robi, jak go używać, jakie ma wymagania itd. Obecne jest mocno robocze.

Dodać plik z licencją projektu.

Playbook do automatycznego przygotowania maszyny.

Przykładowy config supervisord do repo.

Jeśli jest dodaj, to mogłoby być usuń, gdyby jednak ktoś się rozmyślił przed losowaniem.
Po losowaniu i w fazie zbierania potwierdzeń wysłania/odebrania powinna być (tak jak dodaj) zablokowana.

Chyba dobrze by było zdefiniować kilka synonimów dla komend np. często się zdarza, że ktoś pisze "odebrano" zamiast komendy "otrzymano". Wysłano ma już synonim dla wersji bez polskich znaków.