Dawno temu pisałem o monitoringu rowerów Nextbike na stacjach. Moja strona podająca aktualną ilość rowerów miejskich na stacjach Nextbike działała do kwietnia tego roku, po czym przestała odświeżać dane. Jest to o tyle niefajne dla mnie, że appka androidowa Nextbike i jej wyszukiwanie rowerów to jakaś kpina i zdecydowanie łatwiej i szybciej znajdowałem potrzebne dane u siebie. Albo po prostu I don’t like the bugs but the bugs like me, czyli znowu mam pecha i u mnie nie działa. W ogóle o appkach na Androida, zwłaszcza polskich wypadałoby już popełnić osobny wpis…
Poczyniłem szybki debug i okazało się, że Nextbike zapytany o konkretne miasto zwraca od niedawna błędny XML, zawierający zawsze także dane dla Indii. Zgłosiłem błąd mailem, co wiązało się z zabawną sytuacją, bo po pierwsze zostałem przez centralę wzięty za pracownika (chyba raczej stażystę) firmy Nextbike i odesłany do innego pracownika, który może założyć ticket w systemie. Padło też pytanie, a skądże to ja mam namiar na ten URL (przypominam, mający official w nazwie). No cóż, URL lata w wielu miejscach w sieci…
W każdym razie błąd został zgłoszony, a dane się nie pokazywały. Próbowałem na szybko zreanimować skrypt w Perlu, ale albo zmian było więcej, albo nie do końca umiem korzystać z tej biblioteki. W każdym razie poległem, a na dłuższe grzebanie w Perlu nie miałem ochoty. Przy okazji niegdyś poukładany kod wydał mi się już nie taki fajny i w sumie można by go przepisać…
Wczoraj zrobiłem przymiarkę do napisania tego w Pythonie. Okazało się, że bez problemu jestem w stanie parsować XML. Przy okazji zrezygnowałem z pobierania danych dla każdego miasta oddzielnie – miast jest na tyle dużo, że szybciej jest pobrać plik XML raz. Skoro zapowiadało się tak fajnie, to od razu postanowiłem przerzucić konfigurację z hasha w programie do pliku YAML. A skoro szło tak fajnie, to zmieniłem „template”, zaszyty w printach w skrypcie, na Jinja2, przy okazji mając pierwszy praktyczny kontakt z tym rozwiązaniem, bo wcześniej „korzystałem” z niego tylko w template’ach dla bloga opartego o Pelican. Bardzo fajne, rozbudowane bardziej, niż przypuszczałem i jednak rządzące się swoimi prawami. W każdym razie mniej oczywiste niż mi się wydawało do tej pory.
Skoro szło tak dobrze, to dorzuciłem pięć kolejnych miast (Pszczyna, Zgierz, Kędzierzyn-Koźle, Kołobrzeg i Tychy), bo tyle pojawiło się od kwietnia. Oczywiście już nie do skryptu, tylko do prostego w utrzymaniu pliku z konfiguracją. 🙂 Całość zapakowana w virtualenv oczywiście, dla przenośności.
Ze skryptu nie jestem w 100% zadowolony – pewnie można go jeszcze uprościć, ale… może kiedy indziej, tym bardziej, że mógłbym jeszcze uzupełnić dane o geolokalizacji i pewnie gdzieniegdzie zostało błędne kodowanie znaków. Póki co, strona z ilością rowerów znowu działa. Ciekawostka – wszystkie pliki (skrypt, konfig, dane o wymaganych modułach) mają tyle samo linii co oryginalny Perl (TBH żadne nie było specjalnie sprzątane czy optymalizowane pod kątem wielkości), a jest o niebo czytelniej i prościej.
Pytanie, pokazuje ilość dostępnych rowerów uwzględniając te oznaczone jako zepsute do serwisu? Czy to samo co w apce nextbike czyli nie zwracając na to uwagi. Ostatnio na stacji były trzy rowery przy jednej stacji ale się okazało że wszystkie oznaczone jako zepsute.
Patrzę na bikes w XML, po prostu. Ale z tego co widzę sam Nextbike średnio skutecznie rozróżnia stany w tym XML – raz typ 31 wlicza się do liczby rowerów, raz nie. BTW w jaki sposób i gdzie były oznaczone jako zepsute?
„BTW w jaki sposób i gdzie były oznaczone jako zepsute?”
To się pojawia w aplikacji dopiero przy próbie wypożyczenia takiego roweru.
Dane prezentowane w tym XML-u pozostawiają też dużo do życzenia, jeżeli chodzi o ich aktualność, zwłaszcza przy obleganych stacjach. Zrobiłem ostatnio projekt, który pobiera dla Lublina dane o wszystkich stacjach i rowerach po to, aby je potem przetwarzać pod kątem lokalizacji każdego roweru. Po kilku tygodniach zbierania danych widzę, że np. w XML-u jest informacja o 3 rowerach, podczas gdy widzę tę stację z daleka i rowerów już tam nie ma, a taki stan utrzymuje się w XML czasem nawet przez kilkanaście minut. Podobnie, gdy sprawdzam sobie lokalizację roweru, którym jechałem danego dnia – dane z XML-a są opóźnione od kilku do kilkudziesięciu nawet minut.
To pewnie kwestia energooszczędności stacji (pracują w końcu wyłącznie na ogniwach słonecznych) lub po prostu duża ilość danych do przetworzenia, jednak dane o ilości dostępnych (i sprawnych) rowerów to moim zdaniem sprawa kluczowa w tego typu projektach – stacje nie są tak blisko siebie i decyzję o wyborze tej, a nie innej, podejmuje się wcześniej właśnie na podstawie dostępności rowerów.
Mhm. W takim razie prawdopodobnie korzysta z innej bazy (ktoś chętny na posniffowanie komunikacji z Androida?). Być może jest to przechowywane właśnie w stanie roweru, wtedy uwzględnianie jest trywialne, tylko… nie znam dokumentacji/opisu do stanów. Plus to o czym pisałem, czyli rozbieżności. Oczywiście mogę zliczać wprost wg stanu, bez oglądania się na liczbę rowerów, jeśli nie są w stanie tego pilnować (nie zdziwiłbym się wcale, patrząc na całokształt), tylko znowu pytanie, czy to pomoże?
Jak testowałem, a zdarza mi się widząc małą ilość rowerów na stacji sprawdzić co widać na stronie, to w Poznaniu raczej się zgadzało.