Czasami czekanie dłużej poprawia doświadczenie użytkownika.

Można by długo rozważać dlaczego i w jakich kontekstach, ale największe tl;dr to "gdy coś się dzieje natychmiastowo, wydaje się proste" - co w przypadku np. zabezpieczeń może zmniejszać zaufanie do produktu.

Ale cóż, to czy i jakie opóźnienie dodać łatwiej sprawdzać w produkcji - dlatego idealnie powinna być to konfigurowalna funkcja.

Jeszcze tego nie zbadałem, ale warto by było naprawić :V

Currently cherrydoor-hardware has a ping command, however - it's not giving back door status.
Ideally there would be a status command used instead of ping to both confirm that the link is alive and pass the current status of the lock.

Obecnie najlepsze co mogę powiedzieć o samej stronie to to, że działa.

Tak jak serwer, front-end powstał na podstawie innego mojego niedokończonego i nieopublikowanego projektu który miał inne założenia, a i tak miał drobny chaos choćby jeśli chodzi o formularze. Przykładem tu może być formularz logowania wykorzystujący jako jedyny na stronie WTForms.

Serio - WTForms nie jest nigdzie indziej wykrozystywane.

JS jest drobnym chaosem, wynikającym z tego, że chciałem podzielić na pliki coś, co powinno być jednym skryptem i przez to chyba może się coś zepsuć jeśli się załaduje skrypty w złej kolejności lub nie daj boże przed załadowaniem strony.

Wykorzystuję jQuery, bootstrapa, dodatkowy styl do bootstrapa który ostatecznie niewiele zmienia, chart.js, skrypt i styl do wybierania godziny, moment.js i kilka innych rzeczy, które niekoniecznie są zupełnie potrzebne. Szczególnie chciałbym wywalić jQuery i bootstrapa, ale połowa reszty od nich zależy, więc nie mogę tego zrobić bez pełnego przepisania wszystkiego.

Myślę też nad wykrozystaniem jakiegoś frameworku typu Svelte lub Vue zamiast polegania na templateach Jinja2...

Tbh. Flask trochę przeszkadza reszcie aplikacji. Muszę obchodzić to, że serwer zupełnie blokuje wątek tworząc pełen osobny proces tylko na serial.

To znacznie komplikuje architekturę programu, i wymaga uruchomienia pełnych osobnych procesów na komunikację po serialu i na serwer.

Serial już został przekonwertowany na asyncio w c4998de, co już tworzy dobrą podstawę by serwer także zmienić tak by korzystał z asyncio.

Flask jednak to niezbyt wspiera... Na szczeście istnieje aiohttp. Jest proste, działa dobrze z asyncio (pod to powstało :V) i co ważne ma biblioteki zastępujące wszystko z czego korzystam do Flaska.

"A co z moimi wątkami!" - w zasadzie będzie lepiej.

Asyncio opiera się na event loopie, więc jest to dalej jeden wątek, tylko dobrze zarządzany. Jednak event loop ma tę wadę, że jeśli pojedyncze zadanie zajmuje zbyt długo, to blokuje całą pętlę.

Dlatego też asyncio ma nawet kilka sposobów na uruchamianie zadań w osobnym wątku. Polecanym sposobem na blokujący kod jest loop.run_in_executor korzystające z concurrent.futures. Co jest lepszym rozwiązaniem niż trzymanie procesu tylko na Flaska i nie wychodzenie z niego już specjalnie dalej poza to co biblioteki robią czasami w tle (np. pymongo).

Dodatkowo aiohttp jest we wszystkim poza najprostszymi zadaniami (szczególnie w rzeczach wymagających jakiegokolwiek I/O) znacznie szybsze od Flaska. Kilka benchmarków:

• https://klen.github.io/py-frameworks-bench/ (Flask odrobinę szybszy w serializacji otrzymanych danych do JSON, ale aiohttp jest najszybszym frameworkiem gdy potrzebne jest zebranie odpowiedzi z innego miejsca jak np. baza danych)
• https://currentsapi.services/en/blog/2019/03/27/python-microframework-benchmark/.html (aiohttp, japronto i tornado są podobne, z japronto minimalnie na czele. Flask daje ~50% wydajności tych frameworków)
• https://y.tsutsumi.io/2017/09/23/aiohttp-vs-multithreaded-flask-for-high-io-applications/ (w zastosowaniach wymagających sporej ilości I/O aiohttp deklasuje Flaska, nawet gdy ten jest uruchomiony na masie wątków).

Najlepiej wydajność podsumowuje chyba wykres z ostatniego linku:

I tak, wydajność w I/O jest ważna, bo w zasadzie aplikacja istnieje jako interfejs do bazy danych i połączenia z arduino po serialu.

Więc TL;DR - przejście na aiohttp uprości architekturę aplikacji (brak konieczności tworzenia dwóch wątkówi dwóch instancji pymongo/motor przy starcie), ułtawi interakcję webapliakcji z serialem, poprawi wydajność i da okazję do naprawienia różnych błędów popełnionych przy tworzeniu wersji na Flaska - w tym też okazję do zajęcia się #47

Jakiś rodzaj konsoli pozwalający zobaczyć logi przesyłanych wiadomości i/lub wysyłać je manualnie - ułatwi to debuggowanie i rozwój po stronie interfejsu.

Zmienienie wyglądu interfejsu użytkownika by był podobny do https://wisniowasu.pl/

Wygląda na to, że akcja od Black się zupełnie zepsuła. Dodatkowo obecna akcja do publikowania jest przekomplilkowana. Najpewniej więc napiszę je od nowa :V

It'd be simpler to manage if it connected with other services I guess. School MS365 perhaps? Or Discord? Auth0?

Jedno co cierpi na przejściu to dokumentacja w kodzie - idealnie każda metoda i klasa miała by przynajmniej krótki docstring, a w dziwniejszych miejscach kodu pojawił by się komentarz wyjaśniający powody dla których kod został w ten sposób napisany.

Idealnie powinno być 100% coverage przez pytest.
Obecnie jest 0%

Powinna istnieć opcja wklejenia/przesłania pliku CSV by masowo dodać użytkowników z interfejsu webowego

Podnoszenie uprawnień w Pythonie jest, cóż, niezbyt dobrym doświadczeniem dla użytkownika. Szczególnie gdy jest mowa o modułach instalowanych przez pip - bo wtedy trzeba instalować je dwukrotnie, w tym korzystać z bardzo niepolecanego sudo pip install, przez co trzeba śledzić i aktualizować dwie wersje programu...
Idealnie użytkownik powinien być w stanie instalować wszystko z uprawnieniami tylko do swojego folderu domowego, wykorzystując foldery ze specyfikacji XDG i systemctl --user zamiat sudo systemctl

Python ma wbudowaną bibliotekę do logowania zdarzeń z obsługą wielu poziomów logów, więc przydało by się z niej skorzystać

Idealnie pip install cherrydoor powinno wystarczyć by zainstalować wszystko co potrzeba. Później co najwyżej może być potrzebny setup np. bazy danych, czy konfiguracji.

Obecnie wygląda to jakoś tak:

├── cherrydoor
│       ├── cli
│       │       ├── __init__.py (entry point komend)
│       │       ├── install.py
│       ├── server
│       │       ├── __init__.py
│       │       ├── routes.py
│       │       ├── api.py
│       │       ├── websockets.py
│       ├── interface
│       │       ├── __init__.py
│       │       ├── serial.py
│       ├── __init__.py

Problem: to są trzy moduły umieszczone w czwartym, z których każdy na start musi ładować ten sam plik konfiguracyjny (nawet instalacja ładuje go jeśli istnieje by zachować zmiany dokonane przez użytkownika), a po rozwiązaniu #48 - które korzystają po uruchomieniu z tej samej pętli asyncio i tej samej instancji motor.

Dodatkowo sam folder cli jest trochę głupi, bo do cli w modułach python ma specjalny plik __main__.py wywoływany domyślnie przez python -m <moduł>, więc to tam powinien trafić entry point.

Chciałbym więc przynajmniej trochę spłaszczyć strukturę. Być może serial zostanie w osobnym folderze, ale cli i serwer nie powinny być oddzielone w ten sposób.

Bo obecna jest do v0.1

An android app with HCE and possibly self-registration for cards (for users with required permissions) would be really useful.

Would also be an opportunity to move UI everywhere to flutter for consistency.

Bo GraphQL>REST

Kiedy to projektowałem myślałem, że raczej używam MongoDB dość naiwnie, ale nie jest jakoś bardzo źle.
Teraz już rozumiem że w kilku miejscach obchodziłem problemy które powstały tylko dlatego że nie wiedziałem o tym, że MongoDB oferuje ich rozwiązanie.

TBH przyda się tu drobny rework i przygotowanie bazy danych - już przynajmniej stworzenie indeksów i korzystanie z agregacji zamiast wykonywania większej ilości niepotrzebnej pracy w Pythonie...

Obecnie jest to json, którym w zasadzie poza deserializacją zajmuję się manualnie.

Nie jest to zarówno idealny format jak i sposób korzystania z niego - plik jest ładowany kilkukrotnie, a do tego nie ma żadnej walidacji.

Dodatkowo brakuje obsługi zmiany konfiguracji przez argumenty w cli albo przez zmienne środowiskowe.

Idealnie więc powinienem do tego korzystać z już istniejącego rozwiązania które pozwala poprawić wszystkie te problemy - np. [confuse](https://github.com/beetbox/confuse, pconf, czypython-configuration. Najlepszym formatem do konfiguracji byłby chyba YAML, tym bardziej że jest w zasadzie supersetem JSON, więc technicznie rzecz ujmując obecna konfiguracja dalej będzie prawidłowa.