Przejdź do głównej zawartości

Hello, Mr. Developer


Po dłuższej robocie z innymi rzeczami trafił mi się jeden mały projekt, który idealnie nadał się na rozpoznanie bojem, co tam nowego panie w światku bibliotek narzędziowych/ramówek do robienia aplikacji sieciowych - proste REST API z jednym zasobem w kilku perspektywach. Pierwsza myśl była "robiłem to meeelion razy, w jeden dzień będzie z pokryciem 100%". Ale zaraz zorientowałem się, że to dobra okazja, żeby przy okazji rozejrzeć się, czy czasem coś nowego nie pojawiło się na arenie w ciągu tych 3 czy 4 lat, kiedy tłukłem w standardzie Flask + SQLAlchemy, do porzygu. Pamiętam przecież, jak ze 3 lata temu co chwilę pojawiały się jakieś zajawki, że tu jakiś framework osiągnął niesamowite wyniki w benchmarkach, a to jakiś przełomowy koncept miał na zawsze odmienić sposób w jaki robi się webaplikacje w Pythonie, a to to, a to tamto. Poprosiłem więc o chwilę ekstra na zastanowienie się i wyruszyłem wraz z Google na poszukiwanie króla dżungli.

Jest źle, a nawet bardzo źle.

Asynchroniczna smuta

Ostatnie 3 czy 4 lata to okres asynchronicznej rewolucji w Pythonie, więc spodziewałem się znaleźć przynajmniej jeden w miarę dojrzały projekt - poza Twisted, które było dojrzałe już 10 lat temu, po 5 latach rozwoju (15 lat, to jest dopiero szokujące!). Nic z tych rzeczy, niestety, pomimo że prace nad implementacją referencyjną ASGI, asynchronicznym następcą WSGI, trwają już prawie 3 lata i są prowadzone w ramach bardzo stabilnej organizacji (Django), a sama implementacja doczekała się już wersji 2, z małym okładem. Oczywiście jest Tornado (8 lat rozwoju to też piękny wynik, pogratulować), ale szukałem czegoś "mniej", raczej w stylu Werkzeug niż Flask. No i "wartość dodana" Tornado względem Twisted wynosi dla mnie niemal zero. Ramówka aplikacyjna która zdaje się mieć najlepsze perspektywy i na moje oko wygląda najlepiej (Starlette) wciąż jest w stanie "alpha", przecież nie postawię na tym produkcyjnej aplikacji, choćby była nie wiadomo jak mała. Nie wnikałem zanadto w przyczyny tego smutnego stanu rzeczy, ale wydaje mi się, że duży kawał asynchronicznego tortu zeżarło NodeJS, a Python został mocno w tyle na starcie.

WSGI, trochę lepiej ale też bez szału

W światku bardziej tradycyjnym, czyli WSGI czas się jakby zatrzymał. Są duże ramówki (Django, Pyramid), są małe ramówki (Flask, CherryPy), są biblioteki narzędziowe (Werkzeug, WebOb) - wszystkie one są stabilne jak skała i ugruntowane jak Stonehenge, a jedynie Flask ma mniej niż 10 lat rozwoju za sobą. Co między innymi wiąże się z tym, że w pewnym okresie mojej kariery z prawie każdym już miałem do czynienia. Może pojawiło się coś nowego, coś świeżego, jakieś nowe spojrzenie? Niby jest Falcon, też nie młodzieniaszek (5 lat rozwoju), a jednak wciąż brakuje mu wielu rzeczy. Na pierwszy rzut oka wydawał się idealnym rozwiązaniem (dopasowany do domeny, mało zależności, minimalny zestaw składników, zero funkcji których bym nie użył), więc zdecydowałem się poświęcić mu trochę więcej czasu. Szybko okazało się, że wygoda użytkowania i powszechne zwyczaje nie jest tym, czym autorzy Falcona zdają się przejmować, np. zazwyczaj odpowiedź zwraca się z funkcji obsługującej żądanie, a tu modyfikuje się przekazany obiekt. Czasem też trzeba zejść poziom niżej, do warstwy WSGI żeby mieć jakąś funkcjonalność. A czasem po prostu nie ma, np. obsługi danych kodowanych w application/x-www-form-urlencoded czy multipart/form-data, i trzeba sobie radzić przy użyciu młotka i przecinaka. Nawet jakbym chciał tam cokolwiek poprawić i przyłożyć się do rozwoju projektu, to mój światopogląd mi na to nie pozwala, ponieważ w projekcie obowiązuje CoC z którym się nie zgadzam, a licencja projektu nie zezwala mi na wycofanie mojego wkładu.

Badum-tss

Konkluzja? Niejednoznaczna. Jak trzeba coś zrobić, to jest czym. Jak ktoś chce spróbować czegoś nowego, to za bardzo nie ma czego. Ostatecznie aplikację zrobię w Falconie - i mam nadzieję że nie będę tego żałował.

Komentarze

Popularne posty z tego bloga

Programowanie ESP8266 w C/C++

ESP8266 powoli ustępuje miejsca swojemu następcy ESP32, ale jest to proces wyjątkowo powolny. Może to ceny tak samych chipów jak i płytek developerskich to powodują (niewiele jest gotowych modułów w cenie poniżej $10 z przesyłką), a może rozbudowany ekosystem bibliotek do ESP8266. W każdym razie ze starszym bratem ESP32 jeszcze długo będziemy mieć do czynienia, zwłaszcza że jest to wciąż jedna z najlepszych opcji jeżeli chodzi o mikrokontrolery.

ESP8266 można programować w Lua lub w Pythonie, jednak najlepszym wyjściem jest zaprogramowanie własnego firmware w C++ lub w C - daje to największą kontrolę i zapewnia najlepszą wydajność. Jakie mamy do tego możliwości? Od najłatwiejszej do najbardziej skomplikowanej.
ESP8266 core dla Arduino Link: Github

To jest najprostsze rozwiązanie, implementacja ramówki Wiring dla ESP8266. Jakkolwiek można tę obsługę zainstalować w Arduino IDE, to nie ma to większego sensu, bo nie da się tego edytora używać do niczego poważniejszego. Pisze się to w nor…

RetroPie, bo mi się dziecko alienowało

Dziecko moje najdroższe alienowało mi się siedząc przed komputerem w swoim pokoju. Nie żebym jej zabraniał, ale skoro ma grać, to niech gra przy nas, w salonie. Przynajmniej będziemy wiedzieli w co gra.

Wymagane hardware:

Raspberry Pi 2 Mod. B,karta SD min. 8GB,gamepad na USB,telewizor
Opcjonalne w zależności od konfiguracji:

karta WiFi na USBklawiatura na USBpendrive czy inny storage na USB Jak już to wszystko mamy, to możemy robić. Zajmie to parę godzin wszystkiego.
RetroPie Obraz RetroPie pobieramy ze strony projektu, to będzie ten którego nazwa kończy się na rpi2.img.gz. Następnie obraz ten trzeba rozpakować i nagrać w standardowy sposób na kartę SD. Wkładamy kartę do RPi, podłączamy pada do USB, bootujemy naszą zabawkę i zaczynamy konfigurowanko jak zwykle z RPi (z podłączonego klawikordu i na telewizorze, albo po ludzku, po zalogowaniu przez SSH), czyli najpierw używając skryptu raspi-config rozciągamy system plików na całą kartę, reboot, pełna aktualizacja systemu, być może reboo…

RetroPie, ROM-y z USB

Po wrzuceniu kilku ROM-ów na PSX okazało się, że karta SD z której bootuje się system jest za mała na to, żeby je tam trzymać. Inne opcje jakie przyszły mi do głowy to trzymać je na pendrive albo zamontować katalog z NAS po Sambie. W pomieszczeniu gdzie stoi telewizor WiFi działa co najwyżej jako-tako (nikt nie pomyślał o kablaturze podczas budowy...), więc na początek pójdzie 8GB pendrive. Powinno wystarczyć na parę dni.
Albo rybka, albo pipka RetroPie ma bardzo fajny ficzer automatycznego transferu ROM-ów po podłączeniu storage do USB. Jakkolwiek bardzo miłe i user friendly, to zupełnie nie będzie przydatne w momencie, gdy będziemy tam trzymać ROM-y. W końcu jak będziemy chcieli sobie coś tam wgrać, to i tak trzeba będzie wyjąć pendrive i włożyć go ponownie. Zaczynamy więc od wyłączenia tego wodotrysku, odpalamy retropie_setup.sh i na ekranie głównym wybieramy "Setup / configuration", a następnie "USB ROM Service":
i dalej "Disable USB ROM Service": Wyd…